Skip to content

V
V8
Switch branch/tag
  1. 13 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Simplify async function instrumentation. · 41f0c0ba
      Benedikt Meurer authored 
      This unifies and simplifies the way we instrument async functions for
the purpose of async stack traces and async stepping. It does so while
retaining the observable behavior on the inspector level (for now).

Previously we'd mark the implicit promise of the async function object
with the async task ID, and whenever we awaited, we'd copy the async
task ID to the throwaway promise that is created by the `await`. This
however made things unnecessarily interesting in the following regards:

1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the
`AsyncFunctionFinished` events, coming from the throwaway promises,
while the implicit promise is "done". This is especially confusing
with rejection propagation and requires very complex stepping logic
for async functions (after this CL it'll be possible to unify and
simplify the stepping logic).
2. We have to thread through the "can suspend" information from the
Parser all the way through AsyncFunctionReject/AsyncFunctionResolve
to the async function instrumentation to decide whether to cancel the
pending task when the async function finishes.

This CL changes the instrumentation to only happen (non recurringly) for
the throwaway promises allocated upon `await`. This solves both problems
mentioned above, and works because upon the first `await` the stack
captured for the throwaway promise will include the synchronous part as
expected, while upon later `await`s the synchronous part will be empty
and the asynchronous part will be the stack captured for the previous
throwaway promise (and the V8Debugger automatically short circuits
stacks with empty synchronous part).

Bug: chromium:1280519, chromium:1277451, chromium:1246867
Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78599}
      41f0c0ba
  3. 12 Jan, 2022 1 commit
    • Simon Zünd's avatar
      [debug] Add new 'CreateMessageFromException' function · c0682832
      Simon Zünd authored 
      CDP has a "ExceptionDetails" structure that is attached to various
CDP commands, e.g. "Runtime#exceptionThrown" or "Runtime#evaluate".
The stack trace in the "ExceptionDetails" structure is used in
various places in DevTools. The information in the "ExceptionDetails"
structure is extracted from a v8::Message object. Message objects
are normally created at the exception throw site and may augment
the error with manually inspecting the stack (both to capture a fresh
stack trace in some cases, as well as to calculate location info).

The problem is that in some cases we want to get an "ExceptionDetails"
structure after the fact, e.g. when logging a JS "Error" object in
a catch block. This means we can't reuse Isolate::CreateMessage as
the JS stack at call time is unrelated to the time when an Error
object was thrown.

To re-use some of the code, this CL introduces a new
"CreateMessageFromException" method that is only available from the
debugging interface (not public V8 API!). The new method works
similar to Isolate::CreateMessage, but:
  1) Does not look at the current JS stack, neither for a fresh
     stack trace nor for location information.
  2) Only uses the "detailed" stack trace for location info.
     This is because the "simple" stack trace could have already
     been serialized by accessing Error#stack.

Bug: chromium:1278650
Doc: https://bit.ly/runtime-get-exception-details
Change-Id: I0144516001c71786b9f76ae4dec4442fa1468c5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3337257Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78586}
      c0682832
  5. 10 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [inspector] Capture stack trace only once for JSError objects. · 765ca6a0
      Benedikt Meurer authored 
      When creating a new JSError object (or using the non-standard API
`Error.captureStackTrace`) V8 would previously capture the "simple stack
trace" (as FixedArray of CallSiteInfo instances) to be used for the non-
standard `error.stack` property, and if the inspector was active also
capture the "detailed stack trace" (as FixedArray of StackFrameInfo
instances). This turns out to be quite a lot of overhead, both in terms
of execution time as well as memory pressure, especially since the
information needed for the inspector is a proper subset of the
information needed by `error.stack`.

So this CL addresses the above issue by capturing only the "simple stack
trace" (in the common case) and computing the "detailed stack trace"
from the "simple stack trace" when on demand. This is accomplished by
introducing a new ErrorStackData container that is used to store the
stack trace information on JSErrors when the inspector is active. When
capturing stack trace for a JSError object while the inspector is
active, we take the maximum of the program controlled stack trace limit
and the inspector requested stack trace limit, and memorize the program
controlled stack trace limit for later formatting (to ensure that the
presence of the inspector is not observable by the program).

