This CL adds the following specific cases, to make sure they are
correctly handled by the slow path:
- the backing store of a TypedArray gets detached after optimisation
- passing null instead of a TA doesn't lead to a deopt
Bug: v8:11739, chromium:1052746
Change-Id: I7dfd3da9f535831901998ca6fad854af6e93e9f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320425
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78274}
This removes the additional call to `didPause` solely for
instrumentation breakpoints. They will be reported along with any
other pause reasons, and if several apply, 'ambiguous' will be
reported as a reason.
Bug: chromium:1229541
Change-Id: I38557248dc2274c2ff2c396aa19073f4a5c5abd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300134
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78271}
This is a reland of 3ee4804f83.
The CL was originally reverted for blink test failures. Since the
revert, the blink top-level await flag has been removed.
Original change's description:
> [top-level-await] Remove --harmony-top-level-await
>
> TLA has been shipped since v8.9.
>
> Bug: v8:9344, chromium:1271114
> Change-Id: Ibebf21da8bacb1f0d212390133847495ad8553e5
> Reviewed-on:
https://chromium-review.googlesource.com/c/v8/v8/+/3307103
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78169}
Bug: v8:9344, chromium:1271114
Change-Id: I96a9641967a23a12ba2467a69e5859ad8647f3e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318717
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78261}
This aligns the Torque semantics of catch with the JavaScript behavior:
When we catch an exception, we also reset the pending exception.
This also fixes a long-standing bug that we didn't restore the original
pending message after executing arbitrary JS in IteratorCloseOnException
Bug: v8:12439
Change-Id: I268d9d639d09023a424f352547cdce03428f983a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3303805
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78259}
For shared strings, String::MakeThin is protected by using the map word
of the string being migrated as a spinlock.
Note that this CL does not make it safe yet to access character data
from multiple threads. The spinlock here only protects write-write races
in String::MakeThin.
For more information, see the following two design docs:
https://docs.google.com/document/d/1c5i8f2EfKIQygGZ23hNiGxouvRISjUMnJjNsOodj6z0/edithttps://docs.google.com/document/d/1Drzigf17t4ofy0evDmaIL5p0MDZuAl95c9fSeX-QjVg/edit
Bug: v8:12007
Change-Id: I9c47412c6ec7360a672b65a8576b4f6156ee5846
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313429
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78257}
This reverts commit 2d087f237e.
Reason for revert:
- Causing MSVC build failures: https://crbug.com/v8/12476
- Causing flaky failures: https://crbug.com/v8/12475
Original change's description:
> [profiler] Surface VM & Embedder State
>
> Add APIs to surface VMState and new EmbedderState to CpuProfile samples.
>
> EmbedderState:
> * An EmbedderState is defined as a value uint8_t and a v8::context used
> for filtering.
> * EmbedderStates are stack allocated by the embedder, construction and
> destruction set/unset the state to the isolate thread local top.
> * A v8::context is used to filter states that are added to a CpuProfile,
> if the CpuProfile do not have a ContextFilter set or if contexts do not
> match, state defaults to Empty.
>
> * v8:StateTag is already propagated all the way to a Sample, simply add
> an API to surface it.
>
> VMState:
> Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e
> Bug: chromium:1263871
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072
> Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78250}
Bug: chromium:1263871, v8:12475, v8:12476
Change-Id: I02670b1ed3bb863033208369227642a7419fce00
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3315444
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78256}
Add APIs to surface VMState and new EmbedderState to CpuProfile samples.
EmbedderState:
* An EmbedderState is defined as a value uint8_t and a v8::context used
for filtering.
* EmbedderStates are stack allocated by the embedder, construction and
destruction set/unset the state to the isolate thread local top.
* A v8::context is used to filter states that are added to a CpuProfile,
if the CpuProfile do not have a ContextFilter set or if contexts do not
match, state defaults to Empty.
* v8:StateTag is already propagated all the way to a Sample, simply add
an API to surface it.
VMState:
Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e
Bug: chromium:1263871
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072
Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78250}
This CL makes sure that the API reports an error if the embedder
attempts to create a fast API function which could be used as a
constructor. It also adds corresponding cctest.
Bug: chromium:1052746
Change-Id: I36e51b298889900131bd5c3894134df3d8d28e5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314856
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78243}
When performing a shared GC, we need to find references from the client
heaps into the shared heaps. For now we achieve this by simply
iterating all objects in client heaps.
We need to do this both for marking and when updating pointers after
evacuation.
Bug: v8:11708
Change-Id: Ic1dd94cc352be0404095e548979c37b1ef25682a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300142
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78240}
This interface is meant to eventually replace the existing
v8::PageAllocator interface. Beyond general refactoring of the
PageAllocator APIs, the new interface now supports the concept of
(contiguous) address space reservations, which previously had to be
implemented through page allocations. These reservations now make better
use of provided OS primitives on Fuchsia (VMARs) and Windows
(placeholder mappings) and can be used to back many of the cages and
virtual memory regions that V8 creates.
The new interface is not yet stable and may change at any time without
deprecating the old version first.
Bug: chromium:1218005
Change-Id: I295253c42e04cf311393c5dab9f8c06bd7451ce3
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3301475
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78235}
This is in preparation for supporting concurrent access in
String::SlowEquals, which will need to compare character buffers with
relaxed ordering.
Bug: v8:12007
Change-Id: Ie8ac62c15df48ebd605985c35b843b510c7ad167
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313467
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78231}
Previously, StoreStoreElimination handled allocations as
"can observe anything". This is pretty conservative and prohibits
elimination of repeated double stores to the same field.
With this CL allocations are changed to "observes initializing or
transitioning stores".
This way it is guaranteed that initializing stores to a freshly created
object or stores that are part of a map transition are not eliminated
before allocations (that can trigger GC), but allows elimination of
non-initializing, non-transitioning, unobservable stores in the
presence of allocations.
Bug: v8:12200
Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78230}
Rather than creating a ParseInfo when creating a BackgroundCompileTask
(and passing ownership across to the BG thread which deallocates it),
create one when running it.
This allows the ParseInfo Zone to be both allocated and deallocated on
the same thread, which will improve its allocator friendliness.
As a side-effect, we now use the on-heap PreparseData from the
SharedFunctionInfo, rather than cloning the in-Zone PreparseData. This
means that we don't have to copy the PreparseData across Zones, but we
do need to Unpark the LocalHeap when accessing preparse data.
Change-Id: I16d976c1ad54c1090180f2936f40a23a6dbb5904
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312483
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78228}
If multiple isolates are running concurrently and one of them calls
`quit`, we should not delete the counters map, because another isolate
might still access it.
R=mlippautz@chromium.orgCC=nikolaos@chromium.org
Bug: v8:12453
Change-Id: I6d41478f188f0043b7d6055b0872574c28fd3039
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310807
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78226}
This allows streamed sources to also trigger parallel compile tasks. The
chunk vectors are shared via std::shared_ptr.
Clone chunked streams are initialised with a null source, and are not
allowed to fetch any more data. Similarly, the original stream is not
allowed to fetch data if it has been cloned (since the vector is shared
and would mutate if we added more data to it).
This is ok for the purposes of cloning for parallel compile tasks, as we
fully parse before cloning for the task.
Change-Id: Ic268e4956e0894acb63111bf0aaf32eaad426066
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310917
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78209}
This CL makes sure to forward the information that we are pausing
because of a debugger statement, and to encode it explicitly
as an 'other' reason when reporting the pause to the front-end.
Drive-by: refactoring the way break reasons are propagated by
introducing a new enum for break reasons
Bug: chromium:1229541, chromium:1133307
Change-Id: I9d2e8d8da54d96a231eff9d1f62b74507955b18f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306978
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78202}
We optimize away type upcasts for nominal types in WasmFullDecoder.
Upcasts trivially hold for nominal types, which is not the case for
structural types. Note that we already optimize away trivially-failing
checks (when types are unrelated) for both nominal and structural types.
Bug: v8:7748
Change-Id: I720c9803cb8b4071aa4bae112ce06d587b7a68fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306984
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78201}
This fixes data races when lazily creating counters (and populating the
{counter_map_}, and when concurrently adding samples to the counters.
It also ensures that the Wasm engine is stopped (via {V8::Dispose})
before printing and deleting counters, as background threads might still
try to update the counters otherwise.
R=mlippautz@chromium.org
CC=nikolaos@chromium.org
Bug: v8:12453, chromium:1275117
Change-Id: Ie6beea6cc74eea52143d12f9921597da4a250f2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308710
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78191}
When emitting code, character ranges must only specify ranges which
the actual subject string (one- or two-byte) may contain.
This was not always the case, specifically for ranges with
`from <= kMaxUint8` and `to > kMaxUint8`.
The reason this is so tricky: 1. not all parts of the pipeline know
whether we are compiling for one- or two-byte subjects; 2. for
case-insensitive regexps, an out-of-bounds CharacterRange may have an
in-bounds case equivalent (e.g. /[Ÿ]/i also matches 'ÿ' == \u{ff}),
which only gets added somewhere in the middle of the pipeline.
Our current solution is to clamp immediately before code emission. We
also keep the existing handling/dchecks of the 0x10ffff marker value
which may occur in the two-byte subject case.
Bug: v8:11069
Change-Id: Ic7b34a13a900ea2aa3df032daac9236bf5682a42
Fixed: chromium:1275096
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306569
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78186}
Add suppose for compiling non-eager, non-top-level inner functions in
parallel, using the compiler dispatcher. This behaviour can be enabled
with --parallel-compile-tasks-for-lazy.
There are a couple of consequences:
* To support this we need support for off-thread ScopeInfo
deserialization, so this adds that too.
* The previous --parallel-compile-tasks flag is renamed to the more
descriptive --parallel-compile-tasks-for-eager-toplevel.
* Both parallel-compile-tasks flags are moved onto
UnoptimizedCompileFlags so that they can be enabled/disabled on a
per-compile basis (e.g. enabled for streaming, disabled for
re-parsing).
* asm.js compilations can now happen without an active Context (in
the compiler dispatcher's idle finalization) so we can't get a
ContextId for metric reporting; we'd need to somehow fix this if we
wanted asm.js UKM but for now it's probably fine.
* Took the opportunity to clean up some of the "can preparse" logic in
the parser.
Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78183}
c++17 is being enabled on some platforms:
https://crrev.com/c/3306812
which causes gcc to emit the following warning:
```
error: null argument where non-null required (argument 2)
memcpy(storage_ + kReturnCount, param_types.data(),
~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Unlike clang, gcc is not able to detect if memcpy is actually
being executed or not when src is NULL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22179
Therefore need to disable this warning at this location.
Change-Id: I44da9f698ef724e39bb9c7d4b235d1004d52f491
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308916
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78182}
Try blocks (whether catch or finally) will unconditionally create
handler tables and start a new basic block for the exception handler.
This can accidentally resurrect a dead block when the entire try block
is dead (and hence can never enter the exception handler in the first
place).
Add a deadness check to BuildTryCatch/Finally to fix this.
Bug: chromium:1273677
Change-Id: Icda9deb1459e47de5cb83e7b636299e24c3ebe77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306555
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78179}
Until now, LABs were accessed from generated code via external
references, e.g., see NewSpaceAllocationTopAddress() and
NewSpaceAllocationLimitAddress().
This patch places them in the IsolateData, so they can be accessed
using Isolate-constant offsets. It affects the hot path of all TF
generated code.
Bug: v8:12428
Change-Id: I7bfd54bea4febead404829d8e0b058b6cf53a374
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3303800
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78176}
Currently, JSFinalizationRegistry has a BodyDescriptor that iterates
next_dirty as a custom weak field, and it has a WeakListVisitor that
cleans up any items from the list that should be removed. However, none
of that code is used, because JSFinalizationRegistry objects are created
with visitor ID kVisitJSObjectFast. This change gives them a custom
visitor ID so that next_dirty can be treated as weak.
Bug: v8:12430
Change-Id: I31c1935257ad508b13a3e684662d2ca406d8ed19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3307096
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78167}
- V8::Deprecate ShutdownPlatform in favor of V8::DisposePlatform
- Rename i::V8::TearDown to i::V8::Dispose
- Clean up i::V8::Initialize
- Remove needless V8::Initialize() calls in cctests
- Remove CcTest::DisableAutomaticDispose()
- Add checks to Isolate::Allocate and Isolate::Dispose that there is
and active platform
Change-Id: Iac84f9ade9d1781e9e8b8c88ea8fe74013f51c4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306482
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78162}
This will allow making HeapObject::IsBlah() checks faster when external
code space is enabled.
Bug: v8:11880
Change-Id: I68473ba88063c555c90330c9748462adeb35aa0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308797
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78156}
The CL converts uses of v8::internal::Worklist to heap::base::Worklist
which does not require to know the number of tasks working with the
work list upfront. heap::base::Worklist is the common implementation
for V8's heap and cppgc and should be used/optimized going forward.
Bug: v8:12426
Change-Id: Id6ef1aa05df858b01df90d653b6421a9bb68b997
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306382
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78151}
Previously when hitting a debugger statement we would ignore reporting
the hit breakpoints.
Bug: chromium:1229541, chromium:1133307
Change-Id: I47427a541391a27fc7783930e5e7eb41fbf2bb6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306373
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78145}
--experimental-wasm-mv has been removed, and --wasm-loop-unrolling is on
by default.
Change-Id: I094870765031ef46fcec95e9071333e4e80f407b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302805
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78140}
{WasmInternalFunction::external} might return a function that is not
a WasmExportedFunction, at which point the code in ProcessTypeFeedback
fails.
See crrev.com/c/3277878 for context.
Bug: v8:12436, v8:12166
Change-Id: I09ef96df3fc051586044dd9c2ce88d6aeeb34b9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306391
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78139}
memory[1] needs to be set in LE order even on BE platforms.
Change-Id: I44620c30a25719d0d61e0f14490342ee930dbbb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302852
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78136}
With https://crrev.com/c/3272577 we introduced a `StackFrame` cache for
the inspector, which is keyed on the script ID, line and column number,
so the syntactic properties of the function. However, the name that we
report for functions is dynamic and can change (per closure) by
explicitly reconfiguring the "name" property via
```js
var f = function() { /* ... */ }
Object.defineProperty(f, "name", {value: "super duper function"});
```
for example, so we need to take that into account as well, and only use
the cached `StackFrame` instance if the dynamic names still match up.
Otherwise we just overwrite the cached entry with a new instance (the
assumption here is that "name" isn't reconfigured often).
Fixed: chromium:1274529
Bug: chromium:1268436
Change-Id: I519017c762aed5b4f93b9dc4553fa81d5979f1a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306376
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78127}
To trigger speculative inlining, a function needs to run a few times on
Liftoff-tier, and then tier-up to Turbofan. We make sure this happens
by enabling --wasm-dynamic-tiering with a small budget, and running
the critical functions until {%IsLiftoffFunction} is false.
We also add an additional test.
Bug: v8:12166
Change-Id: I6c5e0d3f1e3ba0df8510ae6850d8e9af1d01c179
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306372
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78123}
