Skip to content

V
V8
Switch branch/tag
  1. 02 Nov, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm] Simplify 'ref' field for API-defined functions · 48b2b891
      Manos Koukoutos authored 
      Design doc:  https://bit.ly/3jEVgzz

Summary:
We change the context for WasmJSFunction and WasmCapiFunction from a
tuple containing the instance to a triple WasmAPIFunctionRef =
{isolate root, context, callable}. This way we do not have to maintain
the correct instance at runtime. Also, a few places in the code get
simplified.

Changes:
- In WasmGraphBuilder, support having a WasmAPIFunctionRef at parameter
  0.
- Remove unpacking of (instance, callable) tuple from code generators.
- Remove the part in WasmGraphBuilder and LiftoffCompiler that used to
  set the instance field of the function reference.
- Modify code that handles the 'ref' field in wasm-objects.*, factory.*
  and c-api.cc.
- Fix the recorded safepoint address for arm when calling a C function
  from wasm.
- (Drive-by) Remove WasmAllocatePair.

Bug: v8:11510
Change-Id: I2a4ef3abaf9da36c4a2d85b434965a40a289b9ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3236719
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77639}
      48b2b891
  3. 20 Sep, 2021 1 commit
  5. 17 Sep, 2021 1 commit
  7. 25 Aug, 2021 1 commit
  9. 24 Aug, 2021 1 commit
    • Dan Elphick's avatar
      Reland "[include] Split out v8.h" · ec06bb6c
      Dan Elphick authored 
      This is a reland of d1b27019

Fixes include:
Adding missing file to bazel build
Forward-declaring classing before friend-classing them to fix win/gcc
Add missing v8-isolate.h include for vtune builds

Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}

Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
Bug: v8:11965
Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76460}
      ec06bb6c
  11. 23 Aug, 2021 2 commits
    • Dan Elphick's avatar
      Revert "[include] Split out v8.h" · 44fe02ce
      Dan Elphick authored 
      This reverts commit d1b27019.

Reason for revert: Broke vtune build, tsan build and possibly others

Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}

Bug: v8:11965
Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76428}
      44fe02ce
    • Dan Elphick's avatar
      [include] Split out v8.h · d1b27019
      Dan Elphick authored 
      This moves every single class/function out of include/v8.h into a
separate header in include/, which v8.h then includes so that
externally nothing appears to have changed.

Every include of v8.h from inside v8 has been changed to a more
fine-grained include.

Previously inline functions defined at the bottom of v8.h would call
private non-inline functions in the V8 class. Since that class is now
in v8-initialization.h and is rarely included (as that would create
dependency cycles), this is not possible and so those methods have been
moved out of the V8 class into the namespace v8::api_internal.

None of the previous files in include/ now #include v8.h, which means
if embedders were relying on this transitive dependency then it will
give compile failures.

v8-inspector.h does depend on v8-scripts.h for the time being to ensure
that Chrome continue to compile but that change will be reverted once
those transitive #includes in chrome are changed to include it directly.

Full design:
https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing

Bug: v8:11965
Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76424}
      d1b27019
  13. 29 Jul, 2021 1 commit
  15. 01 Jul, 2021 1 commit
  17. 21 Jun, 2021 1 commit
  19. 18 Jun, 2021 2 commits
  21. 10 Jun, 2021 2 commits
  23. 25 May, 2021 1 commit
  25. 19 May, 2021 2 commits
  27. 30 Apr, 2021 1 commit
  29. 29 Apr, 2021 1 commit
  31. 13 Apr, 2021 1 commit
  33. 22 Mar, 2021 1 commit
  35. 08 Mar, 2021 1 commit
  37. 22 Feb, 2021 1 commit
  39. 15 Feb, 2021 1 commit
    • Benedikt Meurer's avatar
      [stack-traces] Cache source position on StackFrameInfos. · 7b07c779
      Benedikt Meurer authored 
      Previously we had cached the source position information on
JSStackFrame (C++) objects and reused that between calls to
GetLineNumber() and GetColumnNumber(). The refactoring in
https://crrev.com/eed0d27c2f774b3adbc85d0a5fb30a8cf0f018a8
effectively removed that cache, while still making things
faster though.

This CL puts back the caching on the StackFrameInfo objects
by reusing the `offset` slot to store the computed source
position (as indicated by a bit in the `flags`). For promise
combinator async frames, the bit is always set and the
`offset_or_source_position` slot thus always contains the source
position (aka the `promise index` in this case). We also
added a `StackFrameInfo::ComputeLocation()` method to remove the
last remaining place where we'd peek into the StackFrameInfo from
outside stack-frame-info.{cc,h}.