On the `standalone.js` benchmark from crbug.com/1283162 (with the
default max call stack size of 200) we reduce execution time by around
16% compared to ToT. And compared to V8 9.9.4 (the version prior to the
regression in crbug.com/1280831), we are 6% faster now.

Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Bug: chromium:1280831, chromium:1278650, chromium:1258599
Bug: chromium:1280803, chromium:1280832, chromium:1280818
Fixed: chromium:1283162
Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78542}
      765ca6a0
  7. 04 Jan, 2022 2 commits
  9. 03 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Lazily lookup source positions for StackFrameInfo. · 2ffc79b7
      Benedikt Meurer authored 
      This changes the StackFrameInfo to either hold on to a pair of

  (Script,source position)

or a pair of

  (SharedFunctioInfo,bytecode offset)

similar to what we do for MessageLocation. The idea here is to defer the
costly bytecode offset to source position lookup until really needed,
and in particular, avoid the costly lookup during stack trace capturing.

On the `standalone.js` benchmark in crbug.com/1283162#c1, this reduces
overall average execution time by roughly 25%, and the performance is
almost back to where it was before crrev.com/c/3302794 (being only 12%
slower than before on the `standalone.js` test case).

Note that due to unrelated limitations we cannot encode -1 as bytecode
offset in the flags field of the StackFrameInfo, and so we treat this
case specially (happens when stack trace capturing is triggered in the
function entry sequence) and just eagerly resolve it to the source
position.

Bug: chromium:1278650, chromium:1283162, chromium:1280803
Bug: chromium:1280818, chromium:1280831, chromium:1280832
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Change-Id: If7cf62fce48d32c0f188895d1f8c9eee51b9e70d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359633Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78466}
      2ffc79b7
  11. 22 Dec, 2021 1 commit
  13. 16 Dec, 2021 2 commits
  15. 15 Dec, 2021 2 commits
    • Samuel Groß's avatar
      V8 Sandbox rebranding · 277fdd1d
      Samuel Groß authored 
      This CL renames a number of things related to the V8 sandbox.
Mainly, what used to be under V8_HEAP_SANDBOX is now under
V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
is now simply the V8 Sandbox:

V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
V8VirtualMemoryCage => Sandbox
CagedPointer => SandboxedPointer
fake cage => partially reserved sandbox
src/security => src/sandbox

This naming scheme should simplify things: the sandbox is now the large
region of virtual address space inside which V8 mainly operates and
which should be considered untrusted. Mechanisms like sandboxed pointers
are then used to attempt to prevent escapes from the sandbox (i.e.
corruption of memory outside of it). Furthermore, the new naming scheme
avoids the confusion with the various other "cages" in V8, in
particular, the VirtualMemoryCage class, by dropping that name entirely.

Future sandbox features are developed under their own V8_SANDBOX_X flag,
and will, once final, be merged into V8_SANDBOX. Current future features
are sandboxed external pointers (using the external pointer table), and
sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
because they are encoded as offsets). This CL then also introduces a new
build flag, v8_enable_sandbox_future, which enables all future features.

Bug: v8:10391
Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78384}
      277fdd1d
    • Benedikt Meurer's avatar
      [debug] Introduce a dedicated StackFrameInfo for v8::StackFrame. · b8e2a423
      Benedikt Meurer authored 
      This is the final change list in the list of refactorings to split off
the implementations of v8::StackFrame and CallSite objects (as used by
the V8 JavaScript stack API). See https://bit.ly/v8-stack-frame for the
whole story.

This CL adds the v8::internal::StackFrameInfo class as new backing
implementation of v8::StackFrame, and puts it into debug-objects.tq
to indicate that it's used for the debugger API only. This new class
is lightweight and only holds on to static information about the
stack frame, and is thus usable for the V8 inspector to implement
async stack traces in a cheaper manner going forward.

