Skip to content

V
V8
Switch branch/tag
  1. 11 Feb, 2021 4 commits
    • Benedikt Meurer's avatar
      [stack-traces] Remove StackFrameInfo. · 11b6f176
      Benedikt Meurer authored 
      For a long time, V8 had two distinct ways to capture and store a stack
trace, one where we'd just collect and symbolize the information for the
v8::StackTrace API (script id, name, line and colum information mostly),
and one where V8 would also memorize the closures, receivers, and
optionally the parameters of the stack frame, which we use for
Error.stack and the non-standard CallSite APIs. Those two were often out
of sync and suffered from various different issues. Eventually they were
refactored into a single captureStackTrace() bottleneck that would
produce a FrameArray.

This CL is a logical continuation of the refactorings. It repairs a
regression where we'd compute the method name (as part of the
cached StackFrameInfo) even if we don't need them (as is the case for
the inspector and any other use of the v8::StackTrace API).

Everytime a method was invoked on StackTraceFrame, it'd call into
StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo
like this:

  1. Create a FrameArrayIterator and point it to the FrameArray at the
     index stored in the StackTraceFrame.
  2. Invoke FrameArrayIterator::Frame(), which copies the information
     from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame
     or WasmStackFrame C++ object, and use the StackFrameBase virtual
     methods to transfer all information to a newly created
     StackFrameInfo object.
  3. Kill the link to the FrameArray and put a link to the
     StackFrameInfo object into the StackTraceFrame.

This caching turned out to be extremely costly, since beyond other
things, it'd always invoke JSStackFrame::GetMethodName(), which is
extremely costly (the execution time is linear in the number of
properties on the receiver and it's prototype chain). The cost was so
high that several work-arounds had been added, which would avoid
triggering the eager construction of the StackFrameInfo object (i.e.
https://crrev.com/c/2080663, https://crrev.com/c/2550504 or
https://crrev.com/c/2261736, but also https://crrev.com/c/1688927).

This CL removes the StackFrameInfo caching completely, since neither the
inspector nor Error.stack benefit from the caching at all. It's only the
first part in a series of refactorings that will significantly reduce
the complexity and overhead of the stack trace collection.

Doc: https://bit.ly/2wkbuIy
Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742
Bug: chromium:1127391, chromium:1098530, chromium:981541
Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72647}
      11b6f176
    • Dominik Inführ's avatar
      [handles] Add DCHECK to ensure main thread for main thread handle · a1bfedb1
      Dominik Inführ authored 
      Make main-thread handle allocation fail more gracefully when run on
background threads.

Bug: v8:10315
Change-Id: Iece9215aed21020b97fede40d78ea56b9baffac4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689184
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72646}
      a1bfedb1
    • Deepti Gandluri's avatar
      [ia32] Use Wasm SSSE3 codegen flag for checking SIMD support · 8981ecbb
      Deepti Gandluri authored 
      Bug: v8:11154
Change-Id: I71d524bb33dbc2f7583da9a7d9dc2c350b57bf51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686680
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72645}
      8981ecbb
    • Jakob Gruber's avatar
      [regexp] Don't update last match info in @@split special case · 51fcfd58
      Jakob Gruber authored 
      V8 implements a fast-path for RegExp.prototype.split which diverges
from the spec: instead of creating a new sticky regexp instance
`splitter` and running it in a loop, we reuse the existing non-sticky
regexp without looping through each character.

This works fine in most cases, but we run into issues when matching at
the very end of the string. According to the spec, matches at the end
of the string are impossible in @@split, but in our fast-path
implementation they can happen.

The obvious fix would be to remove our fast-path but this comes with
high performance costs. The fix implemented in this CL adds a special
flag to `exec` s.t. matches at the end of the string can be treated as
failures. This is only relevant for @@split.

Bug: chromium:1075514
Change-Id: Ifb790ed116793998d7aeb37e307f3f3f764023d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681950
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72644}
      51fcfd58
  3. 10 Feb, 2021 31 commits
  5. 09 Feb, 2021 5 commits