Skip to content

V
V8
Switch branch/tag
  1. 11 Aug, 2022 3 commits
  3. 10 Aug, 2022 4 commits
  5. 09 Aug, 2022 5 commits
    • Qifan Pan's avatar
      Reland "Reland "[TurboFan] Support BigIntMultiply"" · 25530fd6
      Qifan Pan authored 
      This is a reland of commit 30ee0690

Avoid terminating from another thread in unit tests to make the termination of optimized bigint multiplication deterministic on windows

Original change's description:
> Reland "[TurboFan] Support BigIntMultiply"
>
> This is a reland of commit ccde4205
>
> Added a test case for terminating optimized bigint multiply and attached frame_state to the runtime call to provide deopt information to determine the throw location
>
> Original change's description:
> > [TurboFan] Support BigIntMultiply
> >
> > Bug: v8:9407
> > Change-Id: Iab0a4ca8dd5d83444d1addd6043a5c8e3a8577a7
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773773
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#82140}
>
> Bug: v8:9407
> Change-Id: Ia691d758265148da1de291365d41c7c1d1f98ddd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810391
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82232}

Bug: v8:9407
Change-Id: I7d04897f4e8f260aba31dbad55ce1263406473d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819621
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82304}
      25530fd6
    • Tobias Tebbi's avatar
      Revert "Reland "[shared-struct] Add Atomics.Condition"" · 74d4f133
      Tobias Tebbi authored 
      This reverts commit b1020a43.

Reason for revert: Causes timeout for `condition-workers`: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/40516/overview

Original change's description:
> Reland "[shared-struct] Add Atomics.Condition"
>
> This is a reland of commit e2066ff6
>
> Changes since revert:
> - Rebased against c9918524, which
>   uses the external pointer table for the WaiterQueueNode stored
>   in the state field when compressing pointers. This relaxes
>   the alignment requirement of the state field to be 4-bytes when
>   compressing pointers.
> - Moved the state field into the JSSynchronizationPrimitive base
>   class, since alignment and padding can now be made simpler.
>
> Original change's description:
> > [shared-struct] Add Atomics.Condition
> >
> > Bug: v8:12547
> > Change-Id: Id439aef9cab3348171a23378cdd47ede5f4d7288
> > Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630350
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Reviewed-by: Adam Klein <adamk@chromium.org>
> > Commit-Queue: Shu-yu Guo <syg@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#81734}
>
> Bug: v8:12547
> Change-Id: I638304c3d5722c64bd04708ed4cf84863cdebb81
> Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763787
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82278}

Bug: v8:12547
Change-Id: I27c2aeb131f1b68c2240323189db88d552aa92f9
Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3817187
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Owners-Override: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82292}
      74d4f133
    • jameslahm's avatar
      [runtime] Invalidate TypedArraySpeciesLookupChain protector · 15aa8c58
      jameslahm authored 
      ... when setting the prototype of TypedArray constructor.

Setting the __proto__ of TypedArray constructor could change TypedArray's
@@species, thus we need to invalidate the @@species protector.

Bug: v8:13110
Change-Id: Ib3b2c88d1136965c221492ff81a26ae69533b356
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3813063
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82282}
      15aa8c58
    • Samuel Groß's avatar
      [sandbox] Atomically load/store ExternalPointerHandles · f7c20bae
      Samuel Groß authored 
      Since those are accessed from background threads during marking, they
should generally be loaded and stored using atomic operations. Further,
when an external pointer slot is initialized, the handle should be
stored using release semantics to prevent reordering of the store into
the pointer table after the store of the handle to the object.

Bug: v8:10391, v8:13156
Change-Id: I5c33b4e791482f84e2770cd047a11f5762a0aa65
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/+/3812035Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82280}
      f7c20bae
    • Shu-yu Guo's avatar
      Reland "[shared-struct] Add Atomics.Condition" · b1020a43
      Shu-yu Guo authored 
      This is a reland of commit e2066ff6