Doc: https://bit.ly/v8-stack-frame
Bug: chromium:1258599, chromium:1278650
Fixed: chromium:1278647
Change-Id: I4dbf2d850f47797263af225895129499169aad02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302794
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78382}
      b8e2a423
  17. 14 Dec, 2021 4 commits
  19. 13 Dec, 2021 1 commit
  21. 09 Dec, 2021 2 commits
    • Maya Lekova's avatar
      Revert "[stack-traces] Don't hold on to code objects from StackFrameInfos." · 3ea957a6
      Maya Lekova authored 
      This reverts commit 6b1fb003.

Reason for revert: breaks gc stress bots - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/36626/overview

Original change's description:
> [stack-traces] Don't hold on to code objects from StackFrameInfos.
>
> Previously every `StackFrameInfo` instance would maintain a reference to
> an AbstractCode object, which was used to resolve the `code_offset` on
> that stack frame. However, it turns out that nowadays this is not
> necessary anymore, since all `code_offset`s reported for JavaScript
> frames are already bytecode offsets and thus can be resolved by just
> looking at the functions' bytecode.
>
> For WebAssembly frames we will also eagerly resolve the `code_offset`
> (which is different depending on whether we're looking at Liftoff or
> TurboFan code) to the byte offset (relative to the function start) and
> stash that away in the `StackFrameInfo`.
>
> For builtin exit frames, the `abstract_code` on the function always
> refers to the builtin code object and thus, there's no point in keeping
> an extra pointer to it around on the `StackFrameInfo`.
>
> This way the `StackFrameInfo` representation is somewhat uniform, and
> more importantly, the `StackFrameInfo` instances will no longer need to
> hold to concrete code objects.
>
> Drive-by-fix: Use `FixedArray::SetAndGrow()` when adding to the elements
> in the `StackTraceBuilder`.
>
> Also-By: szuend@chromium.org, jarin@chromium.org
> Bug: chromium:1258599, chromium:1077657, v8:8742, chromium:1069425
> Change-Id: I650e400e0e1acd920281669bdc7b5e1199683ae8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3323073
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78320}

Bug: chromium:1258599, chromium:1077657, v8:8742, chromium:1069425
Change-Id: I20643ad8f0c383b754841fc52f9b3447b004c9d0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327141
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Owners-Override: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78323}
      3ea957a6
    • Benedikt Meurer's avatar
      [stack-traces] Don't hold on to code objects from StackFrameInfos. · 6b1fb003
      Benedikt Meurer authored 
      Previously every `StackFrameInfo` instance would maintain a reference to
an AbstractCode object, which was used to resolve the `code_offset` on
that stack frame. However, it turns out that nowadays this is not
necessary anymore, since all `code_offset`s reported for JavaScript
frames are already bytecode offsets and thus can be resolved by just
looking at the functions' bytecode.

For WebAssembly frames we will also eagerly resolve the `code_offset`
(which is different depending on whether we're looking at Liftoff or
TurboFan code) to the byte offset (relative to the function start) and
stash that away in the `StackFrameInfo`.

For builtin exit frames, the `abstract_code` on the function always
refers to the builtin code object and thus, there's no point in keeping
an extra pointer to it around on the `StackFrameInfo`.

This way the `StackFrameInfo` representation is somewhat uniform, and
more importantly, the `StackFrameInfo` instances will no longer need to
hold to concrete code objects.

Drive-by-fix: Use `FixedArray::SetAndGrow()` when adding to the elements
in the `StackTraceBuilder`.

Also-By: szuend@chromium.org, jarin@chromium.org
Bug: chromium:1258599, chromium:1077657, v8:8742, chromium:1069425
Change-Id: I650e400e0e1acd920281669bdc7b5e1199683ae8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3323073Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78320}
      6b1fb003
  23. 08 Dec, 2021 2 commits
  25. 06 Dec, 2021 1 commit
  27. 03 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler] Create ParseInfo on BG thread · a66c7a38
      Leszek Swirski authored 
      Rather than creating a ParseInfo when creating a BackgroundCompileTask
