1. 15 Feb, 2019 2 commits
    • Benedikt Meurer's avatar
      [isolate] Move ThreadLocalTop into IsolateData. · e17e46fd
      Benedikt Meurer authored
      This refactors the ThreadLocalTop into separate header and
      implementation files, and moves it from the Isolate to the
      IsolateData (with some tweaks to make the layout of the class
      predictable). This has the advantage that all external references
      referring to addresses in the ThreadLocalTop (like js_entry_sp,
      c_function, c_entry_fp, etc.) need only a single memory access
      to reach them. For example the CallApiCallback can now use
      
      ```
      mov %rbp,0x8e40(%r13)
      mov %rsi,0x8de0(%r13)
      mov %rbx,0x8e50(%r13)
      ```
      
      to setup the information about context, frame pointer, and C++
      function pointer in the ThreadLocalTop instead of the previously
      generated code
      
      ```
      mov 0x2e28(%r13),%r10
      mov %rbp,(%r10)
      mov 0x2e38(%r13),%r10
      mov %rsi,(%r10)
      mov 0x2e30(%r13),%r10
      mov %rbx,(%r10)
      ```
      
      which always had to load the scratch register %r10 with the actual
      address first. This has interesting performance impact. On the
      test case mentioned in v8:8820 (with the `d8` patch applied), the
      performance goes from
      
      ```
      console.timeEnd: fnMono, 2290.012000
      console.timeEnd: fnCall, 2604.954000
      ```
      
      to
      
      ```
      console.timeEnd: fnMono, 2062.743000
      console.timeEnd: fnCall, 2477.556000
      ```
      
      which is a pretty solid **10%** improvement for the monomorphic API
      accessor case, and a **5%** improvement for calling into the API
      accessor instead.
      
      But there might as well be other places besides API callback calls
      that will benefit from this change, which I haven't tested explicitly.
      
      Although this change is supposed to be as minimal as possible without
      any functional effects, some changes were necessary/logical. Eventually
      we should reconsider changing the layout and the types for the fields
      in the ThreadLocalTop to be more consistent with the other IsolateData
      entities. But this can be done in separate follow-up CLs, as this will
      be quite a bit of churn on the code base, depending on how we do that
      exactly, and is orthogonal to this optimization.
      
      Bug: v8:8820, v8:8848, chromium:913553
      Change-Id: I4732c8e60231f0312eb7767358c48bae0338220d
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/1474230Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59624}
      e17e46fd
    • Jakob Kummerow's avatar
      [cleanup] #include heap-inl.h less often · 6cac1382
      Jakob Kummerow authored
      This takes heap-inl.h out of the "Giant Include Cluster".
      Naturally, that means adding a bunch of explicit includes
      in a bunch of places that relied on transitively including
      them before.
      As of this patch, no header file outside src/heap/ includes
      heap-inl.h.
      
      Bug: v8:8562,v8:8499
      Change-Id: I65fa763f90e66afc30d105b9277792721f05a6d4
      Reviewed-on: https://chromium-review.googlesource.com/c/1459659
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59617}
      6cac1382
  2. 01 Feb, 2019 1 commit
  3. 08 Jan, 2019 1 commit
  4. 26 Dec, 2018 1 commit
  5. 20 Dec, 2018 1 commit
  6. 19 Dec, 2018 1 commit
  7. 18 Dec, 2018 2 commits
  8. 17 Dec, 2018 1 commit
  9. 11 Dec, 2018 1 commit
  10. 23 Nov, 2018 2 commits
  11. 19 Nov, 2018 1 commit
  12. 16 Nov, 2018 2 commits
  13. 07 Nov, 2018 1 commit
  14. 05 Nov, 2018 1 commit
  15. 26 Oct, 2018 1 commit
  16. 12 Oct, 2018 1 commit
  17. 11 Oct, 2018 1 commit
  18. 10 Oct, 2018 1 commit
    • Hai Dang's avatar
      Add iterator protectors for JSMapIterator/JSSet/JSSetIterator. · 60d3ce72
      Hai Dang authored
      The MapIterator protector protects the original iteration behaviors of
      Map.prototype.keys(), Map.prototype.values(), and Set.prototype.entries().
      It does not protect the original iteration behavior of
      Map.prototype[Symbol.iterator](). The protector is invalidated when:
      * The 'next' property is set on an object where the property holder is the
        %MapIteratorPrototype% (e.g. because the object is that very prototype).
      * The 'Symbol.iterator' property is set on an object where the property
        holder is the %IteratorPrototype%. Note that this also invalidates the
        SetIterator protector (see below).
      
      The SetIterator protector protects the original iteration behavior of
      Set.prototype.keys(), Set.prototype.values(), Set.prototype.entries(),
      and Set.prototype[Symbol.iterator](). The protector is invalidated when:
      * The 'next' property is set on an object where the property holder is the
        %SetIteratorPrototype% (e.g. because the object is that very prototype).
      * The 'Symbol.iterator' property is set on an object where the property
        holder is the %SetPrototype% OR %IteratorPrototype%. This means that
        setting Symbol.iterator on a MapIterator object can also invalidate the
        SetIterator protector, and vice versa, setting Symbol.iterator on a
        SetIterator object can also invalidate the MapIterator. This is an over-
        approximation for the sake of simplicity.
      
      Bug: v8:7980
      Change-Id: I54ad6e4c7f19ccc27d7001f6c4b6c8d6ea4ee871
      Reviewed-on: https://chromium-review.googlesource.com/c/1273102Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Hai Dang <dhai@google.com>
      Cr-Commit-Position: refs/heads/master@{#56530}
      60d3ce72
  19. 03 Oct, 2018 1 commit
  20. 01 Oct, 2018 1 commit
  21. 30 Aug, 2018 1 commit
    • Michael Starzinger's avatar
      [wasm] Remove bogus Isolate::wasm_caught_exception. · 7b621a73
      Michael Starzinger authored
      This removes the thread-local field in question. This side-channel for
      the "caught exception" is not needed, we can just explicitly pass the
      exception value to all support functions. Also, there is an inherent
      problem with having this side-channel, as it will not be properly reset
      when an exception handler ends up not rethrowing the exception.
      
      R=ahaas@chromium.org
      BUG=v8:8097
      
      Change-Id: I2fdaff89f0eb318ce5a33bf56513165185547c1b
      Reviewed-on: https://chromium-review.googlesource.com/1194063Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55517}
      7b621a73
  22. 24 Aug, 2018 1 commit
  23. 20 Jul, 2018 1 commit
  24. 06 Jul, 2018 1 commit
  25. 04 Jul, 2018 1 commit
  26. 23 Apr, 2018 3 commits
  27. 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
  28. 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
  29. 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
  30. 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
  31. 13 Oct, 2017 1 commit
  32. 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
  33. 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