Add a variadic templated C++ union type similar to torque's unions,
which encapsulates a value that is one of a limited set of V8 types.
Tagged pointers to a Union type can be cast (casted?) to one of the
types in the Union in order to access that value, or indeed to a
sub-Union if necessary.
Unions are connected to their types using the `is_subtype` type_trait,
which is substantially expanded to keep working (in trivial cases)
when its types are only forward declared. The sub-type relation for
a Union and another type defines a partial order, as one would expect,
where:
1. Union<T...> is a subtype of U if all T are subtypes of U
2. U is a subtype of Union<T...> if for any T, U is a subtype of T
This type is used, initially, as follows:
1. Torque union types now generate a Union<...> instead of deferring
to the parent class
2. C++ defines typedefs for Number, Numeric, JSPrimitive, JSAny, and
JSCallable. Notably, Object is not (yet?) a Union of Smi and
HeapObject, as we need to decide what to do with the static
methods on the Object class.
3. Union<...> subsumes the UnionT<T,U> types in TNodes and
Turboshaft.
The bulk of the changes in this patch are propagations of types
necessary to satisfy newly strict requirements of torque-generated
functions (in particular, setters). There is also a partial progress on
making Object::NumberValue take a Number rather than an Object, as a
proof-of-concept for Number.
Change-Id: I87868f65eba43a3b5cbda6c0bf5e16e62a8225c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5600543
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94373}
RETURN_ON_EXCEPTION etc take a T parameter just so that they can return
a MaybeHandle<T> of the right type. However, we can already construct this
without knowing T, using kNullMaybeHandle.
Additionally, remove isolate->Throw<T>, which is distinct from
isolate->Throw, and differs only in the return type (null MaybeHandle
vs. exception sentinel).
Change-Id: I0f333c0140f96f4f5fa3372a9a4c736f863abfb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5594089
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94227}
... because we might update to a dictionary map. Instead, DCHECK that
the map isn't deprecated, and fix callers to first update the map.
Bug: 342456991
Change-Id: I8a966437d816c8e0200333c4068854432caf5729
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5588058
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94175}
Add capability to enable/disable linux perf collection from d8, by
passing in control file descriptors to d8 and perf via linux-perf-d8.py.
As an example usage, allow scoped collection which is started by
performance.mark and ended by performance.measure, which we can use to
scope e.g. JetStream measurements to just the measured part.
As a drive-by, change the top-level code in linux-perf-d8.py to be
wrapped in a function and a try-finally block, to make cleanup of
temporary files simpler.
Change-Id: If990000da3658f5658baffcb41ac2d049e8ae078
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5518451
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93734}
Add helpers for handling d8 flags:
* FlagMatches for boolean flag matching, with (optional) automatic
clearing of the argument from the args array
* FlagWithArgMatches for value flag matching, which encodes the
existing prefix matching logic and now additionally allows both
`--flag=arg` and `--flag arg`.
Change-Id: Ie321fcc061132be3ebeab171bb2a0ccda0f20819
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5518171
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93733}
... to also check if this is an optimizable function (i.e. one that is
either uncompiled or has bytecode available). This used to be captured
by allows_lazy_compilation, but that check excluded interpreted but not
lazily compilable functions.
Fixed: chromium:337906703
Change-Id: I718c73bcdf996107f997b86be3fe02df2aa3c2dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5501041
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93650}
... using the test helpers. A function that can't lazy compile can still
lazy allocate a feedback vector and tier up -- a concrete example is the
initializer function of a class.
This requires cleaning up other predicates around these functions to be
robust against not having exited early.
Change-Id: Ib32ccae64713fe358969c15b48433c18671e677b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5497159
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93639}
Looking up an operand by index previously required iterating over
operands, and adding together their sizes. Add a per-bytecode,
per-operand, per-scale lookup table which encodes each operand's offset
directly, avoiding the need for this iteration.
Change-Id: I732aa71a5be8aa1a3a0fb5d09b89b43c14972470
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5496955
Reviewed-by: Olivier Flückiger <olivf@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93635}
Remove the zero-initialized BaselineLabelPointer array, and replace it
with a lazy-initialized Label array, with a bitvector which stores both
the initialization state and the "indirect target" tag.
This is a three-fold optimisation:
* The zero initialization of the BaselineLabelPointer array was
surprisingly expensive, on local measurements (on Linux x64) almost
half as expensive as the actual compiling bytecode visit.
* Making this an array of Label instead of Label* removes one level of
indirection.
* The BitVector is more tightly packed than the tagged label pointers,
so the IsJumpTarget check should be cheaper.
Change-Id: Ib028526e87281c8f666142bab18358b059e2c617
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5492426
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93634}
Change VLQEncodeUnsigned from a loop that adds continuation bits, into
straight code writing the five bytes, with gotos jumping to the
appropriate number of bytes to write based on the value.
In particular, this avoids writing to the same location twice (once for
the value bits, once for the continuation bit), which also means we can
simplify the API to not require process_byte to return a pointer to the
last written byte.
This appears to be ~2x faster than the loop:
https://quick-bench.com/q/TPfnCwLsgDQz4hvUwdJk-pHPwVU
Change-Id: Ia732c0103a140ec5c72ea558dbd71952e98260df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5496956
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93624}
Add a CompileBackgroundBaseline scope to match the existing
CompileBaseline scope, and add a Compile[Background]BaselineBuild scope
to account the Build stage separately from generic CompileBaseline.
Bug: chromium:336000645
Change-Id: I17e0e6330a600354abf1898d0b771b9b17f442a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5492425
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93618}
It seems that clang can sometimes fail to analyze the iteration count in
the magic for loop used to implement IF/IF_NOT/ELSE. Move the EndIf
helper into a third iteration in the loop, so that the loop termination
condition becomes (even more) trivial to analyze.
Bug: chromium:332329850, chromium:332838433
Change-Id: I75d3526438a5d8aa8668fe6a5fc9c715bc6f5d4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5490090
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93610}
In the linux tickprocessor, allow finding symbols for system libraries
that were installed with `libfoo-dbgsym`, by reading off the build-id
from the library and looking for a debug file in /usr/lib/debug
This is particularly useful for libc, by installing
sudo apt install libc6-dbg
Change-Id: I595509fd8fb2115294f3b47f1e526bddb5f7094a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5476327
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93533}
* Return `start - 1` and use <=, since we want the last element
less-than-or-equal-to, not the first element greater than.
* Check for no match (start == 0 in this case, start == length with
the previous fix not applied), and return 0.
Change-Id: Id1b4b16fef884e59c7daf52011b2b2783532fef2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5473602
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93515}
ToLatin1Lower looks up a uint16_t value in a 256 valued array, under the
assumption that the uint16_t value is actually a one-byte character that
happens to be stored in a two-byte string (e.g. a one-byte SlicedString
with a two-byte parent due to externalization). Ensure that this table
lookup can't go out of bounds under heap corruption, by changing the
function to take a uint8_t and doing a DCHECKed truncate of the uint16_t
character to uint8_t.
As a drive-by, audit the surrounding code (e.g. ToLatin1Upper), and add
similar guards -- these won't do a similar table lookup currently, but
maybe they would in the future, and it's good to anyway be consistent
and explicit about this.
The regression test requires support for the memory corruption API in
mjsunit (in particular, to skip tests if the API isn't there), so add
that too.
Fixed: chromium:335810507
Change-Id: I0e5d3ca31dda3bd4ce4dc03c3a2a802290489f2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5471973
Reviewed-by: Samuel Groß <saelo@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93502}
DefineOwnProperty (via DefineOwnIC) should not call the setter of an
existing accessor property, but overwrite the entire property. We
therefore need to make sure that we don't install an accessor handler on
the IC.
Fixed: chromium:332745405
Change-Id: Ie4ae908a581139777db5b5775a3201c495a46690
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5465512
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93442}
Identical code folding can cause external references to be de-duplicated
(e.g. merging memcpy and memmove). This is ok, as long as the same
functions are folded both in the serializing and deserializing binaries.
If the serializing binary merges two functions that the deserializing
binary didn't, then the snapshot deserialization will get the wrong
function reference. This can happen due to whole program optimization of
the snapshot serializing binary.
We can prevent this by disabling ICF for snapshot generation, ensuring
that there are no duplicate references when generating the snapshot.
It's ok for the mismatch to be in the opposite direction, i.e. for the
deserializing binary to have merged functions that the serializing
binary didn't, so this is a safe operation and doesn't affect the
shipped binary.
This also adds a small section to the start of the startup snapshot
which lists all duplicate external reference table entries. The
deserialization verifies that duplicates stayed duplicated. This allows
us to support some duplication in the serializing binary as long as
there is matching duplication in the deserializing binary -- this will
be the case, for example, if the serializing and deserializing binary is
the same (e.g. in tests, or in node with --binary-snapshot).
Bug: chromium:41321762, chromiun:327245456
Change-Id: If19584d19307bec5ea4d8b6a511151593d101988
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5447267
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93396}
With the LOGGING VMState, we might overwrite the GC VMState (if e.g. we
are logging a move event). This is a problem in the profiler, which was
avoiding doing deep analysis of samples in GC, since the pointers it
would look at could be invalid during evacuation.
Use the heap's recorded gc_state in addition, which is more precise than
the VMState and won't be clobbered by VMState changes. We still need the
VMState check though, since some parts of GC (e.g. heap verification)
are outside the "in-GC" state.
Bug: v8:14713
Change-Id: I756cc8f4d402effc12492b5a3c436bd2ba111a3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5439416
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93358}
... and check that V8_TARGET_OS_ANDROID in V8 matches that in the
embedder -- this is necessary for cross-os shapshot generation (e.g.
generating android snapshots from linux).
Bug: chromium:329104605
Change-Id: I894cc1dd6921865739784e6ac08a32a924a1ad10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5445547
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93326}
This fixes an issue where performance.measure slices had incorrect
timestamps when running with perfetto (the legacy tracing used
microseconds, while perfetto uses nanoseconds, and we were passing in an
int64_t without units).
Change-Id: I42bec62fb350bd2090ed12b3b0db111625ff03f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5435116
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93259}
A function that doesn't have baseline code, but is marked as
sparkplug_compiled, should be considered as-if having sparkplug for the
purposes of NotifyICChanged (since it will have sparkplug soon, and the
interrupt budget is now for the next tier-up).
Bug: chromium:332947111
Change-Id: I6c9f2f382b08b80b22e65685cd64a6cbc5b4e8d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5435075
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93255}
We currently reset the interrupt budget on IC change, to delay tier up
until functions have stable feedback.
Sparkplug, however, doesn't need feedback to tier up. In most cases, we
won't have a feedback vector while waiting to tier up to Sparkplug, so
this mechanism works (no IC changes are observed at all with no feedback
vector), but if a feedback vector is installed early (e.g. because of
logging), this mechanism will delay Sparkplug tier-up.
Fix this by bailing out early in NotifyICChanged for interpreted
functions that can tier up to Sparkplug.
Change-Id: Ib10e39b9a258004e4822d9dc40cda4f2527f2a98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5424290
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93168}
In profview:
* Add support for Maglev and Sparkplug in the summary view, with
Maglev replacing Turboprop (which is long gone).
* Include Sparkplug, Maglev, and Maglev deopts in the function
timeline (with appropriate colours matching the legend).
* Add dependency group deopts to the deopt kinds, so that we can see
lazy deopts that discarded code which wasn't on the stack.
* Remove soft deopts and bailouts, which no longer exist.
Additionally, log the specific dependency leading to a dependency deopt,
rather than the generic "code dependency" message.
Change-Id: I0dacd6f53cce4c16f50960da7464623a45347668
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5419180
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93147}
Remove the concept of individual frame singletons in the stack iterator,
replacing it with a union over the different frame types. This reduces
the stack size of the stack iterator (which is important for profiling
stack iterators that have a small stack in the signal handler).
This requires in-place initialising the frame when setting it, which in
turn requires updating code which thinks it can call SingletonFor
without mutating the current frame. So, remove SingletonFor entirely,
making it clear that this is a frame initialisation, and clean up the
code that (mis)used it.
Change-Id: I26b010415334ec6ae8c70ed10e828a19547d2470
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5412661
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93120}
This reverts commit 1b4d48e4d7.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20css%20-%20debug/7060/overview
Original change's description:
> Reland "[heap] remove empty space from executable MemoryChunks"
>
> This is a reland of commit a800f7dcb0
>
> Changes: implemented support in ObjectStartOffsetInCodePage for the
> case where kCodeAlignmentMinusCodeHeader < sizeof(MemoryChunk).
>
> Original change's description:
> > [heap] remove empty space from executable MemoryChunks
> >
> > Since the metadata moved out, we can fix up the data offsets and
> > allocate data right after the header. Since the headers become
> > executable now for code MemoryChunks, we need to add write scopes to
> > MemoryChunk initialization and flag writes.
> > I split the SetFlag functions into three variants for this:
> > * SetFlagNonExecutable for chunks that are never executable and don't
> > need unlocking (e.g. new space chunks)
> > * SetFlagUnlocked for when the code space is already unlocked
> > * SetFlagSlow which will do the unlocking but comes with a perf impact.
> >
> > Change-Id: I7d6854337ccdd56670cd6bd549956b6c9fe6f9e9
> > Bug: v8:13355, chromium:40849120
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5361037
> > Commit-Queue: Stephen Röttger <sroettger@google.com>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#92926}
>
> Bug: v8:13355, chromium:40849120
> Change-Id: I7668ebd30ead660e6f821ce21b7c371c9e1dc087
> Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_no_pointer_compression_dbg
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5378292
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Stephen Röttger <sroettger@google.com>
> Cr-Commit-Position: refs/heads/main@{#92935}
Bug: v8:13355, chromium:40849120
Change-Id: I974e55b355d47b12c9b5635ac4644859a7c5dcbd
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_no_pointer_compression_dbg
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5383471
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#92940}
Two micro optimisations for for-in loops:
* JumpIfForInDone replaces ForInContinue+JumpIfFalse. ForInContinue
was only ever used for exiting the loop anyway, so now it's explicit
and unoptimised tiers don't need to materialise the boolean.
* ForInStep <reg> mutates its register instead of writing to the
accumulator. It was anyway always followed by a Star to the same
register, so may as well skip the middle step.
This requires two changes to the bytecode compiler:
* Add support for Jumps with other scalable operands than just the
jump offset (this affects how constant pool entries for long jumps
are reserved).
* Add support for in-out Reg operands.
Change-Id: If8c3bbf7524af9502b40af2b1a715389fb13210b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5353508
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92901}
This is a reland of commit 84993aa80b
Fixes the attributes in the transition search to not be NONE.
Original change's description:
> [object] Fast path for adding props with existing transition
>
> Add a fast path to AddProperty/CreateDataProperty, which first searches
> the transition array for an existing transition. If a transition exists,
> we can skip a bunch of checks around whether the property already exists
> and is writable.
>
> Change-Id: I57dd37bb9fe649755e972a469cb53163c34faf8f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5342763
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#92683}
Change-Id: Icf03e2a72c847a764bd5900bdb1be19acd774247
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5378402
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92889}
Add a fast path to AddProperty/CreateDataProperty, which first searches
the transition array for an existing transition. If a transition exists,
we can skip a bunch of checks around whether the property already exists
and is writable.
Change-Id: I57dd37bb9fe649755e972a469cb53163c34faf8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5342763
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92683}
Extract the fast -> slow path iteration logic in BuildJsonObject to a
helper on JSDataObjectBuilder which iterates an iterator provided by
BuildJsonObject. This moves the complexity of switching between fast and
slow property initialisation into the helper, and the only thing the
iterator has to do is allow re-visiting the values visited in the fast
path.
Change-Id: I8f567d284c8b537d9f9d986128ffba3d2da09289
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5321529
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92564}
Removing END_IF caused a binary size regression; recover this by:
a) Storing the state in an `if` wrapping the `for`, so that clang's
loop unrolling is able to detect the fixed iteration count,
b) Forcing the unrolling of the two iteration IF loop with a pragma
(this causes a compile-time error if it fails to unroll, and the
unrolling is necessary for eliminating the various iteration
checks),
c) Re-introducing helper methods that operate on the state, which
are allowed to not be inlined.
Change-Id: I9eb647c85e43ea70990cab0c355b9cd699c2f108
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5318121
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92558}
This reverts commit f6fbef25f1.
Reason for revert: Blocking roll (https://chromium-review.googlesource.com/c/chromium/src/+/5318237?tab=checks)
Original change's description:
> [maglev] Inline the TypedArray.prototype.length accessor
>
> TypedArray.prototype.length returns the integer length of the
> TypedArray. We can inline this getter into a simple field load for
> non-resizable typed arrays.
>
> This unfortunately requires expanding the IntPtr representation to be a
> "first-class" representation in the graph, with all the conversions,
> since it can now appear as an arbitrary value in the graph and not only
> an input into bounds checks. To keep things explicit about the value range
> of this representation (0 ≤ value ≤ max_safe_int), rename it to
> TypedArrayLength.
>
> Drive-by fix BuildLoadTypedArrayLength to bail out fully on RAB/GSAB,
> since even the uncached LoadTypedArrayLength is still unsafe.
>
> Bug: v8:7700
> Change-Id: Iad010d65f1c1ac41627abf45fe7a4f3838e34581
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5257837
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#92482}
Bug: v8:7700
Change-Id: I8fc75db4054a06114ed2ef653fdbf9afd1472f04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5319675
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92505}
TypedArray.prototype.length returns the integer length of the
TypedArray. We can inline this getter into a simple field load for
non-resizable typed arrays.
This unfortunately requires expanding the IntPtr representation to be a
"first-class" representation in the graph, with all the conversions,
since it can now appear as an arbitrary value in the graph and not only
an input into bounds checks. To keep things explicit about the value range
of this representation (0 ≤ value ≤ max_safe_int), rename it to
TypedArrayLength.
Drive-by fix BuildLoadTypedArrayLength to bail out fully on RAB/GSAB,
since even the uncached LoadTypedArrayLength is still unsafe.
Bug: v8:7700
Change-Id: Iad010d65f1c1ac41627abf45fe7a4f3838e34581
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5257837
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92482}
trigger a substitution failure -- fix TaggedArrayBase to use this
correctly (including adding an additional intermediate dependent
typename as necessary).
std: :enable_if needs to access the actual enabled_if<...>::type to
Change-Id: Icedf23fbcdf97e4fe650acc29a65614d9cad2625
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5309894
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92427}
Introduce MaybeWeak<T> as a weakness sentinel type, representing a value
in a Tagged<>/Handle<>/TNode<> which can be weak. This fulfils the role
of MaybeObject in a more generic way, and indeed MaybeObject becomes a
typedef for MaybeWeak<Object>. The methods on MaybeObject and
HeapObjectReference become free functions, or are removed entirely in
favour of implicit conversions (after all, any strong ref is also a
maybe weak ref).
This requires a few new specializations of Tagged, and some additional
conversion logic. This CL is designed to be minimally invasive,
converting MaybeObject to Tagged<MaybeObject> but trying to use the
typedef and TaggedImpl methods as much as possible to minimise
non-trivial code changes. In the future, we'll want to add a distinct
Weak<T> for definitely weak values, and have conversions from
Tagged<MaybeWeak<T>> to Tagged<T> that don't erase the type.
Bug: v8:12710
Change-Id: I1b5df70b3d2028d46a09ca2cd9bd894a3fd8cb27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5268603
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92409}
Previously, the IF/ELSE_IF/ELSE macros were implemented as separate
single-iteration for loops, which communicate via pushing/popping off an
if stack, and require an explicit END_IF to terminate them (since we
don't know ahead of time if an IF needs and ELSE).
Now, they are implemented as an if-else in a single two-iteration for
loop, which wraps both IF and ELSE, allowing the for loop to maintain
state and handle teardown, removing the need for an if stack or an
END_IF macro. Notably, ELSE_IF becomes a separate ELSE and IF (similar
to C++ semantics), with the inner if nested inside the outer else.
Additionally, clean up clang formatting of ELSE to not introduce a new
line.
Change-Id: I41705c5550b6fdcae6150d89a2c499bd855c743f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5272318
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92405}
Move the initial object initialization loop from JsonParser to
JSDataObjectBuilder. This means that:
* Object creation now takes an iterator over existing values -- it's
up to the caller to preserve values between the initial fast loop
and the object initializer (e.g. the value serializer keeps a vector
of values, the JsonParser can use the property stack but needs to
skip over index properties).
* The handling around reusing HeapNumbers as mutable HeapNumbers in
double fields is abstracted into JSDataObjectBuilder, as an
additional configuration option.
Change-Id: Icc39a42e8040d1891d4a740c4cbc3b1573ecdce0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5237383
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92168}
* Don't search the ObjectLiteralMap cache if we have an expected map --
only search it if we need to rewind back to a map with zero properties
(i.e. an expected map miss on the first property).
* We can still emit transitions to data properties even if there is an
existing transition to an accessor property; stop differentiating
between these two kinds of found maps, and always try to create a new
transition on the fast path.
* FindTransitionToDataProperty is only ever used for
FindTransitionToField, and data properties can only ever be fields
(ever since we removed constant data in descriptors). Merge these two,
and furthermore specialize FindTransitionToField for Strings rather
than generic Names since that's all the uses anyway. Use this instead
of using SearchTransition directly.
* Get rid of next_map_ -- we only needed it for allowing rewinding to
the current map when the current map had zero properties, and this is
done by looking up in the ObjectLiteralMap cache now, so we can just
have local handles for the next target and a single `map_` field.
* Make the expected map, expected properties, and elements kind
initialisation all happen in the same place (the constructor), so that
there's no weird ordering requirements on the method calls.
Change-Id: I17083b978997263533fe22ac7690812f08161341
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5237040
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92167}
Fix the documentation DCHECK that enum caches stay owned by the old map
chain (rather than moving ownership to the new map chain) by actually
caching the enum cache, rather than trying to mess around with old
descriptors and the complexity that integrity transitions add.
Fixed: chromium:1523713
Change-Id: Ib9f440d41fe9aaf214b29676f6cebed6fac2b766
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5259301
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92166}
... that was deopting because of empty indices. Also fix the empty
indices check to check against the empty fixed array root instead of
loading the length.
Bug: v8:7700
Change-Id: Iadd89bc8b817732028464118b1cbef3ee5323e70
Fixed: chromium:1523798
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5258918
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92158}
The enum cache indices in the descriptor array may get cleared if the
descriptor array is extended with an accessor, but this doesn't
invalidate the old enum cache indices, so we can cache these across the
for-in.
Bug: v8:7700
Change-Id: I472884d3ce127f5a54429c76342e5b6e78e4d372
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5250230
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92118}
Allow the JSDataObjectBuilder to create maps, rather than bailing out if
a transition isn't found, to stay on the fast path (with fast object
initialisation) a bit more often.
Change-Id: I7e6845232e485532755e37f3df6912a165615a81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5228677
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91998}
Factor out the map-walk and allocation folding parts of fast object
initialisation logic in the JSON parser to a few helper classes. In
the future, we can share this with other fast object initialisations
(e.g. the value serializer), and centralise any optimisations (e.g.
staying on the fast path while allocating new maps).
Change-Id: I8cae65c139ea3eb1e5dcc7ba0f99f93c885279e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5224681
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91991}
1. Avoid advancing LookupIterator iteration (e.g. after a successful
access check) with `break` out of the switch over states. This gets
confusing vs. a `break` out of the loop, and looks like we want to
stop iterating rather than continuing.
Instead, use `continue` and `return` inside the handling cases, and
make breaking out of the switch `UNREACHABLE()`.
2. As part of this, treat NOT_FOUND handling like any other lookup
handling, rather than as a bailout from the LookupIterator iteration.
This means replacing `for (; it.IsFound(); it.Next())` loops, with
`for (;; it.Next())` loops, that can only be broken out of with a
`return` or an explicit `break` (explicit breaks should be avoided
because of the `switch` issue above).
3. Rename INTEGER_INDEXED_EXOTIC to TYPED_ARRAY_INDEX_NOT_FOUND -- this
state was only used for a not-found on integer-indexed exotics, which
are only TypedArrays, so be explicit here.
4. Document the different LookupIterator states.
5. Clean up OrdinaryDefineOwnProperty to remove an unnecessary overload
(which was just splitting the logic over two functions), to avoid an
unnecessary loop looking for interceptors, and to avoid an
unnecessary iterator restart when such an interceptor is not found.
Change-Id: Ifdbabe2e4d4a264ec10210c443760f333c9f3798
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5205671
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91960}
This also allows us to drop PrimitiveHeapObjectLayout and make
PrimitiveHeapObject a layout class.
Two small drive-bys driven by this:
* BigInt digits access is simplified, with the Digits class getting a
bit more const correct.
* Float64 field accesses (into mutable HeapNumber) are changed to be a
ForHeapNumberValue FieldAccess with tweaks, rather than tweaking
the previous FieldAccess.
Bug: v8:12710
Change-Id: I8cbf8eecf323d154d67ea768be1f508047d68fb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5148171
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91930}
Should make them easier to read. Right now the source location is
wherever the comment is created -- in the future, for trivial functions,
we could also make trivial functions (e.g. DecompressTagged) pass
through a source location from their caller.
Change-Id: I74b971d1a81bd3fde5045a6872a33f938e834325
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5189468
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91804}
Because of compiler limitations with the flexible array member
extension, in particular around subclassing, introduce a new macro which
defines the flexible array members. This also requires accessing
flexible array members using a macro, rather than with offsetof.
Bug: v8:12710
Change-Id: Ibf8ae9b20bb1a83be7374e439bff484914d7bad1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5148173
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91765}
TypedArray lengths can be larger than Uint32 on 64-bit arch, so we need
the value representation to be IntPtr rather than Uint32. Change Maglev
to have an IntPtr representation instead of a Word64 one, and use this
for TypedArray length checks.
Bug: v8:7700
Change-Id: I8c1fa227f4568aa98e32516f0bbf2dc9561404ec
Fixed: chromium:1516871
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5184218
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91756}
Unify the deopting and non-deopting Load/StoreTypedArrayElement by
making the detached check a separate node. This allows us to
a) Potentially eliminate the check if we've already checked earlier
and there have been no side effects,
b) Check for detached _before_ loading the length, in case some future
code using that no-longet-valid length could have caused trouble.
Bug: v8:7700
Change-Id: I12d390d12fbd3215f781077cc23ca4c8fc783323
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5176948
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91735}
Instead of emitting layout asserts in generated *-tq.h and *-tq-inl.h
files, which might get forgotten and get pulled in for every use of
those headers, emit them in *-tq.cc files. This has two advantages:
1. They are no longer opt-in, so _all_ types with both torque and C++
layouts get asserted (this caught a bug in BytecodeArray!)
2. They no longer need to be templated, because they're not being
defined before the object definition. This will surely make the
compiler happier.
Bug: v8:12710
Change-Id: I630495739c422e1ba89ce78cb218379d858f54cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5163948
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91730}
... when accessing it via `data()`.
As a drive-by, clean up DiscriminatedUnion to operate on the storage
array directly (as a pointer), rather than the address of the storage
(functionally equivalent, but harder to reason about).
Bug: v8:7700, chromium:1511651
Change-Id: Id91b956091a01abe39f7adbf27093a29bbb8ef8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5177008
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91721}
... and use it when getting a Uint32 value from another constant.
This avoids a bunch of CheckedInt32ToUint32 in gaussian-blur.
Bug: v8:7700
Change-Id: I1a8a6d8843dbeabcfa5b8652d0bea0b1989276ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5172601
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91708}
Non-resizable TypedArrays can't change length, so we can cache loads of
their length (for bounds checks) as a constant property.
Since properties are cached by name, and users can overwrite "length"
on a TypedArray, this additionally introduces a mechanism for using
a non-Name value as the key into the properties cache.
Bug: v8:7700
Change-Id: I59e74ed7fdc5929d2de7146ee4d36b14ef35808e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5172594
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91707}
Shifts by a constant can shift by an immediate. As a drive-by, make
bitwise and shift operation definition a bit more uniform across
architectures.
Bug: v8:7700
Change-Id: Id79d856722b7932eedfe12239e774ff0b1e44266
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5172596
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91694}
Split GetOwnFastDataProperty into GetOwnFastConstantDataProperty and
GetOwnFastConstantDoubleProperty (where the former is not allowed to be
used on double representation fields). This allows callers to get the
raw double value of a double-representation field, without needing to
allocate a new HeapNumber for the value.
Change-Id: I0d691730b922c5409439d3638021d6f409e5a0ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5169845
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91688}
Add an explicit TSAN suppression for the racy read of HeapNumber bits
when reading a constant field from the heap. This is a benign race, as
we explicitly add a dependency on constness (thus any reads that race
with a write will also invalidate that dependency), but we don't want to
suppress it by pretending to do a relaxed atomic read, since this read
isn't actually atomic (HeapNumber values are unaligned and not readable
atomically).
Fixed: v8:14526
Change-Id: Id09f1928be01f5075dac22fc595c8ec65074f70b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5165451
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91676}
Checkpoints created during deopt frame scopes are no longer valid after
the scope finishes, so clear the latest checkpoint. This is slightly
pessimistic, as the latest checkpoint could have been created before the
scope, but it probably doesn't matter.
Bug: chromium:1511651
Change-Id: If113c9d6f50a450bb79d74cdd98a3d5588c85e02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5163868
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91661}
We can't atomically load or store HeapNumber values, because they are
stored unaligned under pointer compression. However, the methods are
marked "relaxed", with value_as_bits doing an actual "Relaxed_Memcpy",
to silence TSAN warnings.
However, this doesn't make the read/write an actual relaxed atomic
load/store -- furthermore, the actual writes to the value (not "as
bits"), as generated by torque, still use the non atomic WriteField
helper.
Removing all this and using non-atomic loads seems to still pass the
regression test added in https://crrev.com/c/2996201, so it seems to
be unnecessary.
Bug: chromium:1224277
Change-Id: Ic8558d4c58b08a0280266937e7ac88aa70fe3220
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5145369
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91623}
A strict reading of the offsetof spec reveals that the result has to be
an integral constant, which means in particular the member access can't
include a runtime index. Most compilers seem to be permissive here, but
gcc 11 got stricter and requires the index to be an integral constant
too. We have one case of such code now failing with gcc (getting the
offset of a string character by index) -- change it to explicitly add
the index.
See also:
* Node issue exposing this:
https://github.com/nodejs/node-v8/issues/277
* GCC bug explaining the change:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
Change-Id: I5820432595bd8df7e1d7e239979db1ab506ce901
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5143447
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91618}
Make Name/String/Symbol subclasses of HeapObjectLayout.
This introduces:
* Explicit pragmas forcing 4-byte packing of V8_OBJECT classes -- this
was required for Name under no-pointer-compression builds, which
has a tagged map ptr + int32 field and so would be padded at the
end, for alignment of the map ptr.
* A member type for external pointers
* A differentiation in torque between CC and CCDebug macro lists, to
avoid emitting C++ code for slice macros
* An UncachedExternalString base class for ExternalString which
doesn't have the resource data pointer
* The use of flexible array members to represent variable length
suffixes of classes (in particular, SeqString characters)
* Helper macros for inner classes of object classes, which suppress
the padding warnings
Also, as a drive-by, accessors were changed to not use the cage_base,
since this is available now as a global/thread local, and cleaned up
various callers of these accessors to also not take a cage base or
isolate if not neccessary.
Bug: v8:12710
Change-Id: I15b6393d94e24f5a4fb5d7b363e88974ac1c33b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5077926
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91598}
Leszek Swirski