Skip to content

V
V8
Switch branch/tag
  1. 14 Jan, 2022 1 commit
  3. 13 Jan, 2022 5 commits
    • Lei Zhang's avatar
      Remove many superfluous STL includes in headers. · 87cf0bdd
      Lei Zhang authored 
      Use grep to check for obviously unneeded includes. e.g. headers that
include <vector> but does not contain "std::vector".

Change-Id: I43a9e9f01e072fd495918d28ca4cdad5cfa0294c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3354400Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78613}
      87cf0bdd
    • Nikolaos Papaspyrou's avatar
      heap: Add total wall time for UMA events · 638993ae
      Nikolaos Papaspyrou authored 
      The total wall time for GC reported to Blink is explicitly included in
UMA events. For the C++ managed heap, it is equal to the sum of the four
phases (mark, sweep, compact, weak). For the JS heap, it will be greater
than or equal to that sum in general.

Bug: chromium:1154636
Change-Id: Id710702b8e9d8db5c8d1eb4917deb6b760a77306
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386596Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78611}
      638993ae
    • Leszek Swirski's avatar
      Revert "cppgc-js,heap: Implement snapshots for embedder fields" · 7d4e3d35
      Leszek Swirski authored 
      This reverts commit 142dd775.

Reason for revert: TSAN breaks: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6113/overview

Original change's description:
> cppgc-js,heap: Implement snapshots for embedder fields
>
> https://crrev.com/c/3293410 added concurrent processing of C++ objects
> found through V8 embedder fields. The CL missed that those embedder
> fields are not read atomically from JS objects. The problem is that
> embedder fields are only aligned to kTaggedSize on builds with pointer
> compression and are as such mis-aligned for atomic ops. This is not a
> problem for on-heap values as the upper 32bits are anyways computed
> from the cage. Is is a problem for generic C++ values though, as they
> are used with Oilpan.
>
> This CL adds the standard marker snapshot protocol for embedder fields.
>
> Marker:
> 1. Snapshot embedder fields
> 2. Try to mark host object
> 3. On success: process snapshot
>
> Main thread:
> 1. On setting embedder fields mark the object black first
> 2. Emit a write barrier for the embedder fields
>
> This will get simpler with the heap sandbox that uses a separate table
> for embedder fields. Once the sandbox is the default configuration, we
> 	can use it as dependency for the concurrent fast path.
>
> Bug: chromium:1285706
> Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78604}

Bug: chromium:1285706
Change-Id: If1976c0356f450fc068aa4dcc39fb9a0d5417a40
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386598
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@{#78605}
      7d4e3d35
    • Michael Lippautz's avatar
      cppgc-js,heap: Implement snapshots for embedder fields · 142dd775
      Michael Lippautz authored 
      https://crrev.com/c/3293410 added concurrent processing of C++ objects
found through V8 embedder fields. The CL missed that those embedder
fields are not read atomically from JS objects. The problem is that
embedder fields are only aligned to kTaggedSize on builds with pointer
compression and are as such mis-aligned for atomic ops. This is not a
problem for on-heap values as the upper 32bits are anyways computed
from the cage. Is is a problem for generic C++ values though, as they
are used with Oilpan.

This CL adds the standard marker snapshot protocol for embedder fields.

Marker:
1. Snapshot embedder fields
2. Try to mark host object
3. On success: process snapshot

Main thread:
1. On setting embedder fields mark the object black first
2. Emit a write barrier for the embedder fields

This will get simpler with the heap sandbox that uses a separate table
for embedder fields. Once the sandbox is the default configuration, we
	can use it as dependency for the concurrent fast path.

Bug: chromium:1285706
Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78604}
      142dd775
    • Patrick Thier's avatar
      [string] Make String internalization threadsafe for shared strings · cc3c93f1
      Patrick Thier authored 
      This CL fixes 2 issues with string internalization when the string table
is shared:
1. In-place migration of a string's map to Internalized was done before
   it was sure that the string is going to be internalized (outside the
   critical section). To fix this problem StringTableKey::AsHandle() is
   now split into StringTableKey::PrepareForInsertion(), which is
   invoked outside the critical section and creates a copy if
   necessary, and StringTableKey::GetHandleForInsertion(), which is
   invoked inside the critical section only for string table misses.
   Migration of the map is handled by this method.
2. TryStringToIndexOrLookupExisting() didn't handle already internalized
   strings. So far this was impossible, as this method was only invoked
   for strings that were checked not to be internalized. However with
   a shared string table, the string could be internalized after the
   checks.

Bug: v8:12007
Change-Id: I193d6b54dc41360eee47d21cbcaa36d2652d85dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368103Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78600}
      cc3c93f1
  5. 12 Jan, 2022 8 commits
  7. 11 Jan, 2022 5 commits
  9. 10 Jan, 2022 3 commits
    • 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
    • Romain Pokrzywka's avatar
      [heap] Fix NewArrayList tripping DCHECK with LocalFactory · d6f8af01
      Romain Pokrzywka authored 
      LocalFactory::AllocateRaw() only allows the kOld and kSharedOld
allocation types, but NewArrayList() calls NewFixedArray() without
an explicit allocation argument, which then defaults to kYoung.

Add an allocation argument to NewArrayList() with the same default
value as for NewFixedArray() and pass kOld when calling it from
NewScriptWithId() to avoid tripping the DCHECK with LocalFactory.

Follow-up to https://crrev.com/c/3211575

Bug: chromium:1244145
Change-Id: I88d394bda250c45bf49141b78c09f6ca4a61dbe3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3354087Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78540}
      d6f8af01
    • Shu-yu Guo's avatar
      [heap] Fix --trace-gc-object-stats stats in debug builds · fb855334
      Shu-yu Guo authored 
      Bug: v8:11708
Change-Id: Ibf0f91b9e63646f226a2e70ec4a1733820e968ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3373135
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78538}
      fb855334
  11. 04 Jan, 2022 1 commit
  13. 03 Jan, 2022 2 commits
    • 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
    • Omer Katz's avatar
      cppgc: Fix leftover cached events · 97751649
      Omer Katz authored 
      Clear cached events if there is no embedder recorder.

Bug: chromium:1154636
Change-Id: I9ad3b752ea242d07b417ce3022936789c47afc6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3358292Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78464}
      97751649
  15. 29 Dec, 2021 1 commit
  17. 27 Dec, 2021 1 commit
    • Omer Katz's avatar
      cppgc-js, heap: Concurrently push references from v8 to Oilpan · d10f61e1
      Omer Katz authored 
      Included in this CL:
(*) Introduce CppMarkingState that V8 should use to push references to
    Oilpan. CppMarkingState allocates its own Worklist::Locals to
    support concurrent updates from V8.
(*) Split Oilpan MarkingWorklist object to form a base class used by
    CppMarkingState.
(*) Remove MarkerFactory and split marking initialization. Marking
    worklists should already be initialized when V8 initializes
    visitors. For incremental marking, this requires splitting
    marking initialization and marking start.
(*) Drive-by: Mark JSObject::IsApiWrapper and
    JSObject::IsDroppableApiWrapper as const.

Bug: v8:12407
Change-Id: I35cc816343da86f69a68306204675720e9b3913f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293410Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78446}
      d10f61e1
  19. 22 Dec, 2021 1 commit
  21. 21 Dec, 2021 2 commits
  23. 20 Dec, 2021 1 commit
  25. 16 Dec, 2021 2 commits
  27. 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
  29. 14 Dec, 2021 3 commits
  31. 13 Dec, 2021 1 commit
  33. 11 Dec, 2021 1 commit