One fundamental assumption of the wasm code GC is that code becomes
"potentially dead" at most once; if the ref counts drops to zero later,
it should be freed for real.
In the current implementation, it happens that code becomes potentially
dead, then becomes dead for real (it's removed from the set of
potentially dead code), and then we remove the last reference. At that
point, we re-add the code to the potentially dead code, considering it
for garbage collection again. This can lead to an endless loop.
This CL fixes that by remembering which code was already detected as
dead, and does not consider this code for another GC.
This requires freeing code via the {WasmEngine} such that the set of
dead code can be cleaned up.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: If6a95a7918db2ad82edfad5447c536593243db7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585845
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61073}
If a {NativeModule} dies while a GC is running, we could leave behind
references to code of that deleted module. This CL fixes that.
This issue was found by running with --stress-wasm-code-gc.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I7f0d98977e6510899170306952936c4a7f7d3c10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585722
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61041}
Add a flag which causes wasm code gc to be triggered whenever any code
is found to be potentially dead. This mode found several bugs already,
and I plan to enable it in 'gc-stress' mode once all issues are fixed.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: If28d980ded98b77b9efe7446da74d857e3c5e1b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585720
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61039}
This fixes a deadlock that was detected by layout tests executing with
--future (hence enabling wasm code gc). It did not fail anywhere in v8
because GC is only triggered once we have > 1MB potentially dead code.
I plan to add a '--stress-wasm-code-gc' flag, which lowers this limit
to zero, thereby triggering GC when finding a single potentially dead
code. This mode found this issue, but also finds more, so I need to fix
other issues before enabling these stress tests.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I373955b90c8b79d7b9e16184729f45db947eeeab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1583728
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61034}
The current logic sometimes skips the request for a code logging stack
guard request, even though no such request is pending. This happens if
the previous stack guard already executed, but a foreground task is
still pending.
This CL fixes this by re-requesting a stack guard interrupt when the
first code is added to the vector of outstanding code to be logged.
Plus minor drive-by fix.
R=mstarzinger@chromium.org
Bug: v8:9163
Change-Id: I4937f3983f15e7122141b04ddb1432cd1f78828b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578461
Auto-Submit: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60970}
This CL fixes some issues with GC.
1) It removes dead code from the set of potentially dead code to avoid
considering the same code for GC again and again.
2) It resets the {new_potentially_dead_code_size_} counter to avoid
triggering too many GCs.
3) When code becomes dead after GC, do not unconditionally free it; just
decrement its ref count (there might still be {WasmCodeRefScope}s
holding the code alive).
4) Update the comment of the ref count to be more accurate.
R=titzer@chromium.org
Bug: v8:8217
Change-Id: I28e5a1fed74411b8473bb66ddbad3ffe7643f266
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1574518
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60949}
We have very few tests for this currently, and it's hard to test
this, since code logging happens soon after scheduling the task and
stack guard. If the timing is just right, it can happen though that a
{NativeModule} dies while {WasmCode} objects of that {NativeModule} are
still part of the {code_to_log} vector. In that case, we need to remove
those code objects from the vector to avoid use after free.
R=mstarzinger@chromium.org
Change-Id: I16c7098bf11c54700cc650dad965106af2e39157
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566519
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60902}
This is a reland of 067ba2a0c6.
Unchanged reland, hence TBR.
Original change's description:
> [wasm] Add stack guard for logging code
>
> Benchmarks or worker threads might never return to the event queue,
> hence they will never execute the scheduled foreground task to log
> compiled and published wasm code.
> This CL adds a stack guard to log the code, to ensure that we also log
> it for wasm code that never returns to the event queue.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:9104
> Change-Id: I176959cadb4ab3a60153d0717530c032272ad3e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561073
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60879}
TBR=mstarzinger@chromium.org
Bug: v8:9104
Change-Id: I105b37ef8429d16ef5b983919ba8bca615e347c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1570017
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60899}
Benchmarks or worker threads might never return to the event queue,
hence they will never execute the scheduled foreground task to log
compiled and published wasm code.
This CL adds a stack guard to log the code, to ensure that we also log
it for wasm code that never returns to the event queue.
R=mstarzinger@chromium.org
Bug: v8:9104
Change-Id: I176959cadb4ab3a60153d0717530c032272ad3e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561073
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60879}
This moves the vector of {WasmCode} to log (per isolate) from the
{LogCodesTask} to the {WasmEngine}, where lifetime is more clear.
This makes it harder to mess up the ref count of the stored {WasmCode}
objects.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I07131f95391bfabee3c376378179d8bcdc1555b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566518
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60869}
This adds the {CurrentGCInfo} data structure to the wasm engine. It
holds all information needed for the current GC cycle, which is
currently only the set of Isolates that still need to report their live
code, and the set of dead wasm code (which is potentially reduced when
Isolates report live code).
Running the GC is guarded by the new '--wasm-code-gc' flag. I will add
this to the --future variant in a follow-up CL.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I82e96d986cf5a758bc0f94e49e13ad78fae4e935
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559738
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60721}
This adds data structures to track potentially dead code in the wasm
engine. The engine will then trigger an engine-wide GC once the
potentially dead code reaches a certain threshold.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I13216a66bb8e8e1594b165a65708e53057e9e535
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559736
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60718}
During instantiation, exceptions can be thrown when looking up the
imports, e.g. because of proxies. If the exception is thrown
internally, before actually calling out to JS code, it won't be
externally caught.
This CL removes the DCHECK that errornously checked that a pending
exception was externally caught.
R=mstarzinger@chromium.org
Bug: chromium:948228
Change-Id: Idbdb340167c1943f78397cc9b310ef5743755726
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547855
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60593}
We need to ensure that the NativeModule stays alive while any
{BackgroundCompileScope} exists, because during that time we hold
shared ownership of the mutex in the {BackgroundCompileToken}. If the
{NativeModule} dies during that period, we would need to get exclusive
ownership of the mutex and deadlock.
This change requires holding a {std::weak_ptr<NativeModule>} in the
BackgroundCompileToken instead of a raw pointer, hence it can only be
initialized after the NativeModule was created. This is done via a
separate {InitCompilationState} method.
R=ahaas@chromium.org
Bug: v8:8979
Change-Id: Ia14bd272ea0bc47aec547024da6020608418c9d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518178
Auto-Submit: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60203}
In order to get a more complete picture about the code sizes of
compiled wasm modules, sample the code size of each module after
top-tier compilation finished. This happens via the {WasmEngine}
because that's where we know which isolates use a given {NativeModule}
and can schedule foreground tasks to sample the code size.
R=mstarzinger@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Bug: v8:8217
Change-Id: Id585db8a9ab8f3aa1060b08411afaa31c5414f87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1508404
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60167}
Our UMA data shows a lot of small modules, and I have the suspicion we
are loosing some numbers about the bigger ones. Thus sample the module
code size after baseline compilation finished. At that point the
majority of the code was generated.
Sampling after top-tier finished is not that easy since we do not spawn
a foreground task at that point.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: Icaa4a2efb201d24cbc8d2e1b8da516ae26574f01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1508675
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60158}
Align the Table implementation limits with the JavaScript Embedding
limits defined in the specification (from MAX_UINT32 to 1e7).
Introduce a new helper (max_table_init_entries) that returns the
maximum number of Table entry at initialization. It takes into account
the maximum Table size, which can be passed by a flag.
Bug: v8:8633
Change-Id: Idfa19418e81f478f7886a30876e66c9b216e25ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1496971
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60036}
For macros expanding to function definitions, I removed the spurious ; after
macro invocations. For macros expandign to function declarations, I made the ;
required and consistently inserted it.
No behavior change.
Bug: chromium:926235
Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549
Reviewed-on: https://chromium-review.googlesource.com/c/1467545
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59558}
This makes the existing error message tests also test the error
produced by asynchronous compilation and instantiation.
It also slightly tweaks the error message to contain the name of the
API function invoked instead of "WebAssembly Instantiation".
R=titzer@chromium.org
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Bug: chromium:926311
Change-Id: If4ab963cee8267d43b289169d21b31637c471d6d
Reviewed-on: https://chromium-review.googlesource.com/c/1456085
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59442}
Creating the LogCodesTask and adding the code objects to it adds 10-20%
to Liftoff compilation time. Thus cache whether code logging is needed
per isolate, and avoid the overhead if that flag is false.
R=mstarzinger@chromium.org
Bug: v8:8783, chromium:928722
Change-Id: I059266da3309a4b1ed316016d0a55fa34f139057
Reviewed-on: https://chromium-review.googlesource.com/c/1454484
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59400}
In chromium, the platform might delete the task before executing it
and before fully deregistering the Isolate.
In that case we need to deregister it from the WasmEngine to avoid a
data race or use-after-free.
R=mstarzinger@chromium.org
CC=herhut@chromium.org
Bug: v8:8783, chromium:928458
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Change-Id: Ie94e037f07fbe220505a5d8314b413f24c0990e1
Reviewed-on: https://chromium-review.googlesource.com/c/1454598
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59372}
This is a reland of ac2fb66b65.
Crashes were fixed in https://crrev.com/c/1429862.
Original change's description:
> [wasm] Remove finisher task
>
> This removes the finisher task and instead finishes compilation units
> from the background.
> It also changes ownership of the AsyncCompileJob to be shared among all
> tasks that still operate on it. The AsyncCompileJob dies when the last
> reference dies.
>
> R=ahaas@chromium.org
> CC=mstarzinger@chromium.org
>
> Bug: v8:7921, v8:8423
> Change-Id: Id09378327dfc146459ef41bc97176a8716756ae4
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/1335553
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58630}
Bug: v8:7921, v8:8423
Change-Id: I3dcee4e8e56d2a524d302af91b5cb4a7a9ceb8ce
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1400781
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59302}
This CL revises some of our error messages, and removes unneeded parts
(like "AsyncCompilation: " or "(null): "). It also extends existing
tests to check for the precise error message more thoroughly to detect
changes or nondeterminism earlier.
R=titzer@chromium.org, ahaas@chromium.org
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Bug: chromium:926311
Change-Id: I1ccfb307d4a61291f4582330152a53fbadd0848f
Reviewed-on: https://chromium-review.googlesource.com/c/1445897
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59296}
The compilation state should have no notion of Isolates. Move code
logging and management of the corresponding foreground task to the
WasmEngine.
R=mstarzinger@chromium.org
Bug: v8:8689
Change-Id: Ib690317139d0754731b9f0e71d06e7a722082eed
Reviewed-on: https://chromium-review.googlesource.com/c/1434035
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59093}
The WasmCodeManager held a list of all Isolates that use the
WasmEngine/WasmCodeManager (those two are 1:1).
Since we want to move all isolate-specific tasks (like code logging and
compilation callbacks) to the WasmEngine, this CL moves this management
from the WasmCodeManager to the WasmEngine. We now have a bidirectional
mapping from NativeModules to the Isolates that use them, and from an
Isolate to all the NativeModules it uses (n:n).
The IsolateData struct will be extended in follow-up CLs to hold things
like the ForegroundTaskRunner. The Isolate* in the NativeModule /
CompilationState will eventually be removed.
R=mstarzinger@chromium.org
Bug: v8:8689
Change-Id: Ic2c003c3949f73ce3264dd9dac96884a5c0b9896
Reviewed-on: https://chromium-review.googlesource.com/c/1433793
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59092}
This is a reland of 92d9b09c0e.
Patch unchanged, errors fixed by https://crrev.com/c/1430059.
Original change's description:
> [wasm] Decouple background compile jobs from NativeModule
>
> Background compile jobs should not keep the NativeModule alive, for two
> reasons:
> 1) We sometimes have to wait for background compilation to finish (from
> a foreground task!). This introduces unnecessary latency.
> 2) Giving the background compile tasks shared ownership of the
> NativeModule causes the NativeModule (and the CompilationState) to
> be freed from background tasks, which is error-prone (see
> https://crrev.com/c/1400420).
>
> Instead, this CL introduces a BackgroundCompileToken which is held
> alive by the NativeModule and all background compile jobs. The initial
> and the final phase of compilation (getting and submitting work)
> synchronize on this token to check and ensure that the NativeModule is
> and stays alive. During compilation itself, the mutex is released, such
> that the NativeModule can die.
> The destructor of the NativeModule cancels the BackgroundCompileToken.
> Immediately afterwards, the NativeModule and the CompilationState can
> die.
>
> This change allows to remove two hacks introduced previously: The atomic
> {aborted_} flag and the {FreeCallbacksTask}.
>
> R=mstarzinger@chromium.org
> CC=titzer@chromium.org
>
> Bug: v8:8689, v8:7921
> Change-Id: I42e06eab3c944b0988286f2ce18e3c294535dfb6
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/1421364
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59020}
TBR=mstarzinger@chromium.org
Bug: v8:8689, v8:7921
Change-Id: Iead972ef77c8503da7246cab48e7693b176d8f02
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1429862
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59035}
This reverts commit 92d9b09c0e.
Reason for revert: Crashes on several bots, e.g. https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20UBSan/4237
Original change's description:
> [wasm] Decouple background compile jobs from NativeModule
>
> Background compile jobs should not keep the NativeModule alive, for two
> reasons:
> 1) We sometimes have to wait for background compilation to finish (from
> a foreground task!). This introduces unnecessary latency.
> 2) Giving the background compile tasks shared ownership of the
> NativeModule causes the NativeModule (and the CompilationState) to
> be freed from background tasks, which is error-prone (see
> https://crrev.com/c/1400420).
>
> Instead, this CL introduces a BackgroundCompileToken which is held
> alive by the NativeModule and all background compile jobs. The initial
> and the final phase of compilation (getting and submitting work)
> synchronize on this token to check and ensure that the NativeModule is
> and stays alive. During compilation itself, the mutex is released, such
> that the NativeModule can die.
> The destructor of the NativeModule cancels the BackgroundCompileToken.
> Immediately afterwards, the NativeModule and the CompilationState can
> die.
>
> This change allows to remove two hacks introduced previously: The atomic
> {aborted_} flag and the {FreeCallbacksTask}.
>
> R=mstarzinger@chromium.org
> CC=titzer@chromium.org
>
> Bug: v8:8689, v8:7921
> Change-Id: I42e06eab3c944b0988286f2ce18e3c294535dfb6
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/1421364
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59020}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: I724f460f5aa654a9e75d3ce73d351214e69e2d96
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8689, v8:7921
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1429861
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59022}
Background compile jobs should not keep the NativeModule alive, for two
reasons:
1) We sometimes have to wait for background compilation to finish (from
a foreground task!). This introduces unnecessary latency.
2) Giving the background compile tasks shared ownership of the
NativeModule causes the NativeModule (and the CompilationState) to
be freed from background tasks, which is error-prone (see
https://crrev.com/c/1400420).
Instead, this CL introduces a BackgroundCompileToken which is held
alive by the NativeModule and all background compile jobs. The initial
and the final phase of compilation (getting and submitting work)
synchronize on this token to check and ensure that the NativeModule is
and stays alive. During compilation itself, the mutex is released, such
that the NativeModule can die.
The destructor of the NativeModule cancels the BackgroundCompileToken.
Immediately afterwards, the NativeModule and the CompilationState can
die.
This change allows to remove two hacks introduced previously: The atomic
{aborted_} flag and the {FreeCallbacksTask}.
R=mstarzinger@chromium.orgCC=titzer@chromium.org
Bug: v8:8689, v8:7921
Change-Id: I42e06eab3c944b0988286f2ce18e3c294535dfb6
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1421364
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59020}
Everything was including log.h through heap-inl.h, so remove that
include by moving the one user into heap.cc, and then fix all the
include errors.
This reduces the log.h include ball from ~550 to ~100.
Change-Id: I6d09bc2f365b48645fcfdc695a68ea12539a745d
Reviewed-on: https://chromium-review.googlesource.com/c/1424198
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58981}
We often use ResultBase or VoidResult to store or pass wasm errors
(errors with locations). This CL extracts a WasmError class which can
store an error (can also be empty), and Result<T> which stores an error
or a T (exactly one of them).
R=titzer@chromium.org
Bug: v8:8689
Change-Id: I3f5203559984a0ae8757e0130a9184957fa28df5
Reviewed-on: https://chromium-review.googlesource.com/c/1409365
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58827}
This refactoring CL moves all instantiation logic in its own file,
separating it from the module compiler.
R=ahaas@chromium.org
Change-Id: I5a721c7357022dd7bf32f776b2ab0153f7dd68fc
Reviewed-on: https://chromium-review.googlesource.com/c/1409429
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58797}
This reverts commit ac2fb66b65.
Reason for revert: Flakily crashes on several bots:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32/18524https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20msvc/6824https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20-%20internal%20snapshot/19766
Original change's description:
> [wasm] Remove finisher task
>
> This removes the finisher task and instead finishes compilation units
> from the background.
> It also changes ownership of the AsyncCompileJob to be shared among all
> tasks that still operate on it. The AsyncCompileJob dies when the last
> reference dies.
>
> R=ahaas@chromium.org
> CC=mstarzinger@chromium.org
>
> Bug: v8:7921, v8:8423
> Change-Id: Id09378327dfc146459ef41bc97176a8716756ae4
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/1335553
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58630}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: I6b332b66adaec8f713fb31f4c8517cae7ebb4645
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7921, v8:8423
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1400420
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58634}
This removes the finisher task and instead finishes compilation units
from the background.
It also changes ownership of the AsyncCompileJob to be shared among all
tasks that still operate on it. The AsyncCompileJob dies when the last
reference dies.
R=ahaas@chromium.org
CC=mstarzinger@chromium.org
Bug: v8:7921, v8:8423
Change-Id: Id09378327dfc146459ef41bc97176a8716756ae4
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1335553
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58630}
We currently trigger a GC when creating a module while the remaining
uncommitted code space is below 32MB. For bigger modules, this is not
enough. Instead, make this limit relative: Trigger GC if we fall below
50% of the available code space, and re-adjust this limit after each GC
to avoid repeated GCs that do not free anything.
R=ahaas@chromium.org
Bug: v8:8624
Change-Id: I7abfad3b57663d528a26d29232ad6bc2dc63cef4
Reviewed-on: https://chromium-review.googlesource.com/c/1391753
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58527}
Introduce a LeakyObject template and use that to implement static
lazily initialized objects that never get destructed. This was done in a
hand-crafted and complex way before via LazyInstance and
LazyStaticInstance.
R=tebbi@chromium.org
Bug: v8:8600, v8:8562
Change-Id: Id160996753b2cb1baf0f4b2cec9e1727f1d01512
Reviewed-on: https://chromium-review.googlesource.com/c/1388539
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58494}
Compilation failures are already stored in the {CompilationState}. We
never use the information which individual compilation unit failed.
Hence remove that getter, and only check for failure of the overall
compilation.
R=ahaas@chromium.org
Bug: v8:7921, v8:8343
Change-Id: Ibf90be233c9ff576ec8a3413ba5abefe2fdb645e
Reviewed-on: https://chromium-review.googlesource.com/c/1373783
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58195}
This was done via {managed_native_module()->get()}. Add a simple getter
for that.
R=ahaas@chromium.org
Bug: v8:8562
Change-Id: I8e461a8e16b618abdb772098fad3a6b721d54902
Reviewed-on: https://chromium-review.googlesource.com/c/1371564
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58156}
The class declaration regexp in cpplint did not catch classes decorated
by V8_EXPORT, V8_EXPORT_PRIVATE or any other decorator containing
digits.
This will be fixed in https://github.com/google/styleguide/pull/422.
This CL already prepares the code base by fixing all errors that will
be found after that change.
Some follow-up changes were needed to fix implicit conversion that are
not taken any more now.
R=mstarzinger@chromium.org
Bug: v8:8562
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I03713bd04dbc3f54b89a6c857a93463139aa5efd
Reviewed-on: https://chromium-review.googlesource.com/c/1367751
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58143}
CompileJsToWasmWrappers only needs a WasmModule, so we should not pass
in a NativeModule.
R=clemensh@chromium.org
Bug: v8:8562
Change-Id: Ic38f1bee2eab3a06921c27f56fd175b51688ad5f
Reviewed-on: https://chromium-review.googlesource.com/c/1367748
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58120}
Moves allocation of the WasmModuleObject for asm.js code out of SyncCompileTranslatedAsmJS
since that is called when we are compiling the native context independent SharedFunctionInfo
and the WasmModuleObject requires a native context. Instead save the members required to
create the object in the AsmWasmData and create it during module instantiation. Note:
since the Wasm module is an implementation detail for asm_wasm code and isn't exposed,
this doeesn't have semantic change for asm.js code.
As part of this change, the AsmWasmData is changed from a FixedArray to a dedicated
struct. Some logic is also moved from module-compiler to wasm-engine to make the
seperation between Wasm SyncCompile and AsmJS SyncCompile more clear.
BUG=chromium:900535,v8:8395
Change-Id: Ia48469c095b0688f210aa86e7430c9ab4ea4b26b
Reviewed-on: https://chromium-review.googlesource.com/c/1345509
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57704}
1) For the code space estimate, exclude everything except code.
2) Add some static code size per function.
3) Add some static code size per module.
4) Include signature zone memory.
R=mstarzinger@chromium.org
Change-Id: Ifa9ac347edf98c2e63ab3201a64ac2e0a3de28e5
Reviewed-on: https://chromium-review.googlesource.com/c/1118263
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57436}
For memory limit checks, we should use the minimum of the
--wasm-max-mem-pages flag and kV8MaxWasmMemoryPages. The former is a
limit set by the user, the latter is the maximum we can handle
internally.
R=titzer@chromium.org
Bug: chromium:898677
Change-Id: I3c549f4e90dd016b5d07475d9353f30134f76dcc
Reviewed-on: https://chromium-review.googlesource.com/c/1305274
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57127}
This is a reland of bf3d7b9ae3
Original change's description:
> [wasm] Store compile errors in CompilationState
>
> We are currently storing compilation errors in the individual
> compilation units and pass it to the ErrorThrower during finishing.
> This CL changes that to store errors on the CompilationState directly.
> From there, it is propagated to the ErrorThrower in the compilation
> state callback.
> This removes more work from the finisher task and slims down the
> WasmCompilationUnits.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:8343, v8:7921
> Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9
> Reviewed-on: https://chromium-review.googlesource.com/c/1303720
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57091}
Bug: v8:8343, v8:7921
Change-Id: Iaa5c89d224cb2bcfca2d12eba305413a9ad95618
Reviewed-on: https://chromium-review.googlesource.com/c/1304547
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57126}
This reverts commit bf3d7b9ae3.
Reason for revert: Breaks TSAN build, see
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20TSAN/23248
Original change's description:
> [wasm] Store compile errors in CompilationState
>
> We are currently storing compilation errors in the individual
> compilation units and pass it to the ErrorThrower during finishing.
> This CL changes that to store errors on the CompilationState directly.
> From there, it is propagated to the ErrorThrower in the compilation
> state callback.
> This removes more work from the finisher task and slims down the
> WasmCompilationUnits.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:8343, v8:7921
> Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9
> Reviewed-on: https://chromium-review.googlesource.com/c/1303720
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57091}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: Id32c7337494a4749485adbcfcaae7b2331afea66
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8343, v8:7921
Reviewed-on: https://chromium-review.googlesource.com/c/1304544
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57094}
We are currently storing compilation errors in the individual
compilation units and pass it to the ErrorThrower during finishing.
This CL changes that to store errors on the CompilationState directly.
From there, it is propagated to the ErrorThrower in the compilation
state callback.
This removes more work from the finisher task and slims down the
WasmCompilationUnits.
R=mstarzinger@chromium.org
Bug: v8:8343, v8:7921
Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9
Reviewed-on: https://chromium-review.googlesource.com/c/1303720
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57091}
