- Unhandlify OSROptimizedCodeCache::GetOptimizedCode.
- Unstatic-fy FeedbackVector::SetOptimizedCode.
- Remove frame-walking logic during the OSR tierup decision.
The reland is unchanged from the original CL.
Bug: v8:12161
Change-Id: Ibf03a9dd9a6fcd38c0664e5d5014a26d0240e035
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568463
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79752}
- Process the minidump in a separate function to avoid keeping
references to the mmapped file during disposal
- Clear all MinidumpReader variables before disposing the mmapped file
Change-Id: I0ce468597329d6f7d703a08309e4be378d9c27cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568469
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79750}
This changes the logic for generating method names in `error.stack` to
prepend an inferred type name only when the function name is a valid
ECMAScript identifiers and does not equal the inferred type name, to
(1) give developers more control over the exact name shown in
`error.stack`, as well as
(2) avoid confusion in the presence of renaming of local variables.
Previously we'd leave the function name as-is if it was prefixed by the
inferred type name, but that condition is unnecessarily strict, and led
to a bunch of inconsistencies around special names like
`<instance_member_initializer>` where this dynamic approached often
prefixed it with the correct type name, but also sometimes got it wrong
and prepended `Object.`, which is very unfortunate and misleading.
Specifically for these special names, we'll add logic later in the
parser to infer a useful (complete) name.
The design doc (https://bit.ly/devtools-method-names-in-stack-traces)
contains more background and examples of why we do this change.
Doc: https://bit.ly/devtools-method-names-in-stack-traces
Fixed: chromium:1294619
Bug: chromium:1283435
Change-Id: Ib8b528ba25255dcd07e9d11044c562c11d699bcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565724
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79748}
This is a reland of commit 3ce690eef2
Changed for the reland:
- Remove the currently-unused BytecodeArray member to avoid MSAN
failures.
- s/return/continue/ in optimizing-compile-dispatcher.
Original change's description:
> [osr] Basic support for concurrent OSR
>
> This CL adds basic support behind --concurrent-osr,
> disabled by default.
>
> When enabled:
> 1) the first OSR request starts a concurrent OSR compile job.
> 2) on completion, the code object is inserted into the OSR cache.
> 3) the next OSR request picks up the cached code (assuming the request
> came from the same JumpLoop bytecode).
>
> We add a new osr optimization marker on the feedback vector to
> track whether an OSR compile is currently in progress.
>
> One fundamental issue remains: step 3) above is not guaranteed to
> hit the same JumpLoop, and a mismatch means the OSR'd code cannot
> be installed. This will be addressed in a followup by targeting
> specific bytecode offsets for the install request.
>
> This change is based on fanchen.kong@intel.com's earlier
> change crrev.com/c/3369361, thank you!
>
> Bug: v8:12161
> Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79685}
Bug: v8:12161
Change-Id: I48b100e5980c909ec5e79d190aaea730c83e9386
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565720
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79746}
- Add ConvertUtf8StringToUtf16 to convert utf8
encoded file path to utf16 encoded path on windows.
- Add unicode filename support in OS::FOpen,
OS::MemoryMappedFile::open and
OS::MemoryMappedFile::create on windows.
Bug: v8:12541
Change-Id: I65396c3211355e41e8952bc0587ff01bbb720f9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3538284
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79742}
It doesn't take into account stack-slot liveness at time of spill, so
it can cause false sharing.
Bug: v8:7700
Change-Id: Ib8a00d00d857fad40f14fce1d1496fea071e334f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568465
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79737}
Adds concurrent marking for reaching through v8::TracedReference.
Before this CL, a v8::TracedReference would always be processed on the
main thread by pushing a callback for each encountered reference.
This CL now wires up concurrent handling for such references. In particular:
- Global handles are already marked as well and not repurposed during
the same GC cycle.
- Since global handles are not repurposed, it is enough to
double-deref to the V8 object, checking for possible null pointers.
- The bitmap for global handle flags is mostly non-atomic, with the
markbit being the exception.
- Finally, all state is wired up in CppHeap. Concurrent markers keep
their own local worklist while the mutator marker directly pushes to
the worklist owned by V8.
Bug: v8:12600
Change-Id: Ia67dbd18a57dbcccf4dfb9ccfdb9ee438d27fe71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516255
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@{#79736}
Even if the instructions cannot be dissembled, it still often helps to
know which range of instructions belongs to which function. Thus print
this information on --print-wasm-code if the disassembler is not
available.
R=thibaudm@chromium.org
Change-Id: I9e7a4cb6ae4edf3411740fe4dfee248a5b9439ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563564
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79734}
... instead of Code objects. This is a step towards not creating Code
objects for embedded builtins.
Bug: v8:11880
Change-Id: Ie9f87b09d06e6b872ce3a5fa5d03a2502df979d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564565
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79733}
.. since they are the same as eager deopts (% an unused counter).
Fixed: v8:12765
Change-Id: I2be6210e476ead4ac6629a49259f28321e965867
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565717
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79729}
Rolling v8/build: 3444906..d162691
Rolling v8/buildtools: e1471b2..c2e4795
Rolling v8/buildtools/linux64: git_revision:bd99dbf98cbdefe18a4128189665c5761263bcfb..git_revision:859dde4a7f34a4383179522f8e1061dcffac8691
Rolling v8/buildtools/third_party/libc++abi/trunk: 93b8dcd..e9c9bdf
Rolling v8/buildtools/third_party/libunwind/trunk: d1c7f92..cb96c63
Rolling v8/third_party/android_platform: 87b4b48..2760db4
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/389f33b..a9d86a4
Rolling v8/third_party/depot_tools: 76979da..a9c548e
Rolling v8/third_party/googletest/src: b007c54..af29db7
Rolling v8/third_party/zlib: 923f5eb..d1aa7af
Rolling v8/tools/clang: a15c2df..c8e9f23
Rolling v8/tools/luci-go: git_revision:cb424e70e75136736a86359ef070aa96425fe7a3..git_revision:6da0608e4fa8a3c6d1fa4f855485c0038b05bf72
Rolling v8/tools/luci-go: git_revision:cb424e70e75136736a86359ef070aa96425fe7a3..git_revision:6da0608e4fa8a3c6d1fa4f855485c0038b05bf72
R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: I87aab148bb29806e335fa4ad10e1112c1d799a5d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3567924
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#79728}
This CL removes two obsolete regression tests that were taking too
long on debug engine builds.
Bug: v8:12753
Bug: v8:12754
Change-Id: I818101725caa22fb4b2ed22381f01a2dd9436fe4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563563
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79727}
Make LazyDeoptInfo and EagerDeoptInfo both store a
CheckpointedInterpreterState for the bytecode position and
register frame, and make codegen store pointers to these
deopt infos instead of the checkpoint.
This opens the door to using InputLocation for lazy deopts,
same as for eager ones.
Bug: v8:7700
Change-Id: I8ff3056ff72fd9f2288d41769979c5183c3d0972
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563561
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79723}
In DisassembleFunction runtime, function may have available
optimized code and we could directly set the optimized code
for the function like in CompileLazy if it's not compiled,
which avoids calling Compiler::Compile and failed in
DCHECK(!function->HasAvailableOptimizedCode()).
Bug: v8:12762
Change-Id: I00001fc598f3fc96dfe86b2367e8ba88f0085fd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563448
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79722}
Traced nodes can contain SMIs, e.g. when base::ScriptValue is
constructed. The CL filters them out when visiting V8->C++ references,
as otherwise it crashes later assuming HeapObject.
Bug: chromium:1029379
Change-Id: Idaafc92d4dc1bd14c7d1a07e2177202a8af336a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3555769
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79719}
IBMi does not yet support prefixed instructions, p10 features need
to be disabled until OS support is available.
Change-Id: Idca7d6ebd791b06ef8f1f8419badd1a3db0f277f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3562980
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#79718}
For short builtin calls, the builtins are copied on the heap when they
cannot be put close enough to be in range of relative calls. This costs
memory, as the embedded builtins are part of the binary, and mapped from
the binary, and as a consequence shared with all running processes.
Rather than copying the memory, we can remap it at a different address,
avoiding the memory cost. This CL does that, on ARM64 macOS only for
now.
This saves at least ~1.4MiB of memory per V8 process. See below the
output of vmmap <PID>:
[...]
Memory Tag 255 7408308000-740833c000 [ 208K 144K 144K 0K] r-x/rwx SM=ZER
Memory Tag 255 740833c000-7408340000 [ 16K 0K 0K 0K] ---/rwx SM=ZER
Memory Tag 255 7408344000-7408348000 [ 16K 0K 0K 0K] ---/rwx SM=ZER
Memory Tag 255 7408348000-740837c000 [ 208K 144K 144K 0K] r-x/rwx SM=ZER
Memory Tag 255 740837c000-740fe80000 [123.0M 0K 0K 0K] ---/rwx SM=ZER
mapped file 740fe80000-740ffe4000 [ 1424K 1328K 0K 0K] r-x/rwx SM=COW ...pp/Contents/Frameworks/Chromium Framework.framework/Versions/102.0.4958.0/Chromium Framework
Memory Tag 255 740ffe4000-7410000000 [ 112K 0K 0K 0K] ---/rwx SM=ZER
The "208K" regions are 256kiB code pages, minus the header and guard
pages, meaning that they are code chunks. The mapped file are the
remapped builtins, showing that they aren't copied, but remapped from
the binary.
Bug: chromium:1298417
Change-Id: Ia30a43e671726d01450a7db0ecb7777b34763053
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3553006
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79716}
Lock mutex for shared isolate in global safepoints, such that e.g. the
StringTable can use isolate->heap()->safepoint()->AssertActive() even
for shared isolates.
Bug: v8:11708, v8:12749
Change-Id: I8d99203581dfa2d7225846e19fa981300f88589e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563138
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79715}
Skipped test: https://crrev.com/c/3561199.
This is a reland of commit 6e2c9bb265
Original change's description:
> [serialize] copy bytes for non detachable array_buffer
> in WriteJSArrayBuffer when array_buffer is not in
> array_buffer_transfer_map_
>
> According to https://html.spec.whatwg.org/multipage/structured-data.html#structuredserializeinternal
> steps 13.3.2-4, should normally serialize array buffer which
> is not detachable.
>
> Bug: v8:12703
> Change-Id: I4554c5d07ae85e1a96a728ebba04c6a071575f6f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3518910
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79466}
Bug: v8:12703
Change-Id: I1ad1b8159ac7b13011831a4590e8577e954db946
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3557689
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79714}
Since the new space is always empty after a full GC, the old-to-new
remembered set is also always empty after a full GC. This means we can
get rid of the sweeping_slot_set_.
This slot set was used to allow the main thread to insert into the
old-to-new remembered set non-atomically. The sweeping slot set was
owned by the sweeper, which deletes slots in free memory from it. The
main thread would start with an empty old-to-new remembered set. After
sweeping both slot sets are merged again.
The sweeper now needs to behave differently during a GC. When sweeping
a page during full GC, the sweeper needs to delete old-to-new-slots in
free memory.
Outside of the GC the sweeper isn't allowed to remove from the
old-to-new slots anymore. This would race with the main thread that adds
slots to that remembered set while the sweeper is running. However,
there should be no recorded slots in free memory. DCHECKing this is
tricky though, because we would need to synchronize with the main
thread right-trimming objects and at least String::MakeThin only deletes
slots after the map release-store.
Bug: v8:12760
Change-Id: Ic0301851a714e894c3040595f456ab93b5875c81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560638
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79713}
Add an array of canonical rtts on the isolate. Each wasm instance
copies its rtts from there, based on the type index -> canonical index
mapping in the module.
Bug: v8:7748
Change-Id: I0958686c51ecab15a3215a0da3bee1ad6d543cb3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548821
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79712}
The current safety margin between the JS stack limit and the actual
boundary of the stack space reserved by the simulator can be overrun by
a large frame.
Raise this margin to 4KiB, corresponding to the "large frame" threshold.
This ensures that the stack check is executed before the frame is
allocated if the frame is larger than this margin.
R=clemensb@chromium.org
Bug: chromium:1308333
Change-Id: I3e1a51bb36c630c7e37e58679971392dada2a83e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560435
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79711}
While this field isn't used, inititialize it to null.
Bug: v8:11708
Change-Id: I9698e73183f49ef54b8978383e1406e5cf765c75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3562982
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79710}
... in JSObject::DefineOwnPropertyIgnoreAttributes().
Don't execute interceptor again if it declined to handle the operation.
Bug: chromium:1311641
Change-Id: If61ed40665ff7d81e96fa6bf29bbb5dfbeadfcc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3562979
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79707}