(and passing ownership across to the BG thread which deallocates it),
create one when running it.

This allows the ParseInfo Zone to be both allocated and deallocated on
the same thread, which will improve its allocator friendliness.

As a side-effect, we now use the on-heap PreparseData from the
SharedFunctionInfo, rather than cloning the in-Zone PreparseData. This
means that we don't have to copy the PreparseData across Zones, but we
do need to Unpark the LocalHeap when accessing preparse data.

Change-Id: I16d976c1ad54c1090180f2936f40a23a6dbb5904
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312483Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78228}
      a66c7a38
  29. 02 Dec, 2021 1 commit
  31. 01 Dec, 2021 1 commit
  33. 30 Nov, 2021 2 commits
  35. 29 Nov, 2021 1 commit
  37. 24 Nov, 2021 1 commit
  39. 22 Nov, 2021 3 commits
    • Nico Hartmann's avatar
      Revert "Reland "[fastcall] Enable float support on arm64 simulator"" · 226995ae
      Nico Hartmann authored 
      This reverts commit d7c3f1cd.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Android%20Arm64%20-%20debug%20builder/22043/overview

Original change's description:
> Reland "[fastcall] Enable float support on arm64 simulator"
>
> This is a reland of b9ddcbc8
>
> The original CL was reverted due to an MSAN issue, that is fixed by
> moving the signature mapping onto the Isolate (instead of having
> per-thread storage, which got invalid on multithreaded compilation).
>
> This CL also contains fixes for the Bazel config and for a data race
> when obtaining the PerIsolateSimulatorData.
>
> Original change's description:
> > [fastcall] Enable float support on arm64 simulator
> >
> > This CL adds support for handling calls to C functions with arbitrary
> > signatures on the arm64 simulator. It adds infrastructure for
> > encoding the signature data from CallDescriptor and FunctionInfo
> > classes into a compact representation, stored in the simulator and
> > called EncodedCSignature.
> >
> > Design doc:
> > https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
> >
> > This CL is a follow up on the native support added in
> > https://chromium-review.googlesource.com/c/v8/v8/+/3182232
> > and is partially based on the previous attempt:
> > https://chromium-review.googlesource.com/c/v8/v8/+/2343072
> >
> > Bug: chromium:1052746
> > Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
> > Commit-Queue: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#77744}
>
> Bug: chromium:1052746, chromium:1267854
> Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78018}

Bug: chromium:1052746, chromium:1267854
Change-Id: Ia8f10d085d13990b331f306957f95ecf3e003cfd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295453
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78019}
      226995ae
    • Maya Lekova's avatar
      Reland "[fastcall] Enable float support on arm64 simulator" · d7c3f1cd
      Maya Lekova authored 
      This is a reland of b9ddcbc8

The original CL was reverted due to an MSAN issue, that is fixed by
moving the signature mapping onto the Isolate (instead of having
per-thread storage, which got invalid on multithreaded compilation).

This CL also contains fixes for the Bazel config and for a data race
when obtaining the PerIsolateSimulatorData.

Original change's description:
> [fastcall] Enable float support on arm64 simulator
>
> This CL adds support for handling calls to C functions with arbitrary
> signatures on the arm64 simulator. It adds infrastructure for
> encoding the signature data from CallDescriptor and FunctionInfo
> classes into a compact representation, stored in the simulator and
> called EncodedCSignature.
>
> Design doc:
> https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
>
> This CL is a follow up on the native support added in
> https://chromium-review.googlesource.com/c/v8/v8/+/3182232
> and is partially based on the previous attempt:
> https://chromium-review.googlesource.com/c/v8/v8/+/2343072
>
> Bug: chromium:1052746
> Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77744}

Bug: chromium:1052746, chromium:1267854
Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78018}
      d7c3f1cd
    • Dominik Inführ's avatar
      Reland "[heap] Support multiple clients in shared GC" · 2c88cec4
      Dominik Inführ authored 
      This is a reland of 90a9d6cb

The original CL got reverted because of two different issues:

* The DCHECK failure on AllowGarbageCollection::IsAllowed() got fixed
  in https://crrev.com/c/3289625.
