Skip to content

V
V8
Switch branch/tag
  1. 23 Jun, 2021 1 commit
  3. 01 Mar, 2021 1 commit
    • Clemens Backes's avatar
      [api][no-wasm] Disable Webassembly in the API · 0be822b4
      Clemens Backes authored 
      This CL removes the includes of src/wasm files from the API if Wasm is
disabled (v8_enable_webassembly=false). This will allow to later
remove the whole src/wasm directory from compilation.
Since we do not want to modify the exposed API in a no-wasm build, we
instead make all Wasm-related functions fail.

R=ulan@chromium.org

Bug: v8:11238
Change-Id: I61038e75ac62871758351eb01f299fe68d478c82
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726504Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73100}
      0be822b4
  5. 12 Feb, 2021 1 commit
    • Benedikt Meurer's avatar
      [stack-traces] Simplify and speedup stack trace collection. · eed0d27c
      Benedikt Meurer authored 
      Following up on https://crrev.com/c/2689185, this CL significantly
simplifies the whole implementation of the stack trace capturing.

Before this CL, capturing any stack trace (for the purpose of the API or
Error.stack) would roughly work like this:

  1. The CaptureStackTrace() function uses the StackFrameIterator to
     walk the system stack. For each native frame it uses the
     FrameSummary abstraction to get all (including potentially inlined)
     frames. For each of those it appends a record consisting of six
     elements to a FrameArray (this holds pointers to the actual
     closures and receivers).
  2. Afterwards the FrameArray is shrinked to the required size, and a
     new FixedArray is allocated, and initialized with new
     StackTraceFrame objects where each holds a reference to the
     FrameArray, the index of the frame, and an initially uninitialized
     StackFrameInfo reference. This new FixedArray is then returned from
     CaptureStackTrace() and either stored on a message object or
     provided to the API as v8::StackTrace.

The new approach removes a lot of the machinery in between and directly
creates a FixedArray of StackFrameInfo objects in CaptureStackTrace().
These StackFrameInfo objects are directly exposed as v8::StackFrame on
the public API, and they hold the six fields that were previously stored
flat in the FrameArray. This not only avoids a lot of copying around of
data and creation of temporary objects and handles, but most importantly
unifies and simplifies the stack frame function inside StackFrameInfo,
so you no longer need to wonder which function / object might be
responsible for a certain API.

There's still a lot of room for improvement. In particular we currently
don't cache the source position for a given StackFrameInfo (or
globally), but rather recompute it every time. This is still very fast,
significantly faster than the previous approach.

There are some notable (potentially user visible) changes:

  - The CallSite#GetPosition() method now consistently returns the
    Wasm module relative bytecode offset for all Wasm frames (previously
    it'd return the function relative bytecode offset for non-asm.js
    Wasm frames).
  - The column and line numbers returned from StackFrameInfo methods are
    consistently 1-based now, instead of sometimes being 0-based (Wasm)
    and sometimes being 1-based (JS and asm.js Wasm). The only
    potentially noticable difference is that for
    CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but
    that was wrong and useless anyways.
  - CallSite#GetThis() would sometimes return the_hole, another bug
    flushed out by this CL.

The CL also contains some other not noteworthy drive-by-cleanups.

Fixed: chromium:1057211
Bug: chromium:1077657, chromium:1069425, v8:8742
Bug: chromium:1127391, chromium:1098530, chromium:981541
Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72694}
      eed0d27c
  7. 08 Jan, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Remove special wasm RemoteObject type. · cde7a77e
      Benedikt Meurer authored 
      Previously we had introduced a special `v8::internal::WasmValue` type
which we used to expose Wasm values to the Scope view in Chromium
DevTools. The problem however is that these values cannot be exposed to
JavaScript (and in particular not to Debug Evaluate), which means that
particularly for v128 and i64 we have inconsistent representations
across the various parts of DevTools.

This change removes the `wasm` type from the RemoteObject and all the
adjacent logic, and paves the way for a uniform representation of Wasm
values throughout DevTools. For i64 we will simply use BigInt
consistently everywhere, and for i32, f32 and f64 we'll just use Number.
For externref we will represent the values as-is directly. For v128
values we currently use a Uint8Array, but will introduce a dedicated
WasmSimd128 class in a follow-up CL.

Bug: chromium:1071432
Fixed: chromium:1159402
Change-Id: I0671e5736c9c27d7ca376e23ed74f16d36e03c80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614428Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71962}
      cde7a77e
  9. 07 Dec, 2020 1 commit
    • Benedikt Meurer's avatar
      [wasm] Use WebAssembly.Memory objects in the scope chain. · 058299a8
      Benedikt Meurer authored 
      Previously V8 would wrap the WebAssembly.Memory backing stores into