Also-By: kimanh@chromium.org
Bug: chromium:1077657, v8:8742, chromium:1069425
Change-Id: I59e26a91965617163776e6cc2610b88e6925452c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695386
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72752}
      7b07c779
  41. 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
  43. 28 Jan, 2021 1 commit
  45. 07 Jan, 2021 1 commit
  47. 17 Nov, 2020 1 commit
  49. 13 Oct, 2020 1 commit
  51. 05 Oct, 2020 1 commit
  53. 24 Sep, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Remove --wasm-max-mem-pages-growth flag · 5f265c33
      Clemens Backes authored 
      This unifies {max_initial_mem_pages} and {max_maximum_mem_pages} into
{max_mem_pages}.
The {CompilationEnv} constructor was incorrectly using the former
instead of the latter anyway. This did not really matter though, since
they typically have the same value.
Also, there is not a single test that sets --wasm-max-mem-pages-growth.

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

Bug: v8:10949
Change-Id: Ib7ab9b4c239d50b72013087eda5a214829c90369
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426619Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70114}
      5f265c33
  55. 18 Sep, 2020 1 commit
    • Manos Koukoutos's avatar
      [wasm-gc] Preparation for typed function tables · a5f68abe
      Manos Koukoutos authored 
      Changes:
- Rename IsSignatureEqual -> MatchesSignature for consistency
- Add WasmInstanceObject field to WasmTableObject.
- Improve some error messages related to tables in
  function-body-decoder-impl.h.
- Introduce WasmTable::IsValidTableType. Use it wherever appropriate.
- Overload equality operators in HeapType to work with
  HeapType::Representation.
- Rename DynamicTypeCheckRef -> TypecheckJSObject.
- Handle WasmCapiFunctions in TypecheckJSObject.
- Use TypecheckJSObject in WasmTableObject::IsValidElement.
- A few more minor improvements.

Bug: v8:9495
Change-Id: I2867dd3486d7c31717ac26b87a50e15cf2b898be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416491
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70001}
      a5f68abe
  57. 16 Sep, 2020 1 commit
  59. 14 Sep, 2020 1 commit
  61. 11 Aug, 2020 1 commit
  63. 06 Aug, 2020 1 commit
    • Andreas Haas's avatar
      [wasm] Check size of tables dynamically · 47434265
      Andreas Haas authored 
      We used to check the size of tables at compile time, and threw a
CompilationError if a given size exceeded the implementation-defined
limit. However, the spec defines that an error should only be thrown
when the implementation-defined limit is reached, which is either at
instantiation time of during runtime at a table.grow.

With this CL the V8 implementation becomes spec compliant in this
regard.

R=jkummerow@chromium.org

Bug: v8:10556
Change-Id: I7d0e688b385a65e4060a569e5ab1dec68947ceea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326331
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69267}
      47434265
  65. 01 Jul, 2020 1 commit
    • Manos Koukoutos's avatar
      [wasm] Properly implement parsing of s33 values · 5df74c35
      Manos Koukoutos authored 
      Motivation:
We used to approximate s33/i33 value parsing by first checking for
specific negative codes, and then parsing an u32 value if that failed.
This is not correct in all cases.

Changes:
- Implement i33 parsing in Decoder.
- Factor out parsing of heap types into read_heap_type.
- Introduce HeapType::kBottom.
- Introduce helper functions in WasmFeatures and value_type_reader.
- Remove macros from the parsing of value types.
- HeapType::code now returns an i32 for compatibility with the i33
  requirement.
- Introduce HeapType::Repr.
- Renamings: HeapType::type() -> representation(),
             ValueType::heap() -> heap_representation()

Bug: v8:7748
Change-Id: I04deabce8837a48af2226411cd706a397f9e5725
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2274118
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68633}
      5df74c35
  67. 29 Jun, 2020 1 commit
  69. 24 Jun, 2020 1 commit
  71. 18 Jun, 2020 1 commit
    • Manos Koukoutos's avatar
      [wasm-gc] Change ValueType representation to account for new types · 52f65296
      Manos Koukoutos authored 
      Motivation:
Changes to the typed function references and gc proposals solidified
the notion of heap type, clarified nullable vs. non-nullable reference
types, and introduced rtts, which contain an integer depth field in
addition to a heap type. This required us to overhaul our ValueType
representation, which results in extensive changes.

To keep this CL "small", we do not try to implement the binary encoding
as described in the proposals, but rather devise a simpler one of our
own (see below). Also, we do not try to implement additional
functionality for the new types.

Changes:
- Introduce HeapType. Move heap types from ValueType to HeapType.
- Introduce Nullability for reference types.
- Rework ValueType helper methods.
- Introduce rtts in ValueType with an integer depth field. Include depth
  in the ValueType encoding.
- Make the constructor of ValueType private, instead expose static
  functions which explicitly state what they create.
- Change every switch statement on ValueType::Kind. Sometimes, we need
  nested switches.
- Introduce temporary constants in ValueTypeCode for nullable types,
  use them for decoding.
- In WasmGlobalObject, split 'flags' into 'raw_type' and 'is_mutable'.
- Change IsSubtypeOfRef to IsSubtypeOfHeap and implement changes in
  subtyping.
- kWasmFuncRef initializers are now non-nullable. Initializers are
  only required to be subtypes of the declared global type.
- Change tests and fuzzers as needed.

Bug: v8:7748
Change-Id: If41f783bd4128443b07e94188cea7dd53ab0bfa5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247657
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68408}
      52f65296