The concurrent marker needs an override for JSObject subclasses with
their own visitor id and body descriptor. Implement the missing
VisitJSSynchronizationPrimitive.
Bug: v8:13214
Change-Id: Ie4f64e2b4e9b211f9661da75bf8d2d012f8d16ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3846320
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82634}
In collator and localeCompare, we have an incorrect optimization
for zero length string that compare the length and ignore the
fact some non zero length string could be considered as equal to
a zero length string because the content are all ignoreable.
Took out this incorrect optimization with test cases.
The regression is introduced in
6fbb8bc806 which first appeared in 97.0.4665.0
Bug: chromium:1347690
Change-Id: Ie70feb9598b1842f8a8744c38f33b3397865abfd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3832526
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82632}
Namely:
- AccessorInfo::getter and AccessorInfo::js_getter,
- CallHandlerInfo::callback and CallHandlerInfo::js_callback.
The redirected/non-redirected callback distinction is required only
for simulated builds but we wasted memory also for all native builds.
Now we store these fields in "redirected" form which allows us to call
them directly from builtins or generated code. In case it's necessary
to call a callback from C++ code the C function address is read from
the redirection. This additional indirection makes the callback calls
from C++ code in simulated builds slower but saves memory for native
builds.
This CL should recover a part of memory regression caused by inlining
Foreign fields into AccessorInfo and CallHandlerInfo.
Bug: v8:12949, chromium:1336105, chromium:1335930
Change-Id: I38470ed21ee23b281247c11a9531542c7e4acca1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3835686
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82631}
This changeset include:
1. [prepare for migrate] move `cctest/compiler/value-helper.h`,
`cctest/compiler/c-signature.h`, and `cctest/compiler/call-tester.h` to
`test/common` directory because both `test-codegen` and a lot of cctest file
include it.
2. [prepare for migrate] separate the tester helper part of `test-codegen`
into a new `codegen-tester` file.
3. finally, migrate test-codegen.cc to `codegen-unittest.cc`
Bug: v8:12781
Change-Id: Ia2f52c1d3b6b62501066dc1c4308a2c09d699e92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3831146
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82630}
We used to treat Heap::ReportExternalMemoryPressure just like
allocation observer marking steps. Which means that we advance
incremental marking but never finalize here immediately. This is
now problematic without a separate COMPLETE phase when we don't reach
the stack guard because we are stuck in C++ for awhile. In such cases
we might perform way more marking work than we used to.
We can fix this by finalizing marking immediately at this point when
the stack guard was already armed. Otherwise we prefer to finalize
marking in a task where we don't have a stack at all.
For this we add a new method
IncrementalMarking::AdvanceAndFinalizeIfNecessary. AdvanceFromTask
is renamed to AdvanceAndFinalizeIfComplete to make the difference
between those methods more clear.
Bug: v8:12775, chromium:1354911
Change-Id: If57bedb1a5f87923ccb8ad3fe2b60952e3843975
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3845082
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82626}
The load for external reference should be a full pointer load
instead of tagged size.
Change-Id: I3460a26abea5053ba6daa5c6ed908cb93431654a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842348
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#82625}
This is a reland of commit 9b0d5cb14b
The newly added check does not allow comparisons with stale or
invalid pointers because attempt to access the page header might
crash.
Original change's description:
> [ext-code-space] Fix Code vs non-Code comparisons
>
> When external code space is enabled comparing Code and non-Code objects
> by looking at compressed values is not always correct. Such an approach
> works only for comparing Code vs Code objects or non-Code vs non-Code
> objects.
>
> This CL instroduces SLOW_DCHECK into Object comparison operators to
> ensure that such a comparison is allowed. Also, this CL instroduces
> an Object::SafeEquals() method which compares uncompressed values
> and thus is safe to be used for comparing Code with non-Code objects.
>
> Bug: v8:11880
> Change-Id: I7ccf1f90f927beb2bb9f45efb303e902b1838d02
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838172
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82611}
Bug: v8:11880
Change-Id: Iab3c8fe49cb954b2dc9171b3fc4b189e84763e73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842932
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82624}
This check leads to quadratic runtime, which is problematic on huge
stacks (>10000 entries in the reproducer).
Typically stacks are small, so we check the first 16 entries one by one,
and then increase the step size. This still gives fuzzers and other
tests a good chance to find bugs, but avoids quadratic runtime.
R=thibaudm@chromium.org
Bug: chromium:1344481
Change-Id: Iaa3684410939d4c56177eed62787b29e409c3136
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842154
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82621}
Currently, when the input ArrayBuffer is detached during DataView
construction, the code will create an invalid DataView object whose
length, offset, and data_pointer are all incorrect. While this is
currently ok as the DataView is never exposed to JavaScript in that
case, it does cause issues as setting the data_pointer to a value
outside of the V8 sandbox leads to a CHECK failure. This CL now ensures
that the constructed DataView is always in a sane state to fix this.
Bug: chromium:1354429
Change-Id: I04260a5cf5547a420956d7a75e77f41408aa4f78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3841931
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82619}
This reverts commit 9b0d5cb14b.
Reason for revert: Seems to fail on gc-stress bots (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/43472/overview)
Original change's description:
> [ext-code-space] Fix Code vs non-Code comparisons
>
> When external code space is enabled comparing Code and non-Code objects
> by looking at compressed values is not always correct. Such an approach
> works only for comparing Code vs Code objects or non-Code vs non-Code
> objects.
>
> This CL instroduces SLOW_DCHECK into Object comparison operators to
> ensure that such a comparison is allowed. Also, this CL instroduces
> an Object::SafeEquals() method which compares uncompressed values
> and thus is safe to be used for comparing Code with non-Code objects.
>
> Bug: v8:11880
> Change-Id: I7ccf1f90f927beb2bb9f45efb303e902b1838d02
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838172
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82611}
Bug: v8:11880
Change-Id: Ie34af0135625eff2975f78f4d2901a76b8517eb7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842930
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82616}
This CL shuffles around some code in `ScopeIterator` to better reflect
the two (internal) iteration modes:
- While "inside" the paused function we iterate based on lexical
scopes.
- Once we move past the paused function we iterate based on runtime
contexts.
This CL renames the advancing functions to `AdvanceScope` and
`AdvanceContext` respectively which operate in the following way:
- `AdvanceScope` first checks if the current lexical scope requires
a context. If so, we move one context up the chain, since the next
lexical scope belongs to that next context. Then we move up one
lexical scope.
- `AdvanceContext` moves one context up the context chain. Then we
we move up through all the lexical scopes until we find the next
lexical scope that requires a context.
The tricky bit is the transition from scope iteration mode to context
iteration mode. This is where the bug fix comes in. After doing one
standard `AdvanceScope` from the `closure_scope_` to the next
lexical scope, we need to keep moving up through the lexical scope
until we find the next lexical scope that requires a context.
The CL also changes how we collect the locals blocklist. The
locals blocklist is always put on the current context. So every
time we move up one context we reset the locals blocklist and
every time we move up the lexical scope we collect the scope
locals into the blocklist.
R=bmeurer@chromium.org, jarin@chromium.org
Fixed: chromium:1354464
Change-Id: I7b37687a8827c20d0660a25413d2c9117b5fe5ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842158
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82615}
AdvanceWithDeadline() was only used from AdvanceFromTask(). So we can
move this method into AdvanceFromTask().
AdvanceFromTask() and AdvanceOnAllocation() share quite some code,
there is already a common bottleneck for both methods: Step(). So we
can move that code into Step().
Bug: v8:12775
Change-Id: I0f749f52df05d951f4310f05ff0d3977c6b2a9aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3843143
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82614}
The generational write-barrier currently does not support background threads. As a result, building in the background a ConsString that
points to a young string can lead to bugs, since the young string could
be freed.
Bug: v8:13203
Change-Id: I0df7c8cca8712d765eff0b1e918379f5477fdee5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840940
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82612}
When external code space is enabled comparing Code and non-Code objects
by looking at compressed values is not always correct. Such an approach
works only for comparing Code vs Code objects or non-Code vs non-Code
objects.
This CL instroduces SLOW_DCHECK into Object comparison operators to
ensure that such a comparison is allowed. Also, this CL instroduces
an Object::SafeEquals() method which compares uncompressed values
and thus is safe to be used for comparing Code with non-Code objects.
Bug: v8:11880
Change-Id: I7ccf1f90f927beb2bb9f45efb303e902b1838d02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838172
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82611}
Write barrier was only used in Factory::CopyCode for the
InterpreterEntryTrampolineForProfiling. This was removed in
in https://crrev.com/c/3811287.
Change-Id: I4cd0863fc2629d2d564af6a269e722d1a9e128f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3843141
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82609}
Turns out parking the outer Isolate needs to encompass the entire
lifetime of the inner Isolate during snapshot stress. Isolate
initialization locks the shared Isolate's client mutex to prevent shared
GCs. This mutex is also taken on Heap teardown on Isolate shutdown
during the shared heap verification, which may end up waiting in a
safepoint, causing deadlock.
Bug: v8:13217
Change-Id: I3893ae883ab345a9d36c9437ea15e90f18951057
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3843288
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82607}
This reverts commit abd0adf106.
Reason for revert: Test times out on Win64
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/23024/overview
Original change's description:
> [compiler] Make ReduceWord32EqualForConstantRhs work for Word64Equal
>
> Adds reduction case in MachineOperatorReducer for when the left-hand side of a
> Word64Equals is based on a 64-bit shift-and-mask operation, as is the case
> when Torque accesses 64-bit bitfields.
>
> This improves Speedometer2 by 0.15% on a Neoverse-N1 machine, with
> React-Redux being improved by 0.4%.
>
> Change-Id: Icd0451c00c1b25f7d370e81bddcfd668a5b2523c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3834027
> Commit-Queue: George Wort <george.wort@arm.com>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82593}
Change-Id: I26515348a3d8de58445ecddc0486d9fcc2711cec
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3839048
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Owners-Override: Shu-yu Guo <syg@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82603}
The mutex is there to protect against concurrent compilation of the same
function. It can be avoided by accumulating the vector of call targets
locally in the LiftoffCompiler, and only transferring it to the stored
type feedback once at the end (under the mutex).
Also, choose slightly better data structures: base::OwnedVector uses
less memory that std::vector (because it never over-reserves), and
std::unordered_map is more memory efficient and faster to lookup that
{std::map}.
R=jkummerow@chromium.org
Bug: v8:13209
Change-Id: I7aa82560a83cbac5c019effc7fd38c9b1495a42c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840294
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82602}
WaiterQueueNodes as used by JS synchronization primitives are per-main
thread, and external pointer handles to those nodes are 1-1. That
1-1-ness is captured by each main thread Isolate having a
waiter_queue_node_external_pointer_ field.
The current logic is incorrect on unlock paths as the Isolate that
requested the unlock can point its own
waiter_queue_node_external_pointer_ to another Isolate's
WaiterQueueNode. This CL fixes this by having each WaiterQueueNode hold onto its own external pointer handle.
This CL also fixes an embarrassing bug where the WaiterQueueNode was not correctly dequeued on timeout.
Bug: v8:13189, v8:12547
Change-Id: I8db16ae6d653d2e71989ad003faae20fcee06a25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3832298
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82601}
Otherwise allocated external pointer handles may be swept if never set
by the caller.
Bug: v8:10391
Change-Id: I3d727b80635ac8e21bd403de6bcad59091ed80a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3832528
Reviewed-by: Samuel Groß <saelo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82597}
Currently there is nothing ensuring the internal VM state of shared
objects are in a coherent state and visible to other threads when the
shared object is published.
This CL adds a store-store memory barrier when returning from Factory methods that allocate shared JSObjects that are exposed to user JS code. For primitives, there is an additional store-store memory barrier in the shared value barrier.
Bug: v8:12547
Change-Id: I4833c7ebf02cc352da9b006d2732669d6d043172
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng,v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819041
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82596}
This CL makes concurrent MinorMC only bailout on the write barrier if
the value is not in young generation.
Bug: v8:13012
Change-Id: I941c6f1e676440cf69e1d4fefcf2786383c9f678
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840296
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82595}
Adds reduction case in MachineOperatorReducer for when the left-hand side of a
Word64Equals is based on a 64-bit shift-and-mask operation, as is the case
when Torque accesses 64-bit bitfields.
This improves Speedometer2 by 0.15% on a Neoverse-N1 machine, with
React-Redux being improved by 0.4%.
Change-Id: Icd0451c00c1b25f7d370e81bddcfd668a5b2523c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3834027
Commit-Queue: George Wort <george.wort@arm.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82593}
Before https://crrev.com/c/3829541, ReduceStringPrototypeStartsWith
would not be called if the String's content wasn't safe to access in
the background, because StringRef::length would fail in that case. Now
that StringRef::length always succeeds, an additional check is
required before calling ReduceStringPrototypeStartsWith.
Note that none of the other callers of StringRef::length access the
String's content later, so we shouldn't have any more bugs caused by
the aforementioned CL.
Bug: chromium:1354439
Change-Id: I4a590ccdb7cc4c8a85e4e6beaf6f3c3ab2d7d479
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840938
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82592}
While working through the type feedback implementation, I left some
documentation and fixed some oddities or inconsistencies.
R=jkummerow@chromium.org
Bug: v8:13209
Change-Id: I6ba9b77ecf30ae020a57f77435005a1a57c2fc7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840293
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82591}
This CL bails out on the generated code write barrier when minor
incremental marking is active.
Currently is_minor_marking_flag_ is always false. It will be connected with incremental marking in subsequent CLs.
Bug: v8:13012
Change-Id: I0f5bc4aa14e9d56adbdad305499f2ca8f951765b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838784
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82590}
This reverts commit b3a27f22cd.
Reason for revert: Fails 'debug-enabled-tier-down-wasm' flakily (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64/48026/overview)
Original change's description:
> Reland "[wasm] Refactor compilation tier computations"
>
> This is a reland of commit e50472d6a3.
> In {ApplyCompilationHintToInitialProgress} we would reset the baseline
> tier to {kNone} if the compilation strategy is {kDefault}, which is
> wrong. We would not generate code but also not install the lazy stub,
> so whenever we start executing the code before top-tier is ready we
> would crash.
>
> Original change's description:
> > [wasm] Refactor compilation tier computations
> >
> > The way we initialized the "compilation progress" was pretty convoluted,
> > with multiple levels of functions being called for initializing every
> > single slot.
> >
> > This CL refactors this to compute one default value for the whole
> > module, and only modifies those slots that need special handling (e.g.
> > because of compilation hints, or lazy/eager compilation after
> > deserialization).
> >
> > We also rename "liftoff_functions" to "eager_functions" in the
> > deserialization path; the idea is that those functions should get
> > eagerly compiled because we expect them to be needed during execution.
> > Usually they would be Liftoff-compiled, but it's more consistent to use
> > the existing logic to choose the baseline tier. In the default
> > configuration, this will still use Liftoff, but if Liftoff is disabled
> > we will use TurboFan instead.
> >
> > R=jkummerow@chromium.org, ahaas@chromium.org
> >
> > Bug: v8:12425
> > Change-Id: Ie58840b19efd0b1e98f1b02d5f1d4369410ed8e1
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829606
> > Commit-Queue: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#82521}
>
> Bug: v8:12425
> Change-Id: Ie41e63148bf6bd0e38fc07a3a514f1094d9d26cf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838409
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82585}
Bug: v8:12425
Change-Id: Ic86d3f5b0e0603dae62ccead3be052d928209506
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842208
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82588}
Now that V8_SANDBOXED_POINTERS is enabled by default on every platform
if the sandbox is enabled, it is no longer necessary to have a separate
option to enable/disable sandboxed pointers.
Bug: chromium:1218005
Change-Id: I2ab4c7c758010007765a3b0595357ddecfe9f258
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/+/3840937
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82587}
Since the overall motionmark regression is minor (<0.5%), we decided to
get benefits of pointer compression on M1. The CL can also slightly
regress speedometer2 (~0.3%).
Bug: chromium:1325007
Change-Id: Ib278f0e82e0ebde563caac79b9f32edfe2d09a53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840301
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82586}
This is a reland of commit e50472d6a3.
In {ApplyCompilationHintToInitialProgress} we would reset the baseline
tier to {kNone} if the compilation strategy is {kDefault}, which is
wrong. We would not generate code but also not install the lazy stub,
so whenever we start executing the code before top-tier is ready we
would crash.
Original change's description:
> [wasm] Refactor compilation tier computations
>
> The way we initialized the "compilation progress" was pretty convoluted,
> with multiple levels of functions being called for initializing every
> single slot.
>
> This CL refactors this to compute one default value for the whole
> module, and only modifies those slots that need special handling (e.g.
> because of compilation hints, or lazy/eager compilation after
> deserialization).
>
> We also rename "liftoff_functions" to "eager_functions" in the
> deserialization path; the idea is that those functions should get
> eagerly compiled because we expect them to be needed during execution.
> Usually they would be Liftoff-compiled, but it's more consistent to use
> the existing logic to choose the baseline tier. In the default
> configuration, this will still use Liftoff, but if Liftoff is disabled
> we will use TurboFan instead.
>
> R=jkummerow@chromium.org, ahaas@chromium.org
>
> Bug: v8:12425
> Change-Id: Ie58840b19efd0b1e98f1b02d5f1d4369410ed8e1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829606
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82521}
Bug: v8:12425
Change-Id: Ie41e63148bf6bd0e38fc07a3a514f1094d9d26cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838409
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82585}
