This adds preliminary support for handling the "br_on_exn" opcode in the
interpreter. It also makes "catch" and "rethrow" use a proper exception
reference instead of a dummy value.
To that end this also adds {Handle<>} as a new kind of {WasmValue} which
is intended to pass reference values (e.g. "anyref" or "except_ref") to
the runtime system. Therefore lifetime of such a {WasmValue} is directly
coupled to any surrounding {HandleScope}.
For now we just store {Handle<>} directly on the simulated operand stack
of the interpreter. This is of course bogus, since the surrounding scope
does not outlive the interpreter activation. Decoupling the lifetime of
the operand stack from a {HandleScope} will be done in a follow-up CL.
As a drive-by this change also implements support for the "ref_null" and
the "ref_is_null" opcodes as a proof-of-concept that the new {WasmValue}
is also applicable to the "anyref" reference type.
R=clemensh@chromium.org
TEST=cctest/test-run-wasm-interpreter/ReferenceTypeLocals
BUG=v8:8091,v8:7581
Change-Id: I2307e0689a19c4aab1d67f1ba6742cb3cc31aa3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550299
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60598}
Adds the notion of a "source type" to CpuProfileNode instances, hinting
at the underlying source of the function or state that resulted in the
generation of the node.
Bug: v8:9001
Change-Id: Ie14c54d41b99eb02f54b423fa5d939e9d7f63785
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1510576
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60590}
Includes both changing from compressed pointers and to compressed pointers.
Also added tests to the representation changer test
B
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng,v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:8977
Change-Id: I8a13f6b7ec2208442aa354949173cc9061bce168
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533866
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60587}
This is a reland of 3cda21de77
Original change's description:
> V8 x64 backend doesn't emit ABI compliant stack frames
>
> On 64 bit Windows, the OS stack walking does not work because the V8 x64
> backend doesn't emit unwinding info and also because it doesn't emit ABI
> compliant stack frames. See
> https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
> for more details.
>
> This problem can be fixed by observing that V8 frames usually all have the same
> prolog and epilog:
>
> push rbp,
> mov rbp, rsp
> ...
> pop rbp
> ret N
>
> and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
> should walk through V8 frames. Furthermore, since V8 Code objects are all
> allocated in the same code-range for an Isolate, it is possible to register a
> single PDATA/XDATA entry to cover stack walking for all the code generated
> inside that code-range.
>
> This PR contains changes required to enable stack walking on Win64:
>
> EmbeddedFileWriter now adds assembler directives to the builtins
> snapshot source file (embedded.cc) to emit additional entries in the .pdata and
> in the .xdata section of the V8 executable. This takes care of stack walking
> for embedded builtins. (The case of non-embedded builtins is not supported).
> The x64 Assembler has been modified to collect the information required to emit
> this unwind info for builtins.
>
> Stack walking for jitted code is handled is Isolate.cpp, by registering
> dynamically PDATA/XDATA for the whole code-range address space every time a new
> Isolate is initialized, and by unregistering them when the Isolate is
> destroyed.
>
> Stack walking for WASM jitted code is handled is the same way in
> wasm::NativeModule (wasm/wasm-code-manager.cpp).
>
> It is important to note that Crashpad and Breakpad are already registering
> PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
> builtins). Since it is not possible to register multiple PDATA entries for the
> same address range, a new function is added to the V8 API:
> SetUnhandledExceptionCallback() can be used by an embedder to register its own
> unhandled exception handler for exceptions that arise in v8-generated code.
> V8 embedders should be modified accordingly (code for this is in a separate PR
> in the Chromium repository:
> https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
>
> All these changes are experimental, behind:
>
> the 'v8_win64_unwinding_info' build flag, and
> the '--win64-unwinding-info' runtime flag.
>
> Bug: v8:3598
> Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#60330}
Bug: v8:3598
Change-Id: If988baf7d3e4af165b919d6e54c1ad985f8e25e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1534618
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60581}
This CL adds all the necessary {WasmCodeRefScope}s in the code base, or
at least a good approximation. A follow-up CL will enable a check that
a {WasmCodeRefScope} exists whenever a pointer to a {WasmCode} object
is returned from the {NativeModule}. This should flush out any missing
scopes.
R=titzer@chromium.org
Bug: v8:8217
Change-Id: I54c7eb39aeb1acde38273c399396e6b1390a4cb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533860
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60566}
This is a reland of 09fa63a935
Original change's description:
> [wasm-hints] Enabled Lazy Compilation by Hint
>
> Hints for lazy compilation are now taken into consideration. If the
> custom hints section suggests lazy compilatin we do so unless the module
> consists of a single function.
>
> Bug: v8:9003
> Change-Id: Ibdc400453cee20d4d5c814733887b38fb675b220
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535827
> Commit-Queue: Frederik Gossen <frgossen@google.com>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60557}
Bug: v8:9003
No-Try: true
Change-Id: I8d6f4518aa548c815fba4e6e62d2206129336cc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547851
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60564}
This reverts commit 09fa63a935.
Reason for revert: Falkes on https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/29942
Original change's description:
> [wasm-hints] Enabled Lazy Compilation by Hint
>
> Hints for lazy compilation are now taken into consideration. If the
> custom hints section suggests lazy compilatin we do so unless the module
> consists of a single function.
>
> Bug: v8:9003
> Change-Id: Ibdc400453cee20d4d5c814733887b38fb675b220
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535827
> Commit-Queue: Frederik Gossen <frgossen@google.com>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60557}
TBR=mstarzinger@chromium.org,clemensh@chromium.org,frgossen@google.com
Change-Id: I18dd424fe8cf05f220f7498bb1ebe4b9fce7d240
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9003
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547668
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60558}
Hints for lazy compilation are now taken into consideration. If the
custom hints section suggests lazy compilatin we do so unless the module
consists of a single function.
Bug: v8:9003
Change-Id: Ibdc400453cee20d4d5c814733887b38fb675b220
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535827
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60557}
Even though both are allowed in the style guide, it recommends to use
'using', as its syntax is more consistent with the rest of C++.
This CL turns all typedefs in heap code to 'using' declarations.
R=mstarzinger@chromium.org
Bug: v8:8834
Change-Id: I8a9f6e1eebdd0adca4373c866e95ebab0a1e992d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545892
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60523}
Even though both are allowed in the style guide, it recommends to use
'using', as its syntax is more consistent with the rest of C++.
This CL turns all typedefs in wasm code to 'using' declarations.
R=ahaas@chromium.org
Bug: v8:8834
Change-Id: Ibdce88a5cc31e0785cbc1b34088bd39aa3ec84b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545890
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60519}
When switching from atomicops to std::atomic, I introduced a bug that
makes us miss the actual peak memory consumption, and only report the
second-highest memory usage in each zone.
This CL fixes that.
R=petermarshall@chromium.org
Bug: chromium:939724
Change-Id: I3db8eeb9719eb026cf6b4a9690c702cbc4c11bd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541227
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60505}
Previously when lazy source positions were enabled, source positions
were immediately collected whenever an exception was thrown for every
frame in the stack trace.
This change makes source position collection trigger only when the
source positions of a stack frame are actually accessed with the
exception of the top frame which is still eagerly collected for now.
Additionally when stack overflows occur during source position
collection, the bytecode is marked with exception in the
source_position_table field so it can be distinguished from the case
where source position collection has never been attempted (undefined)
or is not desired because the bytecode is for natives
(empty_byte_array).
Bug: v8:8510
Change-Id: If7ee68edbacc9e2adadf00fe5ec822a8dbe1c79a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520721
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60504}
- Fixes a bug where signaling NaNs are converted to
Infinities rather than quiet NaNs.
Bug: v8:6020,v8:8639
Change-Id: I2601378f06f1987983f2b93e8970f401333073be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1536911
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60480}
This reverts commit 63608968b6.
Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/19535
Original change's description:
> [wasm] Implement table.init for interpreter
>
> This also fixes CheckCallViaJS when a trap occurs. In that case, the
> trap callback is called instead of an exception being thrown, so if it
> isn't handled, a bogus result will be returned instead.
>
> Bug: v8:8965
> Change-Id: I560e89f353756df23c062fb8c9484d9971c19253
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539078
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ben Smith <binji@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60473}
TBR=binji@chromium.org,mstarzinger@chromium.org
Change-Id: Iee528ac2f16988b25579af3555e6f17974cb0b05
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8965
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539498
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60474}
This also fixes CheckCallViaJS when a trap occurs. In that case, the
trap callback is called instead of an exception being thrown, so if it
isn't handled, a bogus result will be returned instead.
Bug: v8:8965
Change-Id: I560e89f353756df23c062fb8c9484d9971c19253
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539078
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60473}
Drive-by: also add support for trivial bytecodes such as LdaFalse.
Bug: v8:7790
Change-Id: I72626500096310899d37d57e3d0dd3bd54fddff4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532066
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60460}
Allocate feedback vectors lazily when the function's interrupt budget has
reached a specified threshold. This cl introduces a new field in the
ClosureFeedbackCellArray to track the interrupt budget for allocating
feedback vectors. Using the interrupt budget on the bytecode array could
cause problems when there are closures across native contexts and we may
delay allocating feedback vectors in one of them causing unexpected
performance cliffs. In the long term we may want to remove interrupt budget
from bytecode array and use context specific budget for tiering up decisions
as well.
Bug: v8:8394
Change-Id: Ia8fbb71f5e8543a92f14c44aa762973da82d445c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520719
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60450}
This adds OBJECT/SNAPSHOT trace events for Script and SharedFunctionInfo
objects, logging their creation with appropriate information to make
sense of them.
Based on that we introduces five flow events to model the optimized
compilation via tracing in the "disabled-by-default-v8.compile" category:
- "v8.optimizingCompile.start" logs the creation of the
PipelineCompilationJob (for TurboFan JavaScript optimization)
with the "function" argument referring to the trace event
object created for the SharedFunctionInfo.
- "v8.optimzingCompile.prepare" logs the preparation of the
PipelineCompilationJob on the main thread, also carrying the
"function" argument. This connects the flow event to the actual
tracing duration event associated with the preparation phases.
- "v8.optimizingCompile.execute" logs the (usually concurrent)
optimization of the TurboFan graph (again with "function").
- "v8.optimizingCompile.finalize" logs the main thread phase which
finalizes the optimized code and eventually installs it (in case
of success).
- "v8.optimizingCompile.end" signals the end of the
PipelineCompilationJob, which carries the "compilationInfo",
that contains the interesting bits of the OptimizedCompilationInfo,
specifically whether the compile was successfull and which functions
were inlined for example.
This also adds two instant events "V8.AbortOptimization" and
"V8.RetryOptimization" in "disabled-by-default-v8.compile" category
that are emitted when TurboFan cannot optimize a certain function.
In case of "V8.RetryOptimization", TurboFan might be able to optimize
it later, whereas "V8.AbortOptimization" permanently disables the
optimization of a given function. The JSON representation of this is
```js
{
"pid": 256639,
"tid": 256639,
"ts": 6935411377801,
"tts": 159116,
"ph": "I",
"cat": "disabled-by-default-v8.compile",
"name": "V8.AbortOptimization",
"dur": 0,
"tdur": 0,
"args": {
"reason": "Function is too big to be optimized",
"function": {
"id_ref": "0x600000001",
"scope": "v8::internal::SharedFunctionInfo"
}
}
},
```
where the "function" refers to a previously emitted SNAPSHOT for the
function in question. In the trace viewer it will show up as instant
event under "v8.optimizingCompile.prepare" in case of the relevant
example where optimization is disabled due to reaching the bytecode
limit (as in the JSON above), i.e. it'll look something like this
https://i.paste.pics/aafc2de9df10ea8f5acc1a761d80f07b.png
for the example highlighted in the recent blog post
https://ponyfoo.com/articles/javascript-performance-pitfalls-v8
that describes the optimization limit. The "v8.optimizingCompile.end"
duration event will also carry this information as part of the
"compilationInfo" object, but specifically for CI tools, etc. it might
be a whole lot easier to just look for the "V8.AbortOptimization"
instant event.
Bug: v8:8598, v8:9039
Tbr: ulan@chromium.org
Doc: bit.ly/v8-tracing-signals
Change-Id: Ic87ac336004690c65b6b15ad73bc6fbd4b5f12c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511483
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60448}
The macros take implicit local arguments and make the tests harder to
read. Remove the macros and add a helper to get size directly given
this is the only use of the helper that returns the whole list.
Remove the typedef of vector of trace events, because it is only used
in two places now and is also called 'list' not vector.
Use unique pointers for the ownership of MockTraceObject.
Change-Id: Iec495c436cf7326224137321a84035c817622eaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538131
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60443}
This CL adds handling for cleaning up weakmap (EphemeronHashTable)
keys during scavenge, even if the weakmap resides in oldspace.
Change-Id: If8d711c050ddbcae4dd6e8da549e0c0d08ba47b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1523787
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60432}
Both js-to-wasm-wrapper-cache-inl.h and wasm-import-wrapper-cache-inl.h
do not include any inl headers, thus they can be plain headers. If they
ever need to include inl headers again, we should split out the
respective functions into a separete inl header to follow the usual
pattern to have *both* a plain header *and* an inl header.
R=mstarzinger@chromium.org
Bug: v8:8834
Change-Id: I1b1b917a8e2c47f1354522479f8c57475bee6244
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535826
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60431}
- Changes min and max sequences to propagate NaNs and signed
zeroes.
- Note that NaN propagation must preserve canonical NaNs. This is
achieved by always returning canonical NaNs. This is also
consistent with the WebAssembly scalar math spec.
Bug: v8:8639
Change-Id: I04fdefabc54ea60f4d02e2081c32444a02dd6a83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524634
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60414}
Most of the mjsunit/wasm/table-copy.js tests have been ported to
cctests, so they can be tested with all execution tiers.
Bug: v8:8965
Change-Id: I448719be30a4b2bddb9e2cffb4c74d3134db2f50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529548
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60396}
Said instructions look like ChangeTaggedXXXToCompressedXXX and
ChangeCompressedXXXToTaggedXXX for XXX in ("", "Pointer", "Signed").
This change only affects 64 bit architectures (both for x64 and arm64).
Also added tests for the machine operators.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng,v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:8977
Change-Id: I239d9de7f214424852e75b5d56996e8dfdacd400
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526009
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60393}
FixedArray object in LO space are processed incrementally in ranges of slots
size kProgressBarScanningChunk to reduce latency when returning to the
processing loop is critical. A progress bar stores how much slots have been
processed already.
In the case of regular concurrent marking there was a guarantee that the
object was only processed by one thread (main *or* concurrent marking
thread) at the same time.
However, some optimizations that avoid write barriers for each
individual write operation emit a batched write barrier that requires
re-visiting the FixedArray for the marking barrier. In such cases, the
progress bar would be reset using relaxed stores which is problematic as
the concurrent marking thread could race on setting its own progress on the
progress bar. As a result, the array would only be re-scanned partially.
The fix involves using CAS to set the progress bar and bail out in the
case an inconsistent state was observed.
In the following:
MT... main thread
CM... concurrent marking thread
The interesting cases are:
1. MT *or* CM processes the array without interfering: Progress bar is
updated monotonically without failing.
3. MT interferes with itself: The progress bar is just reset and the main
thread will restart scanning from index 0. The object is added twice to
the marking worklist and processed each time one of the entries is
retrieved from the worklist.
4. MT interferes with CM:
4.a.: CM processes a range of slots and re-adds the left overs by
setting the progress bar and re-adding the array to the worklist. In
this case CM *and* MT process the array from index 0. The first time
the CAS for setting the progress bar fails on either of the threads,
the looser will bail out and leave processing for the winner.
4.b.: CM is interrupted while processing a range of the array and
fails in setting the progress bar for the left overs. In this case
the CM bails out right away and the main thread starts processing
from index 0.
In addition, there is a transition from index 0 to the index of the
first actual slot. This transition makes it possible to observe a reset
while processing the first actual chunk of slots.
Bug: chromium:942699
Change-Id: I0b06f47ee075030dadfc959528cd77b6b69bbec2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532325
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60385}
The reason for the revert was that Liftoff did not bail out on indirect
calls to tables other than table 0. Whenever the Liftoff code got
executed, the test would fail.
Original message:
With this CL it is possible to use any anyfunc table in call-indirect,
not just the first table.
The current implementation is based on runtime calls. This is just an
initial implementation which should be replaced by a
dispatch-table-based eventually. However, this implementation allows
us to move forward with the anyref proposal implementation.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: Iedd56ee7acb281441bca32ffd3dc7157203ee1ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532072
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60382}
When running wasm tests, the interpreter previously used a static
collection of function indexes stored in WasmTable to perform
call_indirect calls internal to that module. This has the wrong behavior
if the table is changed (via WasmTableObject::Set, `table.copy`, or
`table.init`).
This CL changes the cctests to always generate an intepreter entry for
all functions, and stores those entries in the dispatch table. This
allows us to use the same execution path as for non-testing code.
The interpreter entry compiler needed to be changed to support
multi-value returns too, since a 64-bit integer return value may be
lowered to two 32-bit integer returns.
Bug: v8:9016
Change-Id: I277df21ffde5c2eee0b691fcc9bab2b1a43eeffc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1531137
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60380}
This reverts commit 3cda21de77.
Reason for revert: Breaks the roll on Windows (see https://cr-buildbucket.appspot.com/build/8918477701097622400)
Original change's description:
> V8 x64 backend doesn't emit ABI compliant stack frames
>
> On 64 bit Windows, the OS stack walking does not work because the V8 x64
> backend doesn't emit unwinding info and also because it doesn't emit ABI
> compliant stack frames. See
> https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
> for more details.
>
> This problem can be fixed by observing that V8 frames usually all have the same
> prolog and epilog:
>
> push rbp,
> mov rbp, rsp
> ...
> pop rbp
> ret N
>
> and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
> should walk through V8 frames. Furthermore, since V8 Code objects are all
> allocated in the same code-range for an Isolate, it is possible to register a
> single PDATA/XDATA entry to cover stack walking for all the code generated
> inside that code-range.
>
> This PR contains changes required to enable stack walking on Win64:
>
> EmbeddedFileWriter now adds assembler directives to the builtins
> snapshot source file (embedded.cc) to emit additional entries in the .pdata and
> in the .xdata section of the V8 executable. This takes care of stack walking
> for embedded builtins. (The case of non-embedded builtins is not supported).
> The x64 Assembler has been modified to collect the information required to emit
> this unwind info for builtins.
>
> Stack walking for jitted code is handled is Isolate.cpp, by registering
> dynamically PDATA/XDATA for the whole code-range address space every time a new
> Isolate is initialized, and by unregistering them when the Isolate is
> destroyed.
>
> Stack walking for WASM jitted code is handled is the same way in
> wasm::NativeModule (wasm/wasm-code-manager.cpp).
>
> It is important to note that Crashpad and Breakpad are already registering
> PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
> builtins). Since it is not possible to register multiple PDATA entries for the
> same address range, a new function is added to the V8 API:
> SetUnhandledExceptionCallback() can be used by an embedder to register its own
> unhandled exception handler for exceptions that arise in v8-generated code.
> V8 embedders should be modified accordingly (code for this is in a separate PR
> in the Chromium repository:
> https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
>
> All these changes are experimental, behind:
>
> the 'v8_win64_unwinding_info' build flag, and
> the '--win64-unwinding-info' runtime flag.
>
> Bug: v8:3598
> Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#60330}
TBR=bbudge@chromium.org,ulan@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,gdeepti@chromium.org,jgruber@chromium.org,paolosev@microsoft.com
Change-Id: If8470da94c58df8c800cbe8887f9f86236e43353
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:3598
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532321
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60372}
This prepares a refactoring to add and publish compilation results in
batches. For this, we need to separate the two phases, so that we can
lock the module, allocate all the code space, release the lock, copy
the code, lock the module, publish the code, and release the lock
again.
In particular, this CL does the following:
1) It removes the {AddOwnedCode} method. The functionality of creating
the {WasmCode} and memcpy'ing the instruction into that is done in
the other {Add*Code} methods. Adding to {owned_code_} is done in
{PublishCode}.
2) {PublishInterpreterEntry} is now functionally equivalent to
{PublishCode}, so it's removed.
3) After {AddCode}, the caller has to call {PublishCode}. In a
follow-up CL, this will be called in batches (first {AddCode} them
all, then {PublishCode} them all).
4) {AddCompiledCode} now assumes that the {WasmCompilationResult}
succeeded. Otherwise, the caller should directly call {SetError} on
the {CompilationState}.
5) {PublishCode} is now the chokepoint for installing code to the code
table, the owned code vector, the jump table, and setting interpreter
redirections. It replaces previous direct calls to {InstallCode} or
explicitly adding to {owned_code_}.
6) Increasing the {generated_code_size_} counter is now done in
{AllocateForCode}, which is the chokepoint for allocating space for
generated code. This way, we will only increase this counter once
once we allocate in batches.
R=titzer@chromium.org
Bug: v8:8916
Change-Id: I71e02e3a838f21797915cee3ebd373804fb12237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530817
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60369}
This reverts commit 9d167f57e0.
Reason for revert: There is a crash on https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/20026
Original change's description:
> [wasm][anyref] Add support of call-indirect for multiple tables
>
> With this CL it is possible to use any anyfunc table in call-indirect,
> not just the first table.
>
> The current implementation is based on runtime calls. This is just an
> initial implementation which should be replaced by a
> dispatch-table-based eventually. However, this implementation allows
> us to move forward with the anyref proposal implementation.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:7581
> Change-Id: I57d09b18add7f525555bf7c949aef17a64b0e7c5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530801
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60360}
TBR=mstarzinger@chromium.org,ahaas@chromium.org
Change-Id: Iba4b84078aa070498be7e79212970b94595f5757
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7581
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532069
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60362}
With this CL it is possible to use any anyfunc table in call-indirect,
not just the first table.
The current implementation is based on runtime calls. This is just an
initial implementation which should be replaced by a
dispatch-table-based eventually. However, this implementation allows
us to move forward with the anyref proposal implementation.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I57d09b18add7f525555bf7c949aef17a64b0e7c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530801
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60360}
This is a reland of f8962ae1a2
Original change's description:
> Preparing v8 to use with python3 /test
>
> There are now less that 400 days until the end of life
> of Python 2(aka _legacy_ Python) https://pythonclock.org/ .
> The code compatibility check for python2 and python3
> used the following tools: futurize, flake8
> You can see the reports here: https://travis-ci.com/bmsdave/v8/builds
>
> This CL was uploaded by git cl split.
>
> Bug: v8:8594
> Change-Id: Idbf467daf629a4e808345a6a88036c2a3f259138
> Reviewed-on: https://chromium-review.googlesource.com/c/1470121
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59679}
Bug: v8:8594
Change-Id: I8c1a8d6593a4a927d56d37dada2c704062e842cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1484300
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60354}
Omit user roots when raw heap snapshots are used, i.e., when
the gn flag v8_enable_raw_heap_snapshots is enabled. For regular
Chrome production builds this is not the case.
Blink CL: https://crrev.com/c/1529096
Bug: chromium:936797
Change-Id: I5ae0ec1ecfab9a76352d8ce927d1c40e707262cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1528994
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60351}
WasmRunner provides CheckCallViaJS, which calls a wasm function through
JS and checks its result.
There are currently two overloads, one that takes a variable number of
arguments, and another more general 4-argument version that takes an
array of arguments. This means if you run code like:
r.CheckCallViaJS(0, 0, 0, 0);
The overload resolution kicks in, and chooses the general version, which
will always segfault.
This CL renames the general version to `CheckCallApplyViaJS` so the
above example will call the variable-argument version instead.
Change-Id: I14a742c467692e09e84f03504cec2306a794fc24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529990
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60345}
On 64 bit Windows, the OS stack walking does not work because the V8 x64
backend doesn't emit unwinding info and also because it doesn't emit ABI
compliant stack frames. See
https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
for more details.
This problem can be fixed by observing that V8 frames usually all have the same
prolog and epilog:
push rbp,
mov rbp, rsp
...
pop rbp
ret N
and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
should walk through V8 frames. Furthermore, since V8 Code objects are all
allocated in the same code-range for an Isolate, it is possible to register a
single PDATA/XDATA entry to cover stack walking for all the code generated
inside that code-range.
This PR contains changes required to enable stack walking on Win64:
EmbeddedFileWriter now adds assembler directives to the builtins
snapshot source file (embedded.cc) to emit additional entries in the .pdata and
in the .xdata section of the V8 executable. This takes care of stack walking
for embedded builtins. (The case of non-embedded builtins is not supported).
The x64 Assembler has been modified to collect the information required to emit
this unwind info for builtins.
Stack walking for jitted code is handled is Isolate.cpp, by registering
dynamically PDATA/XDATA for the whole code-range address space every time a new
Isolate is initialized, and by unregistering them when the Isolate is
destroyed.
Stack walking for WASM jitted code is handled is the same way in
wasm::NativeModule (wasm/wasm-code-manager.cpp).
It is important to note that Crashpad and Breakpad are already registering
PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
builtins). Since it is not possible to register multiple PDATA entries for the
same address range, a new function is added to the V8 API:
SetUnhandledExceptionCallback() can be used by an embedder to register its own
unhandled exception handler for exceptions that arise in v8-generated code.
V8 embedders should be modified accordingly (code for this is in a separate PR
in the Chromium repository:
https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
All these changes are experimental, behind:
the 'v8_win64_unwinding_info' build flag, and
the '--win64-unwinding-info' runtime flag.
Bug: v8:3598
Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60330}
This makes it easier to publish them in batches. Function index and
requested compilation tier are duplicated from the WasmCompilationUnit.
R=titzer@chromium.org
Bug: v8:8916
Change-Id: I87852670be029b1d729f98f01729362ca379fb50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529009
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60325}
We should use 'constant pool' to allow concurrent patching of
the jump table like arm. For now just skip the test to make CI
mips bot green.
Bug: v8:8974
Change-Id: Iaf2b0245128fdcf2c8ed964f796781134570c889
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524755
Commit-Queue: Yu Yin <xwafish@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60323}
This change significantly improves the performance of string
concatenation in optimized code for the case where the resulting string
is represented as a ConsString. On the relevant test cases we go from
serializeNaive: 10762 ms.
serializeClever: 7813 ms.
serializeConcat: 10271 ms.
to
serializeNaive: 10278 ms.
serializeClever: 5533 ms.
serializeConcat: 10310 ms.
which represents a 30% improvement on the "clever" benchmark, which
tests specifically the ConsString creation performance.
This was accomplished via a couple of different steps, which are briefly
outlined here:
1. The empty_string gets its own map, so that we can easily recognize
and handle it appropriately in the TurboFan type system. This
allows us to express (and assert) that the inputs to NewConsString
are non-empty strings, making sure that TurboFan no longer creates
"crippled ConsStrings" with empty left or right hand sides.
2. Further split the existing String types in TurboFan to be able to
distinguish between OneByte and TwoByte strings on the type system
level. This allows us to avoid having to dynamically lookup the
resulting ConsString map in case of ConsString creation (i.e. when
we know that both input strings are OneByte strings or at least
one of the input strings is TwoByte).
3. We also introduced more finegrained feedback for the Add bytecode
in the interpreter, having it collect feedback about ConsStrings,
specifically ConsOneByteString and ConsTwoByteString. This feedback
can be used by TurboFan to only inline the relevant code for what
was seen so far. This allows us to remove the Octane/Splay specific
magic in JSTypedLowering to detect ConsString creation, and instead
purely rely on the feedback of what was seen so far (also making it
possible to change the semantics of NewConsString to be a low-level
operator, which is only introduced in SimplifiedLowering by looking
at the input types of StringConcat).
4. On top of the before mentioned type and interpreter changes we added
new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
checks.
There are several more improvements that are possible based on this, but
since the change was already quite big, we decided not to put everything
into the first change, but do some follow up tweaks to the type system,
and builtin optimizations later.
Tbr: mstarzinger@chromium.org
Bug: v8:8834, v8:8931, v8:8939, v8:8951
Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Doc: https://bit.ly/fast-string-concatenation-in-javascript
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60318}
Consumers can use this to derive the full stack from sampled leaf nodes
without having to flatten the tree.
Bug: v8:8999
Change-Id: I42c638dd2c757837b0c03514c204be0182653291
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1525877
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60309}
Even in streaming mode we want to generate deterministic compile
errors, in particular they should contain the function name.
This CL adds a test to check that the name is present in the error
message even if the blob containing the function names is not present
at the time the compile error is detected.
R=ahaas@chromium.org
Bug: v8:8814
Change-Id: I17eb1b3bca48ee2b58b462089c140c30a3511be8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526001
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60302}
On LoadCodeObjectEntry check for IsOffHeapTrampoline instead of
BuiltinIndexOffset so LoadCodeObjectEntry can correctly jump to the
on-heap trampoline when we use --interpreted-frames-native-stack.
R=jgruber@chromium.org, yangguo@google.com
Bug: v8:8911
Change-Id: I172d4735671726d32328de246990b513106e3a7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1516692
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60288}
