Skip to content

V
V8
Switch branch/tag
  1. 11 Feb, 2021 13 commits
    • Ulan Degenbaev's avatar
      [api] Advance legacy ArrayBuffer API deprecation · b1c36b23
      Ulan Degenbaev authored 
      Bug: v8:9380
Change-Id: I31d825265d283627406d4b976c8ab067eb7d2c06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154798
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72656}
      b1c36b23
    • Marja Hölttä's avatar
      [d8] Fix new style worker creation · 04b02035
      Marja Hölttä authored 
      Bug: v8:11340, chromium:177058
Change-Id: I34f400bc4d66275eb2fed082f1d44eccf21839d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689187Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72655}
      04b02035
    • Pierre Langlois's avatar
      [tools] Fix v8gen.py list command. · 4c5ea143
      Pierre Langlois authored 
      Bug: v8:11361
Change-Id: Ie36b612907fab01c269567e901494d2c7ea01b6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689192Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#72654}
      4c5ea143
    • Benedikt Meurer's avatar
      [stack-traces] Mark CallAsyncModule* builtins as native. · a8467bb4
      Benedikt Meurer authored 
      This bug was flushed out while working on refactoring the stack traces
(as part of https://crrev.com/c/2689183).

Bug: v8:8742
Change-Id: I5bbd4066cc464b71f4d9a7c90acc35e8cef7afb3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689193
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72653}
      a8467bb4
    • Jakob Gruber's avatar
      Reland "[compiler] Don't serialize JSTypedArray fields" · 28105df3
      Jakob Gruber authored 
      This is a reland of da785659

The reland overrides ShouldHaveBeenSerialized for typed array
refs to avoid disabling related optimizations when direct heap
access is enabled.

Original change's description:
> [compiler] Don't serialize JSTypedArray fields
>
> This CL removes serialization of JSTypedArray fields when direct heap
> reads are enabled. Invariants we rely on:
>
> - Of the underlying interesting fields,
>   - base_pointer and external_pointer are set either during
>     initialization, or in a one-time on-to-off-heap transition in
>     GetBuffer.
>   - length and buffer are immutable after initialization.
> - is_on_heap and DataPtr derive from base_pointer and
>   external_pointer s.t. is_on_heap == (base_pointer != 0) and
>   DataPtr == external_pointer in the off-heap case.
>
> In this CL we add one new invariant:
>
> - For all base_pointer and external_pointer mutations after
>   initialization, base_pointer is guaranteed to be release-stored
>   after external_pointer has been written.
>
> With these invariants, concurrent access to off-heap typed arrays is
> trivial as long as is_on_heap (= base_pointer) is read before other
> relevant fields.
>
> Note that JSTypedArray remains a kSerializedHeapObject due to the
> serialized superclass JSObject.
>
> Drive-by: Remove unused Torque operators and empty TODOs.
>
> Bug: v8:7790
> Change-Id: I3c4327318f94e4e6083d4e87476069aad2649386
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679689
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72572}

Bug: v8:7790
Change-Id: I87b37de983e8cf89ca53b5efae7ab195781f3df5
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689182Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72652}
      28105df3
    • Mythri Alle's avatar
      Revert "Enable FLAG_feedback_allocation_on_bytecode_size" · fa7c50cf
      Mythri Alle authored 
      This reverts commit 2a446a90.

Reason for revert: This caused regressions on Octane / Jetstream2 /
Sunspider and a couple of regressions on memory usage on mobile:

https://bugs.chromium.org/p/chromium/issues/detail?id=1177124
https://bugs.chromium.org/p/chromium/issues/detail?id=1177241

Original change's description:
> Enable FLAG_feedback_allocation_on_bytecode_size
>
> This flag enables feedback allocation heuristics to be based on the
> function size. The threshold for feedback allocation is set to
> 4 * bytecode size to roughly mimic the allocation after 4 invocations.
>
> Change-Id: Ia840cd526e3718d4267e01c688c6c6467e352d72
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685175
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72631}

TBR=rmcilroy@chromium.org,mythria@chromium.org,verwaest@chromium.org

Change-Id: Ib756116aa38117c06e95c7f68d8f9ba0acd34084
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689194Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72651}
      fa7c50cf
    • Manos Koukoutos's avatar
      [wasm-gc][test] Make tuple array gcc compatible · 4d85620f
      Manos Koukoutos authored 
      Bug: v8:11390
Change-Id: Ief0463e81744279edd7fd045e2ff0a636bd5cbba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2684365Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72650}
      4d85620f
    • Manos Koukoutos's avatar
      [wasm-gc] Implement br_on_* type relaxation · be2705c8
      Manos Koukoutos authored 
      Additional arguments are allowed along with the reference, but the
targeted branch must have at least one output (corresponding to the
cast reference).

Bug: v8:7748
Change-Id: I17383165e4bae1cada1676c6282437e1fa71905d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685161Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72649}
      be2705c8
    • Clemens Backes's avatar
      [wasm] Send a single scriptParsed event per script · b471bc93
      Clemens Backes authored 
      If a script was shared between multiple modules (because they used the
same wire bytes) it could happen that we still triggered multiple
"scriptParsed" events via CDP. This was because
{WasmEngine::GetOrCreateScript} did not communicate back whether it
used a cached script or whether it created a new one.

This CL moves the call to {Debug::OnAfterCompile} (which triggers the
"scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method,
such that we only call it once per script.
Since the engine only holds a weak reference to the script, we would
still trigger multiple events if the script is garbage-collected in the
meantime. In this case there is no way around this, as the new script
would have a new ID, hence we need to emit a new event to make it
public to the debugger.

R=thibaudm@chromium.org
CC=bmeurer@chromium.org

Bug: chromium:1151211
Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72648}
      b471bc93
    • 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 27 commits