This is a reland of commit 39d387bb72
Original change's description:
> [heap] Invoke allocation observers before limiting the LAB
>
> Currently whenever we reach a step we get a small LAB the same size as
> the allocated object. This is becuase the remaining step size is smaller
> then the current allocation.
> Invoking observers before limiting the LAB, and thus updating step
> sizes, should eliminate the small LAB we get whenever we reach a step.
>
> Drive-by: remove redundant method arguments.
>
> Bug: v8:12612
> Change-Id: Ied92a947308368d3b289e246fdb4f40ac5e5981f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013683
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84157}
Bug: v8:12612, v8:13465
Change-Id: I40fb930a755cb5decccd932c4d25ed7d5d224da4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020177
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84328}
I recently updated the GC's bytecode flushing logic to accept the
possibility that two SharedFunctionInfos refer to the same
BytecodeArray (see https://crrev.com/c/v8/v8/+/3916272 ). However, that
change was insufficient for baseline code flushing. This change updates
the flushing logic to also check for already decompiled bytecode held by
the baseline code.
Bug: v8:13473
Change-Id: I58694727c417d608de3f8bf26dfd765fda1ae4f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4018272
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#84254}
This reverts commit 39d387bb72.
Reason for revert: causes DCHECKS, timeouts, TSAN failures under stress
Original change's description:
> [heap] Invoke allocation observers before limiting the LAB
>
> Currently whenever we reach a step we get a small LAB the same size as
> the allocated object. This is becuase the remaining step size is smaller
> then the current allocation.
> Invoking observers before limiting the LAB, and thus updating step
> sizes, should eliminate the small LAB we get whenever we reach a step.
>
> Drive-by: remove redundant method arguments.
>
> Bug: v8:12612
> Change-Id: Ied92a947308368d3b289e246fdb4f40ac5e5981f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013683
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84157}
Bug: v8:12612, v8:13465
Change-Id: I74b412dc41bfc86ea7fb190ce3284349a9022057
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4018913
Auto-Submit: Adam Klein <adamk@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@{#84162}
Currently whenever we reach a step we get a small LAB the same size as
the allocated object. This is becuase the remaining step size is smaller
then the current allocation.
Invoking observers before limiting the LAB, and thus updating step
sizes, should eliminate the small LAB we get whenever we reach a step.
Drive-by: remove redundant method arguments.
Bug: v8:12612
Change-Id: Ied92a947308368d3b289e246fdb4f40ac5e5981f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013683
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84157}
This CL simplifies safepoint scopes, there are now three kinds of
safepoint scopes:
1) IsolateSafepointScope - performs an isolate local safepoint
2) GlobalSafepointScope - a global safepoint across multiple isolates
3) SafepointScope - chooses based on condition between local/global
This CL is not supposed to change current safepointing behavior in
any way. The CL renames the current SafepointScope to
IsolateSafepointScope and changes GlobalSafepointScope to always
perform a global safepoint. It then also introduces the new
SafepointScope and makes use of it for snapshotting and in heap.cc.
Bug: v8:13267
Change-Id: Ie7e1f81b6158c98d3d98552ba735cc73c9b869c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3973310
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83912}
The implementation of bytecode flushing assumes that there is a single
owning SharedFunctionInfo for each bytecode. However, sometimes there
can be two, because a couple of code paths copy content from one
SharedFunctionInfo to another (BackgroundCompileTask::FinalizeFunction
and BackgroundMergeTask::CompleteMergeInForeground). Usually this works
out okay in practice, because we only copy content from a
SharedFunctionInfo when we're about to abandon all references to it.
However, we shouldn't rely on this lucky timing, especially considering
a possible future where conservative stack scanning could retain the
copied-from SharedFunctionInfo for an arbitrarily long time due to
spurious stack references. This change updates the bytecode flushing
implementation to correctly handle the case of two SharedFunctionInfos
that point to the same BytecodeArray.
I don't know if this fixes the linked bug, but so far it's the only
semi-plausible explanation I've found.
Bug: chromium:1359773
Change-Id: Iaa2c6e4953afcb46df2ac4b17828271151d85e59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916272
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83728}
MinorMC cannot shrink the space while concurrent sweeping is active.
This results in races between sweeping empty pages concurrently and
releasing them on the main thread.
Without concurrent sweeping, MinorMC sweeps all empty pages, then
preallocates more pages if needed, then shrinks by releasing some of
those empty/new pages.
MinorMC can instead shrink during sweeping/evacuation in the atomic
pause, before concurrent sweeping is active.
This resolves the conflict between concurrent sweeping and shrinking and
generally reduces the amount of work the GC has to do (i.e. don't
sweep/preallocate pages that will then be released by shrinking).
Bug: v8:12612
Change-Id: If898e5111c65b0b11d6ee9ee5dcd45751024650b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3933056
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83638}
This is needed to simplify concurrent sweeping for MinorMC.
Also: move evacuation verifiers to a separate file so that they can be
used from heap.cc as well.
Bug: v8:12612
Change-Id: I2a738a31e83a357f4fdded8a30ccb2ff6ba70553
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3932720
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83557}
Detach the marking state from the collectors and move them to heap.
Also update users to access via heap and reduce dependencies on the
collectors.
This is a prerequisite for moving sweeper to the heap, which is needed
for concurrent sweeping in MinorMC.
Bug: v8:12612
Change-Id: Ia0bb2b7566b24eeb0d75c911edbfd626f07dad0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925548
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83542}
FillCurrentPage assumed that everything after top is empty, which
doesn't work with MinorMC and sweeping. Revise FillCurrentPage based
SimulateFullSpace for MinorMC.
I similar implementation is provided both in unittests and cctest.
Migrating affected cctest to unittests is left a future work.
Bug: v8:12612
Change-Id: Ie29be2fc7aaee25e1fd5f66b1c0959c2a45f007f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3885888
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83158}
ShouldFinalize should only be called if major incremental marking is
active, and can crash if minor incremental marking is active, if
MajorMC's local_marking_worklists_ was reset.
The only caller is IsMarkingComplete. This CL changes the IsMarking
check to IsMajorMarking to solve this issue, and renames
IsMarkingComplete to IsMajorMarkingComplete.
Bug: v8:13012
Change-Id: Iba6bd5b7977ec8566c3ab0f047646d8cafd45038
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3879485
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83064}
Avoid the deprecated FLAG_* syntax, access flag values via the
{v8_flags} struct instead.
R=mlippautz@chromium.org
Bug: v8:12887
Change-Id: Id12f9d8270dd9fed651e1b3596c06e45aae9d6d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3846151
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82969}
This CL refactors most of the cctests and unittests (22 out of 31) that
directly invoke heap GC, so that the corresponding internal heap methods
are called from a few specific places in boilerplate code. This will
facilitate impending changes to the interface of GC-related internal
heap methods.
Bug: v8:13257
Change-Id: Ia6773a7952501b0792b279b799171519620497d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3869264
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82927}
Methods are now defined in heap-verifier.h in the HeapVerifier class.
Bug: v8:11708
Change-Id: I13e7f1760598f3659ad6aa31082840caf2e44038
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3857558
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82810}
This CL adds a soft limit (via AllocationObserver) to run
incremental marking for MinorMC.
Once the soft limit is triggered, roots are marked.
This a stepping stone for concurrent marking
(YoungGenerationConcurrentMarkingVisitor, go/YGCMV) integration.
Bug: v8:13012
Change-Id: I5bc9aeb80511159561845deb494023ade3fb7365
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3824339
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Cr-Commit-Position: refs/heads/main@{#82695}
IsRunning() and IsMarking() are now equivalent. So IsRunning() can be
removed in favor of IsMarking().
IsComplete() is also renamed to IsMarkingComplete().
Bug: v8:12775
Change-Id: Ife88be4d674af055590ba5178ec1e410f8fa89d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3849833
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82665}
This is a reland of commit 9b0d5cb14b
The newly added check does not allow comparisons with stale or
invalid pointers because attempt to access the page header might
crash.
Original change's description:
> [ext-code-space] Fix Code vs non-Code comparisons
>
> When external code space is enabled comparing Code and non-Code objects
> by looking at compressed values is not always correct. Such an approach
> works only for comparing Code vs Code objects or non-Code vs non-Code
> objects.
>
> This CL instroduces SLOW_DCHECK into Object comparison operators to
> ensure that such a comparison is allowed. Also, this CL instroduces
> an Object::SafeEquals() method which compares uncompressed values
> and thus is safe to be used for comparing Code with non-Code objects.
>
> Bug: v8:11880
> Change-Id: I7ccf1f90f927beb2bb9f45efb303e902b1838d02
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838172
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82611}
Bug: v8:11880
Change-Id: Iab3c8fe49cb954b2dc9171b3fc4b189e84763e73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842932
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82624}
This reverts commit 9b0d5cb14b.
Reason for revert: Seems to fail on gc-stress bots (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/43472/overview)
Original change's description:
> [ext-code-space] Fix Code vs non-Code comparisons
>
> When external code space is enabled comparing Code and non-Code objects
> by looking at compressed values is not always correct. Such an approach
> works only for comparing Code vs Code objects or non-Code vs non-Code
> objects.
>
> This CL instroduces SLOW_DCHECK into Object comparison operators to
> ensure that such a comparison is allowed. Also, this CL instroduces
> an Object::SafeEquals() method which compares uncompressed values
> and thus is safe to be used for comparing Code with non-Code objects.
>
> Bug: v8:11880
> Change-Id: I7ccf1f90f927beb2bb9f45efb303e902b1838d02
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838172
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82611}
Bug: v8:11880
Change-Id: Ie34af0135625eff2975f78f4d2901a76b8517eb7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842930
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82616}
When external code space is enabled comparing Code and non-Code objects
by looking at compressed values is not always correct. Such an approach
works only for comparing Code vs Code objects or non-Code vs non-Code
objects.
This CL instroduces SLOW_DCHECK into Object comparison operators to
ensure that such a comparison is allowed. Also, this CL instroduces
an Object::SafeEquals() method which compares uncompressed values
and thus is safe to be used for comparing Code with non-Code objects.
Bug: v8:11880
Change-Id: I7ccf1f90f927beb2bb9f45efb303e902b1838d02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838172
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82611}
This CL removes the COMPLETE state from incremental marking. Since
then the only states left were STOPPED and MARKING, we can replace
the state with an is_running_ boolean field.
The state could change back-and-forth between MARKING and COMPLETE.
IsMarking() was already also checking for COMPLETE. So most code
already treated both states the same. IsComplete() now checks whether
marking is running and a transitive closure was reached already.
IncrementalMarking::Step() didn't process the marking queue when in
COMPLETE. This should be relatively rare though since it only
transitioned into COMPLETE when the stack guard was armed and the
allocation observer ran again before reaching a stack guard check.
Bug: v8:12775
Change-Id: Ied48d8c512ad3d1b3d2e29393d43b434b5fda8fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3835689
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82581}
Introducing IncrementalMarking::AdvanceForTesting as last bottleneck
for driving incremental marking in addition to AdvanceFromTask
and AdvanceOnAllocation.
Now that we have those 3 bottlenecks, Step() and AdvanceWithDeadline()
can become private methods in IncrementalMarking. We also don't need
the StepResult return value in Step() anymore, which allows us to
remove CombineStepResult.
Bug: v8:12775
Change-Id: I702714439ef7ea4b9abf2156387503d4d00a7a48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3823131
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82552}
The existing version for paged spaces simply reset the freelist, which
doesn't work for tests that require actual objects in the space.
The version for new space also doesn't work because it assumes
everything after top is free space.
Fill the space with FixedArray by iterating over the freelist and
creating an object in place of each freelist entry.
This method actually fills the space, so that we can also use it to
force page promotion.
Bug: v8:12612
Change-Id: Ie0d73e846bbf688ea52030be29e0587b2f37ed4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3823135
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82437}
This CL includes:
1) Using 1 full GC instead of 2 young GCs to force object promotion.
2) A couple of needed bailouts.
3) Using manual evacuation candidates in old space to ensure an object
is evacuted (moved to a different address) instead of relying on
Scavenger.
And some other minor tweaks
Bug: v8:12612
Change-Id: Idfd925ccdf30215998ab6e7cc632ce750fa2077a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3816661
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82327}
This CL tries to improve readability of TryMarkingComplete() by
splitting it up into multiple smaller methods.
It also removes StepResult::kWaitingForFinalization since this was
only used in one test which could easily be rewritten to not need this
value. This makes CombineStepResult() and Step()s return value simpler
to understand.
Bug: v8:12775
Change-Id: I981bc7b736246ab53058d1e61e3c67db0d1130b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3816668
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82319}
StepOrigin is enough to infer the right completion action: Either
finalization by task (for StepOrigin::kTask) or stack guard
(for StepOrigin::kV8).
Only tests with StepOrigin::kV8 were violating this but they also just
pass when enabling the stack guard.
Bug: v8:12775
Change-Id: I5df50198d8e3612ee97142f84bd497820a5cec78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3816664
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82294}
... - a code range size agnostic version of InterpreterEntryTrampoline
builtin. The new builtin is fully compatible with the default version
and used as a template for creating interpreter entry trampoline
Code objects when --interpreted-frames-native-stack is enabled.
This CL introduces a new assembler option "position_independent_code"
which affects the way builtin calls are generated.
This mode is enabled only for InterpreterEntryTrampolineForProfiling.
Motivation:
* InterpreterEntryTrampoline uses RelocInfo::CODE_TARGET for calling
other builtins which requires the code range to be small enough to
allow PC-relative jumps/calls between Code objects. This is the
reason why --interpreted-frames-native-stack was not supported on
arm and might not work on arm64 because the code range is bigger
than the max PC-relative distance for call/jump instructions.
The new builtin calls other builtins via builtins entry table which
makes the code fully relocatable and usable for any code range size.
* RelocInfo::CODE_TARGET requires a target code to be materialized
as a Code object which contradicts the Code-less builtins goal.
* The --interpreted-frames-native-stack is rarely used in the wild but
we have to pay the price of deserializing InterpreterEntryTrampoline
builtin as a Code object which consumes address space in the code
range and thus limits the number of V8 isolates that can be created
because of code range exhaustion. Now the pointer compression cage
becomes the limiting factor instead of the code range.
* We can remove complicated logic of Factory::CopyCode() and respective
support on GC side.
Bug: v8:11880, v8:8713, v8:12592
Change-Id: Ib72e28c03496c43db42f6fe46622def12e102f31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811287
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82263}
This is a reland of commit a1392fa113
The original change was reverted due to v8:13135, which was fixed
separately.
Original change's description:
> Enable background merging when --stress-background-compile
>
> This change adds new functions to BackgroundCompileTask which closely
> match those in BackgroundDeserializeTask. These functions allow a caller
> to manage background merging of newly compiled content into an existing
> Script from the Isolate compilation cache. These functions are not yet
> exposed via the API; instead, StressBackgroundCompileThread uses them to
> increase test coverage of the merging logic.
>
> Bug: v8:12808
> Change-Id: I4d2f429164223785169fe447ce2bdd8beaee00d4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793959
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82121}
Bug: v8:12808
Change-Id: I530c6e87bbad11e178ef4abfdc25fa98530f0224
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3806590
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#82165}
This reverts commit a1392fa113.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/43149/overview
Original change's description:
> Enable background merging when --stress-background-compile
>
> This change adds new functions to BackgroundCompileTask which closely
> match those in BackgroundDeserializeTask. These functions allow a caller
> to manage background merging of newly compiled content into an existing
> Script from the Isolate compilation cache. These functions are not yet
> exposed via the API; instead, StressBackgroundCompileThread uses them to
> increase test coverage of the merging logic.
>
> Bug: v8:12808
> Change-Id: I4d2f429164223785169fe447ce2bdd8beaee00d4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793959
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82121}
Bug: v8:12808
Change-Id: Ibb0bc2adb79e4655b39a8a6ac33d8c8ffc5ebdb9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804602
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82137}
This change adds new functions to BackgroundCompileTask which closely
match those in BackgroundDeserializeTask. These functions allow a caller
to manage background merging of newly compiled content into an existing
Script from the Isolate compilation cache. These functions are not yet
exposed via the API; instead, StressBackgroundCompileThread uses them to
increase test coverage of the merging logic.
Bug: v8:12808
Change-Id: I4d2f429164223785169fe447ce2bdd8beaee00d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793959
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82121}
This is a partial reland of https://crrev.com/c/3597106
With this change, an existing Script from the compilation cache can be
reused after its top-level SharedFunctionInfo was discarded, but only if
the new script is parsed on the main thread (not deserialized from code
cache data, and not parsed on a background thread).
Bug: v8:12808
Change-Id: I1edaee2095306a89e2c3b91f2fd01ac053f3c770
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3689348
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#81472}
MinorMC maintained a separate marking state to support interleaved GCs.
Since MinorMC now assumes that interleaving is not possible, MinorMC can
use the same marking state as the full GC.
Bug: v8:12612
Change-Id: Ibeb7df2eb24e448f811b497c9d16b3b132f87ec2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3735163
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81468}
Remove finalization step of incremental marking. The step was
historically used to process embedder/weak work on the main thread
before invoking the atomic pause. Remove the infrastructure as the
step is not needed anymore and actually required a safepoint.
Change-Id: I208767bbac3d9a06a0b3c67aa9779f8a5fa07328
Bug: v8:12775
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702801
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81234}
This is a partial reland of https://crrev.com/c/3597106 , except for the
changes in compiler.cc, which are just the minimal possible changes to
make the code compile.
With this change, it is possible that a call to
CompilationCache::LookupScript returns any of:
1. A Script and a toplevel SharedFunctionInfo (cache hit)
2. A Script but no toplevel SharedFunctionInfo (partial cache hit)
3. Nothing (cache miss)
Bug: v8:12808
Change-Id: Id33a4cd0cb28562d6b862fbb113ea9d03f255b2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687425
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#81193}
... which might fail because usual operator== for tagged values compares
only lower 32 bits of the pointer.
Bug: v8:11880, v8:12958
Change-Id: I0978d6c510424aecfee2f044c40ea424b6cb3ab9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695593
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81096}
This is a reland of commit abcb6bb8b4.
The data race is fixed by using atomic operations.
Original change's description:
> [heap] Avoid dynamic updates of FLAG_gc_interval
>
> Flags will be protected from updates after V8 initialization (in the
> future). This CL avoids any updates of the --gc-interval flag during
> runtime, and instead updates a static field on the HeapAllocator
> directly.
>
> R=mlippautz@chromium.org
>
> Bug: v8:12887
> Change-Id: I17a495cae50a46d59a8159c6ece1558d4d61b949
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687691
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80998}
Bug: v8:12887
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Change-Id: Ib5b537500413a627d9b2509354d20906e0474d8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695380
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81008}
This reverts commit abcb6bb8b4.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/20029/overview
Original change's description:
> [heap] Avoid dynamic updates of FLAG_gc_interval
>
> Flags will be protected from updates after V8 initialization (in the
> future). This CL avoids any updates of the --gc-interval flag during
> runtime, and instead updates a static field on the HeapAllocator
> directly.
>
> R=mlippautz@chromium.org
>
> Bug: v8:12887
> Change-Id: I17a495cae50a46d59a8159c6ece1558d4d61b949
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687691
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80998}
Bug: v8:12887
Change-Id: I18310a3f515506d617f42be7a208013957625eaf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695559
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Owners-Override: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81002}
Flags will be protected from updates after V8 initialization (in the
future). This CL avoids any updates of the --gc-interval flag during
runtime, and instead updates a static field on the HeapAllocator
directly.
R=mlippautz@chromium.org
Bug: v8:12887
Change-Id: I17a495cae50a46d59a8159c6ece1558d4d61b949
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687691
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80998}
... as a pair of Code and CodeDataContainer.
In order to stop creating and using trampoline Code objects for
builtins we need a different way to represent an "embedded builtin"
code lookup result of builtin trampoline Code objects.
We can't switch to CodeT for this purpose because GC still needs to
be able to locate not yet evacuated Code objects in order to update
old code pointers on the stack once Code objects are moved.
Bug: v8:11880
Change-Id: I296636a6728a11c8e3220b3fee43fd12ff633c1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3684813
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80937}
This is a reland of commit a76072217a
The bug exposed by landing this change the first time has been fixed
separately in https://crrev.com/c/3654413 .
Original change's description:
> Disable recompilation of existing Scripts from Isolate compilation cache
>
> My previous change https://crrev.com/c/3597106 led to some performance
> regressions in time spent on parsing and compilation. This change
> disables the ability to recompile an existing uncompiled Script, as an
> attempt to both fix the regressions and isolate which part of the
> previous change was the cause of those problems.
>
> Bug: v8:12808, chromium:1325566, chromium:1325567, chromium:1325601
> Change-Id: Ifa086bf27070da8f4b3c0e4415af5ca7b6706b0a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652252
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#80616}
Bug: v8:12808, chromium:1325566, chromium:1325567, chromium:1325601
Change-Id: Ib31864bef90ff3340d1dfd4e25e21bef121f2d49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3655011
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80645}
This reverts commit a76072217a.
Reason for revert: fails on GC Stress bot:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/38512/overview
Original change's description:
> Disable recompilation of existing Scripts from Isolate compilation cache
>
> My previous change https://crrev.com/c/3597106 led to some performance
> regressions in time spent on parsing and compilation. This change
> disables the ability to recompile an existing uncompiled Script, as an
> attempt to both fix the regressions and isolate which part of the
> previous change was the cause of those problems.
>
> Bug: v8:12808, chromium:1325566, chromium:1325567, chromium:1325601
> Change-Id: Ifa086bf27070da8f4b3c0e4415af5ca7b6706b0a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652252
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#80616}
Bug: v8:12808, chromium:1325566, chromium:1325567, chromium:1325601
Change-Id: I0f56163856d04ff49da96b0fb344fb59b5501a40
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3653273
Auto-Submit: Adam Klein <adamk@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@{#80617}
My previous change https://crrev.com/c/3597106 led to some performance
regressions in time spent on parsing and compilation. This change
disables the ability to recompile an existing uncompiled Script, as an
attempt to both fix the regressions and isolate which part of the
previous change was the cause of those problems.
Bug: v8:12808, chromium:1325566, chromium:1325567, chromium:1325601
Change-Id: Ifa086bf27070da8f4b3c0e4415af5ca7b6706b0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652252
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80616}
This adds a new struct "OOMDetails" which is passed to the
OOMErrorCallback. It currently holds the "is_heap_oom" bool that was
also passed before, plus an optional "detail" string.
The struct can later be extended without having to change the signature
of the OOMErrorCallback. Removing fields will have to follow the
standard deprecation rules, but this is also easily possible without the
hassle for this initial change.
We modify the deprecated OOMErrorCallback definition and un-deprecate it,
which can be seen as removing a deprecated API and adding a new one in
one CL.
R=mlippautz@chromium.org, jkummerow@chromium.org
Bug: chromium:1323177
Change-Id: Ic4c2cb5856906ebd664626fe463d8e96cb99b0a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647827
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80565}
Once the root SharedFunctionInfo for any Script gets its bytecode
flushed, the Isolate's compilation cache currently evicts that entry, to
reduce memory usage. However, the associated Script is likely still
alive, since scripts often declare functions which outlive the initial
evaluation of the script. If an identical script is loaded later, a
duplicate Script is created for it, which can waste memory.
In this change, I propose that the compilation cache keys can refer
weakly to the Script. When the root SharedFunctionInfo gets old, instead
of deleting the cache entry entirely, we can just drop the strong
reference to the SharedFunctionInfo. A subsequent lookup in the cache
will retrieve the Script instead of the root SharedFunctionInfo,
indicating an opportunity to save some memory by reusing the existing
Script.
Eventually, all callers to CompilationCache::LookupScript should reuse
the Script if possible. This change implements only the easy case of
reusing the Script for synchronous parsing. Follow-up changes will be
required for the TODO comments left by this change.
Bug: v8:12808
Change-Id: Ia8b0389441a682de9a43e73329049fd2e7835d3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3597106
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80472}
The issue is that a thread_local variable used in RwxMemoryWriteScope
can't be directly accessed from another component, so the workaround is
to avoid inlining accesses the variable into other components.
Bug: v8:12797, chromium:1324333
Change-Id: I0f83358ac0c663c92ef7b3dff54a068472d61aed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3641169
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80470}
