Skip to content

V
V8
Switch branch/tag
  1. 21 Jan, 2022 1 commit
  3. 20 Jan, 2022 2 commits
    • Samuel Groß's avatar
      [sandbox] Implement GC for the external pointer table · 4a3e41c5
      Samuel Groß authored 
      The external pointer table is now managed by the GC, which marks entries
that are alive during major GC, then sweeps the table afterwards to free
all dead entries and build a free list from them. For now, only major GCs
are supported, Scavenger GCs do not interact with the external pointer table.

In more detail, garbage collection of the external pointer table works
as follows:

1. The external pointer table now reserves a large region of virtual
   address space for its backing buffer and is then never reallocated,
   only grown in place until the maximum size is reached.
2. When the GC's marking visitor marks a HeapObject with an external
   pointer as alive, it also marks the corresponding external pointer
   table entry as alive. This can happen on a background thread.
3. For that, it uses the MSB of each entry in the table to indicate
   whether the entry has been marked or not. This works because the MSB
   is always cleared during the AND-based type check performed when
   accessing an external pointer.
4. After marking, the external pointer table is swept while the mutator
   is stopped. This builds an inline, singly-linked freelist of all
   newly-dead and previously-free entries.
5. When allocating an entry from the table, the first entry on the
   freelist is used. If the freelist is empty, the table grows,
   populating the freelist with the new entries.
6. Every newly-allocated entry is marked as alive, and every store to an
   existing entry also automatically marks that entry as alive (by also
   setting the MSB). This simplifies the design of the table GC with
   regards to concurrency (See ExternalPointerTable::Mark).

Bug: v8:10391
Change-Id: I8877fdf5576af3761bde65298951bb09e601bd14
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/+/3359625Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78708}
      4a3e41c5
    • Nico Hartmann's avatar
      Revert "[Torque] Generalize Torque literals to larger size" · 362e265d
      Nico Hartmann authored 
      This reverts commit 757830b0.

Reason for revert: Speculatively revert due to a number of
performance regressions

Original change's description:
> [Torque] Generalize Torque literals to larger size
>
> Previously, literals in Torque were stored as double values, which
> made it impossible to precisely represent 64 bit integer values.
> This CL replaces the old literal expression with an integer and
> floating point literal expression that are unbounded in size. We
> allow implicit conversion of these literals to arbitary integer
> and floating point types respectively and insert a corresponding
> bounds check into generated CSA.
>
> Bug: v8:7793
> Change-Id: I46c231aab92bc2f0c26955d1876079f306b358c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329792
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78671}

Bug: v8:7793
Change-Id: I9896e28b3c69b8cf2488bf93e993ec320d8c5d2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401866Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78706}
      362e265d
  5. 18 Jan, 2022 1 commit
  7. 17 Jan, 2022 2 commits
    • Patrick Thier's avatar
      [cleanup] Remove condition based on kJSArgcIncludesReceiver · db9f6bff
      Patrick Thier authored 
      The receiver is included unconditionally on all platforms
(kJSArgcIncludesReceiver is always true).
Remove all usages of kJSArgcIncludesReceiver from the code.

Bug: v8:11112
Change-Id: I7d62e6de65b73fe6d8c3293f32b500b760b08a3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322980Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78642}
      db9f6bff
    • Benedikt Meurer's avatar
      [debug] Decouple async event delegate instrumentation from PromiseHooks. · b46d5ffb
      Benedikt Meurer authored 
      As described in https://crbug.com/1287476, the fact that the
AsyncEventDelegate is currently implemented on top of the PromiseHooks
causes performance problems and makes it difficult to reason about the
exact (observed) semantics; this is because for this we intercept every
JSPromise creation (via PromiseHook::kInit) and walk the synchronous
stack at that point to see if we find one of Promise#then(),
Promise#catch() or Promise#finally() on the stack. And if we do so, we
report that to the AsyncEventDelegate (which is implemented in the
inspector and will then do the async stack/stepping logic on top).

This CL introduces dedicated instrumentation for Promise#then(), which
is also called from Promise#catch() and Promise#finally(), and uses that
instrumentation for the purpose of the AsyncEventDelegate. It also
adjusts the stack walk to not always walk the full stack (which might
lead to wrong results when calls to Promise#then(), which itself can
call back into user JavaScript, are found deeper in the stack), but
instead only check the top-most builtin frames and whatever user
JavaScript frame is underneath it.

On the standalone.js (from https://crbug.com/1287476#c1), when run with
the DevTools default of maxDepth=200, we go from around 4.00ms to around
0.36ms. For everything that does not call Promise#then() - either
explicitly or implicitly - or `await`s, there's now no observable
performance impact of turning on the AsyncEventDelegate.

Bug: chromium:1280519
Fixed: chromium:1287476
Change-Id: I4911bed146381fc46cfeefb763d6dfc32e8f6071
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386379
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78640}
      b46d5ffb
  9. 14 Jan, 2022 1 commit
    • Samuel Groß's avatar
      [sandbox] Improve sandboxed pointer support · 549ee6f3
      Samuel Groß authored 
      This CL removes the global IsValidBackingStorePointer function and turns
the DCHECKs that ensure that sandboxed pointers point into the sandbox,
which essentially cover the same condition, into CHECKs. This is mostly
to facilitate debugging during the initial rollout, and the CHECKs can
later be turned back into DCHECKs.

In addition, this CL adds a fallback to a partially-reserved sandbox
when sandboxed pointers are enabled and when the regular initialization
fails.