Uint8Arrays and report that as memories, but that's confusing to the
developer, since that's not what's really being used. The way that
DevTools presents the backing stores of memories, it's still perfectly
possible to get hold of an Uint8Array if that's what the developer is
looking for.

To make it possible to easily identify the WebAssembly.Memory objects
in the DevTools front-end (in particular for the memory inspector) we
add a 'webassemblymemory' subtype to the Chrome DevTools Protocol. We
also improve the description for the memories to include the number
of active pages.

Fixed: chromium:1155566
Screenshot: https://imgur.com/8enx57u.png
Change-Id: I63dbabe0e372e9ad6dcc8e6642cdb743147a620c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2574699Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71641}
      058299a8
  11. 30 Nov, 2020 2 commits
  13. 26 Nov, 2020 1 commit
  15. 24 Nov, 2020 1 commit
    • Daniel Clark's avatar
      [modules] Add refactored API to get ModuleRequests and expose import assertions · f588c889
      Daniel Clark authored 
      This change refactors the v8.h API as discussed in
https://docs.google.com/document/d/1yuXgNHSbTAPubT1Mg0JXp5uTrfirkvO1g5cHHCe-LmY/edit#heading=h.q0c9h4p928mn
such that a v8::Module exposes module requests as a FixedArray of
ModuleRequest objects, which can then be used to obtain their module
specifier and source code offset.  This replaces the old functions that
passed back individual specifier Strings and Locations via repeated
calls to getters that take an index.  These are marked as deprecated.

The new ModuleRequest interface includes a getter for an
ImportAssertions FixedArray, which will contain the import assertions
for the request if --harmony-import-assertions is set, and will be
empty otherwise.

One notable change here is that the APIs now return source code offsets
rather than v8::Locations.  The host must then call the new
Module::SourceOffsetToLocation to convert these offsets into line/column
numbers. This requires a bit more back-and-forth, but allows the host to
defer the cost of converting from source offset to line/column numbers
until an error needs to be reported, potentially skipping the work
altogether.

Bug: v8:10958
Change-Id: I181639737c701e467324e6c781aa4d7bdd87ae8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2545577
Commit-Queue: Dan Clark <daniec@microsoft.com>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71387}
      f588c889
  17. 06 Aug, 2020 1 commit
  19. 30 Jul, 2020 1 commit
    • Dominik Inführ's avatar
      [handles] Add PersistentHandlesScope · 3c6d9aac
      Dominik Inführ authored 
      PersistentHandlesScope works similar to the DeferredHandleScope, but
returns PersistentHandles instead of DeferredHandles on Detach().

Since PersistentHandlesScope takes over filled blocks from the
main thread local handle, remove the block_size_ field and use
kHandleBlockSize instead. This way all blocks have exactly the same size.

Bug: v8:10315
Change-Id: I295cad6f84852f87c55d95572905069443f5698c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324254
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69138}
      3c6d9aac
  21. 04 May, 2020 1 commit
  23. 30 Apr, 2020 1 commit
  25. 15 Apr, 2020 1 commit
  27. 24 Feb, 2020 1 commit
  29. 10 Feb, 2020 1 commit
  31. 09 Feb, 2020 1 commit
    • Michael Achenbach's avatar
      Revert "[weakrefs] Schedule FinalizationGroup cleanup tasks from within V8" · 72fc962b
      Michael Achenbach authored 
      This reverts commit 31d8ff7a.

Reason for revert: https://crbug.com/v8/10190

Original change's description:
> [weakrefs] Schedule FinalizationGroup cleanup tasks from within V8
> 
> Deprecate the following explicit FinalizationGroup APIs in favor of
> automatic handling of FinalizationGroup cleanup callbacks:
>   - v8::Isolate::SetHostCleanupFinalizationGroupCallback
>   - v8::FinaliationGroup::Cleanup
> 
> If no HostCleanupFinalizationGroupCallback is set, then
> FinalizationGroup cleanup callbacks are automatically scheduled by V8
> itself as non-nestable foreground tasks.
> 
> When a Context being disposed, all FinalizationGroups that are
> associated with it are removed from the dirty list, cancelling
> scheduled cleanup.
> 
> Bug: v8:8179
> Change-Id: Ic09313a11dd00af36d1f698250b3d735155f45e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986392
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66184}

