Skip to content

V
V8
Switch branch/tag
  1. 12 Jul, 2022 1 commit
    • Jose Dapena Paz's avatar
      [profiler] Emit ETW events only on a trace session. · 0e7d5763
      Jose Dapena Paz authored 
      If a tracing session starts after a script load has happened, then it is
not emitted, so the source information is not visible in ETW. This is
because we keep track of the loads already emitted, and we try to launch
traces even when recording is not happening.

To prevent this problem, this CS keeps track of when recording is
happening. So, when it starts, it will emit all the already generated
code immediately. This will add some overhead on tracing session start
if system instrumentation is enabled, but this is better than not
having instrumentation for previous symbols.

There is still one problem: for each active isolate, it calls for
replaying the event recording in an asynchronous task. So, for any
JS task that is already running when tracing start, symbols will not
be available. This makes this change less useful as, for a batch task
or any long JS code that is already running when tracing start, we
will not get symbols yet. Only after the foreground task runner runs
the task to emit the ETW events we will get the symbols resolved in
the trace.

An specific approach was required for d8 interactive shell. As, when
showing prompt, it is not processing the task runner queue, and it
is only processed when the next script is launched, it first checks
if it needs to generate ETW symbols information before running the
script.

Bug: v8:12932
Change-Id: I8b056c69cee0350f921a01c87beb9f2d51e10583
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3705541Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: José Dapena Paz <jdapena@igalia.com>
Cr-Commit-Position: refs/heads/main@{#81673}
      0e7d5763
  3. 11 Jul, 2022 3 commits
    • Maksim Sadym's avatar
      Fix Date BiDi format · 126d4779
      Maksim Sadym authored 
      1. Add `toISOString` to `v8::Date`.
2. Switch serialization to `ISOString`.

Bug: v8:13043
Change-Id: I8a852f4a4a46bb3b8e5d52ef3cdffde7a408b403
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749203
Auto-Submit: Maksim Sadym <sadym@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81647}
      126d4779
    • Joyee Cheung's avatar
      [serializer] allow SnapshotCreator to destruct without a blob · f3cad8ce
      Joyee Cheung authored 
      Previously SnapshotCreator demanded a blob to be created before
it can be destructed in debug build, this patch removes the
DCHECK so that the embedder can choose not to create the blob
when e.g. the snapshot building isn't successful due to errors.

Change-Id: I72939be1e0d79b257b9761f48a72e45325a1f6d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716682Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#81644}
      f3cad8ce
    • Samuel Groß's avatar
      [sandbox] Prepare ExternalPointerTable rollout · 8a59678b
      Samuel Groß authored 
      This CL does the following:
- It enables (i.e. allocates and initializes) the per-Isolate
  ExternalPointerTable when the sandbox is enabled.
- It refactors the list of external pointer tags to mark them as
  "sandboxed" or "unsandboxed". An unsandboxed external pointer has a
  null tag.
- It changes V8_SANDBOXED_EXTERNAL_POINTERS to now essentially just
  enable sandboxing for all available tags.
- It modifies all low-level external pointer accessors to perform the
  ExternalPointerLookup only if the tag is non-zero and otherwise treat
  the slot as containing a raw pointer.

This now allows rolling out external pointer sandboxing incrementally
(separately for each external pointer type), which will in turn allow
for more precise performance measurements of the impact of the sandbox.

Note: when an external pointer tag is now marked as sandboxed (and
V8_SANDBOXED_EXTERNAL_POINTERS is not enabled), the underlying slots are
still 64-bits in size. This simplifies the implementation as we would
otherwise need to deal with variably-sized external pointer slots. Local
benchmarking suggests that the benefits from 32-bit external pointer
slots are insignificant on typical benchmarks, so this should be ok.

Drive-by: rename kExternalPointerSize to kExternalPointerSlotSize to
make it more clear what it refers to (the on-heap storage size). Also
delete CodeStubAssembler::InitializeExternalPointerField as it is not
currently used and the implementation is fairly inefficient.

