In order to be able to iterate all objects in the heap (including
SHARED_SPACE), all LABs in the shared space need to be iterable. For this reason the HeapObjectIterator needs to perform a global safepoint for the shared heap isolate.
Bug: v8:13267
Change-Id: I2b7583fac0564f8b98b74607404be851fde1281f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3978091
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83939}
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}
This CL fixes the remaining test failures when running test with the
--shared-heap flag locally:
* Remove uses of shared_isolate()
* Fix slot recording in Mark-Compact and Scavenger
* Fixes DCHECKs in tests that do not hold with --shared-heap
Bug: v8:13267
Change-Id: I6869ece70f1e6156d9bb1281e6cd876cf8d471eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3918377
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83530}
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}
Currently the ability to create shared isolates is partially exposed to
API. Instead of fully exposing it, this CL makes shared isolate and
shared heap handling transparent to the embedder.
If a flag that requires the shared heap is true (currently
--shared-string-table and --harmony-struct), the first isolate created
in the process will create and attach to a process-wide shared isolate.
Subsequent isolates will attach to that shared isolate. When that first isolate is deleted, the shared isolate is also deleted.
Bug: v8:12547
Change-Id: Idaf2947bc354066c44f2d10243e10162b1b7e4d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3848825
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Owners-Override: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82756}
This allows V8 to be compiled without zlib.
Currently we use zlib for 3 features:
1. Snapshot compression. The cl asserts v8_snapshot_compression
implies v8_use_zlib.
2. Compression of translation arrays (experimental flag). The runtime
flag is only enabled if v8_use_zlib.
3. Snapshot checksums. We fallback to a simple Fletcher algorithm if
v8_use_zlib is false.
Change-Id: If043c3c21bba4d734573d7e1199d3ddf17b84f41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3833817
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82527}
... - 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}
JSTypedArray needs the base_pointer ByteArray immediately
if it's on heap. JSTypedArray's base_pointer was initialized
to Smi::uninitialized_deserialization_value at first when
deserializing, and if base_pointer was deferred, we will
mistakenly check JSTypedArray not on heap.
Bug: v8:13149
Change-Id: I104c83ff9a2017de1c8071a9e116baa602f6977d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3813068
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#82254}
This is a reland of commit 07e11a64e4.
The original change removed the fill_thehole_and_call_runtime bailout
in StringBuiltinsAssembler::StringToArray() so when the string
is external and cannot be unpacked, the FixedArray won't be filled
with holes before we call into the runtime, thus failing a
heap verification if a GC happens before the array is filled. This
reland adds back the bailout for this case.
Bug: v8:12718, chromium:1330410
Original change's description:
> [heap] pre-populate the single_character_string_cache
>
> This simplifies the code and removes the runtime overhead of
> spontaneously adding strings to the cache.
>
> Bug: v8:12718
> Change-Id: I2ed49bd82e3baf2563eeb8f463be72c0308c52c5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616553
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#80803}
Change-Id: I25e8724d511a8d0d971fa2a9b6ba8a0eafce4413
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793525
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82082}
Previously SnapshotCreator demanded a blob to be created before
it can be destructed in debug build, this patch removes the
DCHECK so that the embedder can choose not to create the blob
when e.g. the snapshot building isn't successful due to errors.
Change-Id: I72939be1e0d79b257b9761f48a72e45325a1f6d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716682
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#81644}
In the case of bugs creating shared->local edges, this lets us catch
dangling pointers via CHECKs before they happen.
Also removed some redundant checks in the shared struct verifier.
Existing heap verification already checks that all of a Heap's pointers
are contained within it.
Bug: v8:12547
Change-Id: Ic7a007b3b6559e3dfd0286fbf869586023c6f801
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3704911
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81335}
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}
This is a reland of commit c443858fa9
The original version included an operation which could left-shift
signed values, which is undefined behavior; the updated version masks
the value first to avoid the problem.
Original change's description:
> Allow lookup of matching scripts in Isolate compilation cache
>
> Currently, if the same script text is compiled multiple times with
> differing details (such as name, line number, or host-defined options),
> then multiple copies of that script are added to the Isolate's
> compilation cache. However, any attempt to look up those scripts can
> find only the first instance. This change makes the script compilation
> cache behave more consistently by checking the details while searching
> the hash table for a match, rather than after a potential match has been
> found.
>
> Bug: v8:12808
> Change-Id: Ic9da0bf74f359d4f1c88af89d585404f173056ee
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3671615
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#80919}
Bug: v8:12808
Change-Id: I494c3c9cc520b79f34247aab6618c40c854b9edc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687070
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#81007}
It is now considered best effort, that in-place internalizable strings
are promoted into the shared old space instead of non-shared old space.
This was previously an invariant, but it doesn't hold if the whole page
containing the shared string is promoted instead of individual objects.
In addition with conservative stack scanning individual objects won't be
moved.
Bug: v8:12007
Change-Id: I7474738b02b0c18080cb2e82268a02bf9b480c40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688512
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80969}
This reverts commit c443858fa9.
Reason for revert: Several UBSan failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/21547/overview
Original change's description:
> Allow lookup of matching scripts in Isolate compilation cache
>
> Currently, if the same script text is compiled multiple times with
> differing details (such as name, line number, or host-defined options),
> then multiple copies of that script are added to the Isolate's
> compilation cache. However, any attempt to look up those scripts can
> find only the first instance. This change makes the script compilation
> cache behave more consistently by checking the details while searching
> the hash table for a match, rather than after a potential match has been
> found.
>
> Bug: v8:12808
> Change-Id: Ic9da0bf74f359d4f1c88af89d585404f173056ee
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3671615
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#80919}
Bug: v8:12808
Change-Id: I6d007374fb607a2670ca260c6bd0d6774d7f51d7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687311
Auto-Submit: Deepti Gandluri <gdeepti@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@{#80922}
Currently, if the same script text is compiled multiple times with
differing details (such as name, line number, or host-defined options),
then multiple copies of that script are added to the Isolate's
compilation cache. However, any attempt to look up those scripts can
find only the first instance. This change makes the script compilation
cache behave more consistently by checking the details while searching
the hash table for a match, rather than after a potential match has been
found.
Bug: v8:12808
Change-Id: Ic9da0bf74f359d4f1c88af89d585404f173056ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3671615
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80919}
Replace all usages of UPDATE_WEAK_WRITE_BARRIER with
UPDATE_WRITE_BARRIER. The barrier wasn't hot, so the additional branch
for the marking barrier shouldn't be a problem.
Performing the marking barrier could in theory cause more floating
garbage. However in this case the write barrier is only run once
directly after e.g. allocating a Code or NativeContext object. Since
UPDATE_WEAK_WRITE_BARRIER only skips the marking barrier, we should only
observe different behavior when marking is on. But since we already
have black allocation for objects in old space, we will not cause
additional floating garbage.
In case of performance regression, we should also be able to replace
those usages with SKIP_WRITE_BARRIER, since NativeContext and Code
objects are never allocated in the young generation, so running the
generational barrier shouldn't be necessary. It's just hard to DCHECK
that SKIP_WRITE_BARRIER is valid here.
Bug: v8:11708
Change-Id: I25d760a46d1d7ec973cc589f51ddf80ca3b5419d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663080
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80839}
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}
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}
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}
* Prefix all isolate variables with i_ for i::Isolate and
v8_ for v8::Isolate
* Change _DO_NOT_USE macro suffix to _INTERNAL
Change-Id: I005efbe0192cf202741448c63a4263e6a4b1fa1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610429
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80252}
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}
This reverts commit 91da38831d.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression%20-%20builder/21150/overview
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: I4a6955f4f20b6f3b13e98d5600c7c6a5205915bc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605608
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80148}
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}
- Rename CodeEventDispatcher to LogEventDispatcher
- Use std::vector instead of std::unordered_set, dispatching speed is
more important than addition/removal of listeners
- Changing the LogEventDispatcher code to be more code-search friendly
- Use a raw pointer for the LogEventDispatcher instance on the isolate
it's a single-owned entity
Bug: v8:12795
Change-Id: I139f05431519c18cba33d1506467be918f52658c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3582125
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79990}
- Restructure the runtime function implementation.
- Rename osr_loop_nesting_level to osr_urgency and add helpers.
The motivation for the latter: I've always struggled with the
`osr_loop_nesting_level` term; it neither matches terminology of
what it's compared against (= the loop depth), nor implies what it's
used for (= osr is triggered when `loop depth < osr nesting level`).
In this CL it's renamed to `osr_urgency` to reflect that as urgency
rises, we consider more and more loops as OSR candidates.
Bug: v8:12161
Change-Id: I194ec5a3f1f02526641af1c7796ee0956b6fd3a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528735
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79509}
Instead of implementing ExternalObjects as plain JSObjects with a single
EmbedderDataSlot pointing to a Foreign containing the actual raw
pointer, this CL now creates a new JSExternalObject type that directly
contains the external pointer.
As a side-effect of this refactoring, nullptr values are now no longer
valid for ExternalObjects.
Change-Id: Ic8ff334681c966e823ca70f34dd1efaaa21a0789
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/+/3513234
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79459}
Currently the Isolate is gotten off of the object that the operation is
being performed on. GetDataProperty may end up using a per-Isolate
lookup cache, which is not threadsafe when the Isolate is shared. Plumb
the executing, non-shared Isolate through.
Bug: v8:12646, v8:12547
Change-Id: Ia08ece9a9e8cbd7eba9ea38b01caa511895f5bf4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3475084
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79180}
Originally, the accessors wont be copied into global object from
deserialized global. And the accessors in serialized global object
will be lost. Fix to copy accessors in deserialized global
into global object when recreating new global object using passed
global proxy template.
Tests credited to xiangyangemail@gmail.comhttps://chromium-review.googlesource.com/c/v8/v8/+/3405405
Bug: v8:12564
Change-Id: Iefb3a6dbfa5445b227d87c26eb423cf1b924dbb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3459937
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79087}
This is a reland of 91f08378bc
When the class scope does not need a context, the deserialized
outer scope of the initializer scope would not be the class scope,
and we should not and do not need to use it to fix up the allocation
information of the context-allocated variables. The original patch
did not consider this case and resulted in a regression when we
tried to reparse the initializer function to look for destructuring
assignment errors. This fixes the regression by not deserializing
the class scope that's going to be reparsed, and using the positions
of the scopes to tell whether the scope info matches the reparsed
scope and can be used to fix up the allocation info.
Original change's description:
> [class] implement reparsing of class instance member initializers
>
> Previously, since the source code for the synthetic class instance
> member initializer function was recorded as the span from the first
> initializer to the last initializer, there was no way to reparse the
> class and recompile the initializer function. It was working for
> most use cases because the code for the initializer function was
> generated eagarly and it was usually alive as long as the class was
> alive, so the initializer wouldn't normally be lazily parsed. This
> didn't work, however, when the class was snapshotted with
> v8::SnapshotCreator::FunctionCodeHandling::kClear,
> becuase then we needed to recompile the initializer when the class
> was instantiated. This patch implements the reparsing so that
> these classes can work with FunctionCodeHandling::kClear.
>
> This patch refactors ParserBase::ParseClassLiteral() so that we can
> reuse it for both parsing the class body normally and reparsing it
> to collect initializers. When reparsing the synthetic initializer
> function, we rewind the scanner to the beginning of the class, and
> parse the class body to collect the initializers. During the
> reparsing, field initializers are parsed with the full parser while
> methods of the class are pre-parsed.
>
> A few notable changes:
>
> - Extended the source range of the initializer function to cover the
> entire class so that we can rewind the scanner to parse the class
> body to collect initializers (previously, it starts from the first
> field initializer and ends at the last initializer). This resulted
> some expectation changes in the debugger tests, though the
> initializers remain debuggable.
> - A temporary ClassScope is created during reparsing. After the class
> is reparsed, we use the information from the ScopeInfo to update
> the allocated indices of the variables in the ClassScope.
>
> Bug: v8:10704
> Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#78299}
Bug: chromium:1278086, chromium:1278085, v8:10704
Change-Id: Iea4f1f6dc398846cbe322adc16f6fffd6d2dfdf3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325912
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78745}
This reverts commit 91f08378bc.
Reason for revert: It's a fairly big change, and the clusterfuzz
found some bugs. Will reland with the fix after M98 branch point.
Original change's description:
> [class] implement reparsing of class instance member initializers
>
> Previously, since the source code for the synthetic class instance
> member initializer function was recorded as the span from the first
> initializer to the last initializer, there was no way to reparse the
> class and recompile the initializer function. It was working for
> most use cases because the code for the initializer function was
> generated eagarly and it was usually alive as long as the class was
> alive, so the initializer wouldn't normally be lazily parsed. This
> didn't work, however, when the class was snapshotted with
> v8::SnapshotCreator::FunctionCodeHandling::kClear,
> becuase then we needed to recompile the initializer when the class
> was instantiated. This patch implements the reparsing so that
> these classes can work with FunctionCodeHandling::kClear.
>
> This patch refactors ParserBase::ParseClassLiteral() so that we can
> reuse it for both parsing the class body normally and reparsing it
> to collect initializers. When reparsing the synthetic initializer
> function, we rewind the scanner to the beginning of the class, and
> parse the class body to collect the initializers. During the
> reparsing, field initializers are parsed with the full parser while
> methods of the class are pre-parsed.
>
> A few notable changes:
>
> - Extended the source range of the initializer function to cover the
> entire class so that we can rewind the scanner to parse the class
> body to collect initializers (previously, it starts from the first
> field initializer and ends at the last initializer). This resulted
> some expectation changes in the debugger tests, though the
> initializers remain debuggable.
> - A temporary ClassScope is created during reparsing. After the class
> is reparsed, we use the information from the ScopeInfo to update
> the allocated indices of the variables in the ClassScope.
>
> Bug: v8:10704
> Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#78299}
Bug: v8:10704
Change-Id: I039cb728ebf0ada438a8f26c7d2c2547dbe3bf2d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325328
Auto-Submit: Joyee Cheung <joyee@igalia.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78315}
Previously, since the source code for the synthetic class instance
member initializer function was recorded as the span from the first
initializer to the last initializer, there was no way to reparse the
class and recompile the initializer function. It was working for
most use cases because the code for the initializer function was
generated eagarly and it was usually alive as long as the class was
alive, so the initializer wouldn't normally be lazily parsed. This
didn't work, however, when the class was snapshotted with
v8::SnapshotCreator::FunctionCodeHandling::kClear,
becuase then we needed to recompile the initializer when the class
was instantiated. This patch implements the reparsing so that
these classes can work with FunctionCodeHandling::kClear.
This patch refactors ParserBase::ParseClassLiteral() so that we can
reuse it for both parsing the class body normally and reparsing it
to collect initializers. When reparsing the synthetic initializer
function, we rewind the scanner to the beginning of the class, and
parse the class body to collect the initializers. During the
reparsing, field initializers are parsed with the full parser while
methods of the class are pre-parsed.
A few notable changes:
- Extended the source range of the initializer function to cover the
entire class so that we can rewind the scanner to parse the class
body to collect initializers (previously, it starts from the first
field initializer and ends at the last initializer). This resulted
some expectation changes in the debugger tests, though the
initializers remain debuggable.
- A temporary ClassScope is created during reparsing. After the class
is reparsed, we use the information from the ScopeInfo to update
the allocated indices of the variables in the ClassScope.
Bug: v8:10704
Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78299}
The main changes of this CL are:
It should no longer be assumed that an empty ArrayBuffer has a nullptr
backing store. This is in preparation for the move to caged pointers,
which cannot represent nullptr, and will instead likely provide a
EmptyBackingStore constant pointing inside the virtual memory cage. For
that reason, a new JSArrayBuffer::IsEmpty() helper is introduced, which
should be used instead of checking against nullptr.
CodeStubAssembler::GetTypedArrayBuffer now checks for on-heap
TypedArrays instead of comparing the backing store pointer to nullptr.
This is consistent with the implementation in JSTypedArray::GetBuffer.
v8::ArrayBufferView::CopyContents now uses JSTypedArray::DataPtr instead
of relying on nullptr backing stores to handle on-heap TypedArrays.
The serializer and deserializer now check for IsEmpty() and use the
kEmptyBackingStoreRefSentinel value to serialize empty backing stores.
Empty ArrayBuffers allocated for on-heap TypedArrays now have a
byte_length of zero. This allows removing the allocation_length() (and
allocation_buffer()) methods, which were only (incorrectly, as they
don't account for GSABs) used for memory measurements.
Bug: chromium:1218005
Change-Id: Ib889ccf855f68525f7a614f3963e46ea56865fa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297709
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78069}
Rename flags to align them with other flags that are named in an
enabled way and drop the "never" prefix.
Drive-by: Refactor compaction entry point.
Bug: v8:12251
Change-Id: If2b189152f3cd22038b87fe3cc2ba0db4953ae23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270534
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77813}
The tests are modeled after another patch that includes
v8::CFunctions into Node.js's builtin snapshot.
Refs: https://github.com/nodejs/node/pull/40649
Change-Id: I5a91682f7944ef06a0d3caf7333b09f974bcd64b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3251138
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#77726}
- Introduce v8::ScriptCompiler::CompileFunction
- Deprecate v8::ScriptCompiler::CompileFunctionInContext
- Add v8::Function::GetUnboundScript
- Add v8::Script::GetResourceName
The ScriptOrModule out-parameter is only used by NodeJS since we don't
allow arbitrary objects has host-defined options and they need a way to
keep the options alive.
This CL deprecates the out-parameter and adds helper methods to
address the most common use-cases.
The final fix still requires more fundamental changes on how host-defined
options are handled.
Bug: chromium:1244145
Change-Id: Id29de53521ad626c41391b8300146ee37a1b8a51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3245117
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77564}
For the upcoming host_defined_options fixes we will have to explicitly
pass the host-defined options to Invoke so we will be able to install
it in the script context in the future.
Bug: chromium:1244145
Change-Id: I690cc774d6a17278db4381aba8c3408e979606c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3222765
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77524}