TBR=ulan@chromium.org,rmcilroy@chromium.org,syg@chromium.org

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

Bug: v8:8179
Change-Id: If7869e9a5841803c10e748691f019a7d28f3b62e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043807Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66190}
      72fc962b
  33. 08 Feb, 2020 1 commit
  35. 10 Dec, 2019 1 commit
  37. 04 Dec, 2019 1 commit
    • Joyee Cheung's avatar
      [class] implement inspector support for private instance methods · 963ff849
      Joyee Cheung authored 
      This patch implements inspector support for private instance methods:

- Previously to implement brand checking for instances with private
  instance methods we store the brand both as the value with the brand
  itself as the key in the stances. Now we make the value the context
  associated with the class instead.
- To retrieve the private instance methods and accessors from the
  instances at runtime, we look into the contexts stored with the
  brands, and analyze the scope info to get the names as well as
  context slot indices of them.
- This patch extends the `PrivatePropertyDescriptor` in the inspector
  protocol to include optional `get` and `set` fields, and make the
  `value` field optional (similar to `PropertyDescriptor`s).
  Private fields or private instance methods are returned in the
  `value` field while private accessors are returned in the `get`
  and/or `set` field. Property previews for the instaces containing
  private instance methods and accessors are also updated similarly,
  although no additional protocol change is necessary since the
  `PropertyPreview` type can already be used to display accessors.

Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit

Bug: v8:9839, v8:8330
Change-Id: If37090bd23833a18f75deb1249ca5c4405ca2bf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934407
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65337}
      963ff849
  39. 06 Nov, 2019 1 commit
  41. 10 Oct, 2019 1 commit
  43. 17 Sep, 2019 1 commit
  45. 13 Sep, 2019 1 commit
  47. 23 Aug, 2019 1 commit
  49. 22 Aug, 2019 2 commits
  51. 20 Aug, 2019 1 commit
  53. 30 Jul, 2019 1 commit
    • Sathya Gunasekaran's avatar
      [WeakRefs] Make cleanup callback run as a task · 743ce772
      Sathya Gunasekaran authored 
      Previously, this was run as a microtask and this CL changes it to run
as a separate task as mandated by the current WeakRef spec.

This CL also introduces a FinalizationGroup type to the V8 API
representing the JSFinalizationGroup. This has a `Cleanup`
function that runs the cleanup callback associated with it.

SetHostCleanupFinalizationGroupCallback is added to set
the embedder defined HostCleanupFinalizationGroupCallback.

ClearKeptObject is exposed on the v8::Isolate to reset the strongly
held set of objects.

The general workflow is the following:

(a) When the GC notices that a given finalization group has dirty
    cells, it calls HostCleanupFinalizationGroupCallback with the given
    finalization group.

(b) As part of HostCleanupFinalizationGroupCallback, the embedder
    enqueues a task that at some point later calls
    FinalizationGroup::Cleanup.

(c) At some point in the future, FinalizationGroup::Cleanup is called,
    which runs the cleanup callback of the finalization group.

This patch also includes d8 changes to use these new APIs. Currently,
d8 cycles through the enqueued finalization groups after a synchronous
turn (and it's microtask checkpoint) and runs the cleanup callbacks.

Change-Id: I06eb4da2c103b2792a9c62bc4b98fd4e5c4892fc
Bug: v8:8179
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655655
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62984}
      743ce772
  55. 19 Jun, 2019 1 commit
  57. 23 May, 2019 2 commits
  59. 22 May, 2019 1 commit
  61. 17 May, 2019 1 commit
  63. 16 May, 2019 2 commits
  65. 04 Apr, 2019 1 commit
  67. 12 Mar, 2019 1 commit
  69. 27 Feb, 2019 1 commit
  71. 18 Feb, 2019 1 commit
    • Simon Zünd's avatar
      [stack trace] Change API to use new StackTraceFrame class · e295ca07
      Simon Zünd authored 
      This CL changes "CaptureCurrentStackTrace" to use the
FrameArrayBuilder. This way, simple and detailed stack traces use
the same mechanism to capture stack traces.

The stack trace API is implemented using the previously introduced
StackTraceFrame class, which uses FrameArray as a backing store and
can lazily initialize StackFrameInfo objects.

R=jgruber@chromium.org, yangguo@chromium.org

Bug: v8:8742
Change-Id: I716a9baa33d9ca1d2ef41a73fba26234a03b045b
Reviewed-on: https://chromium-review.googlesource.com/c/1469822
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59651}
      e295ca07