The new shared memory API should only be used on macOS, but
platform-macos.cc was also included on iOS, causing build failures. This
CL splits platform-macos.cc into platform-xnu.cc (common code for macOS
and iOS) and platform-macos.cc (the macOS specific parts)
Bug: chromium:1218005
Change-Id: Iab332865ffd8990ddd246bb9c08802909464d7e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3468895
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79131}
The flag is required to allow passing in more debug information when
necessary.
Change-Id: I34e407ba57786c242aac8b6f6af258969de43efd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3468894
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79126}
These should not be allowed inside the sandbox as they could be
corrupted by an attacker, thus posing a security risk. Furthermore,
executable pages require MAP_JIT on macOS, which causes fork() to become
excessively slow, in turn causing tests to time out.
Due to this, the sandbox now requires the external code space.
In addition, this CL adds a max_page_permissions member to the
VirtualAddressSpace API to make it possible to verify the maximum
permissions of a subspace.
Bug: v8:10391
Change-Id: Ib9562ecff6f018696bfa25143113d8583d1ec6cd
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/+/3460406
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79119}
LocalAllocator was already renamed to EvacuationAllocator some time ago.
Rename files now as well.
Bug: v8:10315
Change-Id: I337f693998aaf5187a5ba05842cdb2474837b68d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3463719
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: 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@{#79104}
.. to resolve the overloaded 'runtime' term and overall pick a more
meaningful name for this class. It's neither very related to runtime
(instead it's called periodically when the bytecode interrupt budget is
exhausted); nor is profiling its main purpose.
This class is responsible for controlling tiering decisions, hence the
new name 'TieringManager'.
Bug: v8:7700
Change-Id: Id6f1edf4ebe016d0d81903d0a13e0e1fe6e02142
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3463716
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79101}
Allows separating out the allocator from Heap without requiring a
heap.h include.
Drive-by:
- Rename "Retry" to "Failure".
- Avoid implicit constructors.
- Rename "RetrySpace" to "GarbageCollectionSpace" which is its only
use.
Bug: v8:12615
Change-Id: Idac17cded8f0b2b645a2be9045ab31ffd71999b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3456562
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79063}
The build flag is on by default and the actual functionality is guarded
by a runtime flag.
Bug: v8:12612
Change-Id: I6adbd5b766f502400af32eeeb035edca3a3606ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3448383
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79036}
After https://crrev.com/c/3416191 there are too many mixed concerns in
the clusterfuzz directory. We split it into js-fuzzer, foozzie and
trials.
Change-Id: I9a21ee83985e6113d77acba4583e99df88723c60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3443505
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78981}
The web app owner who notified me about bugs v8:12112 and v8:12126 asked
me a reasonable question: "how am I ever supposed to trust the retaining
paths in the devtools, if the heap snapshot is generated by a different
component than the actual marking code?". This change is my attempt to
answer that question. If verification is enabled, the heap snapshot
generator will visit each heap object with a realistic marking visitor
to find all references from that object. It will then check that those
references match the HeapGraphEdges in the snapshot.
I also considered the idea that we could collect retaining information
during the last GC cycle before taking the heap snapshot, or during an
extra GC cycle immediately after. However, running the full GC provides
the embedder with the opportunity to run arbitrary code (including JS)
both before and after PerformGarbageCollection, so there is no clear
guarantee that the heap state during the snapshot actually matches the
heap state during marking.
Bug: v8:12112, v8:12126
Change-Id: Id29e75ecf9eee19e35daedbdb4a3e1df64785380
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3299590
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#78952}
Replacement is v8::TracedReference in combination with v8::Global if a
callback is really needed.
Bug: v8:12603
Change-Id: Iae48fee2e6588a594d430c5f3a71ff0b3e67e5b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439873
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78950}
This is a reland of 517ed4ad00
Original change's description:
> Reland "[Torque] Generalize Torque literals to larger size"
>
> Previously, literals in Torque were stored as double values, which
> made it impossible to precisely represent 64 bit integer values.
> This CL replaces the old literal expression with an integer and
> floating point literal expression that are unbounded in size. We
> allow implicit conversion of these literals to arbitary integer
> and floating point types respectively and insert a corresponding
> bounds check into generated CSA.
>
> Changes in the reland: Simplified IntegerLiteral to single digit.
>
> Bug: v8:7793, chromium:1289282
> Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78811}
Bug: v8:7793, chromium:1289282
Change-Id: I7aadc4d2c9494f03eae85e94949c8f4cab7a075c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3437047
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78939}
The CL does following:
1) Makes sure young generation works and tests pass;
2) Provides CollectGarbageInYoungGenerationForTesting() that is needed
to support remaining tests in Blink;
3) Moved cppgc_enable_young_generation GN flag to v8.gni to refer to it
from Blink;
4) Bails out from marking TracedReferences in UnifiedHeapMarkingState;
5) Disables (temporarily) prompt freeing for young generation;
6) Fixes remembered set visitation for nullptr|kSentinel slots.
Bug: chromium:1029379
Change-Id: I5165fa22c8a0eaa708ef7a35a9978cb12e1cb13e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3429202
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78901}
Previously, when accessing SandboxedPointer fields with the sandbox
disabled, we would always do a ReadUnalignedValue/WriteUnalignedValue.
However, that is only necessary when pointer compression is enabled.
Otherwise, the field will be properly aligned.
This CL also factors out the logic to determine when to use an unaligned
or aligned read/write for a field into two new helper functions.
Bug: chromium:1292669
Change-Id: I2c1af187c5b2699101c3fee9cc551be788d3a845
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/+/3429200
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78887}
- Adds a GN flag to enable the feature
- Adds facets to manifest used by d8/unittests
- Adds some DCHECKS
- Uses zx_handle_t type to avoid global initialization/destructor
Bug: v8:11232
Change-Id: Ibd7766abefbf8c213393cf6365c34f9ff4e6ed7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420828
Reviewed-by: Wez <wez@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78886}
This is a reland #3. The fixes were landed separately.
Perf Sheriffs: this CL might regress some benchmarks while improving
the others.
Bug: v8:11880
Change-Id: I8ed5bf59360649718960dc34c06015ee6ff1532a
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_compile_dbg
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3422643
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78854}
We can now specify the trials for clusterfuzz using the file
clusterfuzz_trials_config.json. There is also a presubmit check
to make sure that it is formatted correctly.
Change-Id: Iafb7063b63b1daeb7653830542d13b419cf187d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416191
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78848}
This reverts commit 517ed4ad00.
Reason for revert: There still seems to be an issue on V8 Win msvc related to this CL (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/20568/overview).
Original change's description:
> Reland "[Torque] Generalize Torque literals to larger size"
>
> Previously, literals in Torque were stored as double values, which
> made it impossible to precisely represent 64 bit integer values.
> This CL replaces the old literal expression with an integer and
> floating point literal expression that are unbounded in size. We
> allow implicit conversion of these literals to arbitary integer
> and floating point types respectively and insert a corresponding
> bounds check into generated CSA.
>
> Changes in the reland: Simplified IntegerLiteral to single digit.
>
> Bug: v8:7793, chromium:1289282
> Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78811}
Bug: v8:7793, chromium:1289282
Change-Id: I818cec9625fbd827a4a30088d8c8b759fb6c50d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3424484
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78847}
Drive-by fix to align what builds the test runner considers to be able
to have shared memory features and what builds can create a shared
Isolate.
Bug: v8:12007
Change-Id: I151513ccbfbee31e5b35c5ce8e9192732eabfee2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3421507
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78824}
This is a reland #2. The fixes were landed separately.
Perf Sheriffs: this CL might regress some benchmarks while improving
the others.
Bug: v8:11880
Change-Id: I397aef5ad5cce42ef189ee10b482805c90ec925a
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_compile_dbg
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3417000
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78817}
Previously, literals in Torque were stored as double values, which
made it impossible to precisely represent 64 bit integer values.
This CL replaces the old literal expression with an integer and
floating point literal expression that are unbounded in size. We
allow implicit conversion of these literals to arbitary integer
and floating point types respectively and insert a corresponding
bounds check into generated CSA.
Changes in the reland: Simplified IntegerLiteral to single digit.
Bug: v8:7793, chromium:1289282
Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78811}
Moves g_root_vmar_base up in the file, so that we have all
the globals together.
Bug: v8:11232
Change-Id: Ic08cdf3399982962de255028be6718951a17aedb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416249
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Samuel Groß <saelo@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78786}
The external pointer table is now managed by the GC, which marks entries
that are alive during major GC, then sweeps the table afterwards to free
all dead entries and build a free list from them. For now, only major GCs
are supported, Scavenger GCs do not interact with the external pointer table.
In more detail, garbage collection of the external pointer table works
as follows:
1. The external pointer table now reserves a large region of virtual
address space for its backing buffer and is then never reallocated,
only grown in place until the maximum size is reached.
2. When the GC's marking visitor marks a HeapObject with an external
pointer as alive, it also marks the corresponding external pointer
table entry as alive. This can happen on a background thread.
3. For that, it uses the MSB of each entry in the table to indicate
whether the entry has been marked or not. This works because the MSB
is always cleared during the AND-based type check performed when
accessing an external pointer.
4. After marking, the external pointer table is swept while the mutator
is stopped. This builds an inline, singly-linked freelist of all
newly-dead and previously-free entries.
5. When allocating an entry from the table, the first entry on the
freelist is used. If the freelist is empty, the table grows,
populating the freelist with the new entries.
6. Every newly-allocated entry is marked as alive, and every store to an
existing entry also automatically marks that entry as alive (by also
setting the MSB). This simplifies the design of the table GC with
regards to concurrency (See ExternalPointerTable::Mark).
Bug: v8:10391
Change-Id: I8877fdf5576af3761bde65298951bb09e601bd14
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/+/3359625
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78708}
This reverts commit 757830b02b.
Reason for revert: Speculatively revert due to a number of
performance regressions
Original change's description:
> [Torque] Generalize Torque literals to larger size
>
> Previously, literals in Torque were stored as double values, which
> made it impossible to precisely represent 64 bit integer values.
> This CL replaces the old literal expression with an integer and
> floating point literal expression that are unbounded in size. We
> allow implicit conversion of these literals to arbitary integer
> and floating point types respectively and insert a corresponding
> bounds check into generated CSA.
>
> Bug: v8:7793
> Change-Id: I46c231aab92bc2f0c26955d1876079f306b358c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329792
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78671}
Bug: v8:7793
Change-Id: I9896e28b3c69b8cf2488bf93e993ec320d8c5d2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401866
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78706}
Previously, literals in Torque were stored as double values, which
made it impossible to precisely represent 64 bit integer values.
This CL replaces the old literal expression with an integer and
floating point literal expression that are unbounded in size. We
allow implicit conversion of these literals to arbitary integer
and floating point types respectively and insert a corresponding
bounds check into generated CSA.
Bug: v8:7793
Change-Id: I46c231aab92bc2f0c26955d1876079f306b358c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329792
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78671}
Now that concurrent inlining is shipping on stable, remove support
--no-concurrent-inlining.
Note that it's still possible to run Turbofan exclusively on the
main thread by passing --no-concurrent-recompilation.
Bug: v8:7790, v8:12142, chromium:1240585
Change-Id: I1943bbbcad7dea7e3a3c337c239f14f7d96c23cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308798
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78644}
The receiver is included unconditionally on all platforms
(kJSArgcIncludesReceiver is always true).
Remove all usages of kJSArgcIncludesReceiver from the code.
Bug: v8:11112
Change-Id: I7d62e6de65b73fe6d8c3293f32b500b760b08a3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322980
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78642}
This reverts commit 142dd775b4.
Reason for revert: TSAN breaks: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6113/overview
Original change's description:
> cppgc-js,heap: Implement snapshots for embedder fields
>
> https://crrev.com/c/3293410 added concurrent processing of C++ objects
> found through V8 embedder fields. The CL missed that those embedder
> fields are not read atomically from JS objects. The problem is that
> embedder fields are only aligned to kTaggedSize on builds with pointer
> compression and are as such mis-aligned for atomic ops. This is not a
> problem for on-heap values as the upper 32bits are anyways computed
> from the cage. Is is a problem for generic C++ values though, as they
> are used with Oilpan.
>
> This CL adds the standard marker snapshot protocol for embedder fields.
>
> Marker:
> 1. Snapshot embedder fields
> 2. Try to mark host object
> 3. On success: process snapshot
>
> Main thread:
> 1. On setting embedder fields mark the object black first
> 2. Emit a write barrier for the embedder fields
>
> This will get simpler with the heap sandbox that uses a separate table
> for embedder fields. Once the sandbox is the default configuration, we
> can use it as dependency for the concurrent fast path.
>
> Bug: chromium:1285706
> Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78604}
Bug: chromium:1285706
Change-Id: If1976c0356f450fc068aa4dcc39fb9a0d5417a40
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386598
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@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@{#78605}
https://crrev.com/c/3293410 added concurrent processing of C++ objects
found through V8 embedder fields. The CL missed that those embedder
fields are not read atomically from JS objects. The problem is that
embedder fields are only aligned to kTaggedSize on builds with pointer
compression and are as such mis-aligned for atomic ops. This is not a
problem for on-heap values as the upper 32bits are anyways computed
from the cage. Is is a problem for generic C++ values though, as they
are used with Oilpan.
This CL adds the standard marker snapshot protocol for embedder fields.
Marker:
1. Snapshot embedder fields
2. Try to mark host object
3. On success: process snapshot
Main thread:
1. On setting embedder fields mark the object black first
2. Emit a write barrier for the embedder fields
This will get simpler with the heap sandbox that uses a separate table
for embedder fields. Once the sandbox is the default configuration, we
can use it as dependency for the concurrent fast path.
Bug: chromium:1285706
Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78604}
The enablement of PAC in Chromium will have two phases where support
will first be enabled on C++ code (e.g. Blink/Chrome/etc) and its
dependencies, followed next by support for dynamic code generated by
V8.
This change will allow enable PAC support for C++ code when V8
is built with Chromium.
Bug: chromium:919548
Change-Id: I8ebcbcfe3c2a3a38807b814f936272ac09625795
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372162
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Adenilson Cavalcanti <cavalcantii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78548}
We implement loop peeling for wasm, currently available behind a flag.
Loops are peeled regardless of size.
Bug: v8:11510
Change-Id: Ia4c883abdee83df632b2611584d608c44e3295c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3367615
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78496}
Introduce a build-time flag to disable all CET shadow-stack
manipulation. This will allow us to develop the feature without breaking
production code, and enable it all at once once the feature is ready.
R=mlippautz@chromium.org
Bug: v8:12522, v8:11246, chromium:1284445, chromium:1284599
Change-Id: Iedc1b9a0c0c74f484bb76d86c84809798c0931b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368101
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78494}
Included in this CL:
(*) Introduce CppMarkingState that V8 should use to push references to
Oilpan. CppMarkingState allocates its own Worklist::Locals to
support concurrent updates from V8.
(*) Split Oilpan MarkingWorklist object to form a base class used by
CppMarkingState.
(*) Remove MarkerFactory and split marking initialization. Marking
worklists should already be initialized when V8 initializes
visitors. For incremental marking, this requires splitting
marking initialization and marking start.
(*) Drive-by: Mark JSObject::IsApiWrapper and
JSObject::IsDroppableApiWrapper as const.
Bug: v8:12407
Change-Id: I35cc816343da86f69a68306204675720e9b3913f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293410
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78446}
This CL renames a number of things related to the V8 sandbox.
Mainly, what used to be under V8_HEAP_SANDBOX is now under
V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
is now simply the V8 Sandbox:
V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
V8VirtualMemoryCage => Sandbox
CagedPointer => SandboxedPointer
fake cage => partially reserved sandbox
src/security => src/sandbox
This naming scheme should simplify things: the sandbox is now the large
region of virtual address space inside which V8 mainly operates and
which should be considered untrusted. Mechanisms like sandboxed pointers
are then used to attempt to prevent escapes from the sandbox (i.e.
corruption of memory outside of it). Furthermore, the new naming scheme
avoids the confusion with the various other "cages" in V8, in
particular, the VirtualMemoryCage class, by dropping that name entirely.
Future sandbox features are developed under their own V8_SANDBOX_X flag,
and will, once final, be merged into V8_SANDBOX. Current future features
are sandboxed external pointers (using the external pointer table), and
sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
because they are encoded as offsets). This CL then also introduces a new
build flag, v8_enable_sandbox_future, which enables all future features.
Bug: v8:10391
Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
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/+/3322981
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78384}
Use build_flags_ with @if/@ifnot in torque for the following flags:
- V8_ENABLE_JAVASCRIPT_PROMISE_HOOKS
- V8_ENABLE_SWISS_NAME_DICTIONARY
- Make sure Torque and CSA code actually respect
V8_ENABLE_JAVASCRIPT_PROMISE_HOOKS.
- Rename V8_ALLOW_JAVASCRIPT_IN_PROMISE_HOOKS to
V8_ENABLE_JAVASCRIPT_PROMISE_HOOKS
- Rename gn/bazel arg v8_allow_javascript_in_promise_hooks to
v8_enable_javascript_promise_hooks
- Unship context promise hooks in chrome and enable them only in d8
for testing purposes
- Make sure d8 and the API throw when using promise hooks without
the compile time feature enabled
Bug: chromium:1265186, v8:11025
Change-Id: I69834d44d683a36d0d7be3c3d68888321be0fd7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3301474
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78362}
This is the second step in the refactoring to make v8::StackFrame
more lightweight and usable for (long time storage) by the V8
inspector (see https://bit.ly/v8-stack-frame for an overview).
This is a purely mechanical change without any functional aspects.
The intention is to make the use case for the CallSiteInfo objects
clear, namely to serve as the backing store for the CallSite objects
exposed via the Error.prepareStackTrace() API and used under the
hood to implement the error.stack accessor.
Doc: https://bit.ly/v8-stack-frame
Bug: chromium:1258599, chromium:1278647, chromium:1278650
Change-Id: I39dffd1f1a8e5158ddc56f2a0a2b1b28321f487a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300138
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78361}
All uses of the build flag will be removed in a follow-up CL.
Bug: v8:11112
Change-Id: Ifc3d9ed5d642646edeba51aa6d60924796d0f788
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322769
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78294}
