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}
This makes it hopefully easier to add new operations and fixes
the current bug where we add new nodes (box/unbox/smitag/smiuntag)
that is not being used since the operation does not support a fast path.
Bug: v8:7700
Change-Id: I7ce33e44a4f8e63f42541a615fa72aa6e1b5cccc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605819
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80211}
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}
params.start was not set when marker was present, however the barrier
relies on params.start.
Bug: chromium:1029379
Change-Id: I12cfbdbdec63518cfc0d0d174085ea8aefb3a375
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605822
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80207}
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}
Port commit 4ae5a813c7
Change-Id: I2b4fccff6bf5266cd4cf9df45cabe3a19f29ab41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3609751
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#80205}
Add a simple unwinder for gdb which, on x64, walks frame pointers
whenever there is no source information available. Ideally we would only
do this for V8 PCs but this appears hard to do in an Unwinder without
messing with gdb's internal assumptions.
Change-Id: Iba1e62a3768340ee912e81d691237c1920a8ae91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608628
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80204}
If the following conditions hold:
1) value is kSentinel,
2) slot is on stack,
3) stack is allocated below 4GB,
then the generational barrier would be erroneously triggered for the
stack object object. This CL fixes it. At the same time, it aims to
simplify the code and potentially optimizes it (by having 'and' instead
of 'sub').
Bug: chromium:1029379
Change-Id: Iafd91d50b0a1c3d97647f7bf3643dfcc7e9fb48f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608629
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80202}
These can be tricked into corrupting memory when an attacker can leak
the "hole" value due to a bug. This CL simply adds CHECKs to prevent
this. A longer-term solution might be to introduce "special-purpose
holes" so that a leaked "hole" value can no longer be used to confuse
unrelated code like the JSMap implementation because that would then use
a different "hole" value.
Bug: chromium:1315901
Change-Id: Id6c432d39fb97002fa67efe90d34014fc5408ba3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3593783
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80201}
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}
Port 9145388055
Change-Id: I863c060cee8a0830a33594d8843898e40e7a71d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606619
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#80197}
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}
Port 9145388055
Original Commit Message:
This is a reland of commit 91da38831d
Original change's description:
> Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
> on arm64.
> Bug: v8:12161
Change-Id: I6e63bd5995340bac32654ef12c52d25b496140e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607997
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80194}
Change-Id: Idca60865da669dc90112eb04bdd464041fc447f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608119
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80193}
Add basic profiler support
- Moved profiling-related helpers to profiling.mjs
- Added bottom-up profiler table
- Added mini-timeline overview wit opt/deopt events and usage graph
- Added flame-graph, pivoted on the currently selected function
Drive-by-fixes:
- Added/updated jsdoc type information
- Fixed static symbols (builtins, bytecodehandlers) that were both
added by the CppEntriesProvider and from code-events in the v8.log
- Support platform-specific (linux/macos) dynamic symbol loader by
adding a query path ('/v8/info/platform') to lws-middleware.js
- added css var --selection-color
Bug: v8:10644
Change-Id: I6412bec63eac13140d6d425e7d9cc33316824c73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585453
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80192}
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}
ShadowRealm.prototype.importValue dynamically imports other files, so
the testing infrastructure need to look for these calls to gather files
to push to e.g. test devices.
The reason to do this over explicit Resources: comment lines is to also
cover test262.
Bug: v8:12829
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng
Change-Id: I6a06933d5da849157b2c7d5fa6b7b98d39f7d39f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606391
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80189}
.. since it's located in ReadOnlySpace and thus immutable. We could
extend this to other strings in RO-space but for now I want to avoid
too much movement. This bumps jetstream2/gbemu scores by ~30%.
Bug: v8:12790,v8:12161
Change-Id: I3fe10703e9ceca19c110d19c83143d811e090192
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607994
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80188}
For lazy compilation there is one generic lazy compilation builtin that
spills all registers on the stack and then triggers the compilation of
the called function. Some of these registers may contain references.
If a GC was triggered during lazy compilation, the GC would have to
know which spill slots on the stack contain references.
This CL adds a check to guarantee that no GC can be triggered during
lazy compilation. Thereby it is not necessary for the GC to know which
spill slots contain references.
If successful, lazy compilation indeed does not allocate on the heap
and therefore cannot trigger a GC. However, when compilation fails, an
error objects needs to be allocated and thrown. This allocation may
trigger a GC, but that's not a problem, because the reference
parameters which may get corrupted by the GC will not be used anyways,
because the called function will never get executed after the failed
compilation.
R=clemensb@chromium.org
Fixes: v8:11366
Change-Id: Ic526d169d4e80ba83f517970ff234e669f854331
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599474
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80187}
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}
.. since they may be written from background threads (for SP concurrent
codegen).
Bug: v8:12161
Fixed: chromium:1319857
Change-Id: I11860137ea4d79645821df69e61b62836f7c8283
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605818
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@{#80185}
... in DeserializeContexts.
Allocate the context before filling the scope info with the correct
variable name may cause DCHECK failure in TorqueGeneratedClassVerifiers::ScopeInfoVerify.
This CL changes the context variables serialization order from
"name, value, name, value" to "name, name... value, value...".
And only allocate and fill the context after setting up the correct
scope info.
Bug: v8:12832
Change-Id: I6e91aa867a528b7ffcae85de0f2364d0f9ea1bd7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607374
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#80184}
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}
This adds the implementation of the {AssemblerBufferCache} class.
PKU-protected memory is allocated via the {WasmCodeManager}, which has
access to the actual protection key.
R=thibaudm@chromium.org
Bug: v8:12809
Change-Id: Id26abd6f98248d5c646ae337ccb903d3e168bed1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3593137
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80181}
Other places use the {kSimd} bailout reason for bailouts because of
missing CPU support for SIMD. We should do the same when encountering
SIMD locals or parameters.
R=thibaudm@chromium.org
Change-Id: I7ea6ff32927a035cdafe437d581a79f67ff0b30f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605243
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80180}
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}
.. when deoptimization occurs after the outermost loop containing the
loop that triggered OSR compilation. The reasoning is that the main
benefit of OSR'd code is speeding up the OSR'd loop; the speedup of
the OSR'd loop is assumed to be higher than deoptimization overhead.
This is a slightly modified version of crrev.com/c/3521361, credit
goes to tao.pan@intel.com for most of the investigation and
implementation work.
Bug: v8:12161
Change-Id: Ie729dd5d1df9c7f529a1cf1b9471bb60ce76c41a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607988
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80177}
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}
