This CL migrates a large number of handles to direct handles. The
changes are only relevant for builds with v8_enable_direct_handle=true.
Affected directories: test.
Bug: 42203211
Change-Id: Ie9fb3d5b3c66ea9ffa0092d928256aa3891c9a9a
Cq-Include-Trybots: luci.v8.try:v8_linux64_css_dbg
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5622011
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94378}
This CL migrates a large number of handles to direct handles. The
changes are only relevant for builds with v8_enable_direct_handle=true.
Affected source directories: ast, baseline, codegen, compiler, d8,
diagnostics, extensions, ic, init, interpreter, logging, maglev,
parsing, profiler.
Bug: 42203211
Change-Id: I3ca12892acfe45f8458d19aa4cbd56ad01842c0a
Cq-Include-Trybots: luci.v8.try:v8_linux64_css_dbg
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5615411
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94363}
This CL migrates a large number of handles to direct handles. The
changes are only relevant for builds with v8_enable_direct_handle=true.
Affected source directories: asmjs, builtins, compiler-dispatcher,
heap, json, numbers, regexp, runtime, snapshot, strings.
Bug: 42203211
Change-Id: Id0e6e17a1ef45e3a98905db927c4836e9a640ccf
Cq-Include-Trybots: luci.v8.try:v8_linux64_css_dbg
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5604486
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94332}
This CL migrates a large number of handles to direct handles. The
changes are only relevant for builds with v8_enable_direct_handle=true.
Affected source directories: api, builtins, debug, deoptimizer,
execution, objects, utils, wasm.
Bug: 42203211
Change-Id: Ic8422835c8e4db849084071fb124b03b2bc34f25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5601391
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94285}
Since https://crrev.com/c/5563331, parking background threads in the
context of conservative stack scanning is safe in general, and not
only for blocking. This CL renames the methods used for this purpose,
from "Block*WhileParked*" to "Execute*WhileParked*".
Bug: 41480448
Change-Id: Icdf0092463956d61bbc8e63e1665348efc40f03f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5568813
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94152}
This is a reland of commit 239f4e587f
Original change's description:
> [heap][handles] Revise parking invariants for direct handles
>
> Until now, when parking a background thread, a DCHECK would fail if
> the thread's stack contained direct handles, practically allowing
> only limited use of direct handles in background threads. With
> https://crrev.com/c/5331543, the stacks of parked background threads
> are correctly scanned (in builds with conservative stack scanning
> enabled) and therefore this restriction can now be eliminated.
>
> This CL:
>
> - allows unrestricted use of direct handles in background threads;
> - revises the methods and scopes for parking threads, to make sure
> that the trampoline is entered every time a thread is parked and
> the stack marker is set and reset appropriately;
> - disallows explicit use of ParkedScope; and
> - updates tests that used the previous logic.
>
> Change-Id: Ia01343d5685cfe4537202e8940bf0cd7d614d8fc
>
> Bug: 41480448
> Bug: 42203211
> Change-Id: Ia01343d5685cfe4537202e8940bf0cd7d614d8fc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5563331
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#94134}
Bug: 41480448
Bug: 42203211
Change-Id: I41fb38bf3ded433556735e0e957f1daca9ac3ab5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5575092
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94146}
Until now, when parking a background thread, a DCHECK would fail if
the thread's stack contained direct handles, practically allowing
only limited use of direct handles in background threads. With
https://crrev.com/c/5331543, the stacks of parked background threads
are correctly scanned (in builds with conservative stack scanning
enabled) and therefore this restriction can now be eliminated.
This CL:
- allows unrestricted use of direct handles in background threads;
- revises the methods and scopes for parking threads, to make sure
that the trampoline is entered every time a thread is parked and
the stack marker is set and reset appropriately;
- disallows explicit use of ParkedScope; and
- updates tests that used the previous logic.
Change-Id: Ia01343d5685cfe4537202e8940bf0cd7d614d8fc
Bug: 41480448
Bug: 42203211
Change-Id: Ia01343d5685cfe4537202e8940bf0cd7d614d8fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5563331
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94134}
This CL migrates some string and error message handles, most of
them passed as parameters to error message generation methods,
to direct. (This is only relevant for builds with
v8_enable_direct_handle=true.)
Bug: b/42203211
Change-Id: I8bc7858459049ddb8c7ce5eec878b3f5f03e9931
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5510684
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93758}
This CL introduces DirectHandleVector<T> for implementing vectors of
direct handles. Such handles must normally be stack-allocated, so a
special vector type is required that correctly registers its backing
store as strong roots. The new type is then used for migrating the
vector of handles that is used in shared heap deserialization.
The CL also revises and simplifies the StrongRootAllocator.
This is only relevant for builds with v8_enable_direct_handle=true.
Otherwise, this vector type simply uses std::vector.
Bug: v8:13270
Change-Id: Ic0eb3be4548ccf0942cf38cd92cee06cded48b7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5458560
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93599}
This is a reland of commit 24094ac73e
Original change's description:
> [handles] Migrate handles in the string table to direct
>
> This CL migrates most handles in the string table that is used for
> string internalization to direct. (This is only relevant for builds
> with v8_enable_direct_handle=true.)
>
> Bug: v8:13270
> Change-Id: Idbb5edaef5988f71c9716d248a8d163f39929948
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5454407
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#93400}
Bug: v8:13270
Change-Id: I4fac78f77af0c0440056cb380b082be7b1bc8bbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5476489
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93570}
This is a reland of commit 440a698edf
Original change's description:
> Reland "[handles] Migrate most handles in string builders to direct"
>
> This is a reland of commit 2cb6341677
>
> Original change's description:
> > [handles] Migrate most handles in string builders to direct
> >
> > This CL migrates most Handle<String> in string builders and related
> > classes to DirectHandle<String>. (This is only relevant for builds
> > with v8_enable_direct_handle=true.) In particular, the classes that
> > are affected are:
> >
> > - FixedArrayBuilder
> > - ReplacementStringBuilder
> > - IncrementalStringBuilder
> > - CircularStructureMessageBuilder
> >
> > In addition, the CL:
> >
> > - Introduces the helper function indirect_handle, which can be used
> > to explicitly convert a DirectHandle<T> to a Handle<T> if necessary
> > (similarly for "maybe" handles).
> > - Updates the `RETURN_ON_EXCEPTION_VALUE` family of macros to allow
> > for direct, as well as indirect handles.
> > - Implements DirectHandle<T>::PatchValue, which is equivalent to the
> > assignment of handles.
> >
> > Bug: v8:13270
> > Change-Id: I88d92645af2a620c9c5216f9aa723bd98d8caa90
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5445083
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> > Reviewed-by: Omer Katz <omerkatz@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#93389}
>
> Bug: v8:13270
> Change-Id: I1512f562d9a6f871ae17beb008084de1a5b87383
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5476488
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#93537}
Bug: v8:13270
Change-Id: I81edafc9d4223713bc76e5a81ad9670b68d728f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5481650
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93560}
This is a reland of commit 2cb6341677
Original change's description:
> [handles] Migrate most handles in string builders to direct
>
> This CL migrates most Handle<String> in string builders and related
> classes to DirectHandle<String>. (This is only relevant for builds
> with v8_enable_direct_handle=true.) In particular, the classes that
> are affected are:
>
> - FixedArrayBuilder
> - ReplacementStringBuilder
> - IncrementalStringBuilder
> - CircularStructureMessageBuilder
>
> In addition, the CL:
>
> - Introduces the helper function indirect_handle, which can be used
> to explicitly convert a DirectHandle<T> to a Handle<T> if necessary
> (similarly for "maybe" handles).
> - Updates the `RETURN_ON_EXCEPTION_VALUE` family of macros to allow
> for direct, as well as indirect handles.
> - Implements DirectHandle<T>::PatchValue, which is equivalent to the
> assignment of handles.
>
> Bug: v8:13270
> Change-Id: I88d92645af2a620c9c5216f9aa723bd98d8caa90
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5445083
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#93389}
Bug: v8:13270
Change-Id: I1512f562d9a6f871ae17beb008084de1a5b87383
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5476488
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93537}
This reverts commit 2cb6341677.
Reason for revert: Colprit for https://g-issues.chromium.org/issues/335397250 Blocks cutting RC branch of Chromium
Original change's description:
> [handles] Migrate most handles in string builders to direct
>
> This CL migrates most Handle<String> in string builders and related
> classes to DirectHandle<String>. (This is only relevant for builds
> with v8_enable_direct_handle=true.) In particular, the classes that
> are affected are:
>
> - FixedArrayBuilder
> - ReplacementStringBuilder
> - IncrementalStringBuilder
> - CircularStructureMessageBuilder
>
> In addition, the CL:
>
> - Introduces the helper function indirect_handle, which can be used
> to explicitly convert a DirectHandle<T> to a Handle<T> if necessary
> (similarly for "maybe" handles).
> - Updates the `RETURN_ON_EXCEPTION_VALUE` family of macros to allow
> for direct, as well as indirect handles.
> - Implements DirectHandle<T>::PatchValue, which is equivalent to the
> assignment of handles.
>
> Bug: v8:13270
> Change-Id: I88d92645af2a620c9c5216f9aa723bd98d8caa90
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5445083
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#93389}
Bug: v8:13270
Change-Id: Idbdf93343ecd4237d86b723be7cd241c7cad51b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5463844
Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Ilya Rezvov <irezvov@chromium.org>
Owners-Override: Ilya Rezvov <irezvov@chromium.org>
Auto-Submit: Ilya Rezvov <irezvov@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93447}
This CL migrates most handles in the string table that is used for
string internalization to direct. (This is only relevant for builds
with v8_enable_direct_handle=true.)
Bug: v8:13270
Change-Id: Idbb5edaef5988f71c9716d248a8d163f39929948
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5454407
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93400}
This CL migrates most Handle<String> in string builders and related
classes to DirectHandle<String>. (This is only relevant for builds
with v8_enable_direct_handle=true.) In particular, the classes that
are affected are:
- FixedArrayBuilder
- ReplacementStringBuilder
- IncrementalStringBuilder
- CircularStructureMessageBuilder
In addition, the CL:
- Introduces the helper function indirect_handle, which can be used
to explicitly convert a DirectHandle<T> to a Handle<T> if necessary
(similarly for "maybe" handles).
- Updates the `RETURN_ON_EXCEPTION_VALUE` family of macros to allow
for direct, as well as indirect handles.
- Implements DirectHandle<T>::PatchValue, which is equivalent to the
assignment of handles.
Bug: v8:13270
Change-Id: I88d92645af2a620c9c5216f9aa723bd98d8caa90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5445083
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93389}
So far, string builders were defined in string-builder-inl.h and
implemented in string-builder.cc, while there was no string-builder.h
file. This CL splits the header file in two parts, as is usual. It also
cleans up the implementation of CallPrinter, which was unnecessarily
complicated because of the rule about not including -inl.h files in .h.
Change-Id: I2d718d510ead43f7811b5efc3a005c35ad9b7e7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5443843
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93382}
Previously, in DEBUG builds, FindImplicationByName could fail in the
event that an implication involving comparison operators is used,
such as "--max-opt 1". The implication "max_opt < 2" would fail to
match with the correct Flag, and a DCHECK asserting that the found
flag name matches the implication flag would fail.
This CL fixes the issue by allowing for suffixes such as the above,
when looking up flag implications. It works correctly as long as the
flag with the suffix compares against other flags exactly as the flag
without the suffix would compare. This is necessarily true if the
suffix in implications begins with a space, e.g., "max_opt < 2", which
is exactly what currently happens in our flag definitions.
Change-Id: I310945ca283a6dce241c5626a0a1cc2d86dc9243
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5438116
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93294}
This CL removes a redundant call to `IterateBackgroundStacks` that
existed in `IteratePointersUntilMarker`. This had resulted in a nested
`SuspendTagCheckingScope`, which crashed on Android MTE builds. The CL
also adds a check in `SuspendTagCheckingScope` to prevent nested usage
earlier.
Bug: v8:13257
Change-Id: I2b7a041bed0155a814454845b8a43fc530199588
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5426676
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93204}
Apart from the regular stack, there are two more stacks used by special
builds: the fake stack, used by ASAN, and the unsafe stack, used when
clang's safe stack feature is enabled.
With this CL:
- Stack::SetStackStart() uses the current stack information for all
kinds of stacks.
- Setting the stack marker takes into account all kinds of stacks, if
appropriate.
- Stack-related methods are removed from internal::HandleHelper and
become static methods in heap::base::Stack.
- Conservative stack scanning correctly scans all appropriate stacks.
Change-Id: Ie5af66414d532cc20bdcb1417a987796895204a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5412936
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93160}
After read-only promotion, some Code objects are promoted to the RO
space. But the corresponding code pointer table (CPT) entries are not
in the read-only segment. Therefore, if a GC is triggered at this
point, they will be swept and this will leave such Code objects with
an invalid self indirect pointer offset. If heap verification (e.g.,
as part of the same GC) ever reaches such an object, it will fail.
This CL:
1. Adds the following invariant to the heap verifier: if an
ExposedTrustedObject is in the RO space, its self indirect pointer
entry must be in the read-only segment, and vice versa.
2. Fixes read-only promotion, so that code pointer table entries are
correctly promoted and the above invariant is satisfied.
3. Triggers the verification of the mutable heap (as well as that of
the read-only heap) after read-only promotion.
4. Modifies cctest/ContextSerializerCustomContext so that a GC is
triggered after read-only promotion (which crashes without the
fix in this CL).
Bug: b/330450848
Change-Id: I5525579339a085082a4dc935f33a9800e1b946e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5383045
Reviewed-by: Samuel Groß <saelo@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93076}
At isolate deinitialization, the optimizing compile dispatcher is
stopped, flushing its queue and waiting for any pending compile tasks
to complete. In this process, a safepoint may be requested, which may
trigger a GC. This CL ensures that, in this case, local GC requests
will be ignored and no GC will be triggered.
Change-Id: I1426d75e093314e05b1d265e74be3b95e0355753
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5355974
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92760}
With v8_enable_direct_local=true, which requires conservative stack
scanning, locals are just direct pointers to objects. This CL fixes
the CallApiGetter builtin to correctly support direct locals.
Bug: v8:13270
Change-Id: I4737bae14c97359e8e4b693f8e5a54e5c306f39b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5351787
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92717}
With this CL, setting v8_enable_conservative_stack_scanning=true
sets also v8_enable_direct_local=true (unless explicitly overriden).
This means that the default configuration for CSS will now use both
direct (internal) handles and direct locals.
Bug: v8:13257
Bug: v8:13270
Change-Id: Iddd9b8da42e5e42fcb77a152dce2f0c488736260
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5339871
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92650}
This CL adds support for conservatively scanning the stacks of
background threads. If such a thread has a non-trivial stack, it
should use Stack::SetMarkerForBackgroundThreadAndCallback to register
its stack for scanning and wait in the callback for a GC to occur.
This method is automatically invoked by the family of
LocalHeap::BlockWhileParked methods. Threading cctests use the
same mechanism for alternating between different threads.
Bug: v8:13257
Bug: v8:13270
Change-Id: I9bcced9e80d2e07f2a4a02f45cb6d129a79a16ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5331543
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92629}
- The DisableConservativeStackScanningScopeForTesting is narrowed as
much as possible and comments are added to explain why it is needed.
- Add two such scopes two disable CSS in two tests.
Bug: v8:13270
Change-Id: I1e2385aa1a1764fa590992c586a50db8fa916f63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5331541
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92614}
When pumping the message loop, we may trigger the execution of a
non-nestable task (e.g., a stackless GC), which assumes that there are
no handles on the current stack. With v8_enable_direct_local=true
(which requires conservative stack scanning), violating this invariant
may result in a crash. This CL fixes d8 and the inspector task runner,
installing a scope to enforce scanning the stack in this case. It also
fixes a unit test that was occasionally failing with conservative stack
scanning.
Bug: v8:13270
Change-Id: I48916866b7bd4ab235736073b66827e71d78feb8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5331539
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92599}
This CL moves method AdaptLocalArgument so that it is accessible
via the __ macro. This method is used to correctly pass parameters
of type v8::Local<T>; notice that with v8_enable_direct_local=true,
which requires conservative stack scanning, locals are just direct
pointers to objects.
It also merges this method with AdaptHandlifiedArgument, that was
used in the wasm compiler for the same purpose.
Bug: v8:13270
Change-Id: I4ce39eb745dda7fc5b0dba93431d95dd82b9a2ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5321466
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92582}
With v8_enable_direct_local=true, which requires conservative stack
scanning, locals are just direct pointers to objects. This CL fixes
fast API calls from wasm for well-known imports, to correctly support
direct locals.
Bug: v8:13270
Change-Id: I0eb62cd4c805d7f405f1047dbda8a26764b5d566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5327550
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92578}
This CL moves method AdaptLocalArgument so that it is accessible
via the __ macro. This method is used to correctly pass parameters
of type v8::Local<T>; notice that with v8_enable_direct_local=true,
which requires conservative stack scanning, locals are just direct
pointers to objects.
Bug: v8:13270
Change-Id: If0eb0ec77dfa83bb7504d0044510c22878a8fbcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5327547
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92577}
This CL refactors the scopes for overriding the embedder stack state,
which are used for testing and other purposes to control whether
conservative stack scanning is performed,
- A distinction is made in internal::EmbedderStackStateScope between
implicit and explicit scopes. The latter take precedence over the
former.
- Explicit scopes are required to force the scanning of the stack,
in case a stackless GC is implicitly invoked by pumping the message
queue from a point where the stack is non-trivial. Such a case is
fixed in Shell::DoHostImportModuleDynamically, in d8.
- In Oilpan, cppgc::testing::OverrideEmbedderStackStateScope uses
internal::EmbedderStackStateScope as the underlying implementation,
unless in stand-alone heaps.
Change-Id: Ibab78f89be16d0e856dac09cb13efc2f1a3ae8a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5306761
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92517}
- The DisableConservativeStackScanningScopeForTesting is narrowed as
much as possible and comments are added to explain why it is needed.
- In one cctest, an array of local handles to contexts is replaced with
an array of global handles, to allow for GC without a stack.
- Formatting and miscellaneous minor fixes.
Bug: v8:13270
Change-Id: I3c6d4edc2ccd9c7d31ed2fc3d07f082b8f4c3eed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5300204
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92360}
This is a reland of commit 26b7b9650f
Original change's description:
> [handles] Process non-nestable tasks with trivial stack in samples/shell
>
> When pumping the message loop, we may trigger the execution of a
> non-nestable task (e.g., a stackless GC), which assumes that there are
> no handles on the current stack. With v8_enable_direct_local=true
> (which requires conservative stack scanning), violating this invariant
> may result in a crash. This CL fixes the V8 shell provided as a sample
> to correctly pump the message loop.
>
> Bug: v8:13270
> Change-Id: I5ed594f5d1b3a0d4514bf2d36f21789f3942fa4b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5262697
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#92309}
Bug: v8:13270
Change-Id: I705d77f8fce155025d957a39df3c6a393beaba75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5296139
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92322}
This CL sets an implication, so that whenever --compact-with-stack is
disabled, --compact-code-space-with-stack is also disabled.
The motivation for this is that with conservative stack scanning all
heap compaction should be disabled when the stack is non-trivial.
The existing implication was between --conservative-stack-scanning
and --compact-with-stack, but --compact-code-space-with-stack was
until now unrelated.
Bug: v8:13257
Change-Id: I8266dbe0a11f5923b7ad91cc4b310a16206fd60b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5293796
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92310}
When pumping the message loop, we may trigger the execution of a
non-nestable task (e.g., a stackless GC), which assumes that there are
no handles on the current stack. With v8_enable_direct_local=true
(which requires conservative stack scanning), violating this invariant
may result in a crash. This CL fixes the V8 shell provided as a sample
to correctly pump the message loop.
Bug: v8:13270
Change-Id: I5ed594f5d1b3a0d4514bf2d36f21789f3942fa4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5262697
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92309}
When pumping the message loop, we may trigger the execution of a
non-nestable task (e.g., a stackless GC), which assumes that there are
no handles on the current stack. With v8_enable_direct_local=true
(which requires conservative stack scanning), violating this invariant
may result in a crash. This CL fixes d8 to correctly pump the message
loop.
Bug: v8:13270
Change-Id: Ie42ac21719572c1fb533a5f084a271593d46757f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5258097
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92307}
- UnifiedHeapTest and YoungUnifiedHeapTest are subclasses of
TestWithHeapInternalsAndContext and they already install an external
handle scope and context.
- Local handles should not be kept around during a stackless GC, unless
the referenced objects are independently retained.
- Code snippets assuming that handles are always indirect are revised.
Bug: v8:13270
Change-Id: Ic6928bc2c01967a4d0a21cca50eeff41f6ae2196
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5242824
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92063}
- The DisableConservativeStackScanningScopeForTesting is narrowed as
much as possible and comments are added to explain why it is needed.
- Local handles, esp. Local<Context>, should not be kept around during
a stackless GC, unless the referenced objects are independently
retained. LocalContext in cctests provides a good replacement in some
cases, as it contains a persistent handle to the context.
- In one cctest, several threads were entering the same isolate
simultaneously. In another one, threads were using an isolate without
entering.
Bug: v8:13270
Change-Id: I80c6407cbbb6c6b6e470058d01dfeb629b493103
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5244805
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92062}
- The DisableConservativeStackScanningScopeForTesting is narrowed as
much as possible and comments are added to explain why it is needed.
- Code snippets assuming that handles are always indirect are revised.
- One test that requires heap compaction is disabled when the
compact_with_stack flag is not enabled.
Bug: v8:13270
Change-Id: I5a58f2ffe2ef19bf642bb0246704c39da9e0d611
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5240367
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92041}
This CL fixes some issues occuring with v8_enable_direct_local=true,
related to the interpretation of PersistentContainerValue as an indirect
handle. It also fixes a related test which could fail with conservative
stack scanning.
Bug: v8:13270
Change-Id: I04f22b41e511113ec7abde78d55eb784df53190a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5237265
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92036}
The arguments to various types of calls come as an array of
v8::Local<v8::Value>. They are internally converted to an array of
i::Handle<i::Object>. With v8_enable_direct_local=true, which requires
conservative stack scanning, locals are just direct pointers to objects.
This CL fixes the API's implementation to correctly perform this
conversion in this case. It also fixes a memory leak that existed in
the direct locals build.
Bug: v8:13270
Change-Id: Ia556de3832f15f281ad39780b0bb4b2baae2bc4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5236965
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92033}
This CL fixes a number of issues related to the interpretation of
local handles as indirect pointers. With v8_enable_direct_local=true
(which requires conservative stack scanning), local handles are simply
direct pointers.
Bug: v8:13270
Change-Id: I1834bfeaaf67ca9e6be46f4482b256750b49b9bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5237470
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92031}
The receiver parameter in fast API calls is of type v8::Local<T>.
The same is true for other V8 values, passed as parameters.
With v8_enable_direct_local=true, which requires conservative stack
scanning, locals are just direct pointers to objects. This CL fixes
the fast API call builder, to correctly support direct locals.
Bug: v8:13270
Change-Id: Idb29450063fba1cee23254cddb71c7ff2d27455f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5235035
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92014}
The receiver parameter in fast API calls is of type v8::Local<T>.
The same is true for other V8 values, passed as parameters.
With v8_enable_direct_local=true, which requires conservative stack
scanning, locals are just direct pointers to objects. This CL fixes
turboshaft's fast API call reducer, to correctly support direct locals.
Bug: v8:13270
Change-Id: I053c04761c788cbcf929ae70ee3d63ad9a727123
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5234896
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92011}
This CL fixes TypecheckWitness when direct local handles are used
(i.e., with v8_enable_direct_local=true, which requires conservative
stack scanning). In this case, its implementation becomes simpler and
faster.
Bug: v8:13270
Change-Id: I8a91767ff419463dae9a74ba495a32c800e921ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5234193
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92007}
With v8_enable_direct_handle=true and v8_enable_direct_local=true,
respectively, v8::Local<T> and v8::internal::DirectHandle<T> contain
direct pointers, instead of indirect ones. The use of both requires
conservative stack scanning.
This CL fixes gdb/lldb helpers to correctly print V8 direct handles
in such builds.
Bug: v8:13270
Change-Id: I6cb732a6c23386ce817a16243121b02d91ee3995
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5234428
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92004}
The receiver parameter in fast API calls is of type v8::Local<T>.
With v8_enable_direct_local=true, which requires conservative stack
scanning, locals are just direct pointers to objects. This CL fixes
the wasm fast API call wrapper, to correctly support direct locals.
Bug: v8:13270
Change-Id: I1df4893d38d6bdf8f91720310f2f14c672bca045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5234895
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92000}
This CL replaces expressions of the form:
*Utils::OpenHandle(value)
Utils::OpenHandle(value)->something
to use Utils::OpenDirectHandle instead of Utils::OpenHandle. Both forms
of expressions create a temporary handle and immediately dereference it,
to get to the referenced object.
Using a temporary direct handle instead, which is simply a pointer in
builds with v8_enable_direct_handle=true (requiring conservative stack
scanning), eliminates the allocation of a handle slot and the double
indirection.
Bug: v8:13270
Change-Id: Ibc242317b3fdfdecead861020677b9ea7b59a7d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5234191
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91997}
Methods in TorqueGeneratedFactory take handles to objects as parameters
and return handles to objects. This CL changes the method signatures to
expect direct instead of indirect handles as parameters. The difference
is only visible with v8_enable_direct_handle=true and, even then, the behaviour is the same as indirect handles can be implicitly converted
to direct handles. For the return type of these methods, indirect
handles are still used.
The CL also fixes some missing newlines from the generated code.
Bug: v8:13270
Change-Id: Iefaafe28100e25f93dccf204c4269514b05e4438
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5192469
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91818}
This is a reland of commit 0c7d381312
Original change's description:
> [handles] Add LIFO check for handle scopes
>
> This CL adds three checks, related to the proper use of isolates and
> handle scopes:
>
> 1. For a given isolate, handle scopes are created and destroyed in a
> LIFO manner;
> 2. When a thread enters an isolate, there is no different thread that
> has already entered it; and
> 3. When a thread exits an isolate, it must have previously entered it.
>
> These checks are behind the compile-time flag V8_ENABLE_CHECKS, which
> is by default enabled for V8 debug builds, and can be enabled from
> chromium builds by setting v8_enable_v8_checks=true. Because the CL
> introduces debug fields to an object of the V8 API (v8::HandleScope),
> the choice of a flag that is consistently set both in chromium and in
> V8 is important.
>
> Change-Id: If24722619729cd4053ea97cb7be8645228ebd2d7
> Bug: v8:13270
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5110566
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Auto-Submit: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#91659}
Bug: v8:13270
Change-Id: I53af99ae74ff99c1659a1db2243a8d7405268abf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5173257
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91808}
This CL replaces some indirect handles, used as parameters in factory
methods, to direct handles. It is essentially a selective search-and-
replace and should not affect behaviour.
Bug: v8:13270
Change-Id: Ic8136e03cc47463949efda0e7258fd440aa3b2c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5030196
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91793}
This CL is the first step for supporting direct handles on background
threads. It revises the existing checks accordingly, and adds some
more. Specifically:
1. Stack information is moved from the isolate to the local heap.
2. internal::DirectHandleBase inherits api_internal::StackAllocated,
to check that direct handles are stack-allocated on debug builds.
3. A counter is introduced for counting used direct handles on
appropriate debug builds.
4. Direct handles can be used on background threads. A direct handle
can only be dereferenced by a background thread if it's allocated
on that thread's stack. A background thread can only park if at
that moment it uses no direct handles (as we don't scan the stacks
of background threads yet).
Bug: v8:13270
Change-Id: I643c4d3e59503c405c0adca68b7919dc5ee48893
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5145367
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91787}
This CL adds three checks, related to the proper use of isolates and
handle scopes:
1. For a given isolate, handle scopes are created and destroyed in a
LIFO manner;
2. When a thread enters an isolate, there is no different thread that
has already entered it; and
3. When a thread exits an isolate, it must have previously entered it.
These checks are behind the compile-time flag V8_ENABLE_CHECKS, which
is by default enabled for V8 debug builds, and can be enabled from
chromium builds by setting v8_enable_v8_checks=true. Because the CL
introduces debug fields to an object of the V8 API (v8::HandleScope),
the choice of a flag that is consistently set both in chromium and in
V8 is important.
Change-Id: If24722619729cd4053ea97cb7be8645228ebd2d7
Bug: v8:13270
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5110566
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91659}
According to V8's public API documentation, local handles (i.e.,
objects of type v8::Local<T>) "should never be allocated on the heap".
This disallows heap-allocated data structures containing instances of
v8::Local, like std::vector<v8::Local<v8::String>>. It is unfortunate
that the V8 API itself requires the usage of such data structures.
This CL continues the deprecation of such data structures from V8's
public API, progressing from DEPRECATE_SOON to DEPRECATED.
Bug: chromium:1454114
Change-Id: Ida483129a801ca6af0779b8cd1f78a17783fedf0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5136838
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91612}
This CL adds an Isolate::Scope to Debug::RestoreDebug, to allow it to
use the isolate when called from v8::Unlocker's destructor. The added
test fails without the fix. See the bug report for more details.
Change-Id: I5924603b464ef1cd02e357faf84eb9089bbf336c
Bug: chromium:1511649
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5119745
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91603}
According to V8's public API documentation, local handles (i.e., objects
of type v8::Local<T>) "should never be allocated on the heap". This CL
replaces a std::vector of local handles in test-api-incumbent.cc that
was introduced in https://crrev.com/c/5077502 with a v8::LocalVector.
Bug: v8:13270
Change-Id: I282acde1464cf20b82627a90b3357131bdcc3cf6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5119552
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91529}
This CL:
1. Introduces the class template api_internal::StackAllocated which
checks that objects of derived classes are stack-allocated. Whether
the checks are actually performed or not is controlled both
statically (via a template parameter) and dynamically (via the
contextual variable internal::StackAllocatedCheck, to be used for
testing).
2. Refactors v8::Local to inherit api_internal::StackAllocated.
3. Introduces internal::DisableHandleChecksForMockingScope to be used
in tests. This scope disables off-stack handle checks and is useful
for mocking functions that take such handles as parameters and/or
return them as results (gmock saves these values off-stack).
4. Introduces v8::base::ContextualVariableWithDefault for creating
contextual variables that have a default value, to be used if there
is no active Scope object.
5. Moves the two helper classes v8::IndirectHandleBase and
v8::DirectHandleBase to the namespace api_internal.
Bug: v8:13270
Change-Id: I254e83cec9c52266340924fcf930f789d6c56700
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5079901
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91500}
According to V8's public API documentation, local handles (i.e., objects
of type v8::Local<T>) "should never be allocated on the heap". This CL
replaces local handles used in unit test objects, which are derived from
testing::Test and are heap-allocated.
Bug: v8:13270
Change-Id: I21c1ba9047777731c81c398ad861d10019e73818
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5076893
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91330}
This CL simplifies AnyCType, which is used for the purpose of testing
fast API calls, changing it from a struct containing a single union to
just a union. It also ensures that this type has trivial ABI (as
required by the implementation of fast API calls) in the unlikely case
that v8::Local is not trivially copyable; this happens in debug builds
with v8_enable_local_off_stack_check=true.
Bug: v8:13270
Change-Id: I655b8e416289b7d749b83c7705137ab069a61d39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5062928
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91195}
Objects of type v8::Local<T> and internal::DirectHandle<T> must be
stack-allocated. In debug builds (and with a compile-time flag, for
the case of v8::Local), there is a check to enforce this. This CL
strengthens this check, enforcing it also in the case of these
objects' copy constructors.
As a result, in such debug builds these handles become not trivially
copyable. This works correctly in Clang but requires the trivial_abi
attribute; the checks in the copy constructors are therefore only
enabled if this is supported.
Bug: v8:13270
Change-Id: I673318f53348b9b993eaf7b9fcfd25dcacda843a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5046670
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91150}
According to V8's public API documentation, local handles (i.e.,
objects of type v8::Local<T>) "should never be allocated on the heap".
While technically this does not prevent their use as global variables,
our implementation of direct locals does not allow this, as they will
be missed by conservative stack scanning.
This CL replaces some global variables of type v8::Local<T> that are
used in cctests and unit tests.
Bug: v8:13270
Change-Id: I6adaa95b73a6a7125cd18aabeaa938e945e59094
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5046677
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91132}
This reverts commit 89c3816fc4.
Reason for revert: These changes were not necessary.
Original change's description:
> [handles] Deprecate vector of handles in error messages
>
> Some methods for constructing error messages take as parameters vectors
> of handles to strings or objects. Such handles cannot be migrated to
> direct handles, as the latter must be stack-allocated. This CL replaces
> these vectors of handles with MemorySpan objects, as a first step in
> the migration towards direct handles.
>
> Bug: v8:13270
> Change-Id: Ia730b3794fa8edf7b5ad07a747c3eb4690b42caf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5020707
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#90894}
Bug: v8:13270
Change-Id: Ie03b8044d31d7bdbc198efc5dc3e5c9ff604518c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5029994
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#90916}
Some methods for constructing error messages take as parameters vectors
of handles to strings or objects. Such handles cannot be migrated to
direct handles, as the latter must be stack-allocated. This CL replaces
these vectors of handles with MemorySpan objects, as a first step in
the migration towards direct handles.
Bug: v8:13270
Change-Id: Ia730b3794fa8edf7b5ad07a747c3eb4690b42caf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5020707
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90894}
This CL introduces some minor changes related to direct handles.
1. It moves internal::ValueHelper and internal::HandleHelper to
v8-internal.h
2. It introduces method internal::HandleHelper::VerifyOnMainThread
3. It fixes some issues in handle conversions and introduces missing
methods
4. It implements handle equality for DirectHandle and between
Handle and DirectHandle
Bug: v8:13270
Change-Id: I7b0a0613ce40926da14677373f56b549a01e3db5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5016850
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90886}
According to V8's public API documentation, local handles (i.e.,
objects of type v8::Local<T>) "should never be allocated on the heap".
This disallows heap-allocated data structures containing instances of
v8::Local, like std::vector<v8::Local<v8::String>>.
This CL continues the deprecation of such data structures from the V8
code base, using v8::LocalVector instead.
Bug: chromium:1454114
Change-Id: I90e76c85abad6be2288666bfafade1bd19352cb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4995788
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90829}
According to V8's public API documentation, local handles (i.e.,
objects of type v8::Local<T>) "should never be allocated on the heap".
This disallows heap-allocated data structures containing instances of
v8::Local, like std::vector<v8::Local<v8::String>>.
This CL continues the deprecation of such data structures from the V8
code base, using v8::LocalVector instead.
Bug: chromium:1454114
Change-Id: Ia91d45e4e298a670f84ba30e7582267b3e29443e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5000625
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90755}
According to V8's public API documentation, local handles (i.e.,
objects of type v8::Local<T>) "should never be allocated on the heap".
This disallows heap-allocated data structures containing instances of
v8::Local, like std::vector<v8::Local<v8::String>>. It is unfortunate
that the V8 API itself requires the usage of such data structures.
This CL continues the deprecation of such data structures from V8's
public API:
1. It deprecates v8::Module::GetStalledTopLevelAwaitMessage
(returning a std::vector of tuples of locals) in favour of
v8::Module::GetStalledTopLevelAwaitMessages (returning a pair
of two v8::LocalVector).
2. It renames the corresponding internal method to
SourceTextModule::GetStalledTopLevelAwaitMessages; plural is
more appropriate, as both return many messages.
Bug: chromium:1454114
Change-Id: I827718bd236074188a553ec040dece479d2502b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4994330
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90738}
According to V8's public API documentation, local handles (i.e.,
objects of type v8::Local<T>) "should never be allocated on the heap".
This disallows heap-allocated data structures containing instances of
v8::Local, like std::vector<v8::Local<v8::String>>.
This CL refactors a few wasm tests that use such vectors, using instead
stack-allocated std::arrays and v8::MemorySpan objects.
Bug: chromium:1454114
Change-Id: I04b467c447e2a61369678fa05606d75f971289cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4994333
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90737}
This CL converts many handles to direct handles in src/api/api.cc.
In fact, it converts all the easy cases with no external dependencies.
Such changes are only visible when conservative stack scanning and
direct handles are enabled. For production, this change has no impact.
The CL also attempts to sanitize the use of handles in src/api/api.cc,
e.g., using more "auto" when the type of the handle can be easily
deduced (when using Open[Direct]Handle, or [Direct]Handle::cast).
Bug: v8:13270
Change-Id: I17be682d384c5c90d5b8adfdf228bbb3c72db454
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4952336
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90528}
This CL fixes a bug in MemoryMeasurement::ReportResults that was
introduced in https://crrev.com/c/4877014. This method was not
working correctly when the array of contexts contained cleared
elements.
Bug: chromium:1454114
Bug: chromium:1494164
Change-Id: Ibeaf614ebefdd3b7e1383066ddf0a28a33daa12d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4958613
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90508}
According to V8's public API documentation, local handles (i.e.,
objects of type v8::Local<T>) "should never be allocated on the heap".
This disallows heap-allocated data structures containing instances of
v8::Local, like std::vector<v8::Local<v8::String>>. It is unfortunate
that the V8 API itself requires the usage of such data structures.
This CL continues the deprecation of such data structures from V8's
public API:
1. It replaces the out parameter of type std::vector<Local<Object>> of
Context::DeepFreezeDelegate::FreezeEmbedderObjectAndGetChildren
with a LocalVector<Object>.
2. It replaces the std::vector<std::pair<Local<Context>, size_t>> of
MeasureMemoryDelegate with two MemorySpan objects.
Bug: chromium:1454114
Change-Id: Ifa7634a37849dee0a3d80d00355a2f1fbfe378ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4877014
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90488}
The current implementation of LocalVector::iterator exhibits UB when
the iterator is not dereferenceable. This CL fixes it, by introducing
a class template internal::WrapperIterator, which allows the safe
conversion between a wrapper iterator type and the underlying iterator
type, upon dereferencing.
Bug: v8:13257
Bug: v8:13270
Bug: chromium:1454114
Change-Id: If253d9f4838f7286d65cd86b8ee83d6c1c6bf077
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4942235
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90481}
This method is used in unittests/inner-pointer-resolution-unittest/
UnusedRegularYoungPages and needs to be exported to avoid a linker
error.
Bug: chromium:1480975
Change-Id: Ib2b3b392d919de841706162ce3e699534fbfd97d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4942232
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90426}
According to V8's public API documentation, local handles (i.e.,
objects of type v8::Local<T>) "should never be allocated on the heap".
This disallows heap-allocated data structures containing instances of
v8::Local, like std::vector<v8::Local<v8::String>>. It is unfortunate
that the V8 API itself requires the usage of such data structures.
This CL introduces a compile-time flag v8_enable_local_off_stack_check
which enforces a run-time DCHECK, that all v8::Local<T> objects are
indeed stack-allocated. The check is disabled by default. It will
fail for all heap data structures containing local handles.
The CL also introduces v8::LocalVector<T> as an intended replacement
for std::vector<v8::Local<T>>. This class implements correctly
heap-allocated vectors of local handles. The backing store of such
vectors does not trigger the off-stack check. Furthermore, if direct
locals are used, the backing store is also registered as a strong
roots region.
Additionally, the CL modifies root visitors so that, when direct
locals are used, they bypass slots containing kTaggedNullPointer.
In the direct local configuration, this value is used to represent
"empty handles" and is expected to be found in the backing stores
of v8::LocalVector<T>, for default-constructed elements.
Bug: v8:13257
Bug: v8:13270
Bug: chromium:1454114
Change-Id: I1fa6277eab95fa3609d840fca211e2531592e657
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4905902
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90335}
This is a reland of commit 9131137b6c
It was reverted because some of the new tests (correctly) fail in
stress configurations that intefere with the GC, such as stress
incremental marking. The reland skips the tests for such configurations.
Original change's description:
> [heap] Refactor StrongRoot(Block)Allocator
>
> This CL cleans up the implementation of StrongRootBlockAllocator,
> removing redundant or deprecated things and aligning with C++ >= 11.
> The allocator is now renamed as StrongRootAllocator, has become a
> template and has StrongRootAllocator<Address> as a special case,
> registering strong roots. All other instances simply behave as
> std::allocator.
>
> The CL also adds tests to verify that the allocator behaves as
> intended, both stand-alone and when used with standard C++ containers.
>
> Change-Id: I8f16a6022918db225c097a8fa742762101aee146
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4866336
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#90168}
Change-Id: I5b8800467f4e09c6e0a09d53400ad7e89a345d9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4900605
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90220}
This CL cleans up the implementation of StrongRootBlockAllocator,
removing redundant or deprecated things and aligning with C++ >= 11.
The allocator is now renamed as StrongRootAllocator, has become a
template and has StrongRootAllocator<Address> as a special case,
registering strong roots. All other instances simply behave as
std::allocator.
The CL also adds tests to verify that the allocator behaves as
intended, both stand-alone and when used with standard C++ containers.
Change-Id: I8f16a6022918db225c097a8fa742762101aee146
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4866336
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90168}
According to V8's public API documentation, local handles (i.e.,
objects of type v8::Local<T>) "should never be allocated on the heap".
This disallows heap-allocated data structures containing instances of
v8::Local, like std::vector<v8::Local<v8::String>>. It is unfortunate
that the V8 API itself requires the usage of such data structures.
This CL starts a deprecation of such data structures from V8's public
API. It replaces the std::vector<Local<String>>, used as parameter to
Module::CreateSyntheticModule, with a MemorySpan<const Local<String>>.
This stands for a (contiguously allocated) array of local handles to
strings, which will not be modified. The size of the array is known,
as part of the MemorySpan object. The CL also replaces some vectors
of locals with arrays of locals in API tests.
Moreover, the CL adds some functionality to the existing
v8::MemorySpan class, so that it behaves more like the upcoming (in
C++20) std::span<T, std::dynamic_extent>. In particular, it makes
spans subscriptable, iterable, and allows implicit conversion from
arrays. It also introduces a helper function template v8::to_array<T>
(the upcoming std::to_array<T>, in C++20), to better support automatic
deduction of array size without omitting the element type.
Bug: chromium:1454114
Change-Id: Iaa36da8199428a9120259aa2a3a4543e261fbc60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4866222
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90056}
This CL cleans up the implementations of ZoneAllocator and
RecyclingZoneAllocator, removing redundant or deprecated things
and aligning with C++ >= 11.
It also adds tests to verify that both these allocators can be
used with standard C++ containers.
Change-Id: I245b39d2bd39f7fbbf7b5a589a973701314d9861
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4866420
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90007}
Until now, LargeObjectSpace::AllocateLargePage created a filler object
in each fresh large page, which would afterwards be replaced by the
actual large object. This CL eliminates this intermediate step, leaving
fresh large pages uninitialized.
Additionally, the CL:
1. Fixes the order of StartIncrementalMarking and object allocation
for the old large space, to be consistent with what's used in other
spaces.
2. Fixes and/or refactors three cctests for spaces. In particular,
cctest/test-spaces/OldSpace was not allocating any objects.
Change-Id: I429efd5f9f927307d88acd2a03495baeca76efd2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4827126
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89794}
A very long time ago, the implementation of HeapObjectIterator and
UnreachableObjectsFilter required that a full iteration was completed
(https://codereview.chromium.org/4888001). This was required because
the actual markbits were used for marking reachable objects and the
heap would be in an incosistent state if iteration was interrupted.
Also a long time ago, the implementation of UnreachableObjectsFilter
changed (https://codereview.chromium.org/2901553002) and now it uses
local markbits.
This CL fixes some obsolete comments, refactors these two classes
(primarily to omit obsolete and redundant checks) and breaks during
a heap object iteration to speed up HeapProfiler::FindHeapObjectById.
Change-Id: I07a7057f2e4f6fc741cde33d294a770fb6033558
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4821927
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89704}
All other space object iterators never return filler of free space
objects, except the LargeObjectSpaceObjectIterator. This CL fixes it
to exhibit the same behaviour.
Change-Id: If92c514797ac96d4292cfcc6f804f47357552519
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4822504
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89698}
In https://crrev.com/c/4804204 a stack marker was introduced in
HeapSnapshotGenerator::GenerateSnapshot(), for ensuring that the GC
and the filling of references will scan the same part of the stack.
This CL moves the stack marker a bit higher in the call chain, to
HeapProfiler::TakeSnapshot, to guarantee that the part of the stack
above the marker will not be modified during snapshot generation.
Bug: v8:13257
Change-Id: I86d446ec709347032158fa929e2500ebfa083112
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4813324
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89641}
Serialization requires predictable GC (and heap iteration) behavior.
With CSS, this is only the case when iterating without the stack.
This CL makes sure that the stack is not scanned conservatively:
1. In the GC that comes before serialization;
2. In the heap iteration during read-only promotion, when determining
the promotees; and
3. In the heap iteration during read-only promotion, when updating the
pointers.
Bug: v8:14275
Change-Id: I37ed909f2b31d3972ef3f52613b8067f297dacb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4807483
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89614}
This CL refactors conservative stack scanning so that it always scans
from the stack marker to the stack start. It assumes that a stack marker
has already been set, when iterating through stack roots. The method
Stack::SetMarkerIfNeededAndCallback must be used to set the marker: it
only does so if the marker has not already been set. The callback is
required because the stack marker is set inside the trampoline for
saving callee-saved registers on the stack.
Using the stack marker instead of scanning the entire stack is useful
in cases where it is important to consistently scan the same part of
the stack successively. This CL addresses two such cases:
1. During GC, for marking and marking verification.
2. In the heap profiler, during snapshot generation, the GC and the
filling of references should scan the same part of the stack.
The same when querying for objects.
(A third case will be handled in a separate CL: during snapshot
serialization, GC and read-only promotion should scan the same part
of the stack or omit the stack entirely.)
The CL also cleans up the trampoline-related logic that was implemented
in the local heap, as well as the now redundant scan stack modes.
Bug: v8:13257
Bug: v8:14278
Change-Id: I36e68e4d5201def75ae9841dfcd9c0fd8fdf329e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4804204
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89610}
Inner-pointer resolution (IPR) using the marking bitmap is now tailored
for the marking visitor. That is, if a maybe-inner-pointer coincides
with the base address of an object that was already marked, IPR returns
a null address and the conservative stack scanning (CSS) visitor does
not pass it to its delegate visitor. This works fine if the delegate
visitor is the marking visitor or the marking verification visitor.
All other visitors, however, may miss visiting some marked objects.
When CSS is enabled, the CSS visitor is used for iterating stack roots.
This does not only happen during the marking phase of a GC but also,
e.g., during snapshot creation and in the heap profiler.
This CL fixes IPR to work correctly, independently of whether the
resolved objects are marked or not. In this way, the CSS visitor
correctly delegates all pointers. The marking visitors will bail out
anyway, if they visit an already marked object.
Bug: v8:13257
Bug: v8:14275
Bug: v8:14278
Change-Id: I4759861d3e2bbce0e13570c12f07aa08d6f3f2c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4806564
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89591}
This CL refactors the API for converting between internal and external
handles, to follow https://crrev.com/c/4798491. In particular:
- Convert, ToLocal and ToApiHandle, which convert internal handles to
external, consistently expect either an (indirect) Handle or a
DirectHandle and an Isolate.
- OpenHandle, OpenDirectHandle and the explicit OpenIndirectHandle,
convert external handles to different flavours of internal handles.
Bug: v8:13270
Change-Id: I367f45d3022022be37e884f82f2f45f9e65f62af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4797930
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89574}
Nikolaos Papaspyrou