Commit Graph

298 Commits

Author SHA1 Message Date
Tobias Tebbi
1047e423a2 [turboshaft] restructure MachineRepresentation and MachineType
Bug: v8:12783
Change-Id: I5de98493d67c7c797d4a1b2dcd18c0347821f0f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3870471
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83262}
2022-09-16 12:14:44 +00:00
Clemens Backes
f9e303e476 [wasm][pgo] Introduce a separate header and cc file
This moves the existing PGO code to a separate cc file with a separate
header. As the implementation will be further extended in follow-up CLs,
it's better to have it separated.

R=jkummerow@chromium.org

Bug: v8:13209
Change-Id: I7b7b5bf9c8d3d542dae734f3874499dccee152a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899321
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83250}
2022-09-16 10:06:53 +00:00
Manos Koukoutos
7db6d76e97 [wasm] Enable --wasm-type-canonicalization, remove old code
Bug: v8:7748
Change-Id: I74041f23ac64a3e509d82f84b4a710d23bbecbaf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3893859
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83227}
2022-09-15 16:22:18 +00:00
Shu-yu Guo
87ce9fce74 [shared-struct] Rework shared value serializer API again
This CL fixes redesigns the current API, which does not correctly
manage lifetimes of the shared object conveyors.

See design doc at
https://docs.google.com/document/d/1TV6agY9dafVJFvdPrUAGbEvos8wL2WDnsmf84n3OJVU/edit?usp=sharing

This CL also removes the incorrect behavior of serializing all shared
strings by sharing instead of copying. Shared strings may be sent to
another process, which should still work.

Bug: v8:12547
Change-Id: I7413abd2d871fd3d52c9b433445cfa1d03e4a732
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3868713
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83044}
2022-09-07 23:41:26 +00:00
Thibaud Michaud
ced65be69f [wasm] Move some code from .h to .cc file
The src/wasm/stacks.h file became progressively bigger, create a
cc file for it and move some function definitions there.

R=clemensb@chromium.org

Bug: v8:12191
Change-Id: I6880a4e11884856bd2f4d777cb745a3c06c71841
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3874936
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83039}
2022-09-07 15:23:46 +00:00
Nico Hartmann
1e017c1499 [base] Add some utilities for working with containers
This CL adds src/base/container-utils.h wich contains a few utilities
to make working with containers easier by providing a few additional
functions (e.g. contains, all_equal, ...) that are not (yet) shipped
with C++ standard containers.

Change-Id: I365b88c4286bf58bcac32c7bb89a5b0a98fc3509
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3865966
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82907}
2022-09-01 11:28:41 +00:00
Tobias Tebbi
9bbc13bd40 [turboshaft] faster hash for GVN
Bug: v8:12783
Change-Id: I97f6a28bfef7c9aed679c84f33d60a71cf467718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3859327
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82865}
2022-08-31 12:33:13 +00:00
Tobias Tebbi
7a61dad0db [turboshaft] some IR refactorings
- Remove TruncateInt64ToInt32 instead of translating to Turboshaft, since it has no effect. Removing it simplifies pattern-matching in optimizations.
- Change how exception handling is done in Turboshaft: The exception value is obtained as the result of `CatchExceptionOp` instead of a special projection. This simplifies projections.
- Add `TupleOp` as the counterpart to `ProjectionOp`, which is useful
  for lowerings of operations that have multiple outputs.

- Split BinopOp into WordBinopOp and FloatBinopOp because they have quite different semantics and many kinds only exist for one of them.
- rename IntegerUnary to WordUnary and other occurences of
  Integer/Integral
