- 17 Jan, 2022 4 commits
-
-
Benedikt Meurer authored
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}
-
Lu Yahan authored
Bug: v8:12543 Change-Id: I6dc98dea4e713323c18666ecfff459cbd55d90d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383514Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Yahan Lu <yahan@iscas.ac.cn> Cr-Commit-Position: refs/heads/main@{#78639}
-
QiuJi authored
According to https://chromium-review.googlesource.com/c/v8/v8/+/725721/, ToBoolean should be a simplified operator. Change-Id: I4898e1c022f7b3083aefd880478529b18f0d2dad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361661Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: ji qiu <qiuji@iscas.ac.cn> Cr-Commit-Position: refs/heads/main@{#78638}
-
Tobias Tebbi authored
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:
-
- 16 Jan, 2022 1 commit
-
-
Dan Clark authored
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/+/3388130Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#78636}
-
- 15 Jan, 2022 3 commits
-
-
Clemens Backes authored
This is a reland of 40b062ce. Known existing problems have been fixed, see https://crbug.com/v8/12330. Original change's description: > [future] Use mid-tier regalloc for huge functions > > Stage the --turbo-use-mid-tier-regalloc-for-huge-functions behind > --future. > > R=thibaudm@chromium.org > > Bug: v8:12287, v8:12320 > Change-Id: I7145ca1b022bfdcb0b61d6666daf855f14cbc4ce > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3236547 > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77549} Bug: v8:12287, v8:12320, v8:12330 Change-Id: I90eb2cb54b42fca77c1e3db9c18b20080f0d9338 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3347822Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#78635}
-
Clemens Backes authored
Access private fields directly instead. R=thibaudm@chromium.org Bug: v8:12330 Change-Id: I2b52dc8a2d0a1ee3a87cf6bd24b145e5c7419770 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380914Reviewed-by:
-
Clemens Backes authored
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/+/3380597Reviewed-by:
-
- 14 Jan, 2022 19 commits
-
-
Clemens Backes authored
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/+/3378782Reviewed-by: -
Michael Lippautz authored
This is a reland of 142dd775 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/+/3386600Reviewed-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}
-
Milad Fa authored
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/+/3387608Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Farazmand <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/main@{#78630}
-
Junliang Yan authored
Change-Id: If401e5c9d1ab6f293de2d8efed1f885683667408 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386389Reviewed-by:
Milad Farazmand <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/main@{#78629}
-
Thibaud Michaud authored
- 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/+/3345004Reviewed-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}
-
Milad Fa authored
Port 87cf0bdd Original Commit Message: Use grep to check for obviously unneeded includes. e.g. headers that include <vector> but does not contain "std::vector". R=thestig@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: I404409eda1f06a98ddd162799facc8aaec74826e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3387617Reviewed-by:
-
Benedikt Meurer authored
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/+/3386382Reviewed-by:
-
Leszek Swirski authored
This reverts commit f605d778. 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}
-
Igor Sheludko authored
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/+/3386381Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78624}
-
Victor Gomes authored
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/+/3386603Reviewed-by:
-
Victor Gomes authored
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/+/3386601Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#78622}
-
Victor Gomes authored
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/+/3386599Reviewed-by:
-
Samuel Groß authored
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/+/3367617Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78620}
-
Hannes Payer authored
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/+/3386800Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78619}
-
Michael Lippautz authored
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:
-
Frank Tang authored
get Temporal.*.prototype.epoch(Millis|Micros|S)econds) Bug: v8:11544 Change-Id: I97d7560f386666fb4bff84b97de9927769e6ca04 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3374043Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/main@{#78617}
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/google_benchmark/src: https://chromium.googlesource.com/external/github.com/google/benchmark/+log/31e7941..6cf20f1 Suppress GoogleTest warnings on windows (MSVC) too. (#1320) (Dominic Hamon) https://chromium.googlesource.com/external/github.com/google/benchmark/+/6cf20f1 Add docs on Memory profiling (#1217). (#1319) (Dominic Hamon) https://chromium.googlesource.com/external/github.com/google/benchmark/+/5531ec8 R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com,mlippautz@chromium.org Change-Id: I4ba1571dc6b955a3ba1ad1569300518a709dd8e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3387111 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@{#78616}
-
Leszek Swirski authored
This reverts commit 3cb4039c. Reason for revert: TSAN failure in newly added test: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/18086/overview Original change's description: > [string] Support shared strings in Value{Serializer,Deserializer} > > 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} Bug: v8:12007 Change-Id: I5bb8f9b4e9b641c6d5cb16f963e9dbc1b13ac56a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386799 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> 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@{#78615}
-
Shu-yu Guo authored
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/+/3277250Reviewed-by:
-
- 13 Jan, 2022 13 commits
-
-
Lei Zhang authored
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/+/3354400Reviewed-by:
-
Manos Koukoutos authored
Bug: v8:7748 Change-Id: I3a20c588c2e0753c646cceb0a03fd882041fed7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383779Reviewed-by:
-
Nikolaos Papaspyrou authored
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/+/3386596Reviewed-by:
-
Benedikt Meurer authored
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:
-
Junliang Yan authored
Change-Id: I7f2463e8363a060651daabc6e32fbc56405868b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3387074Reviewed-by:
-
Manos Koukoutos authored
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/+/3383135Reviewed-by:
-
Tobias Tebbi authored
Bug: chromium:1274443 Change-Id: I3f6766dc84019ae017b6da1ae797c946a33079b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3351968Reviewed-by:
-
Nico Hartmann authored
Bug: v8:12261 Change-Id: I4872ba82676bf64fa51d5a599323382c65cc465a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386594 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
-
Leszek Swirski authored
This reverts commit 142dd775. 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}
-
Michael Lippautz authored
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/+/3380983Reviewed-by:
-
Seth Brenith authored
Change-Id: I7cf964294304c380fb285eebf1e65b0f84dec1a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3384233Reviewed-by:
-
Jochen Eisinger authored
I'm not going to realistically work on resolving them. Change-Id: Idd59fe5758ab7132fa2412477242bc045b0ee02d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378636Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
-
Yang Guo authored
R=leszeks@chromium.org Change-Id: I8e5930d9ed946ae12cad98b3456055aefcef7d18 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386593 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by:
-
