This prints a message whenever we discard compiled metadata of an SFI.
The message identifies the SFI. I've found this helpful when debugging.
Change-Id: Ib34266199ade2ef88a6bafe32295ab505ce7c899
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324260
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69132}
I noticed that, with pointer-compression enabled, in map checks we no
longer load the map as part of the cmp instruction:
movl rcx,[rdx-0x1]
movl rdi,0x8286f8d ;; (compressed) object: <Map(HOLEY_ELEMENTS)>
cmpl rdi,rcx
This CL restores that:
movl rcx,0x82c6f8d ;; (compressed) object: <Map(HOLEY_ELEMENTS)>
cmpl [rdx-0x1],rcx
Change-Id: Ifcc7f34fddf6aa423c0a26066ac124e9757cb9ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320653
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69130}
The bug was that the allocation of the result array (before the loop)
was using the outer frame state, thus returning the allocation's result
(an array full of holes) as the return value of the map operation in
case the allocation triggers a lazy deopt.
Bug: chromium:1104514
Change-Id: I9a6db8a5860472e1b438b6b54414938d61e166c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324249
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69129}
Since we now add the additional required capacity when assessing
StringTable shrinking during LookupKey-caused string insertion, we no
longer have to add a slack capacity. This more closely matches previous
behaviour, which didn't consider the additional required capacity but
did add slack (which, because of rounding to the next power of two,
amounts to the same thing).
Bug: chromium:1108258
Change-Id: I81f513fdc800a2caab76e030c0c5e767cd1360d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324253
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69127}
If we don't have slack and we want to add an element to the
TransitionArray, we would create a new TransitionArray. The background
hread, however, can be holding a pointer to the old transitions. This
test tests that this is safe to do, i.e the background thread reading
the old TransitionArray.
To make sure that we are testing that, we can add more synchronization
via an extra semaphore.
Bug: v8:7790
Change-Id: Ie454d79282ac267d3527269e8490baced979aa45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323351
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69126}
This CL aims to clean dead code across the app
and use private class fields for storing private
information.
Bug: v8:10644, v8:10735
Change-Id: I1129104925f230bed922cc76abdb432d536d2111
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323352
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69125}
This is the first step towards implementing a tier-up mechanism from
NCI code to TF. We will follow the existing Ignition-to-Turbofan
mechanics, which are, roughly:
1. Track a bytecode interrupt budget.
2. When exhausted, call the runtime profiler, which increments
profiler ticks for the top frame's function.
3. When a function should tier up, it is marked as such using the
FeedbackVector::optimized_code_weak_or_smi slot / the
OptimizationMarker mechanism.
4. The InterpreterEntryTrampoline checks this slot and calls into
runtime to compile if needed.
5. The finished code is also placed into this slot, as well as
installed on the JSFunction.
6. Again, the IET checks the slot and tail-calls the code object if it
exists.
This CL implements step 1 for NCI code by inserting the new simplified
UpdateInterruptBudget operator at the same spots (and using the same
offsets) as Ignition. When the budget is exhausted, we call a runtime
function that currently does nothing and will be implemented in the
next CL.
Bug: v8:8888
Change-Id: I98c0f8d96f32d515218dc2a76f961d44fe281c86
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312778
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69124}
The CL add two files:
1) copy.bara.sky - source file for copybara that needs to migrate cppgc
from v8 repo to GitHub;
2) export_to_github.sh - top level bash script that runs copybara and
generates CMake files if needed.
Bug: v8:10724
Change-Id: I6a5f0ed1d007533914d578203a37fab2c3e9774a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320651
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69123}
Zap freed local and persistent handles similar to main thread handles.
As a drive-by change, fix the creation of local handles without
LocalHandleScope.
Bug: v8:10315
Change-Id: Ia71bc5419c62ae073928751f57fc221ea11de254
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323362
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69121}
Port 1250fd59aahttps://crrev.com/c/2307240
Original Commit Message:
This generic wrapper builtin is currently used only when the wasm
function has no parameters and no return value.
Added a new V8 flag to use this generic wrapper.
Also added a JS test function for this generic wrapper.
Change-Id: I2c515e095730ba3880b639bdd85504e644b64e53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2325258
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#69117}
This cl also
1. Fixes a bug in effect-control-linearizer where we should have
converted fixed array length from Smi to integer
2. Also prints deopt location for the new "bailout" deopt type on
--trace-deopt.
Bug: v8:10582, v8:9684
Change-Id: Iafc5e8abbca5252a8783a5a1184a1667a7f708a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297460
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69115}
LocalHeap should only be used on the heap it was created on.
Bug: v8:10315
Change-Id: Ia06f0169d39b4148b356568795f4e316361a1e9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323358
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69114}
1. Adds a flag to specify if minimorphic accesses should be optimized
using dynamic map checks operators. This flag is disabled by default.
2. Builds the PropertyAccessInfo from handlers instead of reading it
from maps for minimorphic accesses
3. Uses DynamicMapChecks operator to lower the minimorphic accesses.
Bug: v8:10582, v8:9684
Change-Id: I0b7b26b876f9ad12d6fc38788137b66ee6455aeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241524
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69112}
Setup the function table exactly like the module's function table, so
that we can share most of the call generation logic.
R=clemensb@chromium.org
Bug: v8:10751
Change-Id: Ie74150af8cf79d00adcc59d6880d2ed3e7cf78f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323353
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69111}
Currently WebAssembly always goes through the ArgumentsAdaptorTrampoline
builtin for wasm-to-js calls as soon as there's a mismatch between the
actual number of arguments and the expected number of arguments.
This can be made faster in cases where:
1. the callee has "don't adapt arguments" set, which is often the case
for builtins, or
2. the callee has "skip adapt arguments" set, which is often the case
for strict mode functions.
TurboFan already supports this for JS calls:
https://chromium-review.googlesource.com/c/1482735;
explainer document:
http://bit.ly/v8-faster-calls-with-arguments-mismatch.
Even though it is probably not as common to have arity mismatches in
Wasm->JS calls as it is in JS->JS calls, this still seems a worthwhile
optimization to do.
This CL ports the TurboFan fix to WebAssembly. In particular, the CL
introduces a new WasmImportCallKind (kJSFunctionArityMismatchSkipAdaptor)
for the case where the call to Builtins_ArgumentsAdaptorTrampoline
can be skipped, and modifies WasmImportWrapperCache::CacheKey to also
consider the arity of the imported JS function.
A micro-benchmark for this change can be found here:
- https://gist.github.com/paolosevMSFT/72c67591170d6163f67c9b03a7e12525#file-adapter-cc
- https://gist.github.com/paolosevMSFT/72c67591170d6163f67c9b03a7e12525#file-adapter_test-js
With this benchmark, we can save a 40% overhead of
Builtins_ArgumentsAdaptorTrampoline for calls that pass too many
arguments, while the savings for calls that pass too few arguments are
less impressive:
Before After
callProperApplication: 563 ms 566 ms
callOverApplication1: 972 ms 562 ms
callOverApplication2: 962 ms 562 ms
callUnderApplication: 949 ms 890 ms
Bug: v8:8909
Change-Id: Id51764e7c422d00ecc4a48704323e11bdca9377f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317061
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69110}
This gives the GC a location where it can interrupt background
compilation.
Bug: v8:7790
Change-Id: I8cf40e9c9b69c00fdfd5d59ed87e83137e481fb3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2310366
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69109}
Adds support for populating reference maps to the fast
register allocator. In order to calculate whether a stack slot
is live at a given instruction, we use the dominator tree to
build a bitmap of blocks which are dominated by each block.
A variable's spill operand is classed as alive for any blocks that are
dominated by the block it was defined in, until the instruction index
of the spill operand's last use. As such, it may be classified as live
down a branch where the spill operand is never used, however it is safe
since the spill slot won't be re-allocated until after it's last-use
instruction index in any case.
BUG=v8:9684
Change-Id: I772374599ef916f57d82d468f66429e32c712ddf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298008
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69108}
Adds support for tracking the instruction range of spilled operands,
and then allocating spill slots to these ranges. It also adds some
unittests covering spill slot allocation.
Spill slots are allocated in a linear fashion, running through the
instruction stream in a linear order, ensuring that no spill operand
is allocated to a same spill slot that is already assigned to during
this whole start / end range. This isn’t optimal, since it doesn’t
take into account holes in these ranges (e.g, blocks between start
and end that aren’t dominated by the start), but in practice rarely
leads to more than one extra spill slot being allocated compared to
the current allocator.
BUG=v8:9684
Change-Id: Iedee7bcf552080e5b4b6a2f4e96b78b6c1396cab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297470
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69107}
This adds two convenience scripts:
- update-vscode.sh downloads/updates Visual Studio Code
- update-compile-commands.py prepares for code indexers like clangd
by creating compile_commands.json (for all architectures), updating
generated sources, and compiling the Torque Language Server.
No-try: true
Change-Id: I64a15dc298f4312a9b296762593234c40f542b06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317355
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69105}
Also use outer-function name as a ZONE_NAME instead of file:line
and give explicit names to parser and preparser zones.
Bug: v8:10572
Change-Id: I9b5acb23322889d8538a34bc888fd6f610eb6893
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2322627
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69104}
Port 1250fd59aa
Original Commit Message:
This generic wrapper builtin is currently used only when the wasm
function has no parameters and no return value.
Added a new V8 flag to use this generic wrapper.
Also added a JS test function for this generic wrapper.
R=evih@google.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ib1f14081779adaf3668c4936ba6afde0a782ce0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323310
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69103}
This CL creates a timeline track component to
make the timeline view extensible as different
data sources added. The timeline track component will
take data source and display it with respect to time
axis of timeline overview.
Bug: v8:10644, v8:10735
Change-Id: I1c88dd2dc967be68e6235e517dcf8554a891eee4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2302053
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69102}
On 32-bit systems the calculation could overflow, leading to an illegal
limit of the LAB. Cast to uint64_t to avoid this. Add DCHECKs to
catch this earlier.
Bug: chromium:1110214, v8:10315
Change-Id: I73679a2daeb3b83bb303d411c77782a2172e98cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320654
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69101}
Since we have an uninitialized TransitionArray that we want to insert
an element (map1), we can't guarantee that said element would exist at
the point of the search. Then, we search for an element guaranteed not
to be (map2) and we check that we did not find it.
If we have a data race, this would also trigger it.
Bug: v8:7790
Change-Id: Ib90044d7c0901d599aed041f608f2c0bce506d67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319995
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69099}
This generic wrapper builtin is currently used only when the wasm
function has no parameters and no return value.
Added a new V8 flag to use this generic wrapper.
Also added a JS test function for this generic wrapper.
Bug: v8:10701
Change-Id: Id8cd1771f26922927363b715d8a6ffd384a143ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2307240
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69097}
As a downside, class-level static variables of FutexEmulation
now have to be local to the .cc file.
Bug: v8:10239
Change-Id: I3d00c65289f346cf2b16fea657f47bff69863b0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319989
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69096}
If we're close to a stack overflow when starting a script compile, we
may get into a state where main-thread compilation would stack overflow,
but background-thread compilation wouldn't. This triggers a failure of a
CHECK under --stress-background-compile, but isn't actually an
interesting failure.
So, we loosen this CHECK to allow the main-thread having a stack
overflow (strictly speaking, a RangeError) to count as a "success" for
the purposes of comparing against a background compilation success.
Bug: v8:10757
Change-Id: I7d687b52d178973b421c42ca0d89b4da0357232a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320649
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69092}
As an experiment to see how performance is impacted when changing
inline definitions to normal definitions in a .cc file, this CL moves
js-function-inl.h to js-function.cc.
Bug: v8:10749
Change-Id: I97c3a0b7d20217f444c6891442bbe3c34f3b0cc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315993
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69091}
Isolate::PromiseHasUserDefinedRejectionHandler no longer descends
recursively the outer_promise chain but uses an std::stack to avoid
stack overflows with very long promise chains.
Change-Id: Icdf86a34d89b734adc7139357b2ba6b37a7882ad
Bug: chromium:1096139
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316298
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69090}
If multiple isolates were involved, we did not always hit the breakpoint
reliably in all isolates.
This CL fixes this flake this via two changes:
1. Remove breakpoint info when tiering up.
If we keep the breakpoint information, a second isolate that later
sets the same breakpoint will see that the breakpoint already exists,
and will not set it again, even though the code containing the
breakpoint has been replaced at that point.
This fixes a flake in the debug/wasm/breakpoints test.
2. Don't overwrite code with breakpoints by default "tiered down" code.
This is achieved by introducing another state in the {ForDebugging}
enum which marks that code contains breakpoints. Otherwise it could
happen that two isolates start tiering down (both recompiling missing
functions in Liftoff), one isolate finishes and immediately sets a
breakpoint, then the other isolates finishes and overwrites the code
with breakpoints by the usual {kForDebugging} code.
Setting breakpoints is synchronized already, so overwriting
breakpoint code with other breakpoint code is always safe.
R=thibaudm@chromium.org
Bug: v8:10611, v8:10359
Change-Id: I171d86b110a54f9eb5e4c3fa35108638904212e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316080
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69088}
Currently, when running with --trace-turbo, V8 generates a different
.json file for each wasm-to-js thunk that it compiles, but these files
all have the same name "turbo-wasm-to-js-0.json", and only one file is
generated.
This makes it difficult to actually examine the difference in the IR
for this call wrappers produced for different signatures.
This patch fixes this by naming each trace file as:
"wasm-to-js-<kind>-<signature>-0.json", like for example
"turbo-wasm-to-js-5-ii-i-0.json".
Change-Id: Iebb73829cddd4f6bbf9d02ed1ce94a80dcfa5ca7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316834
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69085}
