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}
Mostly in comments, not much to be said...
Bug: v8:12425
Change-Id: Ib1e4d3913f9b91eeafefbef13330fd1388223c06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3650597
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80562}
This is a reland of commit 2b79eefed3
A DCHECK was using map[key] and inadvertently inserted into the map
that way.
Original change's description:
> Reland^2: [heap] Store size with invalidated object
>
> This is a reland of commit 23b2d571a7
>
> 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 not strictly necessary.
>
> 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.
>
> Reason for reverts:
>
> Revert #2: In-object slack tracking on JSObjects doesn't update the
> cached size of invalidated objects. The fix here was to stop
> invalidating recorded slots on JSObjects at all and avoid that problem
> completely (see https://crrev.com/c/3620274).
>
> Revert #1: 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.
>
> Bug: v8:12578, chromium:1316289
> Change-Id: I0478d04601c0270ddb39419ca6cf98719951eb4d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623542
> 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@{#80344}
Bug: v8:12578, chromium:1316289
Change-Id: Ibcc04c209213c584860a7c473082526cb4e53c59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3627635
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80542}
This CL adds to the existing experimental implementation of the
object start bitmap, that is evaluated as a mechanism for resolving
inner pointers (behind the flag v8_enable_conservative_stack_scanning).
It fixes method ObjectStartBitmap::FindBasePtr to ensure that the
correct base pointer is returned, even if the bitmap is not fully
populated (e.g., with object evacuation or inline object allocation).
This method now recalculates the part of the bitmap that is
required for returning the correct result, by iterating through
objects of the page. A special constructor has been introduced to the
PagedSpaceObjectIterator for this purpose.
It also moves the existing inline methods of ObjectStartBitmap to a
new -inl.h header file, to avoid circular dependencies.
Bug: v8:12851
Change-Id: Iabd0df020bee3bb63ef9d4888591b25d24d79dd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3641179
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@{#80538}
This test tests the interpreted/baseline and optimized behaviour of cpu
profiler ticks. We should eventually support this for maglev too, but
for now just disable it.
Bug: v8:7700
Change-Id: Iba89ab2c718025ebf90c86a84ed937c2d1d0af7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647363
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80531}
This is more consistent with similar features, for example
V8_ENABLE_WEBASSEMBLY or V8_ENABLE_MAGLEV.
Drive-by: remove V8_SANDBOX_IS_AVAILABLE as it's no longer needed.
Bug: v8:10391
Change-Id: I8658c5b0c331a4c73892737083b2c2f9b8f84056
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647355
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Samuel Groß <saelo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80530}
Now that we require C++17 support, we can just use the standard
static_assert without message, instead of our STATIC_ASSERT macro.
R=leszeks@chromium.org
Bug: v8:12425
Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80524}
This CL introduces SideEffectDetectorScope which requires explicit
allowlisting of cases when side effects are allowed after calling
interceptor callbacks.
Side effects are not allowed when the callback does not intercept
the request.
The side effects detector is not enabled yet, it will be enabled in
a follow-up CL.
Bug: chromium:1310062
Change-Id: I805764920ed016cb37390aef7bb02cbdf5f72846
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3641172
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80484}
NewSpace is renamed to SemiSpaceNewSpace and NewSpaceBase is renamed to
NewSpace (the new PagedSpace new space implementation will be named
PagedNewSpace).
Most usecases are updated to use the base class rather than the concrete
semi space based implementation. To that end, the base class is extended
with additional virtual methods (for delegating to the concrete class).
This CL follows these guidelines:
(*) If at a method callsite we should know the exact new space
implementation we use, we cast to the concrete class. This is the case
for example for callsites in scavenger.*.
(*) If a method is called from outside the heap implementation or should
be present regardless of the concrete implementation, that method is
made virtual.
(*) Other cases are usually methods that are specific to a concrete
implementation but the concrete implementation is not known at the
callsite and there's no clear way to nicely abstract the method. In such
cases we cast to the concrete SemiSpaceNewSpace implementation for now
and we will revisit these cases once PagedNewSpace exists.
Bug: v8:12612
Change-Id: I7b85626774ce0d785b0257bf8d32b9f50eeaf292
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625975
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80482}
Prototype the instruction on the interpreter, and Arm64. Details of
instruction lowerings on all relevant architectures can be found at:
https://github.com/WebAssembly/relaxed-simd/issues/40
Bug: v8:12284
Change-Id: Id4cb3889d94cf0bb7169ea068efe5ca68cfcbad9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3636365
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80475}
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}
In some cases we were still trying to change permissions of RWX pages
which is not allowed.
Bug: v8:12797
Change-Id: I9f4ca319d842c524fc6f60bfd3bb3726f8d3029d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3635719
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80442}
Builtins are not snapshotted, but instead we insert "builtin wrappers"
into the snapshot, and create references to the corresponding builtin
when deserializing.
Subclassing builtins will be implemented in a follow-up CL.
First version: https://chromium-review.googlesource.com/c/v8/v8/+/3630080
Fix: initialize builtin_objects_handle_
Bug: v8:11525,v8:12820
Change-Id: Ia2b5d41af5d7f577f1b02356b22a8760963009e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3635718
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80430}
Many uses of "volatile" are deprecated in C++20 because they don't
actually do anything. Remove "volatile" in these cases.
Bug: chromium:1284275
Change-Id: I64a3989d73f25e0cd933375dd6fa0b3f2b3acb54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630343
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80428}
Builtins are not snapshotted, but instead we insert "builtin wrappers"
into the snapshot, and create references to the corresponding builtin
when deserializing.
Subclassing builtins will be implemented in a follow-up CL.
Bug: v8:11525,v8:12820
Change-Id: If72695d46bdfc8bf7e477471be1264b668551854
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630080
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80419}
This is deprecated in C++20. Use constexprs and explicit casts to work
around.
Bug: chromium:1284275
Change-Id: I6a3974f3c678cb797081938622036a12a99c5d1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630349
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80392}
Change-Id: I88a1bbddc7604fc5e557ae875ca196cf9c46574c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3626453
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Neden Wang <nedenwang@tencent.com>
Cr-Commit-Position: refs/heads/main@{#80390}
In C++20, u8"" generates a const char8_t*, not a const char*. Since ""
accepts UTF-8 already, just switch to it.
Bug: chromium:1284275
Change-Id: I873321a62a4d9e32b3b463913a3bc10231db3db3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630347
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80382}
This prevents ambiguity errors in C++20 due to ADL when casting types in
std::, which gains std::bit_cast<>().
Bug: chromium:1284275
Change-Id: I25046d1952a9304852e481ad8b84049c6769c289
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625838
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80378}
This CL cleans up the existing experimental implementation of
conservative stack scanning. It retains the object start bitmap, to
evaluate it as a mechanism for resolving inner pointers, and the
conservative stack scanning visitor (which is currently not used).
The flag v8_enable_conservative_stack_scanning is kept and will be
used for experimental purposes. It currently does not imply any
other flag.
Bug: v8:10614
Bug: v8:12851
Change-Id: Id0ae0f437ed2601eed9ec634d2d1dd2f030d814e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602516
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80365}
This reverts commit 2b79eefed3.
Reason for revert: Speculative revert because of https://crbug.com/1322305
Original change's description:
> Reland^2: [heap] Store size with invalidated object
>
> This is a reland of commit 23b2d571a7
>
> 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 not strictly necessary.
>
> 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.
>
> Reason for reverts:
>
> Revert #2: In-object slack tracking on JSObjects doesn't update the
> cached size of invalidated objects. The fix here was to stop
> invalidating recorded slots on JSObjects at all and avoid that problem
> completely (see https://crrev.com/c/3620274).
>
> Revert #1: 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.
>
> Bug: v8:12578, chromium:1316289
> Change-Id: I0478d04601c0270ddb39419ca6cf98719951eb4d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623542
> 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@{#80344}
Bug: v8:12578, chromium:1316289
Change-Id: I6dd2dd13583123b9cb7933b15e2113fddc0c0b0b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3627511
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80357}
This is a reland of commit 23b2d571a7
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 not strictly necessary.
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.
Reason for reverts:
Revert #2: In-object slack tracking on JSObjects doesn't update the
cached size of invalidated objects. The fix here was to stop
invalidating recorded slots on JSObjects at all and avoid that problem
completely (see https://crrev.com/c/3620274).
Revert #1: 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.
Bug: v8:12578, chromium:1316289
Change-Id: I0478d04601c0270ddb39419ca6cf98719951eb4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623542
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@{#80344}
To be consistent with the all the other tiers and avoid confusion, we
rename --opt to ---turbofan, and --always-opt to --always-turbofan.
Change-Id: Ie23dc8282b3fb4cf2fbf73b6c3d5264de5d09718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610431
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80336}
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}
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}
