With caged heap enabled, we can halve Member<> by storing only the least
significant half. The base of the heap is stored in a thread local
variable. The feature has therefore an implication that only single heap
is allowed per thread.
The feature is gated by the new GN arg:
cppgc_enable_pointer_compression.
Bug: chromium:1325007
Change-Id: Ic7f1ecb7b9ded57caad63d95bbc8e8ad6ad65031
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739979
Reviewed-by: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80518}
Spec text:
https://tc39.es/proposal-temporal/#sec-temporal.calendar.prototype.erahttps://tc39.es/proposal-temporal/#sec-temporal.calendar.prototype.erayear
Notice this only implement the "iso8601" calendar and we will implement the
code for other calendar later by calling ICU with other Calendar methods.
This CL reduce the differences of testing result between ALWAYS and no_i18n
because the code in no_i18n will not call Calendar era or eraYear and therefore
passed the test even w/o this CL but the ALWAYS tests will cause Temporal
object to internal call era and eraYear and therefore fail if w/o this CL.
Bug: v8:11544
Change-Id: I921fbfbbd26473c238024161eb58b096c38b881b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3641938
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80513}
This CL adds two experimental JS builtins to convert between
i16 Wasm GC and JS strings. This is a non-standard experimental
feature only available with the flag --wasm-gc-js-interop.
WebAssembly.experimentalConvertArrayToString(array, start, count)
Convert the `count`-many WTF-16 code units starting at index `start`
into a JS string. Throws a TypeError if `array` is not an i16 array,
or if `start` and `count` are not numbers or not in range.
WebAssembly.experimentalConvertStringToArray(string, sampleArray)
Convert `string` to an i16 array. The `sampleArray` parameter needs
to be an arbitrary i16 array, which is only used to extract the rtt.
Throws a TypeError if `string` is not a string or `sampleArray` is not
an i16 array.
Change-Id: I7ac2f6bd89b8f638427f61da1bb01ccba90d735b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3642301
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80505}
This reverts commit 8278cb5015.
Reason for revert: breaking https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/10778/overview
Original change's description:
> [inspector] Re-enable Debugger#restartFrame
>
> Doc: https://bit.ly/revive-restart-frame
>
> This CL "undeprecates" Debugger#restartFrame and adds a new optional
> "mode" parameter for back-wards compatibility. Moreover, the return
> values are all deprecated. They were never actually used in the
> DevTools frontend and the same information is available from the
> Debugger#paused event that fires once execution stops at the
> beginning of the restarted function.
>
> The CL also re-baselines all the restart-frame inspector tests that
> now run successfully.
>
> R=bmeurer@chromium.org, kimanh@chromium.org
>
> Bug: chromium:1303521
> Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80491}
Bug: chromium:1303521
Change-Id: Ibc33328c31a4b6ea736d07ce5e5ee109039eec8b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3645767
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80495}
The IsValidSectionCode function shouldn't include internally-used
numeric identifiers of well-known optional sections.
Fixed: v8:12867
Change-Id: I9d894ee57157455e92a17ddcde94f32f05fb038d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644612
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80494}
Doc: https://bit.ly/revive-restart-frame
This CL "undeprecates" Debugger#restartFrame and adds a new optional
"mode" parameter for back-wards compatibility. Moreover, the return
values are all deprecated. They were never actually used in the
DevTools frontend and the same information is available from the
Debugger#paused event that fires once execution stops at the
beginning of the restarted function.
The CL also re-baselines all the restart-frame inspector tests that
now run successfully.
R=bmeurer@chromium.org, kimanh@chromium.org
Bug: chromium:1303521
Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80491}
Hexadecimal/octal/binary BigInt property names should be converted
to decimal, i.e. the following object literals should all be equivalent:
var o = {0xF: 1}, p = {0xFn: 1}, q = {15: 1}, r = {15n: 1}.
Test case by yangwenming@bytedance.com, uploaded at
https://chromium-review.googlesource.com/c/v8/v8/+/3634937
Fixed: v8:10600
Change-Id: Ie1d8a16e95697cd31cbc0784843779c921ce91fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3642302
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80490}
This CL introduces SideEffectDetectorScope which requires explicit
allowlisting of cases when side effects are allowed after calling
interceptor callbacks.
Side effects are not allowed when the callback does not intercept
the request.
The side effects detector is not enabled yet, it will be enabled in
a follow-up CL.
Bug: chromium:1310062
Change-Id: I805764920ed016cb37390aef7bb02cbdf5f72846
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3641172
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80484}
NewSpace is renamed to SemiSpaceNewSpace and NewSpaceBase is renamed to
NewSpace (the new PagedSpace new space implementation will be named
PagedNewSpace).
Most usecases are updated to use the base class rather than the concrete
semi space based implementation. To that end, the base class is extended
with additional virtual methods (for delegating to the concrete class).
This CL follows these guidelines:
(*) If at a method callsite we should know the exact new space
implementation we use, we cast to the concrete class. This is the case
for example for callsites in scavenger.*.
(*) If a method is called from outside the heap implementation or should
be present regardless of the concrete implementation, that method is
made virtual.
(*) Other cases are usually methods that are specific to a concrete
implementation but the concrete implementation is not known at the
callsite and there's no clear way to nicely abstract the method. In such
cases we cast to the concrete SemiSpaceNewSpace implementation for now
and we will revisit these cases once PagedNewSpace exists.
Bug: v8:12612
Change-Id: I7b85626774ce0d785b0257bf8d32b9f50eeaf292
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625975
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80482}
Prototype the instruction on the interpreter, and Arm64. Details of
instruction lowerings on all relevant architectures can be found at:
https://github.com/WebAssembly/relaxed-simd/issues/40
Bug: v8:12284
Change-Id: Id4cb3889d94cf0bb7169ea068efe5ca68cfcbad9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3636365
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80475}
Once the root SharedFunctionInfo for any Script gets its bytecode
flushed, the Isolate's compilation cache currently evicts that entry, to
reduce memory usage. However, the associated Script is likely still
alive, since scripts often declare functions which outlive the initial
evaluation of the script. If an identical script is loaded later, a
duplicate Script is created for it, which can waste memory.
In this change, I propose that the compilation cache keys can refer
weakly to the Script. When the root SharedFunctionInfo gets old, instead
of deleting the cache entry entirely, we can just drop the strong
reference to the SharedFunctionInfo. A subsequent lookup in the cache
will retrieve the Script instead of the root SharedFunctionInfo,
indicating an opportunity to save some memory by reusing the existing
Script.
Eventually, all callers to CompilationCache::LookupScript should reuse
the Script if possible. This change implements only the easy case of
reusing the Script for synchronous parsing. Follow-up changes will be
required for the TODO comments left by this change.
Bug: v8:12808
Change-Id: Ia8b0389441a682de9a43e73329049fd2e7835d3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3597106
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80472}
This adds a non-standard, unsafe instruction for performance
experiments: ref.cast_nop_static behaves like ref.cast_static
as far as static types are concerned, but emits no code.
Bug: v8:7748
Change-Id: Ic5797a941146a06d7c6ff249d8e29919145d8ea1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3639206
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80471}
The issue is that a thread_local variable used in RwxMemoryWriteScope
can't be directly accessed from another component, so the workaround is
to avoid inlining accesses the variable into other components.
Bug: v8:12797, chromium:1324333
Change-Id: I0f83358ac0c663c92ef7b3dff54a068472d61aed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3641169
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80470}
This CL adds the array type flag to distinguish between
sparse array and dense array and adds serialization
and deserialization for sparse array.
Bug: v8:11525
Change-Id: Ia302af017d6f52924256a2b3fa9e3d2b34caa442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629739
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80449}
In some cases we were still trying to change permissions of RWX pages
which is not allowed.
Bug: v8:12797
Change-Id: I9f4ca319d842c524fc6f60bfd3bb3726f8d3029d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3635719
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80442}
Add new opcode numbers for relaxed-simd opcodes as in:
https://github.com/WebAssembly/relaxed-simd/pull/61, and updates
for decoded opcodes larger than two bytes.
Bug: v8:12284
Change-Id: I0bff22812243a39599bfeee3c0bc69171dd3c7d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625835
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80432}
Builtins are not snapshotted, but instead we insert "builtin wrappers"
into the snapshot, and create references to the corresponding builtin
when deserializing.
Subclassing builtins will be implemented in a follow-up CL.
First version: https://chromium-review.googlesource.com/c/v8/v8/+/3630080
Fix: initialize builtin_objects_handle_
Bug: v8:11525,v8:12820
Change-Id: Ia2b5d41af5d7f577f1b02356b22a8760963009e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3635718
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80430}
Many uses of "volatile" are deprecated in C++20 because they don't
actually do anything. Remove "volatile" in these cases.
Bug: chromium:1284275
Change-Id: I64a3989d73f25e0cd933375dd6fa0b3f2b3acb54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630343
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80428}
Builtins are not snapshotted, but instead we insert "builtin wrappers"
into the snapshot, and create references to the corresponding builtin
when deserializing.
Subclassing builtins will be implemented in a follow-up CL.
Bug: v8:11525,v8:12820
Change-Id: If72695d46bdfc8bf7e477471be1264b668551854
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630080
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80419}
Allocation granularity (8 bytes on 64bit platforms) is already subsumed
by whatever range size we choose.
Bug: chromium:1029379
Change-Id: Iab95e6f36955c9ffbbe9ea0c98cb9d1f8dd0337b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629869
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80415}
This is deprecated in C++20. Use constexprs and explicit casts to work
around.
Bug: chromium:1284275
Change-Id: I6a3974f3c678cb797081938622036a12a99c5d1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630349
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80392}
- Repurpose flag `treat_global_objects_as_roots` when taking a heap
snapshot for toggling whether internals should be exposed (to
`hide_internals`).
- Use the toggle in creating heap snapshots for exposing class names
as object names for C++ objects that have not explicitly been given a
name.
Change-Id: I77d71babfdfe53269964fe81ed985037a431c28b
Bug: chromium:1321620
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623740
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80391}
Change-Id: I88a1bbddc7604fc5e557ae875ca196cf9c46574c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3626453
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Neden Wang <nedenwang@tencent.com>
Cr-Commit-Position: refs/heads/main@{#80390}
In C++20, u8"" generates a const char8_t*, not a const char*. Since ""
accepts UTF-8 already, just switch to it.
Bug: chromium:1284275
Change-Id: I873321a62a4d9e32b3b463913a3bc10231db3db3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630347
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80382}
1. Move the use of MAYBE_RETURN to MAYBE_ASSIGN_RETURN_ON_EXCEPTION_VALUE
if possible.
2. Remove some MYABE_RETURN in the wrong spot and therefore fix some tests.
3. Change Intl::GetTimeZoneIndex() to return Maybe<int32_t> as index and use
< 0 value to indicate not getting index to make the function signature
simpler.
Bug: v8:11544
Change-Id: I685cbff142e9dea69ef316a1bc180730aef5aec8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625839
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80379}
This prevents ambiguity errors in C++20 due to ADL when casting types in
std::, which gains std::bit_cast<>().
Bug: chromium:1284275
Change-Id: I25046d1952a9304852e481ad8b84049c6769c289
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625838
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80378}
This is a reland of commit 507fa4d7f5
This CL moves the NewJSObjectFromMap after deserializing object properties with dictionary map and fixes the DCHECK failure in JSReceiver::HasFastProperties when triggering GC.
Original change's description:
> [web snapshot] Add support for object with dictionary mode
>
> This CL adds the serialization support for object properties
> with dictionary map. Shape id is used to distinguish between if the object has dictionary map. And add TODO to support “no map objects” which can have fast map and “objects with map” which needs to be turned to dictionary mode.
>
> Bug: v8:11525
> Change-Id: If3eb4195115a41d4a3f6cc7372924b982ca96fc1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3621593
> Commit-Queue: 王澳 <wangao.james@bytedance.com>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80366}
Bug: v8:11525
Change-Id: I88422d698aa03fb7d3b21b5709eec2d0cf306256
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629738
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80374}
Based on the robust test suite for checking property "has/in" queries, with the intention
of measuring the performance of accessing getOwnPropertyDescriptor.
Background: getOwnPropertyDescriptor and defineProperty were identified as hot code taking up
a significant chunk of startup time in a customer application. This benchmark aims to measure
the difference made by a modifying Object.getOwnPropertyDescriptor.
By current measurements, the geometric mean time of the new version is typically 1/6 that of
the current upstream implementation, using this test specifically (however, only on arm64 /
Apple M1... On Linux/x64, the results look more reasonable at a roughly 5-12% improvement in
score).
In its current form, this benchmark does very little to attempt to verify the results of the
object, which may result in branches being discarded in Turbofan (but given the enormous
difference between x64 and arm64, I'm not positive this is what is happening, and have not yet
verified this).
BUG=
Change-Id: I0f10735315313ed97efd00fcccaedc1272d4d314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3624979
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80373}
Consider the following
* A ValueNode has inputs A and B
* Input A has later uses, input B doesn't
* The ValueNode's result must be in the same register as A
It can then happen that UpdateUses frees B, and the result allocation
emits a gap move from A's register to B's old register (now free) to
preserve the value of A when the ValueNode writes into its register.
This gap move is emmitted before the ValueNode start, which means that
it clobbers B.
Now, UpdateUses only clears registers _after_ node result allocation, so
that the known free registers are still the ones before updating uses.
Done naively, this would have bad consequences -- in the case where A
has no later uses, it would still force the regalloc to save its value
thinking that it is still live. So, this patch also introduces a concept
of "AllocationStage" where we're either allocating at the start or end
of a Node. Inputs are allocated at the start, results at the end. When
walking registers during an allocation, nodes whose lifetimes end at the
current node are considered to be dead at the "end" allocation stage,
and we are allowed to a) use their registers, and b) drop them without
preserving their value.
Bug: v8:7700
Change-Id: I5ca764ed04b12269f189577e81eb7e2a27cd1b09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625978
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80371}
This reverts commit 507fa4d7f5.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/38308/overview
Original change's description:
> [web snapshot] Add support for object with dictionary mode
>
> This CL adds the serialization support for object properties
> with dictionary map. Shape id is used to distinguish between if the object has dictionary map. And add TODO to support “no map objects” which can have fast map and “objects with map” which needs to be turned to dictionary mode.
>
> Bug: v8:11525
> Change-Id: If3eb4195115a41d4a3f6cc7372924b982ca96fc1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3621593
> Commit-Queue: 王澳 <wangao.james@bytedance.com>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80366}
Bug: v8:11525
Change-Id: I0d236a9937a5942b387553a61991716321b063e6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629541
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80368}
This CL adds the serialization support for object properties
with dictionary map. Shape id is used to distinguish between if the object has dictionary map. And add TODO to support “no map objects” which can have fast map and “objects with map” which needs to be turned to dictionary mode.
Bug: v8:11525
Change-Id: If3eb4195115a41d4a3f6cc7372924b982ca96fc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3621593
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80366}
This CL cleans up the existing experimental implementation of
conservative stack scanning. It retains the object start bitmap, to
evaluate it as a mechanism for resolving inner pointers, and the
conservative stack scanning visitor (which is currently not used).
The flag v8_enable_conservative_stack_scanning is kept and will be
used for experimental purposes. It currently does not imply any
other flag.
Bug: v8:10614
Bug: v8:12851
Change-Id: Id0ae0f437ed2601eed9ec634d2d1dd2f030d814e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602516
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80365}
This reverts commit 2b79eefed3.
Reason for revert: Speculative revert because of https://crbug.com/1322305
Original change's description:
> Reland^2: [heap] Store size with invalidated object
>
> This is a reland of commit 23b2d571a7
>
> When updating pointers during a full GC, a page might not be swept
> already. In such cases there might be invalid objects and slots
> recorded in free memory. Updating tagged slots in free memory is fine
> even though not strictly necessary.
>
> However, the GC also needs to calculate the size of potentially dead
> invalid objects in order to be able to check whether a slot is within
> that object. But since that object is dead, its map might be dead as
> well which makes size calculation impossible on such objects. The CL
> changes this to cache the size of invalid objects. A follow-up CL will
> also check the marking bit of invalid objects.
>
> Reason for reverts:
>
> Revert #2: In-object slack tracking on JSObjects doesn't update the
> cached size of invalidated objects. The fix here was to stop
> invalidating recorded slots on JSObjects at all and avoid that problem
> completely (see https://crrev.com/c/3620274).
>
> Revert #1: Not all size changes go through NotifyObjectLayoutChange, so
> https://crrev.com/c/3607992 introduced NotifyObjectSizeChange as a
> bottleneck for object size changes/right-trimming. This method is
> now used to update the size of invalidated objects.
>
> Bug: v8:12578, chromium:1316289
> Change-Id: I0478d04601c0270ddb39419ca6cf98719951eb4d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623542
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80344}
Bug: v8:12578, chromium:1316289
Change-Id: I6dd2dd13583123b9cb7933b15e2113fddc0c0b0b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3627511
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80357}
This is a reland of commit 23b2d571a7
When updating pointers during a full GC, a page might not be swept
already. In such cases there might be invalid objects and slots
recorded in free memory. Updating tagged slots in free memory is fine
even though not strictly necessary.
However, the GC also needs to calculate the size of potentially dead
invalid objects in order to be able to check whether a slot is within
that object. But since that object is dead, its map might be dead as
well which makes size calculation impossible on such objects. The CL
changes this to cache the size of invalid objects. A follow-up CL will
also check the marking bit of invalid objects.
Reason for reverts:
Revert #2: In-object slack tracking on JSObjects doesn't update the
cached size of invalidated objects. The fix here was to stop
invalidating recorded slots on JSObjects at all and avoid that problem
completely (see https://crrev.com/c/3620274).
Revert #1: Not all size changes go through NotifyObjectLayoutChange, so
https://crrev.com/c/3607992 introduced NotifyObjectSizeChange as a
bottleneck for object size changes/right-trimming. This method is
now used to update the size of invalidated objects.
Bug: v8:12578, chromium:1316289
Change-Id: I0478d04601c0270ddb39419ca6cf98719951eb4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623542
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80344}
Before this CL, the heap object name of unnamed objects(those not
inheriting from NameProvider) would be solely determined by whether the
build-time configuration cppgc_enable_object_names is enabled.
This patch adds a way to override that value at runtime. This is
useful for preserving default behavior with custom builds but at the
same time allow them to still enable the feature.
Bug: chromium:1321620
Change-Id: I3aa06db15e58d9ba9773be6797572f17f007e9ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620279
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80338}
To be consistent with the all the other tiers and avoid confusion, we
rename --opt to ---turbofan, and --always-opt to --always-turbofan.
Change-Id: Ie23dc8282b3fb4cf2fbf73b6c3d5264de5d09718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610431
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80336}
This fixes:
runtime error: upcast of misaligned address 0x000000000001
for type 'cppgc::internal::(anonymous namespace)::SimpleGCed<64>', which
requires 8 byte alignment
Bug: chromium:1029379
Change-Id: Id03ce022e72fc07a18c171d4cf5e42f50cb684f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3622918
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80332}
Due to the consistent overhead of snapshot checksum verification
we ideally want to avoid it all-together. However there are still enough
devices out there that suffer from corrupted snapshots that might
cause hard to debug heap corruptions.
This CL exposes the calculated (dummy value for now) and the expected
snapshot checksum as a crash key, so it can be easily consulted during
investigation.
Note: The calculated crash key contains 0x0 for now as a dummy value. We
will come up with a strategy later-on to limit the overhead of
calculating the checksum.
Bug: v8:12195
Change-Id: I6da6d74c035cb6f9b0edae212a36e6c41c048a5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605813
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80325}
When formatting console messages (for consumption in Chromium/Blink), we
have special logic to unwrap value wrapper objects. But this logic was
not very consistent, and especially Number values and NumberObject
values were formatted differently.
This changes the V8ValueStringBuilder::append() logic to always unwrap
any value wrapper first and then use the regular dispatch for the
primitive value.
Fixed: chromium:1321833
Change-Id: I9996671e1f91da0841e5d5f1687cf647ab72a561
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3622913
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80323}
This change adds support for computing SHA-256 hashes in the stack
output of errors by adding a function to the prototype of the
`CallSite` object, passed to `Error.prepareStackTrace`. Additionally,
it updates the `hash` property from `Debugger.scriptParsed` and
`Debugger.scriptFailedToParse` to be SHA-256 instead of the
proprietary hash it is today.
It is intended to be an advancement in indexing source maps to
support improved tooling, especially for post-hoc or in-production
diagnostics scenarios.
The explainer can be found here:
https://docs.google.com/document/d/13hNeeLC2Ve_FVieNndZUUUP15x2O4ltvjnGWwOsMlrU/edit?usp=sharing
Change-Id: Ifbbed4b22c8256e74e6d79974d2dd1e444143eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229957
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Robert Paveza <Rob.Paveza@microsoft.com>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80320}
This is a reland of commit 8960031432
Changes since revert: None, reverted wrong suspect CL
Original change's description:
> [Temporal] Fix Calendar.prototype.fields CSA
>
> Use LoadAndUntagToWord32ObjectField instead of LoadObjectField<Uint32T>
> to load the flag since it is defined as
> flags: SmiTagged<JSTemporalCalendarFlags>;
>
> Otherwise LoadObjectField<Uint32T> will load the zero part when
> v8_enable_pointer_compression = false
>
> Add unit tests to intl (because the problem only show up on calendar
> other than non iso8601.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_mipsel_compile_rel,v8_linux_mips64el_compile_rel
>
>
> Bug: v8:12848
> Change-Id: I44b685af99dc9820dfa228447e2b42ae0a82464c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3617388
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80314}
Bug: v8:12848
Change-Id: I423ea5f0a4a30fc73546df208d24aec84db76eb4
Cq-Include-Trybots: luci.v8.try:v8_linux_mipsel_compile_rel,v8_linux_mips64el_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620838
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80319}
This reverts commit 8960031432.
Reason for revert: UBSAN errors in GC tests
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/21069/overview
Original change's description:
> [Temporal] Fix Calendar.prototype.fields CSA
>
> Use LoadAndUntagToWord32ObjectField instead of LoadObjectField<Uint32T>
> to load the flag since it is defined as
> flags: SmiTagged<JSTemporalCalendarFlags>;
>
> Otherwise LoadObjectField<Uint32T> will load the zero part when
> v8_enable_pointer_compression = false
>
> Add unit tests to intl (because the problem only show up on calendar
> other than non iso8601.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_mipsel_compile_rel,v8_linux_mips64el_compile_rel
>
>
> Bug: v8:12848
> Change-Id: I44b685af99dc9820dfa228447e2b42ae0a82464c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3617388
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80314}
Bug: v8:12848
Change-Id: I3a8af8acbbdfc5d0f5386f2a9d50d62b9f422fb8
Cq-Include-Trybots: luci.v8.try:v8_linux_mipsel_compile_rel,v8_linux_mips64el_compile_rel
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620837
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80317}
Use LoadAndUntagToWord32ObjectField instead of LoadObjectField<Uint32T>
to load the flag since it is defined as
flags: SmiTagged<JSTemporalCalendarFlags>;
Otherwise LoadObjectField<Uint32T> will load the zero part when
v8_enable_pointer_compression = false
Add unit tests to intl (because the problem only show up on calendar
other than non iso8601.
Cq-Include-Trybots: luci.v8.try:v8_linux_mipsel_compile_rel,v8_linux_mips64el_compile_rel
Bug: v8:12848
Change-Id: I44b685af99dc9820dfa228447e2b42ae0a82464c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3617388
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80314}
https://crrev.com/c/3571817 introduced a bug that string table lookups
failed on SlicedStrings with a start offset of 0.
This CL fixes the issue by re-using the already computed hash only
if the length of the source string matches the length of the string to
lookup.
Bug: chromium:1320179, chromium:1321573
Change-Id: Ic8755a0266a9ec67fe5eb9c96fdab1b55d5009f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616723
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80309}
This is a reland of commit 9145388055
Fixed: properly reference the ClearedValue in CSA (i.e. without
the cage_base upper 32 bits).
Original change's description:
> Reland "[osr] Use the new OSR cache"
>
> This is a reland of commit 91da38831d
>
> Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
> on arm64.
>
> Original change's description:
> > [osr] Use the new OSR cache
> >
> > This CL switches over our OSR system to be based on the feedback
> > vector osr caches.
> >
> > - OSRing to Sparkplug is fully separated from OSR urgency. If
> > SP code exists, we simply jump to it, no need to maintain an
> > installation request.
> > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> > If a valid target code object exists, we enter it *without*
> > calling into runtime to fetch the code object.
> > - Finally, OSR urgency still remains as the heuristic for
> > requesting Turbofan OSR compile jobs. Note it no longer has a
> > double purpose of being a generic untargeted installation
> > request.
> >
> > With the new system in place, we can remove now-unnecessary
> > hacks:
> >
> > - Early OSR tierup is replaced by the standard OSR system. Any
> > present OSR code is automatically entered.
> > - The synchronous OSR compilation fallback is removed. With
> > precise installation (= per-JumpLoop-bytecode) we no longer
> > have the problem of 'getting unlucky' with JumpLoop/cache entry
> > mismatches. Execution has moved on while compiling? Simply spawn
> > a new concurrent compile job.
> > - Remove the synchronous (non-OSR) Turbofan compile request now
> > that we always enter available OSR code as early as possible.
> > - Tiering into Sparkplug no longer messes with OSR state.
> >
> > Bug: v8:12161
> > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> > Commit-Queue: Jakob Linke <jgruber@chromium.org>
> > Auto-Submit: Jakob Linke <jgruber@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80147}
>
> Bug: v8:12161
> Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80167}
Bug: v8:12161,chromium:1320189
Change-Id: Ibd9a2ab61f51ebb32a3f5a66f7c602faead71c3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620273
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80306}
The CL prepares the sources and the tests for enabling
cppgc_enable_young_generation by default. The static initializer
in YoungGenerationEnabler (due to v8::base::Mutex) changed to be lazy.
The tests are now checking the runtime flag.
Bug: chromium:1029379
Change-Id: I1497a3dd2b8d62c1acd48496821f07324b7944d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616726
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80304}
We weren't really translating between location (line and column number)
and source position (character offset) consistently, especially when it
came to inline <script>s. There were also inconsistencies between what
Debugger.getPossibleBreakpoints and Debugger.setBreakpointByUrl would
do.
With this CL, we are now consistently operating under the following
assumptions:
(1) For inline <scripts>s with a //@ sourceURL annotation, we assume
that the line and column number that comes in via the protocol is
in terms of the source text of the script.
(2) For inline <script>s without said annotation, we assume that the
line and column numbers are in terms of the surrounding document.
This is finally aligned with how the DevTools front-end operates.
Fixed: chromium:1319828
Change-Id: I98c4ef04b34a97caf060ff4f32690b135edb6ee6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610622
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80292}
This reverts commit 23b2d571a7.
Reason for revert: Breaks the V8 roll https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/1000394/
Original change's description:
> Reland "[heap] Store size with invalidated object"
>
> This is a reland of commit 5d235def26
>
> The previous version of this CL got reverted because the cached
> size of an invalidated object wasn't up-to-date when performing a GC.
>
> Not all size changes go through NotifyObjectLayoutChange, so
> https://crrev.com/c/3607992 introduced NotifyObjectSizeChange as a
> bottleneck for object size changes/right-trimming. This method is
> now used to update the size of invalidated objects.
>
> Original change's description:
> > [heap] Store size with invalidated object
> >
> > When updating pointers during a full GC, a page might not be swept
> > already. In such cases there might be invalid objects and slots recorded
> > in free memory. Updating tagged slots in free memory is fine even though
> > it is superfluous work.
> >
> > However, the GC also needs to calculate the size of potentially dead
> > invalid objects in order to be able to check whether a slot is within
> > that object. But since that object is dead, its map might be dead as
> > well which makes size calculation impossible on such objects. The CL
> > changes this to cache the size of invalid objects. A follow-up CL will
> > also check the marking bit of invalid objects.
> >
> > Bug: v8:12578, chromium:1316289
> > Change-Id: Ie773d0862a565982957e0dc409630d76552d1a32
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599482
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Reviewed-by: Jakob Linke <jgruber@chromium.org>
> > Reviewed-by: Patrick Thier <pthier@chromium.org>
> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80169}
>
> Bug: v8:12578, chromium:1316289
> Change-Id: I1f7c6070b8e7d116aeb1a8d03d4f87927ab40872
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608632
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80262}
Bug: v8:12578, chromium:1316289
Change-Id: I88b73ebe09bb923ba4ac57b0dbdceb08a1badd99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616730
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Owners-Override: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80291}
This reverts commit 9145388055.
Reason for revert: Breaking the Fuchsia Deterministic Builder
Original change's description:
> Reland "[osr] Use the new OSR cache"
>
> This is a reland of commit 91da38831d
>
> Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
> on arm64.
>
> Original change's description:
> > [osr] Use the new OSR cache
> >
> > This CL switches over our OSR system to be based on the feedback
> > vector osr caches.
> >
> > - OSRing to Sparkplug is fully separated from OSR urgency. If
> > SP code exists, we simply jump to it, no need to maintain an
> > installation request.
> > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> > If a valid target code object exists, we enter it *without*
> > calling into runtime to fetch the code object.
> > - Finally, OSR urgency still remains as the heuristic for
> > requesting Turbofan OSR compile jobs. Note it no longer has a
> > double purpose of being a generic untargeted installation
> > request.
> >
> > With the new system in place, we can remove now-unnecessary
> > hacks:
> >
> > - Early OSR tierup is replaced by the standard OSR system. Any
> > present OSR code is automatically entered.
> > - The synchronous OSR compilation fallback is removed. With
> > precise installation (= per-JumpLoop-bytecode) we no longer
> > have the problem of 'getting unlucky' with JumpLoop/cache entry
> > mismatches. Execution has moved on while compiling? Simply spawn
> > a new concurrent compile job.
> > - Remove the synchronous (non-OSR) Turbofan compile request now
> > that we always enter available OSR code as early as possible.
> > - Tiering into Sparkplug no longer messes with OSR state.
> >
> > Bug: v8:12161
> > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> > Commit-Queue: Jakob Linke <jgruber@chromium.org>
> > Auto-Submit: Jakob Linke <jgruber@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80147}
>
> Bug: v8:12161
> Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80167}
Bug: v8:12161
Change-Id: I73e2d98660e9edfbe07a152a14402380ea9227de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615219
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80287}
The CL uses the different scheme to enable the generational barrier. The
separate global counter (is_enabled_) keeps track of the number of heaps
that enable generational GC. If at least one of the heaps enables the
generational GC, the counter will enable the write barrier. Technically,
the counter could be merged with WriteBarrier::is_enabled_, but having a
separate variable allows us to keep DCHECKs if generational barrier is
enabled.
Bug: chromium:1029379
Change-Id: Iafaa76f96acb18a73f8bde7231434e68c04cb683
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616518
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80281}
The CL introduces a new option --cppgc-young-generation. This option
can't be enabled statically, because V8 options are parsed after heap
initialization. The CL changes minor GC so that it can be enabled
dynamically. The way it works is as follows:
- the user calls YoungGenerationEnabler::Enable();
- a heap checks in the next atomic pause whether the flag was enabled;
- if so, the heap enables young generation for itself.
To avoid barrier regressions without young-generation enabled, the CL changes the meaning of the global flag is-any-incremental-or-concurrent-marking to is-barrier-enabled.
The runtime option would enable us to test young generation on try-
and performance-bots.
Bug: chromium:1029379
Change-Id: I664cccdcd208225ffcbf9901f1284b56d088c5c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607993
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80274}
This is a reland of commit 5d235def26
The previous version of this CL got reverted because the cached
size of an invalidated object wasn't up-to-date when performing a GC.
Not all size changes go through NotifyObjectLayoutChange, so
https://crrev.com/c/3607992 introduced NotifyObjectSizeChange as a
bottleneck for object size changes/right-trimming. This method is
now used to update the size of invalidated objects.
Original change's description:
> [heap] Store size with invalidated object
>
> When updating pointers during a full GC, a page might not be swept
> already. In such cases there might be invalid objects and slots recorded
> in free memory. Updating tagged slots in free memory is fine even though
> it is superfluous work.
>
> However, the GC also needs to calculate the size of potentially dead
> invalid objects in order to be able to check whether a slot is within
> that object. But since that object is dead, its map might be dead as
> well which makes size calculation impossible on such objects. The CL
> changes this to cache the size of invalid objects. A follow-up CL will
> also check the marking bit of invalid objects.
>
> Bug: v8:12578, chromium:1316289
> Change-Id: Ie773d0862a565982957e0dc409630d76552d1a32
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599482
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80169}
Bug: v8:12578, chromium:1316289
Change-Id: I1f7c6070b8e7d116aeb1a8d03d4f87927ab40872
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608632
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80262}
This is a reland of commit 9d31f8663a
There were issues with --future flag implications on M1.
Original change's description:
> [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
>
> ... for V8 code space. The feature is currently disabled.
>
> In order to use fast W^X permission switching we must allocate
> executable pages with readable writable executable permissions (RWX).
> However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
> permission changing of RWX memory pages. This means that the code page
> headers must be allocated with RWX permissions too because otherwise
> it wouldn't be possible to allocate a large code page over the freed
> regular code page and vice versa.
>
> When enabled, the new machinery works as follows:
>
> 1) when memory region is reserved for allocating executable pages, the
> whole region is committed with RWX permissions and then decommitted,
> 2) since reconfiguration of RWX page permissions is not allowed on
> MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
> to change them,
> 3) the request to set RWX permissions in the executable page region
> just recommits the pages without changing permissions (see (1), they
> were already allocated as RWX and then discarded),
> 4) in order to make executable pages inaccessible one must use
> OS::DiscardSystemPages() instead of OS::DecommitPages() or
> setting permissions to kNoAccess because the latter two are not
> allowed by the MacOS (see (2)).
> 5) since code space page headers are allocated as RWX pages it's also
> necessary to switch between W^X modes when updating the data in the
> page headers (i.e. when marking, updating stats, wiring pages in
> lists, etc.). The new CodePageHeaderModificationScope class is used
> in the respective places. On unrelated configurations it's a no-op.
>
> The fast permission switching can't be used for V8 configuration with
> enabled pointer compression and disabled external code space because
> a) the pointer compression cage has to be reserved with MAP_JIT flag
> which is too expensive,
> b) in case of shared pointer compression cage if the code range will
> be deleted while the cage is still alive then attempt to configure
> permissions of pages that were previously set to RWX will fail.
>
> This also CL extends the unmapper unit tests with permissions tracking
> for discarded pages.
>
> Bug: v8:12797
> Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80238}
Bug: v8:12797
Change-Id: I0fe86666f31bad37d7074e217555c95900d2afba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610433
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80259}
There are three ways to parse /proc/self/maps in platform-linux.cc,
remove one to use common code. In the process, add a unit test, and fix
some issues in the latest iteration of /proc/self/maps parsing.
Change-Id: I4701ea49fe8cce53aea0179e194dc48fbebb2ff5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605226
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80258}
For some reason the compiler was optimizing away the reference to the
object in WeakContainerTest.ConservativeGCTracesWeakContainer and thus
not finding it conservatively.
This CL revises the tests such that the compiler is no longer able to
optimize references away.
Bug: v8:12824
Change-Id: Ie598a1cf1124c2983a6c61fd4e990734d36f5832
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610627
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80257}
- Supports Float64 Add for SmiAdd bytecode
- Adds a Float64Constant and ChangeInt32ToFloat64 nodes
- Converts floats to tagged in Phi node inputs
- Fixes spill double representation
- Fixes materialisation during a deopt of a double in the stack
Bug: v8:7700
Change-Id: I9217a64313b4bd5d0015f935c23771ecf9a2c7ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610426
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80255}
The test is very resource intensive and is therefore not reliable on
weaker systems. The limits are the same for all configurations, so it's
not a problem if we disable the test for some configurations.
R=machenbach@chromium.org
Fixes: v8:12836
Change-Id: If187bd3d5d352b1685d3a6e43a76860a263f53de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608631
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80253}
* Prefix all isolate variables with i_ for i::Isolate and
v8_ for v8::Isolate
* Change _DO_NOT_USE macro suffix to _INTERNAL
Change-Id: I005efbe0192cf202741448c63a4263e6a4b1fa1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610429
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80252}
The SIMD proposal has been merged into the main spec, it is not
necessary anymore to execute the SIMD proposal tests additionally.
R=gdeepti@chromium.org
Change-Id: I1c5847a1bfba2d0c956cf353816fd71417506a1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3609848
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80241}
This reverts commit 9d31f8663a.
Reason for revert: crashes on Mac/arm64 bots:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20debug/5923/overview
Original change's description:
> [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
>
> ... for V8 code space. The feature is currently disabled.
>
> In order to use fast W^X permission switching we must allocate
> executable pages with readable writable executable permissions (RWX).
> However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
> permission changing of RWX memory pages. This means that the code page
> headers must be allocated with RWX permissions too because otherwise
> it wouldn't be possible to allocate a large code page over the freed
> regular code page and vice versa.
>
> When enabled, the new machinery works as follows:
>
> 1) when memory region is reserved for allocating executable pages, the
> whole region is committed with RWX permissions and then decommitted,
> 2) since reconfiguration of RWX page permissions is not allowed on
> MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
> to change them,
> 3) the request to set RWX permissions in the executable page region
> just recommits the pages without changing permissions (see (1), they
> were already allocated as RWX and then discarded),
> 4) in order to make executable pages inaccessible one must use
> OS::DiscardSystemPages() instead of OS::DecommitPages() or
> setting permissions to kNoAccess because the latter two are not
> allowed by the MacOS (see (2)).
> 5) since code space page headers are allocated as RWX pages it's also
> necessary to switch between W^X modes when updating the data in the
> page headers (i.e. when marking, updating stats, wiring pages in
> lists, etc.). The new CodePageHeaderModificationScope class is used
> in the respective places. On unrelated configurations it's a no-op.
>
> The fast permission switching can't be used for V8 configuration with
> enabled pointer compression and disabled external code space because
> a) the pointer compression cage has to be reserved with MAP_JIT flag
> which is too expensive,
> b) in case of shared pointer compression cage if the code range will
> be deleted while the cage is still alive then attempt to configure
> permissions of pages that were previously set to RWX will fail.
>
> This also CL extends the unmapper unit tests with permissions tracking
> for discarded pages.
>
> Bug: v8:12797
> Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80238}
Bug: v8:12797
Change-Id: Ic07948e036db36326d464a2a901d052aa060a406
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3611665
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80239}
... for V8 code space. The feature is currently disabled.
In order to use fast W^X permission switching we must allocate
executable pages with readable writable executable permissions (RWX).
However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
permission changing of RWX memory pages. This means that the code page
headers must be allocated with RWX permissions too because otherwise
it wouldn't be possible to allocate a large code page over the freed
regular code page and vice versa.
When enabled, the new machinery works as follows:
1) when memory region is reserved for allocating executable pages, the
whole region is committed with RWX permissions and then decommitted,
2) since reconfiguration of RWX page permissions is not allowed on
MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
to change them,
3) the request to set RWX permissions in the executable page region
just recommits the pages without changing permissions (see (1), they
were already allocated as RWX and then discarded),
4) in order to make executable pages inaccessible one must use
OS::DiscardSystemPages() instead of OS::DecommitPages() or
setting permissions to kNoAccess because the latter two are not
allowed by the MacOS (see (2)).
5) since code space page headers are allocated as RWX pages it's also
necessary to switch between W^X modes when updating the data in the
page headers (i.e. when marking, updating stats, wiring pages in
lists, etc.). The new CodePageHeaderModificationScope class is used
in the respective places. On unrelated configurations it's a no-op.
The fast permission switching can't be used for V8 configuration with
enabled pointer compression and disabled external code space because
a) the pointer compression cage has to be reserved with MAP_JIT flag
which is too expensive,
b) in case of shared pointer compression cage if the code range will
be deleted while the cage is still alive then attempt to configure
permissions of pages that were previously set to RWX will fail.
This also CL extends the unmapper unit tests with permissions tracking
for discarded pages.
Bug: v8:12797
Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80238}
If the debug handler (called via {OnDebugBreak}) requests termination of
the isolate, this would only get considered on the next stack check,
where it is turned into a proper termination exception.
Handling this correctly is further complicated by the {DebugScope}
blocking any handling of interrupts via the included
{PostponeInterruptsScope}.
Hence this CL refactors the code to call any debug handlers in a second
function which has the {DebugScope}, and to check for interrupts after
leaving that scope.
R=thibaudm@chromium.orgCC=bmeurer@chromium.org
Bug: chromium:1319343
Change-Id: Ia2df0f2610d50eedc6437841c4bf1d2ad3ac9125
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605228
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80235}
Tests runs out of code space on ppc as size exceeds 32MB.
More details can be found under the comment section of this CL:
https://crrev.com/c/3605814.
Bug: v8:11577
Change-Id: Iadfbc3b9618a0873f5f08a030b799d5761946671
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610628
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80234}
tests where moved from cctest to unittests under this cl:
https://crrev.com/c/3607370
Bug: v8:12781
Change-Id: If625e0dda51034e731c5e7fe87d591dce9804888
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3611182
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80227}
Add an unboxing double field load node, and fix a couple of locations
where it might be used enough to pass tests.
Bug: v8:7700
Change-Id: Ic134484e87a4fa363cbd8a3de667ac8e8116d502
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610623
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80221}
This fixes the ordering of DCHECKs which expect the value to not be in
the free list yet when it is dropped.
Bug: v8:7700
Change-Id: Ifb85d0e20cfe5c083d1f2bc971817143265fdc7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610444
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80218}
CheckedFloat64Unbox mutates the input value, but the register allocator
does not expects this behaviour and propagates a wrong value in the register.
In particular we deopt with the wrong value if the second Float64Unbox
in a Float64Add needs to deopt.
This fixes the input value after we convert to double.
Bug: v8:7700
Change-Id: Ib89573e9f728dc3a34b817fc84f1afcb96f14d18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610422
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80214}
The JS import returns a tagged value, not a value of the machine
representation that corresponds to the signature's return type, since it
hasn't been converted yet.
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: I0783af85eed9c5d25347200540e3e4eee48edfd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3464036
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80213}
This logic was confused in the presence of inlined frames; the
deopt exit offset would point inside the innermost inlined frame
while we incorrectly assumed it points at the outermost frame.
Fix this by always referring to the bytecode offset of the outermost
frame.
Bug: v8:12161
Fixed: chromium:1320094
Change-Id: I2eb28498639432c5344859f64a9388d93ee23bde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608630
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80212}
The AssemblerBufferCache was so far only used for Liftoff compilation.
Hence all TurboFan compilation was using unprotected assembler buffers.
This CL passes the AssemblerBufferCache from the function compiler down
to the TurboFan PipelineData. From there it is used when instantiating
the CodeGenerator to generate the AssemblerBuffer for the
TurboAssembler. This will protect the assembler buffers used for
TurboFan Wasm compilation via PKU, if available.
Since PipelineData has a single constructor for all Wasm compilation, we
have a single choke point to ensure that an AssemblerBufferCache is
passed down. For Wasm stub compilation (import wrappers etc) we
currently explicitly pass a nullptr, this will be fixed in a follow-up
CL.
R=thibaudm@chromium.org, tebbi@chromium.org
Bug: v8:12809
Change-Id: I268bd21047adbd7f0aab78e8b0a4b4df1d1f8ddf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596172
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80210}
Add flag --always-use-string-forwarding-table to always use the
forwarding table (usually only used for shared strings) instead of
ThinString migrations initially (during GC strings will be migrated
to normal ThinStrings). The goal is to get more coverage of this code
that is designed for shared strings.
Bug: v8:12007
Change-Id: I7eb2e5ccf0018c4ac349611aebe337d8288de5c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3536650
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80206}
Introduce a bottleneck for right-trimming an object. In a subsequent CL
we will use this method to update the cached size of invalidated
objects.
This CL also tries to clean-up the various CreateFillerObjectAt
methods. CreateFillerObjectAtRaw is now the internal method for all
these methods. After moving right-trimming to NotifyObjectSizeChange,
both CreateFillerObjectAt and CreateFillerObjectAtBackground don't need
those arguments for clearing slots or memory anymore.
Bug: v8:12578, chromium:1316289
Change-Id: I6ff0bfaced3e0a1765152700e68a4ad33a155723
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607992
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80200}
This CL includes count value to InvalidCountValue error message to make
it easier to dignoise RangeError of String.prototype.repeat. When
InvalidCountValue error throw, we could not know it's
caused by which count value if count value is not included.
Bug: none
Change-Id: I16e6693da0fc3b181241cb90daca27957f59c77c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3593574
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80198}
PR85 https://github.com/tc39/proposal-intl-numberformat-v3/pull/85
Throw RangeError while roundingIncrement is not 1 and
minimumFractionDigits != maximumFractionDigits
Test by new test cases in intl/number-format/rounding-increment-v3.js
Add more unit test to check the resolved options of roundingIncrement,
minimumFractionDigits, and maximumFractionDigits.
PR91 https://github.com/tc39/proposal-intl-numberformat-v3/pull/91
Throw TypeError instead of RangeError while roundingIncrement is not 1
and RoundingType is not fractionDigits
Test by intl402/NumberFormat/constructor-roundingIncrement-invalid.js
in test262
Bug: v8:10776
Change-Id: I071bfe8b3e844c5999144d74bb5f79ea9811e37b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3603059
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80196}
It's necessary to support fast W^X permission switching on MacOS on
ARM64 ("Apple M1"/Apple Silicon) where permission modification of RWX
pages to anything else is prohibited.
On all the other architectures/platforms RecommitPages() is equivalent
to SetPermissions().
The new API will be used in a follow-up CLs.
Bug: v8:12797
Change-Id: Id0d8b8c42c81b80cd8fa6b47c227680d7d1f9b10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606231
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Samuel Groß <saelo@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80190}
I cannot reproduce the original problem anymore. The test passes
nicely. If the test (wasm-js/limits) fails again, then we should
just disable it for those platforms where it is failing.
Fixed: v8:11577
Change-Id: I186da2ec2dd8fd518ce4034e8e3838376fefbc3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605814
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80186}
This is a reland of commit 8ba60b7a8e
Changes to original:
- Weaken DCHECK in MakeThin to allow direct transitions of shared
strings during deserialization. This is safe as the string to be
transitioned is freshly created and hasn't escaped the thread yet.
- To enable this, add has_active_deserializer() to LocalIsolate
- Shared thin string transitions are subject to the same layout changes
as non-shared thin string transitions, thus treat them equally when
checking if a map transition is safe.
Original change's description:
> [string] Non-transitioning shared strings
>
> Instead of transitioning shared strings to ThinString on
> internalization, use a forwarding table to the internalized string and
> store the index into the forwarding table in the string's hash field.
>
> This way we don't need to handle concurrent string transitions that
> modify the underlying string data.
>
> During stop-the-world GC, live strings in the forwarding table are
> migrated to regular ThinStrings.
>
> Bug: v8:12007
> Change-Id: I6c6f3d41c6f644e0aaeafbf25ecec5ce0aa0d2d8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3536647
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79801}
Bug: v8:12007
Change-Id: I022e5c4768b763a86bb28c9c82218c3b807371a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571817
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80183}
When passing anyref-typed things to Wasm, we cannot expect that
all functions are WasmExternalFunctions. Instead of adding a
relatively expensive type check to such calls, this patch disables
function unwrapping for anyref-typed values.
Fixed: v8:12789
Change-Id: Ied57187bac7fde0326634f7b4fc428ad21dc9c2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605231
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80179}
- For simplicity we call a builtin when allocating a number.
- Elision of boxing/unboxing nodes will be done in a followup CL.
Bug: v8:7700
Change-Id: Iec4422d84c6597d3369ab512a1662adb0f077c98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602514
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80178}
Table.set has two arguments, the table index and the value. Therefore
Table.set was defined with a length of 2. However, the value argument is
optional, so the length should actually be 1.
Change-Id: Ica2ea13a8e78c974cb011df2b5dc99f8e7eb4bcd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398496
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80176}
When setting a range for a newly allocated lab, consider adjacent cards.
If either is young, don't mark it as kMixed.
Bug: chromium:1029379
Change-Id: If7d1d920dd5769679de68800eae61f3a8dc1eb17
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3584116
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80175}
This reverts commit 5d235def26.
Reason for revert: Speculative revert because of https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/38153/overview
Original change's description:
> [heap] Store size with invalidated object
>
> When updating pointers during a full GC, a page might not be swept
> already. In such cases there might be invalid objects and slots recorded
> in free memory. Updating tagged slots in free memory is fine even though
> it is superfluous work.
>
> However, the GC also needs to calculate the size of potentially dead
> invalid objects in order to be able to check whether a slot is within
> that object. But since that object is dead, its map might be dead as
> well which makes size calculation impossible on such objects. The CL
> changes this to cache the size of invalid objects. A follow-up CL will
> also check the marking bit of invalid objects.
>
> Bug: v8:12578, chromium:1316289
> Change-Id: Ie773d0862a565982957e0dc409630d76552d1a32
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599482
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80169}
Bug: v8:12578, chromium:1316289
Change-Id: I6949412c5d6e1aa15718d027043d9528137a60a0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605812
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80173}
When updating pointers during a full GC, a page might not be swept
already. In such cases there might be invalid objects and slots recorded
in free memory. Updating tagged slots in free memory is fine even though
it is superfluous work.
However, the GC also needs to calculate the size of potentially dead
invalid objects in order to be able to check whether a slot is within
that object. But since that object is dead, its map might be dead as
well which makes size calculation impossible on such objects. The CL
changes this to cache the size of invalid objects. A follow-up CL will
also check the marking bit of invalid objects.
Bug: v8:12578, chromium:1316289
Change-Id: Ie773d0862a565982957e0dc409630d76552d1a32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599482
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80169}
This is a reland of commit 91da38831d
Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
on arm64.
Original change's description:
> [osr] Use the new OSR cache
>
> This CL switches over our OSR system to be based on the feedback
> vector osr caches.
>
> - OSRing to Sparkplug is fully separated from OSR urgency. If
> SP code exists, we simply jump to it, no need to maintain an
> installation request.
> - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> If a valid target code object exists, we enter it *without*
> calling into runtime to fetch the code object.
> - Finally, OSR urgency still remains as the heuristic for
> requesting Turbofan OSR compile jobs. Note it no longer has a
> double purpose of being a generic untargeted installation
> request.
>
> With the new system in place, we can remove now-unnecessary
> hacks:
>
> - Early OSR tierup is replaced by the standard OSR system. Any
> present OSR code is automatically entered.
> - The synchronous OSR compilation fallback is removed. With
> precise installation (= per-JumpLoop-bytecode) we no longer
> have the problem of 'getting unlucky' with JumpLoop/cache entry
> mismatches. Execution has moved on while compiling? Simply spawn
> a new concurrent compile job.
> - Remove the synchronous (non-OSR) Turbofan compile request now
> that we always enter available OSR code as early as possible.
> - Tiering into Sparkplug no longer messes with OSR state.
>
> Bug: v8:12161
> Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80147}
Bug: v8:12161
Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80167}
Currently the Isolate is gotten off of the object that the operation is
being performed on. Shared objects return the shared Isolate, which is
incorrect as it shouldn't be used to run JS, nor does it have
HandleScopes open. Plumb the executing Isolate through.
Bug: v8:12547
Change-Id: I3d960751c798ac657a6122598154e36d9d504c31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606489
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80163}
This CL extends BoundedPageAllocator with PageFreeingMode parameter
which controls how pages should be freed: by setting permissions to
kNoAccess (preferred) or by discarding pages (Apple Silicon specific
behavior for RWX pages). The latter mode allows to ensure that once
pages are configured with RWX permissions they are never reconfigured
to anything else again.
The new mode will be used in a follow-up CL.
Bug: v8:12797
Change-Id: I3277f56ea6fee9c9b38b1682e68c22e66e9a02a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606228
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80162}
This reverts commit 91da38831d.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression%20-%20builder/21150/overview
Original change's description:
> [osr] Use the new OSR cache
>
> This CL switches over our OSR system to be based on the feedback
> vector osr caches.
>
> - OSRing to Sparkplug is fully separated from OSR urgency. If
> SP code exists, we simply jump to it, no need to maintain an
> installation request.
> - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> If a valid target code object exists, we enter it *without*
> calling into runtime to fetch the code object.
> - Finally, OSR urgency still remains as the heuristic for
> requesting Turbofan OSR compile jobs. Note it no longer has a
> double purpose of being a generic untargeted installation
> request.
>
> With the new system in place, we can remove now-unnecessary
> hacks:
>
> - Early OSR tierup is replaced by the standard OSR system. Any
> present OSR code is automatically entered.
> - The synchronous OSR compilation fallback is removed. With
> precise installation (= per-JumpLoop-bytecode) we no longer
> have the problem of 'getting unlucky' with JumpLoop/cache entry
> mismatches. Execution has moved on while compiling? Simply spawn
> a new concurrent compile job.
> - Remove the synchronous (non-OSR) Turbofan compile request now
> that we always enter available OSR code as early as possible.
> - Tiering into Sparkplug no longer messes with OSR state.
>
> Bug: v8:12161
> Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80147}
Bug: v8:12161
Change-Id: I4a6955f4f20b6f3b13e98d5600c7c6a5205915bc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605608
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80148}
This CL switches over our OSR system to be based on the feedback
vector osr caches.
- OSRing to Sparkplug is fully separated from OSR urgency. If
SP code exists, we simply jump to it, no need to maintain an
installation request.
- Each JumpLoop checks its dedicated FeedbackVector cache slot.
If a valid target code object exists, we enter it *without*
calling into runtime to fetch the code object.
- Finally, OSR urgency still remains as the heuristic for
requesting Turbofan OSR compile jobs. Note it no longer has a
double purpose of being a generic untargeted installation
request.
With the new system in place, we can remove now-unnecessary
hacks:
- Early OSR tierup is replaced by the standard OSR system. Any
present OSR code is automatically entered.
- The synchronous OSR compilation fallback is removed. With
precise installation (= per-JumpLoop-bytecode) we no longer
have the problem of 'getting unlucky' with JumpLoop/cache entry
mismatches. Execution has moved on while compiling? Simply spawn
a new concurrent compile job.
- Remove the synchronous (non-OSR) Turbofan compile request now
that we always enter available OSR code as early as possible.
- Tiering into Sparkplug no longer messes with OSR state.
Bug: v8:12161
Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80147}
This introduces an AssemblerBufferCache class which will (later) cache
the backing store of AssemblerBuffers. This is needed for PKU-protected
assembler buffers, which are expensive to allocate and deallocate.
For now, the AssemblerBufferCache does not do any caching, this will be
added in a follow-up CL.
R=thibaudm@chromium.org
Bug: v8:12809
Change-Id: I4a7ccff49c9930584a9fcda8899cfe38cfc61419
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3593136
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80145}
TurboShaft is a new, CFG-based IR for TurboFan.
This CL adds the basic IR and bidirectional translation from/to
TurboFan's sea-of-nodes-based IR for some common operators (still
incomplete even for JS).
Bug: v8:12783
Change-Id: I162fdf10d583a9275a9f655f5b44b888faf813f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563562
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80136}
- In DeserializeContext, scope info local values
snapshot is in order of `name,value,name,value`,
and we should ReadValue after ReadString.
- Support non-inlined ScopeInfo locals, use
NameToIndexHashTable to serialize and deserialize
scope info local values when its local count is
more than kScopeInfoMaxInlinedLocalNamesSize.
Bug: v8:11525, v8:12820
Change-Id: I6ea2c498b594bed7ba8ca5be6af2ab9f0d39aa2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3600531
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#80130}
These were originally proposed as a part of the fixed-width SIMD
proposal, and were then migrated to the relaxed-simd proposal
which also deems these operations out of scope.
Github issue: https://github.com/WebAssembly/relaxed-simd/issues/4
Bug: v8:12284
Change-Id: I65ceb6dfd25c43cf49bd7ec5b5ecd6b32cc3516a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3595970
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80125}
As per https://tc39.es/ecma262/#sec-hostimportmoduledynamically defined,
referencingScriptOrModule in HostImportModuleDynamically can be a Script
Record, a Module Record, or null.
So to https://tc39.es/proposal-shadowrealm/#sec-shadowrealmimportvalue,
the HostImportModuleDynamicallyCallback is been invoked with a `null`
resource_name. This may not be considered a breaking change as the
parameter resource_name is defined as Local<Value>.
Updates d8's DoHostImportModuleDynamically to handle null resource_name,
and resolve the dynamically imported specifier relative to the executing
script's origin. In this way, we have to set ModuleEmbedderData.origin
even if the JavaScript source to be evaluated is Script. Also, a
ModuleEmbedderData is created for each ShadowRealm to separate their
module maps from the initiator context's.
Bug: v8:11989
Change-Id: If70fb140657da4f2dd92eedfcc4515211602aa46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3522883
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#80118}
This CL extends GetIterator to check whether the result of
calling @@iterator is JSReceiver and throw SymbolIteratorInvalid
if it's not JSReceiver.
GetIterator bytecode involves 3 steps now:
- method = GetMethod(obj, @@iterator)
- iterator = Call(method, obj)
- if(!IsJSReceiver(iterator)) throw SymbolIteratorInvalid [Added]
New Builtin: CallIteratorWithFeedbackLazyDeoptContinuation, which
is used when lazy deopt is triggered by call @@iterator.
Related spec: https://tc39.es/ecma262/#sec-getiterator.
Related doc: https://docs.google.com/document/d/1s67HC2f-4zxA_s1Bmm7dfwMFv_KDUfMiWIKkNSeQNKw/edit#heading=h.kdzv8mq4g4ks.
Bug: v8:9489
Change-Id: I17952c0f3e24e1e600ee1348809fb188c2c70f8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563447
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#80112}
There is currently a bug in docker where fstat may not
return the correct device id and as a result a check under
`OS::RemapPages, stat_buf.st_dev != enclosing_region.dev`
fails, details on the bug:
https://github.com/moby/moby/issues/43512
Platform specific page sizes are also defined for kMaxPageSize
to fix compilation errors.
Change-Id: I026609329aa6432eda4f1880a0f586c0c2162461
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3601211
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80111}
Normally, taking a heap snapshot in the near heap limit would
result in a full GC, then the overhead of the promotions would
cause another invocation of the heap limit callback and it can
raise the limit in the second call to avoid an OOM, so we test
that the callback can indeed raise the limit this way in this
case. When there is only one generation, however, there would
not be the overhead of promotions so the callback may not be
triggered again during the generation of the heap snapshot.
In that case we only need to check that the callback is called
and it can perform GC-triggering operations jsut fine there.
Bug: v8:12815
Change-Id: If244417624b56bc068aed480fb3391d26c19005a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3600357
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#80094}
In the simplest way possible.
Bug: v8:7700
Change-Id: I155aaf85192b75c89617820d6f127a2ae04c7d9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599484
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80089}
When moving forward and optimizing internals, these APIs cannot be
trusted anymore as their semantics are tangled to the current
implementation.
Bug: v8:12819
Change-Id: I0e3370724307a420ee42fed8070b55542be9400d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599475
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80082}
Add a --maglev-inlining flag, and add some half-baked support for
inlining functions when there is call feedback.
When the flag is enabled and there is call feedback, we create a nested
MaglevGraphBuilder for the current graph, and pause building the graph
of the outer function. We manually set up its prologue to set up its
frame with the arguments pass into the call, build the body with the
nested graph builder. This inner builder knows that it is building an
inlined function, and all Return bytecodes will instead emit a Jump to a
single merge block at the end of the function, where execution of the
outer function can resume.
These inner function basic blocks are wired into the outer graph with
new JumpToInline and JumpFromInline control nodes. The idea is that
subsequent passes will know what the inline function is, and will use
these to manage the function stack (particularly for codegen and
especially deopts).
Bug: v8:7700
Change-Id: I4e9b153f8cf4d06c56e7be6365e7a18b86a773c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585958
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80077}
Removes support for specifying weak handles with finalizers that allow
for object resurrection.
This CL removes the public facing APIs. Internal support will be
removed in a follow up.
Bug: v8:12672
Change-Id: Ia6ea269093aaa128caadb7508aca2e5a1254923c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596174
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80070}
As ecma262 normative change https://github.com/tc39/ecma262/pull/2683,
exception thrown on PromiseResolve the broken promises need to be caught
and use it to reject the promise returned by
`AsyncGenerator.prototype.return`.
AsyncGeneratorReturn didn't handle the exception thrown by Await. This
CL add an exception handler around it and pass through the caught
exception to the returned promise and resume the generator by
AsyncGeneratorAwaitResume if the generator is not closed, otherwise
reject the promise by AsyncGeneratorReject and drain the queue.
Bug: v8:12770
Change-Id: Ic3cac4ce36a6d8ecfeb5d7d762a37a2e0524831c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3581158
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#80066}