* The crash with the incremental marking job were because of a nested
  GC started from a SafepointScope. This CL adds IgnoreLocalGCRequests
  scopes to SafepointScopes in src/heap.

In addition this CL prevents shared GCs during isolate deserialization
by locking the clients_mutex_ until the isolate is fully deserialized.
The original GC used a DisallowSafepoints scope to prevent shared GCs
from interrupting isolate deserialization.

Original change's description:
> [heap] Support multiple clients in shared GC
>
> Add support for safepointing multiple isolates as described in the
> design doc (link is below). A safepoint across multiple isolates is
> considered a global safepoint to distinguish it from regular safepoints.
>
> The basic idea behind the implementation is that we reach a
> safepoint for each client. What's new is that now also main threads
> need to participate in the safepointing protocol and need to give up
> control in time. The slow paths of Park(), Unpark() and Safepoint() on
> the main thread need to be adjusted for this reason as well.
>
> This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
> IsolateSafepoint and IsolateSafepointScope.
>
> This CL adds the type IgnoreLocalGCRequests, it is used to prevent
> Park() and Unpark() from honoring the request from background threads
> to perform a local GC. This is used heap-internally to not have GCs
> (or even nested GCs) in certain locations. E.g. when initiating a
> safepoint to perform a GC we don't want a "recursive" GC to occur.
>
> Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
>
> Bug: v8:11708
> Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77812}

Bug: v8:11708, v8:12375, v8:12377
Change-Id: I9d1af6fbc06a3a8b6f216ec5e9027665ad071809
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283067
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78013}
      2c88cec4
  41. 19 Nov, 2021 1 commit
  43. 18 Nov, 2021 1 commit
  45. 17 Nov, 2021 1 commit
    • Tobias Tebbi's avatar
      [builtins] add Torque fast-path for String.prototype.localeCompare · 6181ce59
      Tobias Tebbi authored 
      This fast path works for ASCII-only strings and is similar to the
existing fast-path in C++. Important differences:
- The locale check is done at Turbofan optimization time instead of
  at runtime
- Use tables of size 256 instead of 128 to save a bounds-check when
  handling one-byte strings.
- It first performs an equality check that's optimized for detecting
  inequality quickly by comparing the strings from both ends. If the
  equality check succeeds, we are done. Otherwise chances are high
  that the strings differ according to collation level L1 already.
  Therefore, we first do an L1 check and perform the L3 check
  only when L1 didn't find a difference. This is based on the assumption
  that few strings are identical except for different capitalization.
- Use the Torque version of string flattening instead of the runtime
  version.

Bug: v8:12196
Change-Id: I2d043c1138846783f6d567b736d34063ba9301e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268465Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77946}
      6181ce59
  47. 15 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler] Post compile tasks from ignition instead of the parser · 6b2fa4c1
      Leszek Swirski authored 
      Posting compile tasks from the parser has several issues:

  1. We don't know how many functions there will be total, so we can't
     yet allocate shared_function_infos array on the Script
  2. Without this array, inner function compiles can't look up their own
     inner functions during bytecode finalization, so we can't run that
     finalization before script parse completes
  3. Scope analysis can't have run yet, so we can only post top-level
     function tasks and if we allocate SharedFunctionInfos early they
     are forced into a bit of a limbo state without an outer ScopeInfo.

Instead, we can post compile tasks during bytecode generation. Then, the
script parse is guaranteed to have completed, so we'll have a
shared_function_infos array and we will have allocated ScopeInfos
already. This also opens the door for posting tasks for compiling more
inner functions than just top-level, as well as generating better code
for functions/methods that reference same-script top-level
let/const/class.

Bug: chromium:1267680
Change-Id: Ie1a3a3c6f1b264c4ef28cd4763bfc6dc08f45d4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277884
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77894}
      6b2fa4c1
  49. 11 Nov, 2021 2 commits
    • Dominik Inführ's avatar
      Revert "[heap] Support multiple clients in shared GC" · 2f98fb28
      Dominik Inführ authored 
      This reverts commit 90a9d6cb.