Changes since revert:
- Rebased against c9918524, which
  uses the external pointer table for the WaiterQueueNode stored
  in the state field when compressing pointers. This relaxes
  the alignment requirement of the state field to be 4-bytes when
  compressing pointers.
- Moved the state field into the JSSynchronizationPrimitive base
  class, since alignment and padding can now be made simpler.

Original change's description:
> [shared-struct] Add Atomics.Condition
>
> Bug: v8:12547
> Change-Id: Id439aef9cab3348171a23378cdd47ede5f4d7288
> Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630350
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81734}

Bug: v8:12547
Change-Id: I638304c3d5722c64bd04708ed4cf84863cdebb81
Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763787Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82278}
      b1020a43
  7. 05 Aug, 2022 4 commits
  9. 04 Aug, 2022 1 commit
  11. 03 Aug, 2022 3 commits
  13. 02 Aug, 2022 4 commits
  15. 01 Aug, 2022 1 commit
  17. 29 Jul, 2022 4 commits
  19. 28 Jul, 2022 5 commits
    • Marja Hölttä's avatar
      [rab/gsab] Fix error handling in GetDerivedRabGsabMap · 0d0e73e6
      Marja Hölttä authored 
      It was delegating to GetDerivedMap but not handling the possible
error coming from it.

Bug: v8:11111,chromium:1347722
Change-Id: I348ed721281d8edd324f0e364d8ed45602cb9f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791063Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82046}
      0d0e73e6
    • Seth Brenith's avatar
      Reland "Background merging of deserialized scripts" · 766b2a4d
      Seth Brenith authored 
      This is a reland of commit e895b7af

The unit test has been updated to work correctly when
--stress-incremental-marking is enabled.

