1. 13 Jun, 2017 1 commit
  2. 12 Jun, 2017 1 commit
  3. 08 Jun, 2017 1 commit
  4. 07 Jun, 2017 1 commit
  5. 06 Jun, 2017 4 commits
    • Igor Sheludko's avatar
      [parser] Introduce SharedFunctionInfo::has_shared_name(). · 9a2c18f5
      Igor Sheludko authored
      Properly propagate the fact that the function has a statically known name from
      parser to SharedFunctionInfo objects. The empty string that has been set as
      name before this CL does not help to distinguish cases like:
        var o1 = { ''(){} };
        var o1 = { [foo()](){} };
      or
        var o2 = { get ''(){} };
        var o2 = { get [foo()](){} };
      
      This is a preliminary step for using different layouts for closure objects with
      and without computed names.
      
      TBR=bmeurer@chromium.org, marja@chromium.org
      
      Bug: v8:6459
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d
      Reviewed-on: https://chromium-review.googlesource.com/522073
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45744}
      9a2c18f5
    • jgruber's avatar
      [coverage] Block coverage with support for IfStatements · b4241540
      jgruber authored
      This CL implements general infrastructure for block coverage together with
      initial support for if-statements.
      
      Coverage output can be generated in lcov format by d8 as follows:
      
      $ d8 --block-coverage --lcov=$(echo ~/simple-if.lcov) ~/simple-if.js
      $ genhtml ~/simple-if.lcov -o ~/simple-if
      $ chrome ~/simple-if/index.html
      
      A high level overview of the implementation follows:
      
      The parser now collects source ranges unconditionally for relevant AST nodes.
      Memory overhead is very low and this seemed like the cleanest and simplest
      alternative.
      
      Bytecode generation uses these ranges to allocate coverage slots and insert
      IncBlockCounter instructions (e.g. at the beginning of then- and else blocks
      for if-statements). The slot-range mapping is generated here and passed on
      through CompilationInfo, and is later accessible through the
      SharedFunctionInfo.
      
      The IncBlockCounter bytecode fetches the slot-range mapping (called
      CoverageInfo) from the shared function info and simply increments the counter.
      We don't collect native-context-specific counts as they are irrelevant to our
      use-cases.
      
      Coverage information is finally generated on-demand through Coverage::Collect.
      The only current consumer is a d8 front-end with lcov-style output, but the
      short-term goal is to expose this through the inspector protocol.
      
      BUG=v8:6000
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Review-Url: https://codereview.chromium.org/2882973002
      Cr-Commit-Position: refs/heads/master@{#45737}
      b4241540
    • Mythri's avatar
      [Interpreter] Introduce bytecodes that check for hole and throw. · c360c6a1
      Mythri authored
      Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole 
      / ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks.
      In the bytecode-graph builder they are handled by introducing a deopt point
      instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant
      bytecodes are removed since they are no longer required.
      
      
      Bug: v8:4280, v8:6383
      Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1
      Reviewed-on: https://chromium-review.googlesource.com/509613
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45720}
      c360c6a1
    • Mircea Trofin's avatar
      [wasm] Remove support for overloading async APIs. · fc3cc3bc
      Mircea Trofin authored
      This wraps up the move to explicit APIs, i.e.
      instantiateStreaming/compileStreaming.
      
      Bug: 
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Icc8280b2b3ad35acb90cc0beebe3acd7581179d7
      Reviewed-on: https://chromium-review.googlesource.com/525141
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Commit-Queue: Brad Nelson <bradnelson@chromium.org>
      Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45719}
      fc3cc3bc
  6. 22 May, 2017 1 commit
  7. 17 May, 2017 2 commits
  8. 16 May, 2017 2 commits
    • Leszek Swirski's avatar
      [ignition] Change --trace-ignition to a runtime flag · 4becbe34
      Leszek Swirski authored
      Generate the code (extra runtime calls) for --trace-ignition support at
      compile time, based on a #define (similar to TRACE_MAPS). Then check for
      --trace-ignition at run-time when deciding whether to actually print
      anything. This should make --trace-ignition less painful to use.
      
      Note that --trace-igition is disabled by default, even on debug builds.
      It has to be enabled with the gn arg "v8_enable_trace_ignition=true"
      
      As a drive-by, TRACE_MAPS is renamed to V8_TRACE_MAPS, for consistency,
      and SFI unique index (needed both by --trace-ignition and --trace-maps)
      is cleaned up to be behind another #define.
      
      Change-Id: I8dd0c62d0e6b7ee9c75541d45eb729dc03acbee9
      Reviewed-on: https://chromium-review.googlesource.com/506203
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45346}
      4becbe34
    • Ross McIlroy's avatar
      Reland: [Interpreter] Transition JSFunctions to call optimized code when possible. · 73d21080
      Ross McIlroy authored
      Now that the optimized code hangs off the feedback vector, it is possible
      to check whether a function has optimized code available every time it's
      called in the interpreter entry trampoline. If optimized code exists, the
      interpreter entry trampoline 'self-heals' the closure to point to the
      optimized code and links the closure into the optimized code list.
       
      BUG=v8:6246
      
      Change-Id: I53b095db2a75ae4824c8195faf8649d766c86118
      Reviewed-on: https://chromium-review.googlesource.com/501967Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45328}
      73d21080
  9. 10 May, 2017 3 commits
  10. 09 May, 2017 1 commit
    • Michael Achenbach's avatar
      Revert "Revert "Revert "Introducing an event loop mechanism for d8.""" · 02595c60
      Michael Achenbach authored
      This reverts commit 7dcc8eff.
      
      Reason for revert: Some flakes still (see comments) and breaks predictable testing:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20predictable/builds/11452
      
      Original change's description:
      > Revert "Revert "Introducing an event loop mechanism for d8.""
      > 
      > This reverts commit f7c25da6.
      > 
      > Reason for revert: Fixed
      > 
      > Original change's description:
      > > Revert "Introducing an event loop mechanism for d8."
      > > 
      > > This reverts commit de964dbe.
      > > 
      > > Reason for revert:
      > > https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/17958
      > > 
      > > Original change's description:
      > > > Introducing an event loop mechanism for d8.
      > > > 
      > > > This mechanism ensures APIs like wasm async complete their work, 
      > > > without requiring use of natives (%APIs).
      > > > 
      > > > The mechanism is similar to the one used in content_shell,
      > > > which should allow us to easily port tests in that environment.
      > > > 
      > > > Review-Url: https://codereview.chromium.org/2842843005
      > > > Cr-Original-Commit-Position: refs/heads/master@{#44908}
      > > > Bug: 
      > > > Change-Id: I9deee0d256a600c60b42902fc8ef8478e5546344
      > > > Reviewed-on: https://chromium-review.googlesource.com/494968
      > > > Commit-Queue: Mircea Trofin <mtrofin@google.com>
      > > > Reviewed-by: Jochen Eisinger <jochen@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#45165}
      > > 
      > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,mtrofin@google.com,jochen@chromium.org
      > > NOPRESUBMIT=true
      > > NOTREECHECKS=true
      > > NOTRY=true
      > > 
      > > Change-Id: Iafec2615d705d1990c57229cab3a988c00b5e12f
      > > Reviewed-on: https://chromium-review.googlesource.com/498630
      > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > > Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#45166}
      > 
      > TBR=bradnelson@chromium.org,machenbach@chromium.org,mtrofin@chromium.org,mtrofin@google.com,jochen@chromium.org,v8-reviews@googlegroups.com
      > NOPRESUBMIT=true
      > NOTREECHECKS=true
      > NOTRY=true
      > 
      > Change-Id: Ic3c782e918326e291a6cb9bb349c609e9a340b09
      > Reviewed-on: https://chromium-review.googlesource.com/498430
      > Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
      > Commit-Queue: Mircea Trofin <mtrofin@google.com>
      > Cr-Commit-Position: refs/heads/master@{#45172}
      
      TBR=bradnelson@chromium.org,machenbach@chromium.org,mtrofin@chromium.org,mtrofin@google.com,jochen@chromium.org,v8-reviews@googlegroups.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Change-Id: I21ffba7141db0bfb4a3275b6e1bf4fb399800ed2
      Reviewed-on: https://chromium-review.googlesource.com/500128Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45177}
      02595c60
  11. 08 May, 2017 4 commits
  12. 05 May, 2017 1 commit
  13. 04 May, 2017 2 commits
  14. 26 Apr, 2017 1 commit
  15. 24 Apr, 2017 1 commit
  16. 20 Apr, 2017 1 commit
  17. 19 Apr, 2017 2 commits
  18. 18 Apr, 2017 3 commits
  19. 13 Apr, 2017 1 commit
  20. 12 Apr, 2017 4 commits
    • hablich's avatar
      Revert of [wasm] instantiate expressed in terms of compile (patchset #6... · d3f1d5c5
      hablich authored
      Revert of [wasm] instantiate expressed in terms of compile (patchset #6 id:140001 of https://codereview.chromium.org/2806073002/ )
      
      Reason for revert:
      Roll blocker: https://bugs.chromium.org/p/chromium/issues/detail?id=710824
      
      Original issue's description:
      > [wasm] instantiate expressed in terms of compile
      >
      > Today, the semantics of:
      >
      > WebAssembly.instantiate
      >
      > and
      >
      > WebAssembly.compile().then(new WebAssemblyInstance)
      >
      > are subtly different, to the point where attempting the proposed
      > change uncovered bugs.
      >
      > In the future, it's possible that .instantiate actually have different
      > semantics - if we pre-specialized to the provided ffi, for example.
      > Right now that's not the case.
      >
      > This CL:
      > - gets our implementation closer to what developers may write using
      > the compile -> new Instance alternative, in particular wrt promise
      > creation. By reusing code paths, we uncover more bugs, and keep
      > maintenance cost lower.
      >
      > - it gives us the response-based WebAssembly.instantiate implicitly.
      > Otherwise, we'd need that same implementation on the blink side. The
      > negative is maintenance: imagine if the bugs I mentioned could only be
      > found when running in Blink.
      >
      > BUG=chromium:697028
      >
      > Review-Url: https://codereview.chromium.org/2806073002
      > Cr-Commit-Position: refs/heads/master@{#44592}
      > Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb
      
      TBR=bradnelson@chromium.org,ahaas@chromium.org,adamk@chromium.org,mtrofin@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:697028
      
      Review-Url: https://codereview.chromium.org/2810203002
      Cr-Commit-Position: refs/heads/master@{#44614}
      d3f1d5c5
    • jgruber's avatar
      [string] Add a fast path to String.p.replace · f4ba786d
      jgruber authored
      This adds a fast path to skip runtime calls to GetSubstitution when
      the replacer string does not contain a '$' char.
      
      Extended background:
      
      String.prototype.replace is (roughly) structured as follows:
      
      * Check if {searchValue} has a @@replace Symbol, and delegate to that if
        so. We currently implement efficient fast paths when {searchValue} is
        a String or a fast RegExp.
      * A specialized fast path for single-char {searchValue}, "long" subject
        string, and String {replaceValue} that do not contain '$' chars (yes,
        this fast path is very specialized).
      * Check for the location of the first match using StringIndexOf, and
        exit early if no match is found.
      * Finally build the return value, which is 'prefix + replacement +
        suffix', where replacement is either the result of calling {replaceValue}
        (if it is callable), or GetSubstitution(ToString({replaceValue}))
        otherwise.
      
      There's several spots that could be improved.
      
      StringIndexOf currently calls into C++ runtime for all but the simple
      1-byte, 1-char {searchValue} case. We need to finally add support for
      remaining cases.
      
      The runtime call to GetSubstitution can be skipped if the replacer
      string does not contain any '$' syntax. This CL handles that case.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2813843002
      Cr-Commit-Position: refs/heads/master@{#44606}
      f4ba786d
    • Sathya Gunasekaran's avatar
      [builtins] Change semantics of class constructors returning primitives · a7c4e778
      Sathya Gunasekaran authored
      This change mirrors the semantics for derived class constructors. This
      change doesn't affect non class constructors.
      
      This change could potentially break web compat. More details:
      https://github.com/tc39/ecma262/pull/469
      
      Bug=v8:5536
      
      Change-Id: I519599949523733332d0b35e4f8d9ecb01cac495
      Reviewed-on: https://chromium-review.googlesource.com/461225Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44594}
      a7c4e778
    • mtrofin's avatar
      [wasm] instantiate expressed in terms of compile · 7829af32
      mtrofin authored
      Today, the semantics of:
      
      WebAssembly.instantiate
      
      and
      
      WebAssembly.compile().then(new WebAssemblyInstance)
      
      are subtly different, to the point where attempting the proposed
      change uncovered bugs.
      
      In the future, it's possible that .instantiate actually have different
      semantics - if we pre-specialized to the provided ffi, for example.
      Right now that's not the case.
      
      This CL:
      - gets our implementation closer to what developers may write using
      the compile -> new Instance alternative, in particular wrt promise
      creation. By reusing code paths, we uncover more bugs, and keep
      maintenance cost lower.
      
      - it gives us the response-based WebAssembly.instantiate implicitly.
      Otherwise, we'd need that same implementation on the blink side. The
      negative is maintenance: imagine if the bugs I mentioned could only be
      found when running in Blink.
      
      BUG=chromium:697028
      
      Review-Url: https://codereview.chromium.org/2806073002
      Cr-Commit-Position: refs/heads/master@{#44592}
      7829af32
  21. 11 Apr, 2017 3 commits