1. 28 Oct, 2019 1 commit
  2. 13 Aug, 2019 1 commit
    • Jakob Gruber's avatar
      [isolate-data] Move hot fields closer to isolate_root · fb698cec
      Jakob Gruber authored
      In generated code, we access fields inside IsolateData through the
      root-register. On some platforms it is significantly cheaper to access
      things that are close to the root-register value than things that are
      located far away. The motivation for this CL was a 5% difference in
      Octane/Mandreel scores between
      
      // Part of the stack check.
      cmpq rsp,[r13+0x9ea8]
      
      and
      
      cmpq rsp,[r13-0x30]  // Mandreel score improved by 5%.
      
      This moves the StackGuard up to fix Mandreel. As a drive-by, also move
      two more fields up that are accessed by each CallCFunction.
      
      Tbr: yangguo@chromium.org
      Bug: v8:9534,chromium:993264
      Change-Id: I5418b63d40274a138e285fa3c99b96e33a814fb1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751345Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63187}
      fb698cec
  3. 12 Aug, 2019 1 commit
    • Jakob Gruber's avatar
      [isolate-data] Move the StackGuard to IsolateData · ef24a565
      Jakob Gruber authored
      IsolateData guarantees a fixed root-relative offset for its contents,
      thus allowing more efficient code generation for accesses to these
      addresses. The stack limit, located within the StackGuard, is used by
      all stack checks in CSA.
      
      This CL moves the StackGuard inside IsolateData to make such efficient
      loads of the limit possible.
      
      Bug: v8:9595,v8:9534
      Change-Id: I9abe26b88952709c88bf625cc6c028497815a58c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741648Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63160}
      ef24a565
  4. 11 Jul, 2019 1 commit
  5. 24 May, 2019 1 commit
  6. 23 May, 2019 1 commit
  7. 22 May, 2019 1 commit
  8. 21 May, 2019 1 commit
  9. 08 Mar, 2019 1 commit
  10. 15 Feb, 2019 1 commit
    • 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
  11. 18 Jan, 2019 1 commit
  12. 17 Dec, 2018 1 commit
  13. 14 Dec, 2018 1 commit
  14. 05 Dec, 2018 1 commit
  15. 29 Nov, 2018 2 commits
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · 6c8b4102
      Peter Marshall authored
      This is a reland of d5f4a33e
      Landing with test disabled for now.
      
      Original change's description:
      > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
      >
      > Before fast C calls, store the current FP and PC on the isolate. When
      > iterating frames in SafeStackFrameIterator, check if these fields are
      > set and start iterating at the calling frame's FP instead of the current
      > FP, which will be in C++ code. We need to do this because c_entry_fp is
      > not set on the Isolate for Fast-C-Calls because we don't build an exit
      > frame.
      >
      > This change makes stack samples that occur within 'Fast-C-Calls'
      > iterable, meaning we can properly attribute ticks within the JS caller.
      >
      > Fast-C-Calls can't call back into JS code, so we can only ever have one
      > such call on the stack at a time, allowing us to store the FP on the
      > isolate rather than the stack.
      >
      > TBR=v8-mips-ports@googlegroups.com
      >
      > Bug: v8:8464, v8:7202
      > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > Reviewed-by: Alexei Filippov <alph@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57896}
      
      TBR=v8-mips-ports@googlegroups.com
      TBR=jgruber@chromium.org
      
      Bug: v8:8464, v8:7202
      Change-Id: I260d5ab3bc12c9c4529fb52a297a1040dcaa8ebf
      Reviewed-on: https://chromium-review.googlesource.com/c/1354466
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57935}
      6c8b4102
    • Michael Achenbach's avatar
      Revert "Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame"" · 76786104
      Michael Achenbach authored
      This reverts commit ddaa1f0a.
      
      Reason for revert:
      Still flaky on windows. Maybe reland and keep skipped on windows?
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32%20-%20nosnap%20-%20shared/31002
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/27826
      
      Original change's description:
      > Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame"
      > 
      > This is a reland of d5f4a33e
      > 
      > Original change's description:
      > > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
      > >
      > > Before fast C calls, store the current FP and PC on the isolate. When
      > > iterating frames in SafeStackFrameIterator, check if these fields are
      > > set and start iterating at the calling frame's FP instead of the current
      > > FP, which will be in C++ code. We need to do this because c_entry_fp is
      > > not set on the Isolate for Fast-C-Calls because we don't build an exit
      > > frame.
      > >
      > > This change makes stack samples that occur within 'Fast-C-Calls'
      > > iterable, meaning we can properly attribute ticks within the JS caller.
      > >
      > > Fast-C-Calls can't call back into JS code, so we can only ever have one
      > > such call on the stack at a time, allowing us to store the FP on the
      > > isolate rather than the stack.
      > >
      > > TBR=v8-mips-ports@googlegroups.com
      > >
      > > Bug: v8:8464, v8:7202
      > > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      > > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      > > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > > Reviewed-by: Alexei Filippov <alph@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#57896}
      > 
      > TBR=v8-mips-ports@googlegroups.com
      > TBR=jgruber@chromium.org
      > 
      > Bug: v8:8464, v8:7202
      > Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
      > Reviewed-on: https://chromium-review.googlesource.com/c/1354042
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57912}
      
      TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com
      
      Change-Id: If810648dbf60df2ff70455b6e8ef466136c90145
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8464, v8:7202
      Reviewed-on: https://chromium-review.googlesource.com/c/1354461Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57925}
      76786104
  16. 28 Nov, 2018 3 commits
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · ddaa1f0a
      Peter Marshall authored
      This is a reland of d5f4a33e
      
      Original change's description:
      > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
      >
      > Before fast C calls, store the current FP and PC on the isolate. When
      > iterating frames in SafeStackFrameIterator, check if these fields are
      > set and start iterating at the calling frame's FP instead of the current
      > FP, which will be in C++ code. We need to do this because c_entry_fp is
      > not set on the Isolate for Fast-C-Calls because we don't build an exit
      > frame.
      >
      > This change makes stack samples that occur within 'Fast-C-Calls'
      > iterable, meaning we can properly attribute ticks within the JS caller.
      >
      > Fast-C-Calls can't call back into JS code, so we can only ever have one
      > such call on the stack at a time, allowing us to store the FP on the
      > isolate rather than the stack.
      >
      > TBR=v8-mips-ports@googlegroups.com
      >
      > Bug: v8:8464, v8:7202
      > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > Reviewed-by: Alexei Filippov <alph@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57896}
      
      TBR=v8-mips-ports@googlegroups.com
      TBR=jgruber@chromium.org
      
      Bug: v8:8464, v8:7202
      Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
      Reviewed-on: https://chromium-review.googlesource.com/c/1354042Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57912}
      ddaa1f0a
    • Maya Lekova's avatar
      Revert "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · 2f530d5c
      Maya Lekova authored
      This reverts commit d5f4a33e.
      
      Reason for revert: Seems to cause a no snapshot build failure - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21967
      
      Original change's description:
      > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
      > 
      > Before fast C calls, store the current FP and PC on the isolate. When
      > iterating frames in SafeStackFrameIterator, check if these fields are
      > set and start iterating at the calling frame's FP instead of the current
      > FP, which will be in C++ code. We need to do this because c_entry_fp is
      > not set on the Isolate for Fast-C-Calls because we don't build an exit
      > frame.
      > 
      > This change makes stack samples that occur within 'Fast-C-Calls'
      > iterable, meaning we can properly attribute ticks within the JS caller.
      > 
      > Fast-C-Calls can't call back into JS code, so we can only ever have one
      > such call on the stack at a time, allowing us to store the FP on the
      > isolate rather than the stack.
      > 
      > TBR=v8-mips-ports@googlegroups.com
      > 
      > Bug: v8:8464, v8:7202
      > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > Reviewed-by: Alexei Filippov <alph@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57896}
      
      TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com
      
      Change-Id: I85f846e57b6fa845e7770c616435cebffdb2a245
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8464, v8:7202
      Reviewed-on: https://chromium-review.googlesource.com/c/1352302Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57899}
      2f530d5c
    • Peter Marshall's avatar
      [cpu-profiler] Fix stack iterability for fast C calls with no exit frame · d5f4a33e
      Peter Marshall authored
      Before fast C calls, store the current FP and PC on the isolate. When
      iterating frames in SafeStackFrameIterator, check if these fields are
      set and start iterating at the calling frame's FP instead of the current
      FP, which will be in C++ code. We need to do this because c_entry_fp is
      not set on the Isolate for Fast-C-Calls because we don't build an exit
      frame.
      
      This change makes stack samples that occur within 'Fast-C-Calls'
      iterable, meaning we can properly attribute ticks within the JS caller.
      
      Fast-C-Calls can't call back into JS code, so we can only ever have one
      such call on the stack at a time, allowing us to store the FP on the
      isolate rather than the stack.
      
      TBR=v8-mips-ports@googlegroups.com
      
      Bug: v8:8464, v8:7202
      Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMartyn Capewell <martyn.capewell@arm.com>
      Reviewed-by: 's avatarAlexei Filippov <alph@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57896}
      d5f4a33e
  17. 21 Nov, 2018 1 commit
  18. 12 Nov, 2018 1 commit
  19. 30 Oct, 2018 1 commit
  20. 26 Oct, 2018 1 commit
  21. 25 Oct, 2018 1 commit
  22. 22 Oct, 2018 1 commit
  23. 16 Oct, 2018 3 commits
  24. 15 Oct, 2018 1 commit
  25. 11 Oct, 2018 1 commit