Original change's description:
> Background merging of deserialized scripts
>
> Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
> with which an embedder could request that V8 merge newly deserialized
> script data into an existing Script from the Isolate's compilation
> cache. This change implements those new functions. This functionality is
> still disabled by default due to the flag
> merge_background_deserialized_script_with_compilation_cache.
>
> The goal of this new functionality is to reduce memory usage when
> multiple frames load the same script with a long delay between (long
> enough for the script to have been evicted from Blink's in-memory cache
> and for the top-level SharedFunctionInfo to be flushed). In that case,
> there are two Script objects for the same script: one which was found in
> the Isolate compilation cache (the "old" script), and one which was
> recently deserialized (the "new" script). The new script's object graph
> is essentially standalone: it may point to internalized strings and
> readonly objects such as the empty feedback metadata, but otherwise
> it is unconnected to the rest of the heap. The merging logic takes any
> useful data from the new script's object graph and attaches it into the
> old script's object graph, so that the new Script object and any other
> duplicated objects can be discarded. More specifically:
>
> 1. If the new Script has a SharedFunctionInfo for a particular function
>    literal, and the old Script does not, then the old Script is updated
>    to refer to the new SharedFunctionInfo.
> 2. If the new Script has a compiled SharedFunctionInfo for a particular
>    function literal, and the old Script has an uncompiled
>    SharedFunctionInfo, then the old SharedFunctionInfo is updated to
>    point to the function_data and feedback_metadata from the new
>    SharedFunctionInfo.
> 3. If any used object from the new object graph points to a
>    SharedFunctionInfo, where the old object graph contains a matching
>    SharedFunctionInfo for the same function literal, then that pointer
>    is updated to point to the old SharedFunctionInfo.
>
> The document at [0] includes diagrams showing an example merge on a very
> small script.
>
> Steps 1 and 2 above are pretty simple, but step 3 requires walking a
> possibly large set of objects, so this new API lets the embedder run
> step 3 from a background thread. Steps 1 and 2 are performed later, on
> the main thread.
>
> The next important question is: in what ways can the old script's object
> graph be modified during the background execution of step 3, or during
> the time after step 3 but before steps 1 and 2?
>
> A. SharedFunctionInfos can go from compiled to uncompiled due to
>    flushing. This is okay; the worst outcome is that the function would
>    need to be compiled again later. Such a risk is already present,
>    since V8 doesn't keep IsCompiledScopes for every compiled function in
>    a background-deserialized script.
> B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
>    compilation. This is also okay; the merge completion logic on the
>    main thread will just keep this lazily compiled data rather than
>    inserting compiled data from the newly deserialized object graph.
> C. SharedFunctionInfos can be cleared from the Script's weak array if
>    they are no longer referenced. This is mostly okay, because any
>    SharedFunctionInfo that is needed by the background merge is strongly
>    referenced and therefore can't be cleared. The only problem arises if
>    the top-level SharedFunctionInfo gets cleared, so the merge task must
>    deliberately keep a reference to that one.
> D. SharedFunctionInfos can be created if they are needed due to lazy
>    compilation of a parent function. This change is somewhat troublesome
>    because it invalidates the background thread's work and requires a
>    re-traversal on the main thread to update any pointers that should
>    point to this lazily compiled SharedFunctionInfo.
>
> At a high level, this change implements three previously unimplemented
> functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
>
> - BackgroundDeserializeTask::SourceTextAvailable, run on the main
>   thread, checks whether there is a matching Script in the Isolate
>   compilation cache which doesn't already have a top-level
>   SharedFunctionInfo. If so, it saves that Script in a persistent
>   handle.
> - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
>   whether the persistent handle from the first step exists (a fast
>   operation which can be called from any thread).
> - BackgroundDeserializeTask::MergeWithExistingScript, run on a
>   background thread, performs step 3 of the merge described above and
>   generates lists of persistent data describing how the main thread can
>   complete the merge.
> - BackgroundDeserializeTask::Finish is updated to perform the merge
>   steps 1 and 2 listed above, as well as a possible re-traversal of the
>   graph if required due to newly created SharedFunctionInfos in the old
>   Script.
>
> The merge logic has nothing to do with deserialization, and indeed I
> hope to reuse it for background compilation tasks as well, so it is all
> contained within a new class BackgroundMergeTask (in compiler.h,cc). It
> uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
> the object visitation that updates pointers to SharedFunctionInfos.
>
> [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
>
> Bug: v8:12808
> Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#81941}

Bug: v8:12808
Change-Id: Id2036dfa4eba8670cac899773d7a906825fa2c50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787266Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#82045}
      766b2a4d
    • Clemens Backes's avatar
      [wasm] Do not allocate guard regions for memory64 · 965e688d
      Clemens Backes authored 
      Memory64 currently does not use trap handling, so we should not allocate
a guard region (10GB total reservation).
This is implemented by adding a {WasmMemoryFlag} enum in the backing
store header, which replaces the previous {MemoryIndexType}. The flag is
not stored with the backing store, as the backing store does not care
about the index type, and we might want to share the same backing store
for memory32 and memory64 (if sizes permit this).
Instead, we (still) store the flag with the WasmMemoryObject and pass it
to the backing store methods.

R=jkummerow@chromium.org

Bug: v8:10949
Change-Id: I284b85b98d181ba5e8d454b24bfa48f6ac201be5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789506Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82038}
      965e688d
    • Marja Hölttä's avatar
      Reland [rab/gsab] Fix accessing raw byte length · 602960f8
      Marja Hölttä authored 
      Now with smaller repro

Bug: v8:11111,chromium:1347721
Change-Id: I637d85e91249aa8eb433f6e00e4fd385d5b950ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789519
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Marja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82022}
      602960f8
    • Clemens Backes's avatar
      [backingstore] Inline TryAllocateWasmMemory · 4fd2314e
      Clemens Backes authored 
      This method is only called from {AllocateWasmMemory}, so does not need
to be public.

R=jkummerow@chromium.org

Bug: v8:10949
Change-Id: Idf411179b6cf816adc111ceebf79335177e3440b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789502Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82019}
      4fd2314e
  21. 27 Jul, 2022 6 commits