Implementations are added to macro-assembler to be shared between
liftoff and code generator.
Change-Id: Ic38677b3266399e5e170a4b2d6a8f90d0b830d47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3389090
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78650}
Verify usages of SKIP_WRITE_BARRIER in builds with SLOW_DCHECKs enabled.
We can only remove the write barrier in specific circumstances that
can also be DCHECK'ed.
I also switched some write barriers to UPDATE_WRITE_BARRIER where those
simple rules didn't hold but relied on more elaborate explanations.
Bug: v8:12544
Change-Id: I4caa43627f8a3209d853e3352caabc161568e6eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386803
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78649}
We are guaranteed to have a valid ref for the prototype now that the
no-concurrent-inlining configuration has been removed.
Bug: v8:7790
Change-Id: I8400d1887f5cd41b14c92c87151847c0ed78f911
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3394708
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78648}
This CL exposes the `recurring` flag on the experimental async stack
tagging API which was implemeted in the following CL:
https://chromium-review.googlesource.com/c/v8/v8/+/3212506
It serves as a prototype to check if such an API is suitable for
improving stack traces for frameworks which split up tasks across
multiple frames, yielding back to the main thread when some time budget
is consumed.
The tests are implemented as Blink web tests in the following CL:
https://chromium-review.googlesource.com/c/chromium/src/+/3383386
Bug: chromium:332624
Change-Id: I3e8c5de723cb7c0413d03ca4292c22d6a6e565b0
Signed-off-by: Victor Porof <victorporof@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380495
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78647}
In preparation to use the hash table in the scope_info, we
setup a hashtable from name to indices.
Bug: v8:12315
Change-Id: I77f1eb40191c2fb2d40127e1e84dbc41ca2e4b70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386804
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78646}
This CL introduces a dedicated API to retrieve the current (w.r.t. the
JS stack) script name or sourceURL. Currently, API clients will
collect multiple stack traces in increasing sizes to accomplish the
same goal. The new method walks the JS stack in the same way as the
stack trace collection mechanic but doesn't create/allocate stack info
or callsite objects along the way.
R=bmeurer@chromium.org, yangguo@chromium.org
Doc: https://bit.ly/v8-current-script-name
Bug: chromium:1286677
Change-Id: Id53e4f04bf17349d34f3d581bc712b1f4aa055db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3382818
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78645}
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}
Give the "phantom" script containing the web snapshot functions the same
name as the original script.
Bug: v8:11525
Change-Id: Iae77d58152642256560ceb3688bc2b3d0d9800be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3394707
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78643}
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}
As described in https://crbug.com/1287476, the fact that the
AsyncEventDelegate is currently implemented on top of the PromiseHooks
causes performance problems and makes it difficult to reason about the
exact (observed) semantics; this is because for this we intercept every
JSPromise creation (via PromiseHook::kInit) and walk the synchronous
stack at that point to see if we find one of Promise#then(),
Promise#catch() or Promise#finally() on the stack. And if we do so, we
report that to the AsyncEventDelegate (which is implemented in the
inspector and will then do the async stack/stepping logic on top).
This CL introduces dedicated instrumentation for Promise#then(), which
is also called from Promise#catch() and Promise#finally(), and uses that
instrumentation for the purpose of the AsyncEventDelegate. It also
adjusts the stack walk to not always walk the full stack (which might
lead to wrong results when calls to Promise#then(), which itself can
call back into user JavaScript, are found deeper in the stack), but
instead only check the top-most builtin frames and whatever user
JavaScript frame is underneath it.
On the standalone.js (from https://crbug.com/1287476#c1), when run with
the DevTools default of maxDepth=200, we go from around 4.00ms to around
0.36ms. For everything that does not call Promise#then() - either
explicitly or implicitly - or `await`s, there's now no observable
performance impact of turning on the AsyncEventDelegate.
Bug: chromium:1280519
Fixed: chromium:1287476
Change-Id: I4911bed146381fc46cfeefb763d6dfc32e8f6071
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386379
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78640}
The fast path has an early return if the two inputs are the same
object. However, this was missing the check that the receiver
is not undefined required by the spec.
This fixes it by first checking that the receiver is a string and
only afterwards checking for reference equality.
Bug: v8:12495
Change-Id: I4c5fc80e09060b013c94b05bbc9da504ddbb5206
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386602
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78637}
Shell::FetchModuleTree assumes that the module at file_name wasn't
already fetched. Shell::ExecuteModule is calling into
FetchModuleTree without checking if the module is already in the module
map, violating this assumption.
This change fixes this by having Shell::ExecuteModule check for the
existence of the module before calling into Shell::ExecuteModule, the
same way that Shell::DoHostImportModuleDynamically does.
Bug: v8:12530
Change-Id: Ia038cbd1715e85c9c92c4554fd486c657ef952e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3388130
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78636}
Similar to the case of fixed registers, we need to consider both cases:
A SIMD register might collide with either the low or high FP register,
or the FP register might collide with a previously allocated SIMD
register. We did only consider the first case so far.
R=thibaudm@chromium.org
Bug: chromium:1286253, v8:12330
Change-Id: Id4c995586cc8b97a2e131ee9d3417525e409bcef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380597
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78633}
For getting from one SIMD "sibling" register to the other, the mid tier
register allocator was relying on the indexes of the two registers to be
{2N} and {2N+1}. This is only true for lower SIMD registers; later
registers can be at {2N-1} and {2N} instead, because of holes in the
allocatable double registers (e.g. d13-d15 are not allocatable currently
on ARM).
We can rely on other facts though:
1) The two aliasing registers are always successive.
2) A SIMD register code always maps to the lower register index.
3) We can get from an F32 register code to F64 and from F64 to S128 by
shifting one bit to the right (this is what
{RegisterConfiguration::GetAliases} uses).
This bug was uncovered by running the existing
cctest/test-code-generator/FuzzAssemble* tests with either
--turbo-use-mid-tier-regalloc-for-huge-functions or with
--turbo-force-mid-tier-regalloc. Hence it will be covered by these tests
once https://crrev.com/c/3347822 lands.
R=thibaudm@chromium.org
TEST=cctest/test-code-generator/FuzzAssemble*
Bug: v8:12330
Change-Id: I168840fe50b6ba6cdaa6a5462596a5cbf55c87ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378782
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78632}
This is a reland of 142dd775b4
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: I024e50fc0757fbcd13cb9ffde027dff55f99d25c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386600
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78631}
Implementations are added to macro-assembler to be shared between
liftoff and code generator.
Change-Id: I945e312b45d87e021ffd64948bdfd69d0642fb83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3387608
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78630}
- Add suspend asm builtin stub, and call it from the suspending
wasm-to-js wrapper
- Rename frame type to match both builtins (prompt and suspend)
- Add suspend bool to the import cache key
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: Ie5a8ca7cbe4bcb91697e05b6470e3d632d608993
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345004
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78628}
Following up on https://crrev.com/c/3383775 I realized that we could
just use the existing %DebugPopPromise and %DebugPushPromise runtime
functions, which do exactly the same job as %DebugAsyncFunctionFinished
and %DebugAsyncFunctionResumed, and are already used in other places of
promise instrumentation.
We can also remove %DebugAsyncFunctionEntered and utilize the logic in
NewJSPromise() to deal with the various promise hooks, and otherwise go
with %DebugPushPromise for the debugger side.
Bug: chromium:1280519
Change-Id: I79c77236f19c8783161c1eee36d2a16d52c60e82
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386382
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78626}
This reverts commit f605d77822.
Reason for revert: Segfaults: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/36908/overview
Original change's description:
> [runtime] Adds LocalNameIterator
>
> ScopeInfo will contain either inlined (array) local names or
> a hash table (names => index) containing the local names.
>
> We abstract iteration with LocalNameIterator and remove
> ContextLocalName since accessing a local name by index in
> the hash table would be expensive.
>
> This CL only implements the iterator for the array.
>
> Bug: v8:12315
> Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78623}
Bug: v8:12315
Change-Id: Ibabe231f4357a3dd02d24b89847d579b83867a1a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386385
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78625}
The Isolate might not be aware that remapped builtins are used (see
Code::OffHeapInstructionStart()), so always try to lookup PC in the
remapped builtins if they are available.
This is a follow-up to
https://chromium-review.googlesource.com/c/v8/v8/+/3379817.
Bug: chromium:1241665, v8:11460
Change-Id: Ied59ce6c7920278ed701e7139c8b6839a04cf1cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386381
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78624}
ScopeInfo will contain either inlined (array) local names or
a hash table (names => index) containing the local names.
We abstract iteration with LocalNameIterator and remove
ContextLocalName since accessing a local name by index in
the hash table would be expensive.
This CL only implements the iterator for the array.
Bug: v8:12315
Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78623}
kScopeInfoMaxInlinedLocalNamesSize is a threshold for inlined storage,
otherwise local names will be stored in a hash table.
Bug: v8:12315
Change-Id: Ibfa5bec5222c9e60765c3663707623544895ec0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386601
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78622}
ScopeInfo will contain either inlined (array) local names or
a hash table (names => index) containing the local names.
If we have the local names inlined, we should save the class
variable context slot index.
If we have a hash table instead, we should save the class
variable offset in the internal hash table storage.
Bug: v8:12315
Change-Id: Ifd9ae4f285d11fc034e8560c8558038b38a474fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386599
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78621}
This CL removes the global IsValidBackingStorePointer function and turns
the DCHECKs that ensure that sandboxed pointers point into the sandbox,
which essentially cover the same condition, into CHECKs. This is mostly
to facilitate debugging during the initial rollout, and the CHECKs can
later be turned back into DCHECKs.
In addition, this CL adds a fallback to a partially-reserved sandbox
when sandboxed pointers are enabled and when the regular initialization
fails.
Bug: chromium:1218005
Change-Id: I75526f1a00ddb9095ae0e797dc9bb80a210f867b
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/+/3367617
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78620}
InvokeSecondPassPhantomCallbacks() may allocate which may result in a different GC selection.
Bug: v8:12503
Change-Id: I936634f9b819bc160749e058cbee8fb1c555f376
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386800
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78619}
Since ManualGCScope changes marking flags it should finalize any
ongoing GC before changing the flags. Otherwise, the GC may observe
inconsistent state.
Bug: chromium:1285706
Change-Id: Ie8ef6a1117ba0523d0bed0c46d9116ffbc02069c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386607
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78618}
When FLAG_shared_string_table is true, postMessaging strings will share
instead of copy.
Note that not all operations on shared strings are supported, and shared
strings may be slower than non-shared strings for some operations.
Bug: v8:12007
Change-Id: I3462128e15410d2568868143571571b3025722c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277250
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78614}
Use grep to check for obviously unneeded includes. e.g. headers that
include <vector> but does not contain "std::vector".
Change-Id: I43a9e9f01e072fd495918d28ca4cdad5cfa0294c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3354400
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78613}
The total wall time for GC reported to Blink is explicitly included in
UMA events. For the C++ managed heap, it is equal to the sum of the four
phases (mark, sweep, compact, weak). For the JS heap, it will be greater
than or equal to that sum in general.
Bug: chromium:1154636
Change-Id: Id710702b8e9d8db5c8d1eb4917deb6b760a77306
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386596
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78611}
Following up on https://crrev.com/c/3383775 we are now able to further
simplify the implementation of `await` and its instrumentation (for both
debugger and promise hooks), which aligns the implementation more
closely with the spec text and removes a whole bunch of unnecessary
code.
This also moves the `await` instrumentation into runtime-debug.cc along
with the other instrumentation methods for async functions.
Bug: chromium:1280519, chromium:1277451, chromium:1246867
Change-Id: I3fb543c76229091b502f3188da962784977158ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386597
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78610}
When initializing a table entry with null or a function constant, do not
go through EvaluateInitExpression. Remove the option to treat functions
lazily in EvaluateInitExpression/InitExprInterface.
Drive-by: Shrink indirect tables by removing redundant field.
Bug: chromium:1284557
Change-Id: I78a64becebf4b967b0a440d43855e163ec190b7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383135
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78608}
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}