- rename ChangeOp::Kind::kUnsignedFloatTruncate` to `kJSFloatTruncate`
  because it actually has JS wrap-around semantics.
- move/add representation DCHECKs to operation constructors.
- add some convinience helpers to `AssemblerInterface`.

- Add a mechanism to check which operations are supported by the machine.

Drive-by fix: Abort current block in OptimizationPhase::VisitBlock if
  we lower to a block-terminator.

Bug: v8:12783
Change-Id: Ib738accccd22fb1606d9dab86f57ac1e739fcec2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3857449
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82857}
2022-08-31 10:13:47 +00:00
Dominik Inführ
810a0b5ff7 [heap] Move Verify* methods out of the heap class
Methods are now defined in heap-verifier.h in the HeapVerifier class.

Bug: v8:11708
Change-Id: I13e7f1760598f3659ad6aa31082840caf2e44038
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3857558
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82810}
2022-08-30 09:22:27 +00:00
Shu-yu Guo
7524089264 [shared-struct] Use PersistentHandles to convey shared values
Shared values need to be kept alive while being conveyed across threads (i.e. by
postMessage). Currently they are meant to be conveyed through the
serializer/deserializer by the embedder via API. This both clunky and
the embedder has no good choice for what to do, because the most natural
choice is v8::Global and it is not designed to be threadsafe.

This CL removes the API and transparently handles conveying shared
values by using a wrapper around PersistentHandles called
SharedValueConveyors. Any isolate can own the conveyor provided it
outlives the receipt of the message by the receiving isolate. For
simpler lifetime management, the shared isolate currently owns all
conveyors.

Bug: v8:12547
Change-Id: I8f71b2faa0f8a1973f8b97ffccf4f5ad230f4e16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3857453
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82795}
2022-08-29 19:44:47 +00:00
Michael Lippautz
76d61b2195 [base] Unify wrappers for malloc and friends
- Unify AIX and Starboard wrapping code.
- Move all wrapping code into `platform/memory.h`

Change-Id: I42c04dd1e982edff2db7bbfa9eecdbdd67f40714
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3858226
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82794}
2022-08-29 19:03:46 +00:00
Patrick Thier
348adb07ca Prepare StringForwardingTable for external strings
- Move StringForwardingTable implementation to own compilation unit.
- Refactoring preparing for layout change (Introduce explicit record
  class to make transition from contiguous Tagged_t fields to a
  heterogeneous record layout easier).
- Replace RootVisitor pattern for transitioning/cleanup during GC with
  callback.
- Minor cleanups.

Bug: v8:12957
Change-Id: Iae343393f470130eac0c54148a1303b67fb95aa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3845635
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82730}
2022-08-25 15:17:49 +00:00
Tobias Tebbi
d75a0eed1c [base] allow inlining of hash_combine to improve performance
This improved Turboshaft value numbering performance
significantly in local testing.

Change-Id: I8b8c8e3a67da9b83b57efc34c08ca693e84d9076
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3852486
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82708}
2022-08-24 18:58:27 +00:00
Victor Gomes
208bda4824 [bazel] Remove zlib dependency
That entails that V8 built with bazel does not support
snapshot compression.

NOTE: Snapshot compression has always been supported, but it has never
been enabled. We do not even have a flag for it.

Change-Id: I4b67db618be2c62e6a6f34e71eb0dac2ec26fa36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3834031
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82537}
2022-08-17 15:30:25 +00:00
Michael Lippautz
a4840410e5 [heap] Invoke internal GC callbacks before Heap verification
- Move InnerPointerToCodeCache to using internal callbacks.
- Refactor internal and external callbacks to use a unified interface.

Bug: v8:13184
Change-Id: If0006d324b0433f5d6bbf00b6d0fc1a2589227bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3834583
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82515}
2022-08-17 09:00:28 +00:00
Shu-yu Guo
374a93e23a [change-array-by-copy] Implement Array.prototype.toSorted
Bug: v8:13035
Change-Id: I028f77f7dea73d56bf9df56ee06908fd01ce8a43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3830034
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82491}
2022-08-16 14:11:53 +00:00
Darius M
de04959f17 [compiler] Remove delayed string constants
StringConstantXXX were introduced when we switched to concurrent
compilation, as a way to build strings in Turbofan in a background
thread, without having to actually allocate them on the main heap
from the background. See https://crrev.com/c/1221807.

Now that we have local heaps, we can actually allocate strings from
the background, making StringConstantXXX useless.

Moreover, we would fold constant string concatenations into
ConsString, which sounds a bit dubious for performance. Now, small
constant string concatenations will be folded into SeqStrings, while
larger ones will remain ConsString, just to avoid the quadratic
worst-case.

Change-Id: I0479d16aa5691c9d774187c4cc0d03ff4fe2b4f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811291
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82381}
2022-08-11 07:41:53 +00:00
Michael Lippautz
65d43890f3 Reland "[handles] Remove precise on-stack representation of global handles"
This is a reland of commit 6953b5550e

The reland fixes tests that retrieved the stack start from a
non-inlined frame's fp. This does not work in certain configurations
as the resulting marker is too low to consider the first local
variables in subsequent calls.

The fix uses an inline frame address for the tests to get an upper
bound of stack addresses to consider.

Original change's description:
> [handles] Remove precise on-stack representation of global handles
>
> Since https://crrev.com/c/3806439 on-stack traced handles are marked
> conservatively when being used in combination with CppHeap.
>
> This change removes the precise on-stack representation of the
> internal traced nodes as they nodes would anyways be marked
> conservatively. The effects are:
> - cheaper representation (just a single node space);
> - uniform handling: no checks to distinguish on-stack vs on-heap;
> - no brittleness around cleaning on-stack handles when the event loop
>  is empty;
>
> Change-Id: Id859623bfed77a66bdd064ea8065536264515eae
> Bug: v8:13141
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812039
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82306}

Bug: v8:13141
Change-Id: I53ece36220e99d02be6df18f83c18450e5d5037b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820585
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82342}
2022-08-10 11:59:24 +00:00
Michael Lippautz
850b225033 Revert "[handles] Remove precise on-stack representation of global handles"
This reverts commit 6953b5550e.

Reason for revert: Failing on CI: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20full%20debug/22876/overview

Original change's description:
> [handles] Remove precise on-stack representation of global handles
>
> Since https://crrev.com/c/3806439 on-stack traced handles are marked
> conservatively when being used in combination with CppHeap.
>
> This change removes the precise on-stack representation of the
> internal traced nodes as they nodes would anyways be marked
> conservatively. The effects are:
> - cheaper representation (just a single node space);
> - uniform handling: no checks to distinguish on-stack vs on-heap;
> - no brittleness around cleaning on-stack handles when the event loop
>  is empty;
>
> Change-Id: Id859623bfed77a66bdd064ea8065536264515eae
> Bug: v8:13141
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812039
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82306}

Bug: v8:13141
Change-Id: I5ebb2ed9eeec1394c2dd48504e91f6ff789b0711
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820584
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82313}
2022-08-09 17:21:54 +00:00
Michael Lippautz
6953b5550e [handles] Remove precise on-stack representation of global handles
Since https://crrev.com/c/3806439 on-stack traced handles are marked
conservatively when being used in combination with CppHeap.

This change removes the precise on-stack representation of the
internal traced nodes as they nodes would anyways be marked
conservatively. The effects are:
- cheaper representation (just a single node space);
- uniform handling: no checks to distinguish on-stack vs on-heap;
- no brittleness around cleaning on-stack handles when the event loop
 is empty;

Change-Id: Id859623bfed77a66bdd064ea8065536264515eae
Bug: v8:13141
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812039
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82306}
2022-08-09 15:04:31 +00:00
Omer Katz
68b3b65ef3 [heap] Eliminate fast promotion mode
Bug: v8:12612
Change-Id: Iaf967da524413b6701aa93fa471d79e2a82e43e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3805064
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82147}
2022-08-02 15:15:43 +00:00
Simon Zünd
33dfda38e7 [liveedit] Move live edit diffing code into separate file
This is a strictly code moving change. We move the diffing algorithm
out of liveedit.cc into its own file.

We want to replace the current diffing algorithm and to stay safe we
will ship old and new algorithm side-by-side for a release for easy
revertability. Given that liveedit.cc is already large enough we
extract the diffing algo into a separate file.

R=kimanh@chromium.org

Bug: chromium:1205288
Change-Id: If5ebb6c2dff2f00387c9e2ab87e4bb61d1f1484a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3802687
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82124}
2022-08-02 07:32:13 +00:00
Darius M
ba7d9e5fa0 [turboshaft] port value numbering optimization
Bug: v8:12783
Change-Id: I5b7acf2445b0f898158448dde206a0cecdab6a80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3764345
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82097}
2022-08-01 13:30:12 +00:00
Seth Brenith
766b2a4d52 Reland "Background merging of deserialized scripts"
This is a reland of commit e895b7af73

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/+/3787266
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#82045}
2022-07-28 17:02:55 +00:00
Shu-yu Guo
3767ca8be5 [change-array-by-copy] Remove TypedArray.prototype.toSpliced
Normative update from
https://github.com/tc39/proposal-change-array-by-copy/issues/88

Bug: v8:13035
Change-Id: I939cebc13b4ab3cafbfb96a45d93b50453fd07e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785282
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81989}
2022-07-27 07:51:12 +00:00
Clemens Backes
6e72b810c5 [API] Allow copying of structs with deprecated fields
The implicit copy constructor triggers a deprecation warning if the
struct contains a deprecated field. We can fix this by explicitly
declaring the copy and move constructors and assignment operators
with the deprecation warning disabled.

This CL also adds a test to check that we can indeed call the
constructors and assignment operators, which did not work before.

R=leszeks@chromium.org

Bug: v8:13092
Change-Id: Ia63ff9375de13fc6e5b5a8d59d827a742c99fb39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785145
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81962}
2022-07-26 11:47:25 +00:00
Deepti Gandluri
44fc1fdac2 Revert "Background merging of deserialized scripts"
This reverts commit e895b7af73.

Reason for revert: TSAN failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/8468/overview

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: I82a080e6287828445293cb6b4b94a5e8f15eb8f3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787213
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#81943}
2022-07-25 23:01:07 +00:00
Seth Brenith
e895b7af73 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}
2022-07-25 17:29:06 +00:00
Jakob Kummerow
966e6f02c1 [wasm] Expose disassembler to DevTools
Bug: v8:12917
Change-Id: I8942664831c591f9b5566ee5b1609f68948601e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749208
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81826}
2022-07-19 17:43:16 +00:00
Michael Lippautz
509ee760d9 cppgc: Avoid decompression for Member write barriers
Thread through compressed pointer into write barrier to allow to delay
compression after checking whether a write barrier is actually needed.

Change-Id: If7e6cbb69a57cc9aeeb551c11f685bace4e56c4c
Bug: chromium:1325007
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769826
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81816}
2022-07-19 15:23:16 +00:00
ishell@chromium.org
2be2109032 [pku] Move PKU support from Wasm to base/platform
The header is only slightly refactored:
* function names are slightly shortened,
* global functions and enums are converted to static methods and enums
  of a MemoryProtectionKey class.

This is a first step towards adding PKU support for V8 code space.

Bug: v8:13023
Change-Id: Iebcb075b07286d18d6834fbcf6697327f08c9f50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762584
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81732}
2022-07-14 21:54:29 +00:00
Michael Achenbach
f8e4c4aadb [build] Fix bazel build
No-Try: true
Bug: v8:7700
Change-Id: I66288693034bd501fece756916d0ef9a31e45e07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3752798
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81628}
2022-07-11 07:52:06 +00:00
Tobias Tebbi
9d45d274b1 [turboshaft] port decompression optimization
Bug: v8:12783
Change-Id: Ib23aa682054bfcf35efe1adef64fc97afe8f9619
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3743642
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81615}
2022-07-08 16:34:30 +00:00
Leszek Swirski
c96aa211c7 [bazel] Fix bazel build to include safepoint-table-base.h
Bug: v8:7700
Change-Id: I78d22fe079313312274a1ee9ac285d5dc4e9c38f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3751208
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81606}
2022-07-08 11:26:54 +00:00
Jakob Kummerow
7890a89d47 [wasm] Add FunctionBodyDisassembler
Unused as of this CL; users will follow.

Bug: v8:12917
Change-Id: I82658ea8a401834a5b3661068766bbdfec54d5a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3726214
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81533}
2022-07-05 14:47:31 +00:00
Jakob Kummerow
f76486e60a [wasm][refactor] Move ModuleDecoderImpl to -impl.h
Ctrl+X, Ctrl+V. No change in behavior.
This is a preparational step for templatizing the module decoder
for disassembler purposes.

Bug: v8:12917
Change-Id: I08a5d2e666cd16a207e9862b2691446c0473ddb0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3738221
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81489}
2022-07-01 11:43:09 +00:00
Shu-yu Guo
0d6e95b43e [change-array-by-copy] Implement TypedArray.prototype.toSpliced
Bug: v8:12764
Change-Id: I5f915d1c4dad22f1ce12423f6149a85ad32d6725
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3733043
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81477}
2022-06-30 21:47:38 +00:00
Jakob Kummerow
9983fda8a9 [wasm] Introduce NamesProvider
NamesProvider class:
This consolidates logic used so far for the debugger interface.
It also adds support for the "extended name section" proposal:
https://github.com/WebAssembly/extended-name-section

StringBuilder class:
Like std::ostringstream, but 4x faster for this use case.

This lays the groundwork for an updated Wasm disassembler.

Bug: v8:12917
Change-Id: I98aa258147834bc0e314ba98c5927b4cd6070b8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3720714
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81446}
2022-06-29 16:00:07 +00:00
Shu-yu Guo
3c4c25dbd4 [change-array-by-copy] Implement Array.prototype.toSpliced
Drive-by: add unscopable test for Array.prototype.toReversed.

Bug: v8:12764
Change-Id: I9d7dd8d4eae6d23811382b6795c2c6ff7f76be72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717552
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81364}
2022-06-24 22:05:39 +00:00
Shu-yu Guo
60515ab624 Fix bazel build
Bug: v8:12547
Change-Id: I13ef21d5246fb1115cf75fb1f6b4bcde33f84dd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3715379
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81316}
2022-06-22 19:42:28 +00:00
Luis Fernando Pardo Sixtos
afb26623df [shared-struct] Shared Array Initial prototype
Initial implementation for concurrent shared arrays. Current implementation exposes a `SharedArray` constructor, but its syntax might
change in the future.

Shared arrays can be shared across Isolates, have a fixed size, have no
prototype, have no constructor, and can only store primitives, shared structs and other shared arrays. With this CL shared structs are also allowed to store shared arrays.

The Backing storage for the SharedArrays is a `FixedArrayBase`. This CL introdces a new ElementKind: `SHARED_ARRAY_ELEMENTS`. The new kind should match the overall functionality of the `PACKED_SEALED_ELEMENTS` kind, but having it as standalone kind allows for easier branching in CSA and turbofan code.

Bug: v8:12547
Change-Id: I054a04624d4cf1f37bc26ae4b92b6fe33408538a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585353
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81285}
2022-06-22 02:24:46 +00:00
Manos Koukoutos
8df4e9be52 [turbofan] Factor out and templatize path conditions
We factor out the path-state part of branch elimination, to reuse it for
wasm path-based type optimizations. The node state becomes a template
parameter for the {ControlPathState} and
{AdvancedReducerWithControlPathState} classes.

Change-Id: I5e9811ced0b71140ec73ba26fae358ac7d56c982
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714238
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81270}
2022-06-21 10:07:55 +00:00
Manos Koukoutos
e4a7ef2b3b [wasm][refactor] Clean up constant expressions
Changes:
- Rename InitExpression -> ConstantExpression in places which reference
  the ConstantExpression type.
- Move ConstantExpression to its own file, along with ValueOrError and
  EvaluateConstantExpression.

Change-Id: Ife572d783531216b6ea3d2626e4fbf4048463253
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702798
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81204}
2022-06-16 06:11:03 +00:00
Tobias Tebbi
77ba98ef32 [turboshaft] add support for all JS machine-level operators
In particular, this CL adds support for:
- exception handling
- source positions
- OSR
- various numeric operations and conversions

Since the test suite now passes with `--turboshaft`, this also adds a
new variant for Turboshaft and enables it on some bots.

Bug: v8:12783
Change-Id: Ia2dd2e16f56fc955d49e51f86d050218e70cb575
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3669251
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81074}
2022-06-10 15:17:20 +00:00
Anton Bikineev
62159ea316 cppgc: shared-cage: Remove heap-specific metadata from cage-header
The CL is a prerequisite for the shared cage. Instead of storing
state variables (is_incremental_marking_in_progress,
is_young_generation_enabled) in the cage metadata, the CL moves them to
HeapHandle. The HeapHandle pointer is now retrieved from page-headers.

To make sure that the write-barrier code is better optimized, the
HeapHandle definition is moved to internal/ headers. The part of
BasePage that contains HeapBase (i.e. HeapHandle) pointer is also
extracted and moved to the headers.

Bug: v8:12231
Change-Id: I44bf65d99a621d9548e4250386cf87476ca186ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3689730
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81005}
2022-06-08 16:13:53 +00:00
Andy Wingo
b912d54562 [stringrefs] Move WTF-8 string handling closer to UTF-8
No functional change.

Bug: v8:12868
Change-Id: I5f09861e2b5beb400dcc1656f80230404cf544b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3693704
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andy Wingo <wingo@igalia.com>
Cr-Commit-Position: refs/heads/main@{#80996}
2022-06-08 12:55:32 +00:00
Manos Koukoutos
51d662f712 [wasm-gc] Introduce typed-based optimizations
We introduce a Turbofan pass which optimizes wasm-gc nodes based on
the types of their inputs.

Bug: v8:7748
Change-Id: I281eb0785e9e4201ef925ec201d76dc3d274ad05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3679198
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80929}
2022-06-03 07:29:19 +00:00
Manos Koukoutos
aee0ec979a [wasm-gc][turbofan] Implement typing phase
We introduce a typing phase into the Turbofan compilation pipeline for
wasm-gc. It has two functionalities: (1) to type nodes that were not
typed during code generation (mainly phi nodes) and (2) to narrow types
as much as possible.
The following nodes are handled, which should be enough for our
purposes: TypeGuard, WasmTypeCast, AssertNotNull, Phi, LoadFromObject,
and LoadImmutableFromObject.
Loop phi types are computed by first assigning the type of the
non-recursive input, and updating once we have the type of the recursive
inputs, and repeating this process to a fixed point.

Drive-by: Remove the narrowing of function signatures during wasm
inlining, as it created some issues and should not be needed after this
series of changes.

Bug: v8:7748
Change-Id: I8a72488d5c221c4ae8257fc5abf6f0368cf10e96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3678208
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80912}
2022-06-02 11:08:21 +00:00
Shu-yu Guo
7ff1857560 Reland "[shared-struct] Add Atomics.Mutex"
This is a reland of commit ea9a1f1cbe

Changes since revert:
- Make the state field uintptr-aligned since arm64 faults on
  atomic accesses to non-naturally aligned addresses.

Original change's description:
> [shared-struct] Add Atomics.Mutex
>
> This CL adds a moving GC-safe, JS-exposed mutex behind the
> --harmony-struct flag. It uses a ParkingLot-inspired algorithm and
> each mutex manages its own waiter queue.
>
> For more details, please see the design doc: https://docs.google.com/document/d/1QHkmiTF770GKxtoP-VQ1eKF42MpedLUeqiQPfCqus0Y/edit?usp=sharing
>
> Bug: v8:12547
> Change-Id: Ic58f8750d2e14ecd573173d17d5235a136bedef9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3595460
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80789}

Bug: v8:12547
Change-Id: I776cbf6ea860dcc6cb0ac51694a9b584b53d255c
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3673354
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@{#80875}
2022-06-01 01:12:07 +00:00
Shu-yu Guo
0f510c4ab1 [change-array-by-copy] Implement with
Bug: v8:12764
Change-Id: I67b9b0e4f3c7ca6a2719c234b7f7605f07f86b28
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3671760
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80874}
2022-06-01 00:47:32 +00:00