Adds new `br_on_cast <branch depth> <heap type>` instruction
with opcode 0xfb42.
The instruction does not branch on null.
The heap type may be any concreate heap type index or an abstract
type like `(ref null eq)`.
Bug: v8:7748
Change-Id: Id1d238645c176b32b568249d67fa28517b435ad4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4069559
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84598}
When importing a WasmExportedFunction into a module, we checked that
its type is equivalent with the declared type of the import. Instead,
we should check that the imported function has an isorecursive subtype
of the declared type.
Change-Id: I2a5f68d4c4c8c65a0eed5b82e8e825affb832cfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061732
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84593}
1) Pass {WasmFeatures} by value, it's a single word.
2) Pass a {base::Vector} instead of {start} and {end} pair.
3) Remove a redundant constructor (just pass an empty wire bytes vector
instead).
R=thibaudm@chromium.org
Change-Id: I337c3c86960505ae23c88cb6adc5646a61111f76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030434
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84382}
With dynamic tiering, each WebAssembly function has a tiering budget,
and the function gets optimized once the tiering budget is reached. So
far the tiering budget exists per process, which means that whenever
a web application got loaded, it started with a full tiering budget.
As a result, functions that only get called few times during startup
and never reach the tiering budget would never get optimized.
With this CL the tiering budget gets written to the cache. Given that
caching events are happening, this means that also startup functions get
optimized eventually as long as the web application gets visited often
enough.
R=clemensb@chromium.org
Bug: chromium:1384530
Change-Id: I5066bc8f3daf457159b6eb785d2e17eda43c8c4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026769
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84320}
Since crrev.com/30c19f3292fed9c499dd5a8f852bc76a481d6368, we always
allocate the wasm_internal_functions array on WasmInstanceObject
creation. This patch initializes that array with zero bits, so we
can use a Smi check (instead of a comparison to Undefined) to check
whether a given slot has been initialized already. This makes the
code generated for `ref.func` slightly smaller and more efficient.
Bug: v8:7748
Change-Id: I9d2b8fba4dc61d27e96b6e917c77133519af43ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4028561
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84272}
This is a reland of commit 05a80427dc.
We skip the test for now, until we figure out how to make it fast
enough.
Original change's description:
> [wasm] Do not add too much code at once
>
> Especially on arm64 we have a rather low code space limit (128MB), so it
> can happen that a background thread generates more code in one batch
> than can be held in a single code space. This case is not implemented
> yet.
>
> This CL implements this by never batch-adding more than half of a code
> space.
>
> In order to test the implementation, we add a new flag called
> --wasm-max-code-space-size-mb which can be used to artificially lower
> the code space size limits in tests.
>
> R=jkummerow@chromium.org
>
> Bug: v8:13436
> Change-Id: I18a3457fda724129fb1bb8c44a9815df265b6b2c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023072
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84245}
Bug: v8:13436
Change-Id: I983ef2f2cc2316172edab1f62dbde0dd4cb56fdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4025548
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84253}
This reverts commit 05a80427dc.
Reason for revert: Getting timeouts on some slow bots.
Original change's description:
> [wasm] Do not add too much code at once
>
> Especially on arm64 we have a rather low code space limit (128MB), so it
> can happen that a background thread generates more code in one batch
> than can be held in a single code space. This case is not implemented
> yet.
>
> This CL implements this by never batch-adding more than half of a code
> space.
>
> In order to test the implementation, we add a new flag called
> --wasm-max-code-space-size-mb which can be used to artificially lower
> the code space size limits in tests.
>
> R=jkummerow@chromium.org
>
> Bug: v8:13436
> Change-Id: I18a3457fda724129fb1bb8c44a9815df265b6b2c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023072
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84245}
Bug: v8:13436
Change-Id: I0b2492eb7fee40b7d62b3b3a8fb19a4bc7fda26b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4025546
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84248}
Especially on arm64 we have a rather low code space limit (128MB), so it
can happen that a background thread generates more code in one batch
than can be held in a single code space. This case is not implemented
yet.
This CL implements this by never batch-adding more than half of a code
space.
In order to test the implementation, we add a new flag called
--wasm-max-code-space-size-mb which can be used to artificially lower
the code space size limits in tests.
R=jkummerow@chromium.org
Bug: v8:13436
Change-Id: I18a3457fda724129fb1bb8c44a9815df265b6b2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023072
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84245}
Reland of https://crrev.com/c/3998633.
Each thread has its own MarkingBarrier instance for incremental
marking. A thread local variable is used to get the current thread's
instance on background threads.
However on main threads this thread local variable was always
set to nullptr. The main thread would get to its own instance through
the heap_ field in the host object's page header. This was solved this
way because setting current_marking_barrier on the main thread
seemed quite complex. Multiple isolates may be run on the same thread
and isolates may even be migrated between threads.
However, with --shared-space loading the heap_ field for a shared
object would return the main isolate's heap and we end up with
the wrong MarkingBarrier instance on client isolates. So this
CL makes main and background threads more uniform by setting the
thread local field also on the main thread. The field is set by
the already existing v8::Isolate::Scope API. Some embedders might have
to add these scopes if they don't use them properly already.
Bug: v8:13267
Change-Id: Idc257ecf6b6af09a379bdd7cd7c1d4a5e46689c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4016715
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84237}
When building the Turbofan graph for an inlined function, we should
record dangling exceptions (which will be connected to the callee's
handler) as we go, rather than try to recover them later. Apart from
making the code more maintainable, this fixes a bug where the handler
was not recovered correctly when memory start/size were reloaded.
Bug: v8:12166
Change-Id: Idbb71f0ba9f9d492f00115c516cbe5e61b6cd162
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4016876
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84165}
This reverts commit 910def9edc.
Reason for revert: Speculative Revert https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/9800/overview
Original change's description:
> [heap] Load MarkingBarrier from thread local on main thread
>
> Each thread has its own MarkingBarrier instance for incremental
> marking. A thread local variable is used to get the current thread's
> instance on background threads.
>
> However on main threads this thread local variable was always
> set to nullptr. The main thread would get to its own instance through
> the heap_ field in the host object's page header. This was solved this
> way because setting current_marking_barrier on the main thread
> seemed quite complex. Multiple isolates may be run on the same thread
> and isolates may even be migrated between threads.
>
> However, with --shared-space loading the heap_ field for a shared
> object would return the main isolate's heap and we end up with
> the wrong MarkingBarrier instance on client isolates. So this
> CL makes main and background threads more uniform by setting the
> thread local field also on the main thread. The field is set by
> the already existing v8::Isolate::Scope API. Some embedders might have
> to add these scopes if they don't use them properly already.
>
> Bug: v8:13267
> Change-Id: Idfdaf35073d04dd5e13ad6065ef42eae3ce6a259
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3998633
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84144}
Bug: v8:13267
Change-Id: Id8493dfac03d789721ca30cd29b0dd4b67006881
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4017192
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84151}
Each thread has its own MarkingBarrier instance for incremental
marking. A thread local variable is used to get the current thread's
instance on background threads.
However on main threads this thread local variable was always
set to nullptr. The main thread would get to its own instance through
the heap_ field in the host object's page header. This was solved this
way because setting current_marking_barrier on the main thread
seemed quite complex. Multiple isolates may be run on the same thread
and isolates may even be migrated between threads.
However, with --shared-space loading the heap_ field for a shared
object would return the main isolate's heap and we end up with
the wrong MarkingBarrier instance on client isolates. So this
CL makes main and background threads more uniform by setting the
thread local field also on the main thread. The field is set by
the already existing v8::Isolate::Scope API. Some embedders might have
to add these scopes if they don't use them properly already.
Bug: v8:13267
Change-Id: Idfdaf35073d04dd5e13ad6065ef42eae3ce6a259
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3998633
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84144}
We do not need to go through the builtin when the function reference is
already set.
For faster checks, we ensure that
{WasmInstanceObject::wasm_internal_functions} is set at instance
object instantiation time. Therefore it does not need to be optional.
Change-Id: Ie0a6564c171c6a6e3424c3cc0eeae3c83929e616
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4005823
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84095}
It's been enabled by default since Chromium M95.
Also removes duplicate setup code for WebAssembly.Tag JS API
from WasmJs::InstallConditionalFeatures, since we're guaranteed
to set it up via the non-conditional WasmJs::Install.
Bug: v8:8091
Change-Id: Ic500feb655ad4fc0703ed226504847ca6d940537
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3996810
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84074}
It's been enabled by default since Chrome 91.
Bug: v8:6020
Change-Id: Id26b7fb0b7dffe19a88a6f0071dd59203b06415a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3957636
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83862}
It's been enabled everywhere since Chrome 88, and the related
Chromium flag was removed in https://crrev.com/c/2886421.
Bug: v8:6532
Change-Id: I987a5761f9453d4e7d77d16199e8f0b3a659c70a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3956131
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83809}
The new ref.cast (opcode 0xfb41) takes any reference and
expects a Heaptype immediate. the HeapType can be a
concrete or an abstract type.
Differently to the old ref.cast instruction, it traps on
null. A variant which doesn't trap on null (ref.cast null)
will be added in a future CL.
Bug: v8:7748
Change-Id: Id5764a7553a57c5cb838682c9ec331d15d7d25c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3948663
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83724}
This is a reland of commit 3b883e787d
Fixed a test case that was merged in the meantime still using the old
kExprRefAsData which is now called kExprRefAsStruct.
Original change's description:
> Reland "[wasm-gc] Ref types: Convert dataref to structref"
>
> This is a reland of commit 20327d1599
>
> Changed in reland:
> - Added new flag wasm-gc-structref-as-dataref which defaults to true
> and preserves the existing behavior.
> - Passing --no-wasm-gc-structref-as-dataref enables the new behavior.
> - The flag affects static subtyping information between structref and
> arrays and the corresponding cast, test and br_on instructions.
> - Even with the old behavior the name still changed to "structref".
>
> Original change's description:
> > [wasm-gc] Ref types: Convert dataref to structref
> >
> > This change changes the type hierarchy in a non-backwards compatible
> > way: dataref is replaced with structref meaning that arrayref is
> > no longer a subtype of it.
> >
> > Bug: v8:7748
> > Change-Id: I965267d9ed11ea7c7d7df133cc39ee63e6b5abc3
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3929041
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#83515}
>
> Bug: v8:7748
> Change-Id: I2d8dd49dbc56246c087ac93452a87f860ead2195
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3945109
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83697}
Bug: v8:7748
Change-Id: I54f7b141ffc5b7597420fa0c838412be825a260b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952936
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83706}
This reverts commit 3b883e787d.
Reason for revert: gc-optimizations test is broken due to in-flight collision with another CL: https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8800403395649311857/+/u/Check/gc-optimizations
Original change's description:
> Reland "[wasm-gc] Ref types: Convert dataref to structref"
>
> This is a reland of commit 20327d1599
>
> Changed in reland:
> - Added new flag wasm-gc-structref-as-dataref which defaults to true
> and preserves the existing behavior.
> - Passing --no-wasm-gc-structref-as-dataref enables the new behavior.
> - The flag affects static subtyping information between structref and
> arrays and the corresponding cast, test and br_on instructions.
> - Even with the old behavior the name still changed to "structref".
>
> Bug: v8:7748
> Change-Id: I2d8dd49dbc56246c087ac93452a87f860ead2195
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3945109
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83697}
Bug: v8:7748
Change-Id: Icb273a6d433c47a372563d0daf68725c6c5b15e3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952514
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83698}
This is a reland of commit 20327d1599
Changed in reland:
- Added new flag wasm-gc-structref-as-dataref which defaults to true
and preserves the existing behavior.
- Passing --no-wasm-gc-structref-as-dataref enables the new behavior.
- The flag affects static subtyping information between structref and
arrays and the corresponding cast, test and br_on instructions.
- Even with the old behavior the name still changed to "structref".
Original change's description:
> [wasm-gc] Ref types: Convert dataref to structref
>
> This change changes the type hierarchy in a non-backwards compatible
> way: dataref is replaced with structref meaning that arrayref is
> no longer a subtype of it.
>
> Bug: v8:7748
> Change-Id: I965267d9ed11ea7c7d7df133cc39ee63e6b5abc3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3929041
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83515}
Bug: v8:7748
Change-Id: I2d8dd49dbc56246c087ac93452a87f860ead2195
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3945109
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83697}
In production we will only compile Wasm code with TurboFan after it has
already been executed via Liftoff. Hence we know that the code is valid,
and can skip validation. This will save some binary size, and (minimal)
run time.
Under exotic circumstances (no Liftoff, Liftoff bailed out, ...) we did
not run validation yet. In that case, run it explicitly.
Note that the {kNoValidation} mode still has the validation checks as
DCHECKs, so fuzzers can find bugs in the new logic.
R=jkummerow@chromium.org
Bug: v8:13361, v8:13371
Change-Id: I2d0896bee44a80a9d09d9c273ec5fdbe9ab8da62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3941891
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83676}
In order to drop validation from TurboFan, we need to know which
functions have already been validated when starting TurboFan
compilation. Under normal circumstances, that would be all of them. In a
TurboFan-only configuration, or for new code where Liftoff bails out, we
could need to run validation before TurboFan compilation though.
R=jkummerow@chromium.org
Bug: v8:13361, v8:13371
Change-Id: Ia59bdb1c25e4fc4300ca3d8cfe3ac3caf4985fa1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3942090
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83674}
This reverts commit 20327d1599.
Reason for revert: The code for structref/dataref is in use in
combination with array types, so the change breaks their use cases.
Reverting to restore the previous semantics of dataref.
Original change's description:
> [wasm-gc] Ref types: Convert dataref to structref
>
> This change changes the type hierarchy in a non-backwards compatible
> way: dataref is replaced with structref meaning that arrayref is
> no longer a subtype of it.
>
> Bug: v8:7748
> Change-Id: I965267d9ed11ea7c7d7df133cc39ee63e6b5abc3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3929041
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83515}
Bug: v8:7748
Change-Id: I2a0bcafafe6f67df87aac86813f74573b708cce4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3936156
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83544}
This change changes the type hierarchy in a non-backwards compatible
way: dataref is replaced with structref meaning that arrayref is
no longer a subtype of it.
Bug: v8:7748
Change-Id: I965267d9ed11ea7c7d7df133cc39ee63e6b5abc3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3929041
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83515}
The new ref.test (opcode 0xfb40) takes an any reference (vs. data on
the old instruction) and expects a HeapType immediate.
The HeapType can be a concrete or an abstract type.
Bug: v8:7748
Change-Id: Iaa2010af21d3fee76e27a5f4476ae00f5ca837a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913028
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83475}
We move js-to-wasm wrappers to a WeakFixedArray in the isolate,
indexed by their canonical type index. This ensures that they are
reused across instances, and get GC'd when no longer needed.
We also remove eager compilation of wrappers.
This CL fixes some issues that were caused by out-of-bounds accesses
to wrapper arrays attached to module objects.
Bug: chromium:1363859, chromium:1363895
Change-Id: Idec0925e775f51fdfa7cd380379b0d1798295a0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3893860
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83275}
The number of feedback vector slots is currently stored in the
{WasmFunction}, returned in the {WasmCompilationResult}, and implicitly
stored as the size of the {call_targets} vector in
{FunctionTypeFeedback}.
This CL uses the latter as the source of truth, encapsulated in a new
{NumFeedbackSlots} function. This can be updated when adding new kinds
of feedback that need additional slots.
For now, the implementation of {NumFeedbackSlots} requires taking a
mutex, which we can hopefully avoid when productionizing speculative
inlining. We also take the mutex on every Liftoff compilation, which
adds synchronization between concurrent compilation which we previously
tried very hard to avoid (because it introduced significant overhead for
eager compilation).
As a nice side-effect, this CL reduces the per-function overhead by 8
bytes, independent of enabled features.
R=jkummerow@chromium.org
Bug: v8:13209
Change-Id: I2fe5f7fe73154328032a3f0961e88d068c5d07ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899299
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83253}
Before, import and export wrappers were cached based on their
signature. This change
- makes wrapper canonicalization consistent with that of types and
call_indirect signatures under --wasm-type-canonicalization,
- removes the last uses of signature maps, which will enable us to
remove them in a future CL.
Change-Id: I512bc234f0ae10e50bd94237e8e675ca47ed13c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3891250
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83183}
- Remove the {ValueRepr} parameter from Wasm table and global object
internals. It is now the responsibility of the user to transform
to/from a JS object. This removes duplicate work in some cases (type
checking in the caller, transforming in the callee).
- For the reverse direction in the JS API, introduce
{WasmObjectToJSReturnValue}.
Bug: v8:7748
Change-Id: Ie7625cc0f08d38fe74dbe57e69004de2d93b8a11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3876184
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83031}
This CL adds PKU support for V8 heap, but we will not enable
PKU by default before adding bots that are able to test the
PKU machinery.
Bug: v8:13023
Change-Id: I0465604d56900536ad63311f119ea0324ebe4f2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793944
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82965}
This CL refactors most of the cctests and unittests (22 out of 31) that
directly invoke heap GC, so that the corresponding internal heap methods
are called from a few specific places in boilerplate code. This will
facilitate impending changes to the interface of GC-related internal
heap methods.
Bug: v8:13257
Change-Id: Ia6773a7952501b0792b279b799171519620497d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3869264
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82927}
Per https://github.com/WebAssembly/function-references/pull/76,
call_ref and return_call_ref should consume type immediates specifying
the signature of the funcref. This is a breaking change.
To ease the migration, this patch introduces a temporary alternative
binary encoding for call_ref:
- 0x14 continues to *not* take a type immediate for now.
- 0x17 (formerly "let") is the new call_ref *with* type immediate. Module
producers are encouraged to emit this encoding ASAP.
- After a few weeks of transitionary period, we'll update 0x14 to
take a type immediate as well. At this point, module producers will be
encouraged to switch back to 0x14.
- After a few more weeks of transitionary period, we'll drop 0x17 again.
We're not doing the same dance for return_call_ref because it currently
has no uses that we know of.
Bug: v8:7748,v8:9495
Change-Id: Id8d468be3949f84571efff713c937ffd1addff70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3863280
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82839}
When a call_indirect fails because of a signature mismatch or a null
target, the value stack generated for debug doesn't contain the target
index anymore, which makes it hard for users to understand the error.
Keep the index on the stack, and ensure that the index is not modified
until we generate the debug info. Previously, the index was shifted
in-place to compute various offsets. Instead, use scaled loads to
compute the offset directly in the load instruction.
R=clemensb@chromium.org
Bug: chromium:1350384
Change-Id: Iad5359ec80deef25a69ac119119a0b5ca559a336
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3854309
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82780}
Avoid the deprecated FLAG_* syntax, access flag values via the
{v8_flags} struct instead.
R=jkummerow@chromium.org
Bug: v8:12887
Change-Id: Ieccf35730f69bcefa3740227f15e05686080d122
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3843517
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82774}
Those are not safe in combination with the sandbox as they are stored as
raw pointers. Instead of turning them into ExternalPointers (which use
the ExternalPointerTable indirection), this CL simply turns them into
on-heap ByteArrays which is cheaper and should be unproblematic
security-wise as their contents can be corrupted without causing memory
corruption outside the sandbox address space (just incorrect behaviour
and/or further memory corruption *inside* the sandbox, which is fine).
Bug: chromium:1335046
Change-Id: Id2b901a58b7d6c91dd7596fca553d7c76cbc61ec
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/+/3845636
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82765}
This is a left-over of the removal of the dynamic (rtt-based)
variants.
Bug: v8:7748
Change-Id: I93bb74a72543a5697f1102d283c7d65c6be99466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3856577
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82746}