Reason for revert: Seems to make some test to fail flakily. Revert for now until this is fixed.

Original change's description:
> [heap] Support multiple clients in shared GC
>
> Add support for safepointing multiple isolates as described in the
> design doc (link is below). A safepoint across multiple isolates is
> considered a global safepoint to distinguish it from regular safepoints.
>
> The basic idea behind the implementation is that we reach a
> safepoint for each client. What's new is that now also main threads
> need to participate in the safepointing protocol and need to give up
> control in time. The slow paths of Park(), Unpark() and Safepoint() on
> the main thread need to be adjusted for this reason as well.
>
> This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
> IsolateSafepoint and IsolateSafepointScope.
>
> This CL adds the type IgnoreLocalGCRequests, it is used to prevent
> Park() and Unpark() from honoring the request from background threads
> to perform a local GC. This is used heap-internally to not have GCs
> (or even nested GCs) in certain locations. E.g. when initiating a
> safepoint to perform a GC we don't want a "recursive" GC to occur.
>
> Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
>
> Bug: v8:11708
> Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77812}

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:11708
Change-Id: I85fbf896c59492fc571b3bfaa7f9e3ea8a883260
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275552
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77845}
      2f98fb28
    • Igor Sheludko's avatar
      [ext-code-space] Fix external code range allocation logic · 48490149
      Igor Sheludko authored 
      ... by
1) using platform-specific kMaxPCRelativeCodeRangeInMB constant
   instead of fixed 2GB for computing a region around embedded builtins
   from which the builtins could be reachable by pc-relative call/jump
   instructions,
2) remapping builtins into the code range if the latter happened to be
   allocated too far from embedded builtins (so that the pc-relative
   calls/jumps can't reach the embedded builtins blob).

Bug: v8:11880
Change-Id: I3c8df6836a8f0156d5360edd9c4ae8c295ec7100
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270543Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77837}
      48490149
  51. 10 Nov, 2021 1 commit
    • Dominik Inführ's avatar
      [heap] Support multiple clients in shared GC · 90a9d6cb
      Dominik Inführ authored 
      Add support for safepointing multiple isolates as described in the
design doc (link is below). A safepoint across multiple isolates is
considered a global safepoint to distinguish it from regular safepoints.

The basic idea behind the implementation is that we reach a
safepoint for each client. What's new is that now also main threads
need to participate in the safepointing protocol and need to give up
control in time. The slow paths of Park(), Unpark() and Safepoint() on
the main thread need to be adjusted for this reason as well.

This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
IsolateSafepoint and IsolateSafepointScope.

This CL adds the type IgnoreLocalGCRequests, it is used to prevent
Park() and Unpark() from honoring the request from background threads
to perform a local GC. This is used heap-internally to not have GCs
(or even nested GCs) in certain locations. E.g. when initiating a
safepoint to perform a GC we don't want a "recursive" GC to occur.

Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing

Bug: v8:11708
Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77812}
      90a9d6cb
  53. 09 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      Revert "[flags] Add a sanity check for unchanged jitless flags" · 87370c6b
      Leszek Swirski authored 
      This reverts commit 3a46c81c.

Reason for revert: Breaking roll (or rather, oh no, cast_shell is broken, need to fix that before relanding): https://ci.chromium.org/ui/p/chromium/builders/try/cast_shell_linux/1053410/overview

Original change's description:
> [flags] Add a sanity check for unchanged jitless flags
>
> V8 flags in general should not change in a process after the
> first Isolate has been initialized. --jitless and related flags
> especially sensitive to this, so we introduce a dedicated check
> just for them.
>
> Bug: chromium:1262676, v8:9019, v8:12366
> Change-Id: I239726889d236a3785c1fdc076fa21d1b8983c92
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260508
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77759}

Bug: chromium:1262676, v8:9019, v8:12366
Change-Id: Ie47d183bfd68633c3d30a13a038219051c38eba0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268734
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#77785}
      87370c6b
  55. 08 Nov, 2021 1 commit