When formatting console messages (for consumption in Chromium/Blink), we
have special logic to unwrap value wrapper objects. But this logic was
not very consistent, and especially Number values and NumberObject
values were formatted differently.
This changes the V8ValueStringBuilder::append() logic to always unwrap
any value wrapper first and then use the regular dispatch for the
primitive value.
Fixed: chromium:1321833
Change-Id: I9996671e1f91da0841e5d5f1687cf647ab72a561
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3622913
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80323}
This change adds support for computing SHA-256 hashes in the stack
output of errors by adding a function to the prototype of the
`CallSite` object, passed to `Error.prepareStackTrace`. Additionally,
it updates the `hash` property from `Debugger.scriptParsed` and
`Debugger.scriptFailedToParse` to be SHA-256 instead of the
proprietary hash it is today.
It is intended to be an advancement in indexing source maps to
support improved tooling, especially for post-hoc or in-production
diagnostics scenarios.
The explainer can be found here:
https://docs.google.com/document/d/13hNeeLC2Ve_FVieNndZUUUP15x2O4ltvjnGWwOsMlrU/edit?usp=sharing
Change-Id: Ifbbed4b22c8256e74e6d79974d2dd1e444143eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229957
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Robert Paveza <Rob.Paveza@microsoft.com>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80320}
This is a reland of commit 8960031432
Changes since revert: None, reverted wrong suspect CL
Original change's description:
> [Temporal] Fix Calendar.prototype.fields CSA
>
> Use LoadAndUntagToWord32ObjectField instead of LoadObjectField<Uint32T>
> to load the flag since it is defined as
> flags: SmiTagged<JSTemporalCalendarFlags>;
>
> Otherwise LoadObjectField<Uint32T> will load the zero part when
> v8_enable_pointer_compression = false
>
> Add unit tests to intl (because the problem only show up on calendar
> other than non iso8601.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_mipsel_compile_rel,v8_linux_mips64el_compile_rel
>
>
> Bug: v8:12848
> Change-Id: I44b685af99dc9820dfa228447e2b42ae0a82464c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3617388
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80314}
Bug: v8:12848
Change-Id: I423ea5f0a4a30fc73546df208d24aec84db76eb4
Cq-Include-Trybots: luci.v8.try:v8_linux_mipsel_compile_rel,v8_linux_mips64el_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620838
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80319}
This reverts commit 8960031432.
Reason for revert: UBSAN errors in GC tests
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/21069/overview
Original change's description:
> [Temporal] Fix Calendar.prototype.fields CSA
>
> Use LoadAndUntagToWord32ObjectField instead of LoadObjectField<Uint32T>
> to load the flag since it is defined as
> flags: SmiTagged<JSTemporalCalendarFlags>;
>
> Otherwise LoadObjectField<Uint32T> will load the zero part when
> v8_enable_pointer_compression = false
>
> Add unit tests to intl (because the problem only show up on calendar
> other than non iso8601.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_mipsel_compile_rel,v8_linux_mips64el_compile_rel
>
>
> Bug: v8:12848
> Change-Id: I44b685af99dc9820dfa228447e2b42ae0a82464c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3617388
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80314}
Bug: v8:12848
Change-Id: I3a8af8acbbdfc5d0f5386f2a9d50d62b9f422fb8
Cq-Include-Trybots: luci.v8.try:v8_linux_mipsel_compile_rel,v8_linux_mips64el_compile_rel
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620837
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80317}
This is a reland of commit 445190bf99
The fix addresses the issue where object size accounting went out of
sync because of right-trimmed LO in new space that were migrated with
a different size than they were accounted for.
The fix now iterates only live objects for size computation which
avoids accessing reclaimed maps and fixes up the objects accounting.
Original change's description:
> [heap] Fix bogus object size computation
>
> The map of an object may be gone by the time we try to compute its
> size for accounting purposes.
>
> Bug: chromium:1319217
> Change-Id: I93cca766a8cedebf4ed30a3a65fd6eff5bc72bcf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605817
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80271}
Bug: chromium:1319217
Change-Id: I8d032edf96a4bf4b0faa4bbd9b0be247051c49fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616507
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80316}
This is a reland of commit c575e8ae97
Original change's description:
> PPC/S390: Reland "[osr] Use the new OSR cache"
>
> Port 9145388055
>
> Original Commit Message:
>
> This is a reland of commit 91da38831d
>
> Original change's description:
> > Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
> > on arm64.
> > Bug: v8:12161
>
> Change-Id: I6e63bd5995340bac32654ef12c52d25b496140e3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607997
> Reviewed-by: Junliang Yan <junyan@redhat.com>
> Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
> Cr-Commit-Position: refs/heads/main@{#80194}
Change-Id: Id5e41c659a3c29a6d22c0393ad0003a24fa1ef5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3621273
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80315}
Use LoadAndUntagToWord32ObjectField instead of LoadObjectField<Uint32T>
to load the flag since it is defined as
flags: SmiTagged<JSTemporalCalendarFlags>;
Otherwise LoadObjectField<Uint32T> will load the zero part when
v8_enable_pointer_compression = false
Add unit tests to intl (because the problem only show up on calendar
other than non iso8601.
Cq-Include-Trybots: luci.v8.try:v8_linux_mipsel_compile_rel,v8_linux_mips64el_compile_rel
Bug: v8:12848
Change-Id: I44b685af99dc9820dfa228447e2b42ae0a82464c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3617388
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80314}
Oilpan Young Generation is now controlled by the runtime flag
--cppgc-young-generation.
Bug: chromium:1029379
Change-Id: I9ded9637f43a2f86993cff898cd7f272a051ae3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616728
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80312}
This reverts commit 25e3225286.
Reason for revert: Suspect for roll failure: https://ci.chromium.org/ui/p/chromium/builders/try/android_optional_gpu_tests_rel/98554/overview
Original change's description:
> Reland "[heap] Refactor atomic marking phase"
>
> This is a reland of commit a3f66927f9
>
> The reland addresses a few CHECKs that were too agressive and also
> properly adjusts Oilpan's marking configurations depending on V8's
> flags.
>
> Original change's description:
> > [heap] Refactor atomic marking phase
> >
> > The atomic marking phase was organized in many distinct smaller
> > phases. In particular, before http://crrev.com/c/3584115 the marking
> > phase split into two large separate phases.
> >
> > This CL reorganizes marking into two phases that perform regular V8
> > heap marking, Oilpan, and ephemerons:
> > - A parallel phase that likely drains all marking worklists;
> > - A single-threaded final phase to catch any left overs;
> >
> > This avoids artificial splitting in phases and also avoids repeated
> > starting and joining of jobs.
> >
> > Change-Id: I5cccfc5777837d9ece10d8f4925781bf2d07d9da
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602507
> > Reviewed-by: Omer Katz <omerkatz@chromium.org>
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80265}
>
> Change-Id: I26648da361b92d787c173aa9d390100ce8958728
> Bug: chromium:1320896
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616519
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80301}
Bug: chromium:1320896
Change-Id: I01742f25d54de8e4e22fefe87ce61ba295950baa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620286
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: 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@{#80311}
I was trying to build chromium with Perfetto enabled and I ran into this
compilation error:
```
../../v8/src/libplatform/tracing/recorder-win.cc(48,42): error: no member named 'GetCategoryGroupName' in 'v8::platform::tracing::TracingController'
TracingController::GetCategoryGroupName(
~~~~~~~~~~~~~~~~~~~^
1 error generated.
```
This happens because the GetCategoryGroupName() function is added to
the TracingController class only if Perfetto is disabled.
Signed-off-by: Darshan Sen <raisinten@gmail.com>
Change-Id: If53dab5ea9b8c3e2f69e8e84c8d6ba06ee3c496e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616427
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80310}
https://crrev.com/c/3571817 introduced a bug that string table lookups
failed on SlicedStrings with a start offset of 0.
This CL fixes the issue by re-using the already computed hash only
if the length of the source string matches the length of the string to
lookup.
Bug: chromium:1320179, chromium:1321573
Change-Id: Ic8755a0266a9ec67fe5eb9c96fdab1b55d5009f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616723
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80309}
In Sampler::DoSample, we only guard SignalHandler::Installed before
and Sampler::Stop may happen at the same time, which may cause SIGPROF
signal handler was already restored before SIGPROF was emit and trigger
profiling timer expired. This CL changes Sampler::DoSample to use
SignalHandler::mutex() to guard the entire function and also change
the mutex to recursive mutex.
Bug: v8:12838
Change-Id: I5195742ecdbade342986755233840d7be5d83c62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616429
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#80308}
We usually run benchmarks in multiple variants: default, future, noopt
This is currently only achieved by copying the run-perf json file and
changing the flags at the top-level (or copy whole subsections).
Using "variants" we can duplicate the tests at the current level with
different values and easily create benchmarks that differ only in v8
flags.
Drive-by-fix:
- Add Node.__iter__ and log the whole config graph in debug mode
- Add GraphConfig.__str__ method for better debugging
- Rename TraceConfig to LeafTraceConfig
- Rename RunnableTraceConfig to RunnableLeafTraceConfig
- Make --filter accept a regexp to better filter out variants
Bug: v8:12821, v8:11113
Change-Id: I56a2ba2dd24da15c7757406e9961746219cd8061
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596128
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80307}
This is a reland of commit 9145388055
Fixed: properly reference the ClearedValue in CSA (i.e. without
the cage_base upper 32 bits).
Original change's description:
> Reland "[osr] Use the new OSR cache"
>
> This is a reland of commit 91da38831d
>
> Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
> on arm64.
>
> Original change's description:
> > [osr] Use the new OSR cache
> >
> > This CL switches over our OSR system to be based on the feedback
> > vector osr caches.
> >
> > - OSRing to Sparkplug is fully separated from OSR urgency. If
> > SP code exists, we simply jump to it, no need to maintain an
> > installation request.
> > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> > If a valid target code object exists, we enter it *without*
> > calling into runtime to fetch the code object.
> > - Finally, OSR urgency still remains as the heuristic for
> > requesting Turbofan OSR compile jobs. Note it no longer has a
> > double purpose of being a generic untargeted installation
> > request.
> >
> > With the new system in place, we can remove now-unnecessary
> > hacks:
> >
> > - Early OSR tierup is replaced by the standard OSR system. Any
> > present OSR code is automatically entered.
> > - The synchronous OSR compilation fallback is removed. With
> > precise installation (= per-JumpLoop-bytecode) we no longer
> > have the problem of 'getting unlucky' with JumpLoop/cache entry
> > mismatches. Execution has moved on while compiling? Simply spawn
> > a new concurrent compile job.
> > - Remove the synchronous (non-OSR) Turbofan compile request now
> > that we always enter available OSR code as early as possible.
> > - Tiering into Sparkplug no longer messes with OSR state.
> >
> > Bug: v8:12161
> > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> > Commit-Queue: Jakob Linke <jgruber@chromium.org>
> > Auto-Submit: Jakob Linke <jgruber@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80147}
>
> Bug: v8:12161
> Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80167}
Bug: v8:12161,chromium:1320189
Change-Id: Ibd9a2ab61f51ebb32a3f5a66f7c602faead71c3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620273
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80306}
The CL prepares the sources and the tests for enabling
cppgc_enable_young_generation by default. The static initializer
in YoungGenerationEnabler (due to v8::base::Mutex) changed to be lazy.
The tests are now checking the runtime flag.
Bug: chromium:1029379
Change-Id: I1497a3dd2b8d62c1acd48496821f07324b7944d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616726
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80304}
When deleting a JSObject's last property, only that particular slot
in the old-to-new rememebered set needs to be deleted. The object's
slots don't need to be invalidated anymore since V8 doesn't use
unboxed doubles anymore. While the runtime could install another
property at this address, it will therefore always be a tagged pointer.
Bug: v8:12578, chromium:1316289
Change-Id: Ief072f58e53501c1c1f01c902e21467a37ccdc3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620274
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80303}
This is a reland of commit a3f66927f9
The reland addresses a few CHECKs that were too agressive and also
properly adjusts Oilpan's marking configurations depending on V8's
flags.
Original change's description:
> [heap] Refactor atomic marking phase
>
> The atomic marking phase was organized in many distinct smaller
> phases. In particular, before http://crrev.com/c/3584115 the marking
> phase split into two large separate phases.
>
> This CL reorganizes marking into two phases that perform regular V8
> heap marking, Oilpan, and ephemerons:
> - A parallel phase that likely drains all marking worklists;
> - A single-threaded final phase to catch any left overs;
>
> This avoids artificial splitting in phases and also avoids repeated
> starting and joining of jobs.
>
> Change-Id: I5cccfc5777837d9ece10d8f4925781bf2d07d9da
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602507
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80265}
Change-Id: I26648da361b92d787c173aa9d390100ce8958728
Bug: chromium:1320896
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616519
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80301}
... not exceeding the maximum size of the backing store
before ReplacementStringBuilder in StringReplaceGlobalRegExpWithString.
Bug: v8:12843
Change-Id: I3ccf07a4e6de35a3a571ebfccc34e54eb27a0819
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616555
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#80298}
We weren't really translating between location (line and column number)
and source position (character offset) consistently, especially when it
came to inline <script>s. There were also inconsistencies between what
Debugger.getPossibleBreakpoints and Debugger.setBreakpointByUrl would
do.
With this CL, we are now consistently operating under the following
assumptions:
(1) For inline <scripts>s with a //@ sourceURL annotation, we assume
that the line and column number that comes in via the protocol is
in terms of the source text of the script.
(2) For inline <script>s without said annotation, we assume that the
line and column numbers are in terms of the surrounding document.
This is finally aligned with how the DevTools front-end operates.
Fixed: chromium:1319828
Change-Id: I98c4ef04b34a97caf060ff4f32690b135edb6ee6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610622
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80292}
This reverts commit 23b2d571a7.
Reason for revert: Breaks the V8 roll https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/1000394/
Original change's description:
> Reland "[heap] Store size with invalidated object"
>
> This is a reland of commit 5d235def26
>
> The previous version of this CL got reverted because the cached
> size of an invalidated object wasn't up-to-date when performing a GC.
>
> Not all size changes go through NotifyObjectLayoutChange, so
> https://crrev.com/c/3607992 introduced NotifyObjectSizeChange as a
> bottleneck for object size changes/right-trimming. This method is
> now used to update the size of invalidated objects.
>
> Original change's description:
> > [heap] Store size with invalidated object
> >
> > When updating pointers during a full GC, a page might not be swept
> > already. In such cases there might be invalid objects and slots recorded
> > in free memory. Updating tagged slots in free memory is fine even though
> > it is superfluous work.
> >
> > However, the GC also needs to calculate the size of potentially dead
> > invalid objects in order to be able to check whether a slot is within
> > that object. But since that object is dead, its map might be dead as
> > well which makes size calculation impossible on such objects. The CL
> > changes this to cache the size of invalid objects. A follow-up CL will
> > also check the marking bit of invalid objects.
> >
> > Bug: v8:12578, chromium:1316289
> > Change-Id: Ie773d0862a565982957e0dc409630d76552d1a32
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599482
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Reviewed-by: Jakob Linke <jgruber@chromium.org>
> > Reviewed-by: Patrick Thier <pthier@chromium.org>
> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80169}
>
> Bug: v8:12578, chromium:1316289
> Change-Id: I1f7c6070b8e7d116aeb1a8d03d4f87927ab40872
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608632
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80262}
Bug: v8:12578, chromium:1316289
Change-Id: I88b73ebe09bb923ba4ac57b0dbdceb08a1badd99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616730
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Owners-Override: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80291}
This reverts commit 9145388055.
Reason for revert: Breaking the Fuchsia Deterministic Builder
Original change's description:
> Reland "[osr] Use the new OSR cache"
>
> This is a reland of commit 91da38831d
>
> Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
> on arm64.
>
> Original change's description:
> > [osr] Use the new OSR cache
> >
> > This CL switches over our OSR system to be based on the feedback
> > vector osr caches.
> >
> > - OSRing to Sparkplug is fully separated from OSR urgency. If
> > SP code exists, we simply jump to it, no need to maintain an
> > installation request.
> > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> > If a valid target code object exists, we enter it *without*
> > calling into runtime to fetch the code object.
> > - Finally, OSR urgency still remains as the heuristic for
> > requesting Turbofan OSR compile jobs. Note it no longer has a
> > double purpose of being a generic untargeted installation
> > request.
> >
> > With the new system in place, we can remove now-unnecessary
> > hacks:
> >
> > - Early OSR tierup is replaced by the standard OSR system. Any
> > present OSR code is automatically entered.
> > - The synchronous OSR compilation fallback is removed. With
> > precise installation (= per-JumpLoop-bytecode) we no longer
> > have the problem of 'getting unlucky' with JumpLoop/cache entry
> > mismatches. Execution has moved on while compiling? Simply spawn
> > a new concurrent compile job.
> > - Remove the synchronous (non-OSR) Turbofan compile request now
> > that we always enter available OSR code as early as possible.
> > - Tiering into Sparkplug no longer messes with OSR state.
> >
> > Bug: v8:12161
> > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> > Commit-Queue: Jakob Linke <jgruber@chromium.org>
> > Auto-Submit: Jakob Linke <jgruber@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80147}
>
> Bug: v8:12161
> Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80167}
Bug: v8:12161
Change-Id: I73e2d98660e9edfbe07a152a14402380ea9227de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615219
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80287}
During weak processing we remember weak callbacks for objects in the old
generation. We should check the young-gc flag and enable generational GC
before weak processing, as otherwise we would miss the callbacks and
forget to update the weak refs.
Bug: chromium:1029379
Change-Id: I72c98d4926b57c36af6cc503ce34712f67d50f42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616721
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80286}
Introduce get_hints.py and combine_hints.py in order to make
the interpretation of basic block counts into hints more
configurable and explicit, as well as allowing more accurate
and consistent methods of combining multiple profiles.
get_hints.py allows for the minimum count and threshold ratio
values to be easily altered for different profiles, while
combine_hints.py allows the hints produced from different
benchmarks and threshold values to be easily and sensibly
combined.
Simply summing together basic block counts from different
benchmarks could previously lead to a longer running benchmark
overshadowing multiple shorter benchmarks with conflicting
hints.
Allowing alteration of the current threshold values gives a
doubling of performance, while the new method of combining
distinct profiles can double the performance improvement of the
secondary benchmark while losing as little as 4% of the
improvement gained in the primary benchmark.
Design doc: https://docs.google.com/document/d/1OhwZnIZom47IX0lyceyt-S9i8AApDB0UqJdvQD6NuKQ/edit?usp=sharing
Bug: v8:10470
Change-Id: I1c09d1eabfdda5ed6794592e2c13ff8b461be361
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545181
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: George Wort <george.wort@arm.com>
Cr-Commit-Position: refs/heads/main@{#80282}
The CL uses the different scheme to enable the generational barrier. The
separate global counter (is_enabled_) keeps track of the number of heaps
that enable generational GC. If at least one of the heaps enables the
generational GC, the counter will enable the write barrier. Technically,
the counter could be merged with WriteBarrier::is_enabled_, but having a
separate variable allows us to keep DCHECKs if generational barrier is
enabled.
Bug: chromium:1029379
Change-Id: Iafaa76f96acb18a73f8bde7231434e68c04cb683
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616518
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80281}
This make it easier to follow which function was compiled when many
maglev graphs are outputted.
Bug: v8:7700
Change-Id: If88f6d4aa7306df8a26601f081105bff0eb9c5e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616513
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80279}
The CL introduces a new option --cppgc-young-generation. This option
can't be enabled statically, because V8 options are parsed after heap
initialization. The CL changes minor GC so that it can be enabled
dynamically. The way it works is as follows:
- the user calls YoungGenerationEnabler::Enable();
- a heap checks in the next atomic pause whether the flag was enabled;
- if so, the heap enables young generation for itself.
To avoid barrier regressions without young-generation enabled, the CL changes the meaning of the global flag is-any-incremental-or-concurrent-marking to is-barrier-enabled.
The runtime option would enable us to test young generation on try-
and performance-bots.
Bug: chromium:1029379
Change-Id: I664cccdcd208225ffcbf9901f1284b56d088c5c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607993
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80274}