Bug: v8:10391
Change-Id: I7c38729c7e9048d737a1a8ced84749f5b1f7feab
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/+/3736447Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81636}
      8a59678b
  5. 07 Jul, 2022 1 commit
  7. 28 Jun, 2022 2 commits
  9. 27 Jun, 2022 1 commit
    • Samuel Groß's avatar
      [sandbox] Turn ExternalPointerTag into a template parameter · 8ca93205
      Samuel Groß authored 
      The ExternalPointerTags are assumed to be compile-time constants in most
cases, so turning them into template parameters enforces that. As
decisions such as whether to use the per-isolate or the shared external
pointer table are encoded into the tag values, forcing those to be
compile-time constants guarantees that the compiler will be able to
inline the correct logic when accessing an external pointer.

With this, there are now two (high-level) ways of accessing external pointer fields from C++: the Read/WriteExternalPointerField methods
which require the ExternalPointerTag to be a template parameter, and the
ExternalPointerSlot class which takes the tag as an argument. The latter
is for example used for snapshot deserialization and by the garbage
collector (more generally, by the ObjectVisitor::VisitExternalPointer
method), where the tag is not a compile-time constant.

Finally, this CL also introduces a new ExternalPointerHandle type which
represents the (opaque) on-heap representation of a reference to an
entry in an ExternalPointerTable when sandboxing is enabled. Making this
its own type makes the code a bit more readable.

Bug: v8:10391
Change-Id: I867b8ce41d15d485f1dc66786f233c710c56afcb
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/+/3720641Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81402}
      8ca93205
  11. 21 Jun, 2022 1 commit
  13. 20 Jun, 2022 2 commits
  15. 14 Jun, 2022 1 commit
  17. 13 Jun, 2022 1 commit
    • Clemens Backes's avatar
      [wasm] Rename "OnModuleCompiled" and related callbacks · 61a6fd84
      Clemens Backes authored 
      Already after enabling Liftoff, the name did not match the semantics any
more. The callback was called after top-tier finished, not after initial
compilation of the module finished.
With dynamic tiering, the name is even less fitting.

This CL renames the "OnModuleCompiled" callback in the API to
"MoreFunctionsCanBeSerialized", which makes it more obvious what the
API should be used for. It also internally renames all related typedefs
and methods accordingly.

One call of the callback in the streaming decoder was already wrong
before this CL and is being removed.

R=jkummerow@chromium.org, cbruni@chromium.org

Bug: v8:12899
Change-Id: I95c0fc9e32442383e47e4370e31277cc065bf0fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687689Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81093}
      61a6fd84
  19. 10 Jun, 2022 2 commits
  21. 09 Jun, 2022 3 commits
  23. 08 Jun, 2022 1 commit
  25. 31 May, 2022 1 commit
  27. 30 May, 2022 1 commit
  29. 25 May, 2022 1 commit
  31. 19 May, 2022 2 commits
  33. 18 May, 2022 1 commit
    • Clemens Backes's avatar
      [wasm] Use new OOM API for passing details · 7e14a41c
      Clemens Backes authored 
      In particular use the same "location" in any call site to make grouping
OOMs easier. Move the detail information into the new OOMDetails struct.

Since we cannot construct OOMDetails via "{.detail = ...}" yet (C++20),
we add another variants of FatalProcessOutOfMemory which receives the
detail string and internally stores it in an OOMDetails struct.

R=jkummerow@chromium.org
CC=mlippautz@chromium.org

Bug: chromium:1323177
Change-Id: Ie10cde8dd060867515fab4c61c15030f9c3ccff9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652298Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80612}
      7e14a41c
  35. 16 May, 2022 3 commits
  37. 13 May, 2022 3 commits
  39. 11 May, 2022 2 commits
  41. 09 May, 2022 3 commits
  43. 06 May, 2022 1 commit
  45. 03 May, 2022 1 commit
  47. 28 Apr, 2022 1 commit
  49. 25 Apr, 2022 1 commit