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}
https://tc39.es/proposal-intl-segmenter/
TC39 passed Intl.Segmenter to stage 3 in Jul 21.
This CL move our earlier prototype to the current spec.
Bug: v8:6891
Change-Id: I07234beed54f671c26bdbfb3983c5bc2fa5a29b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219413
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69080}
Currently, only a scriptURL is reported, which can be over-written by
sourceURL comments of the script. This means a script can basically
claim to come from anywhere. This means that DevTools doesn't know the
resource name the embedder provided if there is a sourceURL comment.
This CL adds a `embedderName` field to the scriptParsed and
scriptFailedToParse events that reports the name the embedder
associated with the script.
Bug: chromium:974543
Change-Id: I9863f878f57638174847890d9a3818952b1efc27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317310
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69078}
When we add safepointing, the source position address might change.
Then, we need to use the handlified version for both concurrent-inlining
and not.
The logic for retrieving the Handle can be encapsulated in the
BytecodeArrayRef, which can be reused in the other source_position_*
methods.
Bug: v8:7790
Change-Id: I3e5f937eb06153449cf6f720a2a4321cb338d903
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316301
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69076}
This flag's name is slightly incorrect as it is possible to have more
maps than this in the feecback vector.
This flag doesn't account for deprecated maps in the feedback
vector. To make this explicit, we change the flag to indicate that
this only counts valid maps.
Bug: v8:10582
Change-Id: Ib0cc425a03d590bb21184fc6b104d0ebee1d5b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319992
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69075}
This test should've been rewritten in the last
batch rewrite but wasn't.
Bug: v8:10239
Change-Id: Ic2949e6282f72975898ab7e9aefe3210bba71fbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319988
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69072}
When mksnapshot fails on a static assert in Torque, print the
statement and position from the Torque source. To enable special
treatment, change the syntax of static asserts in Torque
from StaticAssert() to static_assert() to align with assert() and
check() statements.
Bug: v8:7793
Change-Id: Idda8e3c342bdcefc893ff297f8d7727d2734c221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317314
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69069}
This CL allows LocalHandles to be dereferenced by the same thread that
created them, even if we have a DisallowHandleDereference scope.
Bug: v8:7790
Change-Id: Ie227aaa4152c887d0d9c913dfa35217166726614
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316111
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69068}
This CL adds a generic Event Class to unify common
methods of IC and Map events. The Entry Class for IC
Events and V8Map Class for Map Events inherits from
this generic Event Class.
Bug: v8:10644, v8:10735
Change-Id: I77d68fb40ee0ffbe297fcd1a13c3e2b746938168
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317309
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69066}
If the types allow it, sometimes generate a return call instead of a
regular call in the wasm-compile fuzzer.
R=clemensb@chromium.org
Bug: v8:10693
Change-Id: Ie5e92f2b012f655b9d7d5847dba4a669152635c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316297
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69063}
Only the first four elements of the array will be used. Also, the fifth
element sais 'stepInfo' instead of 'stepInto'.
R=thibaudm@chromium.org
Change-Id: I258a8b95795f0cfbcaf500b7d174786680914d36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316110
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69062}
Introduce explicit fast path for allocation from LAB. The slow path
refills the LAB and allocates again. Other changes:
1) Move slow path methods out of the header file
2) AllocateRaw(Aligned|Unaligned) are now private methods. All
allocations need to go through AllocateRaw for NewSpace now.
Bug: v8:10315
Change-Id: Iee2bd7b74aa49be8b20d89fefeb2e087575d532c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319987
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69061}
Add methods NotifyBytes(), NotifyObject() and NextBytes() to
AllocationCounter. Methods are unused for now.
Move AllocationObserver::Step after AllocationCounter methods as well.
Use SetTopAndLimit as bottleneck instead of allocation_info_.Reset.
Bug: v8:10315
Change-Id: I30049cb02e873bb08ebce606a491d99130421227
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316103
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69060}
- Adds a SharedArrayBuffersEnabled callback and uses it to
enable/disable SABs per context. The feature flag is used
if no callback is registered.
Bug: chromium:923807
Change-Id: I4d3472fcd79b158cb50dc98793aece6dbbb81d93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316901
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69057}
This CL adds a Timeline Class to handle data interaction
between panels. The timeline class enables to filter the
data based on selected time range.
Bug: v8:10644, v8:10735
Change-Id: I7fbbe1741abc69d2889b0547113e5da10b7f5510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315983
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69056}
Now the following command builds mkgrokdump for x64.release and runs it
to update v8heapconst.py:
gm.py mkgrokdump
Building the binary for other architectures still works as before.
No-Try: true
Change-Id: Iacfa1a50702b0452d00ba18e1306423b161ffe65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317352
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69054}
Using uint8_t[] causes decay to pointer issue, which manifests in
copying garbage values in the call to WriteLittleEndianValue. Change it
to use a std::array, which doesn't have the decaying behavior.
Also add a regression test from comment#6 of the linked bug.
Bug: v8:10731
Change-Id: I4a1ca69fe99806642e9931625ca7aeab6663f955
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316465
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69052}
These functions match on specific patterns of shuffle that have more
optimized implementations. Moving them out of instruction-selector
allows us to reuse them in Liftoff. Most of these pattern matching
functions do not depend on InstructionSelector, since they work on byte
arrays. (The only one is CanonicalizeShuffle, which swaps node inputs.)
This is only the first pass of moving those functions out. In particular
we can clean things up more by moving the tests out of
instruction-selector as well. Those will come in follow-up changes.
Bug: v8:10696
Change-Id: I4a4333cd8c0259875a672179e72d34dad5f7a008
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2308057
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69051}
csuite.py compare command currently throws exception
"_csv.Error: iterator should return strings, not bytes
(did you open the file in text mode?)"
This should fix it.
Change-Id: I69c0ec43575a8c3627dac81dc99e47ba6adf6f61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316833
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69050}
As there are not enough registers on ia32 to execute the platform-
independent code, the CL also adds ia32-specific code to
liftoff-compiler.cc. For this we first retrieve the memory index from
the stack, do a bounds check, and calculate the final address. Only
afterwards we pop all other values from the stack and pass them to the
platform-dependent code.
R=clemensb@chromium.org
Bug: v8:10108
Change-Id: I741266a9523c8b5c46acc0b29817fd143a75752e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316305
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69047}
This flag is already baked into the snapshot by enabling more
write-barrier elimination, so changing it at runtime would be a bug.
Change-Id: I3bc73f3c880285ec46b69b0c44934f64b49912ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2290856
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69046}
Adds support for register allocation within a block to the fast
register allocator. Also adds some unittests covering basic
register allocation. No support yet for spill slot allocation,
so functions that spill don't work yet.
BUG=v8:9684
Change-Id: I91d0fc0660d7b65f59235242fd5e3b1a7618d813
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297467
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69045}
Otherwise, a failure message from a common macro like UnsafeCast<A> is
not particularly meaningful. With this change, the failure message would
show the line number in the top-level builtin and each in-between macro
that resulted in calling UnsafeCast<A>. This does not include plain CSA
macros, only those generated by Torque.
Bug: v8:7793
Change-Id: If0b9b7d2755f579ceacf47eef2440d97ec84a2ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2303598
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69044}