Bug: chromium:1218005
Change-Id: I75526f1a00ddb9095ae0e797dc9bb80a210f867b
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/+/3367617Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78620}
      549ee6f3
  11. 07 Jan, 2022 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
    • Marja Hölttä's avatar
      [rab/gsab] Add rab / gsab support to TA.p.{join,toLocaleString} · ef240dce
      Marja Hölttä authored 
      Bug: v8:11111
Change-Id: I5cdd26070eb6ddf264e46763a71097e9fb716bf0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3333924Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78383}
      ef240dce
  17. 14 Dec, 2021 1 commit
  19. 08 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Move Job pointer to SFI · 3b9091c8
      Leszek Swirski authored 
      Reduce the enqueuing cost of compiler-dispatcher jobs by getting rid of
the sets and hashmaps, and instead:

  1. Turning the pending job set into a queue, and
  2. Making the SharedFunctionInfo's UncompiledData hold a pointer to
     the LazyCompilerDispatcher::Job, instead of maintaining an
     IdentityMap from one to the other.

To avoid bloating all UncompiledData, this adds two new UncompiledData
subclasses, making it four subclasses total, for with/without Preparse
data and with/without a Job pointer. "should_parallel_compile"
FunctionLiterals get allocated an UncompiledData with a job pointer by
default, otherwise enqueueing a SFI without a job pointer triggers a
reallocation of the UncompiledData to add a job pointer.

Since there is no longer a set of all Jobs (aside from one for
debug-only), we need to be careful to manually clear the Job pointer
from the UncompiledData whenever we finish a Job (whether successfully
or by aborting) and we have to make sure that we implicitly can reach
all Jobs via the pending/finalizable lists, or the set of currently
running jobs.

Change-Id: I3aae78e6dfbdc74f5f7c1411de398433907b2705
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314833Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78302}
      3b9091c8
  21. 06 Dec, 2021 1 commit
  23. 02 Dec, 2021 1 commit
    • Samuel Groß's avatar
      Use CagedPointers for ArrayBuffer backing stores · 42ed4928
      Samuel Groß authored 
      This CL turns references to ArrayBuffer backing stores from
JSArrayBuffers, JSTypedArrays, and JSDataViews into CagedPointers
when those are enabled.

CagedPointers cannot generally represent nullptr, as NULL usually lies
outside the cage. As such, nullptr backing stores are replaced with a
special empty backing store value, which, in the current implementation,
points to the end of the cage, right in front of the trailing guard
regions. Due to this, it is no longer correct to compare a backing store
pointer against nullptr.

Bug: chromium:1218005
Change-Id: I4a6c7a82aabb4debcb6bb2babe4035ba2da8e79f
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/+/3244419
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78218}
      42ed4928
  25. 24 Nov, 2021 1 commit
    • Samuel Groß's avatar
      ArrayBuffer refactoring in preparation for CagedPointers · 6e68daf7
      Samuel Groß authored 
      The main changes of this CL are:

It should no longer be assumed that an empty ArrayBuffer has a nullptr
backing store. This is in preparation for the move to caged pointers,
which cannot represent nullptr, and will instead likely provide a
EmptyBackingStore constant pointing inside the virtual memory cage. For
that reason, a new JSArrayBuffer::IsEmpty() helper is introduced, which
should be used instead of checking against nullptr.

CodeStubAssembler::GetTypedArrayBuffer now checks for on-heap
TypedArrays instead of comparing the backing store pointer to nullptr.
This is consistent with the implementation in JSTypedArray::GetBuffer.

v8::ArrayBufferView::CopyContents now uses JSTypedArray::DataPtr instead
of relying on nullptr backing stores to handle on-heap TypedArrays.

The serializer and deserializer now check for IsEmpty() and use the
kEmptyBackingStoreRefSentinel value to serialize empty backing stores.

Empty ArrayBuffers allocated for on-heap TypedArrays now have a
byte_length of zero. This allows removing the allocation_length() (and
allocation_buffer()) methods, which were only (incorrectly, as they
don't account for GSABs) used for memory measurements.

Bug: chromium:1218005
Change-Id: Ib889ccf855f68525f7a614f3963e46ea56865fa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297709Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78069}
      6e68daf7
  27. 23 Nov, 2021 2 commits
  29. 22 Nov, 2021 1 commit
  31. 18 Nov, 2021 1 commit
  33. 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
  35. 16 Nov, 2021 1 commit
  37. 15 Nov, 2021 1 commit
  39. 04 Nov, 2021 1 commit
  41. 03 Nov, 2021 1 commit
  43. 29 Oct, 2021 1 commit
    • Samuel Groß's avatar
      Introduce CagedPointer · afd15549
      Samuel Groß authored 
      A CagedPointer is guaranteed to point into the Virtual Memory Cage and
will for example be used for ArrayBuffer backing stores when the heap
sandbox is enabled. In the current implementation, CagedPointers are
stored as offsets from the cage base, shifted to the left. Because the
cage base address is usually available in a register, accessing a
CagedPointer is very efficient, requiring only an additional shift and
add operation.

Bug: chromium:1218005
Change-Id: Ifc8c088e3862400672051a8c52840514dee2911f
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/+/3123417Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77614}
      afd15549
  45. 26 Oct, 2021 1 commit
  47. 06 Oct, 2021 1 commit
  49. 05 Oct, 2021 1 commit
  51. 01 Oct, 2021 1 commit
  53. 30 Sep, 2021 1 commit
  55. 28 Sep, 2021 1 commit
  57. 27 Sep, 2021 1 commit
  59. 24 Sep, 2021 1 commit
  61. 14 Sep, 2021 1 commit
  63. 08 Sep, 2021 1 commit
  65. 07 Sep, 2021 1 commit
  67. 06 Sep, 2021 1 commit
  69. 02 Sep, 2021 1 commit