1. 19 Mar, 2018 1 commit
    • Alexey Kozyatinskiy's avatar
      Reland "[inspector] added Runtime.terminateExecution" · 97fc20f3
      Alexey Kozyatinskiy authored
      This is a reland of 14824520
      
      Original change's description:
      > [inspector] added Runtime.terminateExecution
      >
      > Runtime.terminateExecution terminates current or next JavaScript
      > call. Termination flag is automatically reset as soon as v8 call
      > or microtasks are completed.
      >
      > R=pfeldman@chromium.org
      >
      > Bug: chromium:820640
      > Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      > Change-Id: Ie21c123be3a61fe25cf6e04c38a8b6c664622ed7
      > Reviewed-on: https://chromium-review.googlesource.com/957386
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#51912}
      
      Bug: chromium:820640
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I6dd30f65c06c2b7eefd1e7beb9a3cf50ea5bf8cd
      Reviewed-on: https://chromium-review.googlesource.com/967323
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52004}
      97fc20f3
  2. 17 Mar, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "Reland "[inspector] added Runtime.terminateExecution"" · 7652bd27
      Michael Achenbach authored
      This reverts commit 14824520.
      
      Reason for revert: Breaks chromium tsan in roll:
      https://chromium-review.googlesource.com/c/chromium/src/+/967682
      
      Original change's description:
      > Reland "[inspector] added Runtime.terminateExecution"
      > 
      > This is a reland of 98dec8f2
      > 
      > Original change's description:
      > > [inspector] added Runtime.terminateExecution
      > > 
      > > Runtime.terminateExecution terminates current or next JavaScript
      > > call. Termination flag is automatically reset as soon as v8 call
      > > or microtasks are completed.
      > > 
      > > R=pfeldman@chromium.org
      > > 
      > > Bug: chromium:820640
      > > Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      > > Change-Id: Ie21c123be3a61fe25cf6e04c38a8b6c664622ed7
      > > Reviewed-on: https://chromium-review.googlesource.com/957386
      > > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > > Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#51912}
      > 
      > Bug: chromium:820640
      > Change-Id: I8f270c2fdbe732f0c40bfb149d26a6e73d988253
      > Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      > Reviewed-on: https://chromium-review.googlesource.com/966681
      > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52002}
      
      TBR=dgozman@chromium.org,pfeldman@chromium.org,kozyatinskiy@chromium.org
      
      Change-Id: I2f3d24b238f479082bfed349363240887b5ba751
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:820640
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/967781Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52003}
      7652bd27
    • Alexey Kozyatinskiy's avatar
      Reland "[inspector] added Runtime.terminateExecution" · 14824520
      Alexey Kozyatinskiy authored
      This is a reland of 98dec8f2
      
      Original change's description:
      > [inspector] added Runtime.terminateExecution
      > 
      > Runtime.terminateExecution terminates current or next JavaScript
      > call. Termination flag is automatically reset as soon as v8 call
      > or microtasks are completed.
      > 
      > R=pfeldman@chromium.org
      > 
      > Bug: chromium:820640
      > Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      > Change-Id: Ie21c123be3a61fe25cf6e04c38a8b6c664622ed7
      > Reviewed-on: https://chromium-review.googlesource.com/957386
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#51912}
      
      Bug: chromium:820640
      Change-Id: I8f270c2fdbe732f0c40bfb149d26a6e73d988253
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/966681Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52002}
      14824520
  3. 05 Mar, 2018 1 commit
    • Benedikt Meurer's avatar
      [es2015] Refactor the JSArrayIterator. · 06ee127b
      Benedikt Meurer authored
      This changes the JSArrayIterator to always have only a single instance
      type, instead of the zoo of instance types that we had before, and
      which became less useful with the specification update to when "next"
      is loaded from the iterator now. This greatly simplifies the baseline
      implementation of the array iterator, which now only looks at the
      iterated object during %ArrayIteratorPrototype%.next invocations.
      
      In TurboFan we introduce a new JSCreateArrayIterator operator, that
      holds the IterationKind and get's the iterated object as input. When
      optimizing %ArrayIteratorPrototype%.next in the JSCallReducer, we
      check whether the receiver is a JSCreateArrayIterator, and if so,
      we try to infer maps for the iterated object from there. If we find
      any, we speculatively assume that these won't have changed during
      iteration (as we did before with the previous approach), and generate
      fast code for both JSArray and JSTypedArray iteration.
      
      Drive-by-fix: Drop the fast_array_iteration protector, it's not
      necessary anymore since we have the deoptimization guard bit in
      the JSCallReducer now.
      
      This addresses the performance cliff noticed in webpack 4. The minimal
      repro on the tracking bug goes from
      
        console.timeEnd: mono, 124.773000
        console.timeEnd: poly, 670.353000
      
      to
      
        console.timeEnd: mono, 118.709000
        console.timeEnd: poly, 141.393000
      
      so that's a 4.7x improvement.
      
      Also make presubmit happy by adding the missing #undef's.
      
      Bug: v8:7510, v7:7514
      Change-Id: I79a46bfa2cd0f0710e09365ef72519b1bbb667b5
      Reviewed-on: https://chromium-review.googlesource.com/946098Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51725}
      06ee127b
  4. 23 Jan, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Extend the @@species protector to guard Promises. · 79e91f0c
      Benedikt Meurer authored
      Use this in the PromiseThen operation to skip the (expensive) lookup in
      the SpeciesConstructor operation. This yields in a nice 3-5% improvement
      on the bluebird and wikipedia benchmarks, and paves the way for inlining
      certain Promise operations into TurboFan optimized code later.
      
      On the micro-benchmark mentioned in the bug (from the findings doc), we
      reduce the overall execution time by 25%, which makes sense given that
      Promise.prototype.then spends a significant portion of it's time just
      figuring out the appropriate constructor.
      
      Bug: v8:7253, v8:7349
      Change-Id: Ia1577b59d1b7e4b8dbda83e2186583edab76695a
      Reviewed-on: https://chromium-review.googlesource.com/880681Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50794}
      79e91f0c
  5. 13 Oct, 2017 1 commit
  6. 06 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Add support to inline new Array(n) calls. · 34de39bf
      Benedikt Meurer authored
      Make calls like
      
        new Array(n)
        new A(n)
      
      (where A is a subclass of Array) inlinable into TurboFan. We do this by
      speculatively checking that n is an unsigned integer that is not greater
      than JSArray::kInitialMaxFastElementArray, and then lowering the backing
      store allocation to a builtin call. The speculative optimization is
      either protected by the AllocationSite for the Array constructor
      invocation (if we have one), or by a newly introduced global protector
      cell that is used for Array constructor invocations that don't have an
      AllocationSite, i.e. the ones from Array#map, Array#filter, or from
      subclasses of Array.
      
      Next step will be to implement the backing store allocations inline in
      TurboFan, but that requires Loop support in the GraphAssembler, so it's
      done as a separate CL. This should further boost the performance.
      
      This boosts the ARES6 ML benchmark by up to 8% on the steady state,
      and also improves monomorphic Array#map calls by around 20-25% on the
      initial setup.
      
      Bug: v8:6399
      Tbr: ulan@chromium.org
      Change-Id: I7c8bdecf7c814ce52db6ee3051c3206a4f7d4bb6
      Reviewed-on: https://chromium-review.googlesource.com/704639
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48348}
      34de39bf
  7. 25 Sep, 2017 1 commit
    • Karl Schimpf's avatar
      Add capability of throwing values in WASM · 49106e48
      Karl Schimpf authored
      This is a second attempt at landing CL 644866 which was reverted by
      CL 667019.
      
      Extends the current implementation of WASM exceptions to be able to
      throw exceptions with values (not just tags).
      
      A JS typed (uint_16) array is used to hold the thrown values. This
      allows all WASM types to be stored (i32, i64, f32, and f64) as well as
      be inspected in JS.
      
      The previous CL was reverted because the WASM compiler made calls to
      run time functions with tagged objects, which must not be done. To fix
      this, all run time calls use the thread-level isolate to hold the
      exception being processed.
      
      Bug: v8:6577
      Change-Id: I4b1ef7e2847b71a2fab8e9934a0531057db9de63
      Reviewed-on: https://chromium-review.googlesource.com/677056
      Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48148}
      49106e48
  8. 15 Sep, 2017 1 commit
  9. 13 Sep, 2017 1 commit
  10. 07 Sep, 2017 1 commit
  11. 06 Sep, 2017 2 commits
  12. 28 Aug, 2017 1 commit
  13. 14 Aug, 2017 1 commit
  14. 02 Aug, 2017 3 commits
    • Karl Schimpf's avatar
      Reland "Start migration of try/throw/catch to match proposal." · ad49b7b4
      Karl Schimpf authored
      This is a reland of 470a1001
      Original change's description:
      > Start migration of try/throw/catch to match proposal.
      > 
      > This CL does the first baby steps on moving the current (experimental)
      > exception handling to match that of the WebAssembly proposal.
      > 
      > It does the following:
      > 
      > 1) Use exception tags instead of integers.
      > 
      > 2) Only handle empty exception signatures (i.e. no values associated
      >    with the exception tag.
      > 
      > 3) Only handle one catch clause.
      > 
      > 4) Be sure to rethrow the exception if the exception tag does not match.
      > 
      > Note: There are many things that need to be fixed, and are too
      > numerous to list here. However, the code should have TODO's on each
      > missing parts of the implementation.
      > 
      > Also note that the code currently doesn't handle nested catch blocks,
      > nor does it change the throw value being an integer. Rather, the
      > integer value is still being thrown, and currently is the exception
      > tag. Therefore, we don't build an exception object. This is the reason
      > why this CL doesn't handle exceptions that pass values.
      > 
      > Also, the current implementation still can't handle multiple modules
      > because tag resolution (between) modules has not be implemented yet.
      > 
      > Bug: v8:6577
      > Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
      > Reviewed-on: https://chromium-review.googlesource.com/591910
      > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
      > Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47087}
      
      Bug: v8:6577
      Change-Id: I41c3309827c292cb787681a95aaef7cf9b931835
      Reviewed-on: https://chromium-review.googlesource.com/598968Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
      Commit-Queue: Brad Nelson <bradnelson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47100}
      ad49b7b4
    • Ulan Degenbaev's avatar
      Revert "Start migration of try/throw/catch to match proposal." · 41daf8a5
      Ulan Degenbaev authored
      This reverts commit 470a1001.
      
      Reason for revert: GC stress bot failures.
      https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Mac%20GC%20Stress/builds/14522
      
      
      Original change's description:
      > Start migration of try/throw/catch to match proposal.
      > 
      > This CL does the first baby steps on moving the current (experimental)
      > exception handling to match that of the WebAssembly proposal.
      > 
      > It does the following:
      > 
      > 1) Use exception tags instead of integers.
      > 
      > 2) Only handle empty exception signatures (i.e. no values associated
      >    with the exception tag.
      > 
      > 3) Only handle one catch clause.
      > 
      > 4) Be sure to rethrow the exception if the exception tag does not match.
      > 
      > Note: There are many things that need to be fixed, and are too
      > numerous to list here. However, the code should have TODO's on each
      > missing parts of the implementation.
      > 
      > Also note that the code currently doesn't handle nested catch blocks,
      > nor does it change the throw value being an integer. Rather, the
      > integer value is still being thrown, and currently is the exception
      > tag. Therefore, we don't build an exception object. This is the reason
      > why this CL doesn't handle exceptions that pass values.
      > 
      > Also, the current implementation still can't handle multiple modules
      > because tag resolution (between) modules has not be implemented yet.
      > 
      > Bug: v8:6577
      > Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
      > Reviewed-on: https://chromium-review.googlesource.com/591910
      > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
      > Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47087}
      
      TBR=bradnelson@chromium.org,eholk@chromium.org,kschimpf@chromium.org
      
      Change-Id: I01dc8c40cc1057333a988c1d275ce5f457b0cb64
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6577
      Reviewed-on: https://chromium-review.googlesource.com/598847Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47090}
      41daf8a5
    • Karl Schimpf's avatar
      Start migration of try/throw/catch to match proposal. · 470a1001
      Karl Schimpf authored
      This CL does the first baby steps on moving the current (experimental)
      exception handling to match that of the WebAssembly proposal.
      
      It does the following:
      
      1) Use exception tags instead of integers.
      
      2) Only handle empty exception signatures (i.e. no values associated
         with the exception tag.
      
      3) Only handle one catch clause.
      
      4) Be sure to rethrow the exception if the exception tag does not match.
      
      Note: There are many things that need to be fixed, and are too
      numerous to list here. However, the code should have TODO's on each
      missing parts of the implementation.
      
      Also note that the code currently doesn't handle nested catch blocks,
      nor does it change the throw value being an integer. Rather, the
      integer value is still being thrown, and currently is the exception
      tag. Therefore, we don't build an exception object. This is the reason
      why this CL doesn't handle exceptions that pass values.
      
      Also, the current implementation still can't handle multiple modules
      because tag resolution (between) modules has not be implemented yet.
      
      Bug: v8:6577
      Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
      Reviewed-on: https://chromium-review.googlesource.com/591910Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
      Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47087}
      470a1001
  15. 10 Jul, 2017 1 commit
  16. 28 Jun, 2017 1 commit
  17. 08 Jun, 2017 1 commit
  18. 06 Jun, 2017 1 commit
  19. 24 May, 2017 2 commits
  20. 13 Feb, 2017 1 commit
    • bmeurer's avatar
      [es2015] Remove the @@hasInstance protector cell. · 1a236208
      bmeurer authored
      We cannot skip the @@hasInstance lookup in instanceof depending on a
      global protector cell, as the lookup of the property is observable
      via proxies or accessors. So remove the global protector and properly
      implement CSA::InstanceOf via GetPropertyStub, with an appropriate
      fast-path for Function.prototype[@@hasInstance] where we call the
      builtin code object directly if the function matches, skipping all
      the checks from the call sequence, and also avoid the redundant
      ToBoolean conversion on the result.
      
      R=yangguo@chromium.org
      TBR=ulan@chromium.org
      BUG=v8:5958
      
      Review-Url: https://codereview.chromium.org/2684033012
      Cr-Commit-Position: refs/heads/master@{#43137}
      1a236208
  21. 30 Jan, 2017 1 commit
  22. 16 Nov, 2016 1 commit
  23. 15 Nov, 2016 1 commit
    • petermarshall's avatar
      Fastpath some spread-call desugaring. · a63eeb48
      petermarshall authored
      Avoid using the iterator for arrays with fast elements where the iterator has
      not been modified.
      
      Only deals with the case where there is a single spread argument.
      
      Improves the six-speed "spread" benchmark to 1.5x slower than baseline es5 implementation, compared to 19x slower previously.
      
      BUG=v8:5511
      
      Review-Url: https://codereview.chromium.org/2465253011
      Cr-Commit-Position: refs/heads/master@{#40998}
      a63eeb48
  24. 14 Nov, 2016 1 commit
  25. 30 Sep, 2016 1 commit
  26. 29 Sep, 2016 2 commits
  27. 23 Sep, 2016 1 commit
  28. 20 Sep, 2016 1 commit
  29. 19 Sep, 2016 2 commits
  30. 05 Aug, 2016 2 commits
  31. 04 Aug, 2016 1 commit
  32. 26 Jul, 2016 1 commit