- 02 May, 2022 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/google_benchmark/src: https://chromium.googlesource.com/external/github.com/google/benchmark/+log/dc901ff..8d86026 Enable -Wconversion (#1390) (Dominic Hamon) https://chromium.googlesource.com/external/github.com/google/benchmark/+/8d86026 Add benchmark labels to the output of the comparison tool (#1388) (Dominic Hamon) https://chromium.googlesource.com/external/github.com/google/benchmark/+/b0d5adf Filter out benchmarks that start with "DISABLED_" (#1387) (Dominic Hamon) https://chromium.googlesource.com/external/github.com/google/benchmark/+/a162a38 R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com,mlippautz@chromium.org Change-Id: Ie49d074a433a737113c2bfe53d677fc112756df6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615246 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@{#80290}
-
- 01 May, 2022 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/5fb93cb..85814e1 CP PR 2070 fix int32 overflow (Frank Tang) https://chromium.googlesource.com/chromium/deps/icu/+/85814e1 CP two ICU security patches (Frank Tang) https://chromium.googlesource.com/chromium/deps/icu/+/a47bd43 R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com,ftang@chromium.org Change-Id: I2719b470184f94ad06b1920f0649628be3c93bf5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615243 Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#80289}
-
- 30 Apr, 2022 1 commit
-
-
Anton Bikineev authored
Change-Id: I29bcdf3302f37568e8c8925e70a01ba342c17925 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606229Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/main@{#80288}
-
- 29 Apr, 2022 18 commits
-
-
Rohan Pavone authored
This reverts commit 91453880. Reason for revert: Breaking the Fuchsia Deterministic Builder Original change's description: > Reland "[osr] Use the new OSR cache" > > This is a reland of commit 91da3883 > > Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization > on arm64. > > Original change's description: > > [osr] Use the new OSR cache > > > > This CL switches over our OSR system to be based on the feedback > > vector osr caches. > > > > - OSRing to Sparkplug is fully separated from OSR urgency. If > > SP code exists, we simply jump to it, no need to maintain an > > installation request. > > - Each JumpLoop checks its dedicated FeedbackVector cache slot. > > If a valid target code object exists, we enter it *without* > > calling into runtime to fetch the code object. > > - Finally, OSR urgency still remains as the heuristic for > > requesting Turbofan OSR compile jobs. Note it no longer has a > > double purpose of being a generic untargeted installation > > request. > > > > With the new system in place, we can remove now-unnecessary > > hacks: > > > > - Early OSR tierup is replaced by the standard OSR system. Any > > present OSR code is automatically entered. > > - The synchronous OSR compilation fallback is removed. With > > precise installation (= per-JumpLoop-bytecode) we no longer > > have the problem of 'getting unlucky' with JumpLoop/cache entry > > mismatches. Execution has moved on while compiling? Simply spawn > > a new concurrent compile job. > > - Remove the synchronous (non-OSR) Turbofan compile request now > > that we always enter available OSR code as early as possible. > > - Tiering into Sparkplug no longer messes with OSR state. > > > > Bug: v8:12161 > > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 > > Commit-Queue: Jakob Linke <jgruber@chromium.org> > > Auto-Submit: Jakob Linke <jgruber@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#80147} > > Bug: v8:12161 > Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232 > Auto-Submit: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80167} Bug: v8:12161 Change-Id: I73e2d98660e9edfbe07a152a14402380ea9227de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615219Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Owners-Override: Deepti Gandluri <gdeepti@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#80287}
-
Anton Bikineev authored
During weak processing we remember weak callbacks for objects in the old generation. We should check the young-gc flag and enable generational GC before weak processing, as otherwise we would miss the callbacks and forget to update the weak refs. Bug: chromium:1029379 Change-Id: I72c98d4926b57c36af6cc503ce34712f67d50f42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616721Reviewed-by:
-
Igor Sheludko authored
Bug: v8:12797 Change-Id: I2e7f7812b47882766d5accb1963301e7c0731fcd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616725Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#80285}
-
Milad Fa authored
opcodes are already defined under the instruction-selector. Change-Id: Ib8cc1d3b7d8e3f1725306b12450f43c2aff1ae83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616722Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#80284}
-
jameslahm authored
This is a reland of commit b36c87e3. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/42210/overview. This CL moves cctest/test-regexp to unittests/regexp/regexp-unittest and updates unittest.status file for test-regexp. Original change's description: > [test] Move cctest/test-regexp to unittests > > ... /regexp/regexp-unittest. > > Bug: v8:12781 > Change-Id: I3c3ba4c519ff503b242c39d0e3b2350f25d7e84c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607370 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: 王澳 <wangao.james@bytedance.com> > Cr-Commit-Position: refs/heads/main@{#80217} Bug: v8:12781 Change-Id: I8e08147f21feb1e97b681204bc5b771794c3768f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3612663Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#80283}
-
George Wort authored
Introduce get_hints.py and combine_hints.py in order to make the interpretation of basic block counts into hints more configurable and explicit, as well as allowing more accurate and consistent methods of combining multiple profiles. get_hints.py allows for the minimum count and threshold ratio values to be easily altered for different profiles, while combine_hints.py allows the hints produced from different benchmarks and threshold values to be easily and sensibly combined. Simply summing together basic block counts from different benchmarks could previously lead to a longer running benchmark overshadowing multiple shorter benchmarks with conflicting hints. Allowing alteration of the current threshold values gives a doubling of performance, while the new method of combining distinct profiles can double the performance improvement of the secondary benchmark while losing as little as 4% of the improvement gained in the primary benchmark. Design doc: https://docs.google.com/document/d/1OhwZnIZom47IX0lyceyt-S9i8AApDB0UqJdvQD6NuKQ/edit?usp=sharing Bug: v8:10470 Change-Id: I1c09d1eabfdda5ed6794592e2c13ff8b461be361 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545181Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: George Wort <george.wort@arm.com> Cr-Commit-Position: refs/heads/main@{#80282}
-
Anton Bikineev authored
The CL uses the different scheme to enable the generational barrier. The separate global counter (is_enabled_) keeps track of the number of heaps that enable generational GC. If at least one of the heaps enables the generational GC, the counter will enable the write barrier. Technically, the counter could be merged with WriteBarrier::is_enabled_, but having a separate variable allows us to keep DCHECKs if generational barrier is enabled. Bug: chromium:1029379 Change-Id: Iafaa76f96acb18a73f8bde7231434e68c04cb683 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616518Reviewed-by:
-
Junliang Yan authored
Change-Id: I7ba5cd6cf1c76f0955b3ad7184af0a9245f66657 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613765 Commit-Queue: Junliang Yan <junyan@redhat.com> Reviewed-by:
Milad Farazmand <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/main@{#80280}
-
Victor Gomes authored
This make it easier to follow which function was compiled when many maglev graphs are outputted. Bug: v8:7700 Change-Id: If88f6d4aa7306df8a26601f081105bff0eb9c5e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616513 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Victor Gomes authored
Bug: v8:7700 Change-Id: Ia76a091e013aa7649da132c113fcefef06534f3b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616511 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Samuel Groß authored
Bug: chromium:1320784 Change-Id: I7057e294913d3305784af6fc610be250d6431082 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616509 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
-
Victor Gomes authored
The builtin CreateEmptyArrayLiteral actually expects the feedback slot as an smi. Bug: v8:7700 Change-Id: Ib33c3d0abd626ccbc43b4aff2f1cf69a81ff6568 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616506 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Victor Gomes authored
Similar approach as Call (from RegisterList). Bug: v8:7700 Change-Id: Ifc94e2bf53f40a8f556d30d85c2354f8d3a2af1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616502 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Anton Bikineev authored
The CL introduces a new option --cppgc-young-generation. This option can't be enabled statically, because V8 options are parsed after heap initialization. The CL changes minor GC so that it can be enabled dynamically. The way it works is as follows: - the user calls YoungGenerationEnabler::Enable(); - a heap checks in the next atomic pause whether the flag was enabled; - if so, the heap enables young generation for itself. To avoid barrier regressions without young-generation enabled, the CL changes the meaning of the global flag is-any-incremental-or-concurrent-marking to is-barrier-enabled. The runtime option would enable us to test young generation on try- and performance-bots. Bug: chromium:1029379 Change-Id: I664cccdcd208225ffcbf9901f1284b56d088c5c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607993 Commit-Queue: Anton Bikineev <bikineev@chromium.org> Reviewed-by:
-
Nico Hartmann authored
This reverts commit 445190bf. Reason for revert: Speculative revert for https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/38224/overview Original change's description: > [heap] Fix bogus object size computation > > The map of an object may be gone by the time we try to compute its > size for accounting purposes. > > Bug: chromium:1319217 > Change-Id: I93cca766a8cedebf4ed30a3a65fd6eff5bc72bcf > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605817 > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80271} Bug: chromium:1319217 Change-Id: I04139a4b469649a7f689643f949b106cd97dc94b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616503 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Owners-Override: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#80273}
-
Simon Zünd authored
Doc: https://bit.ly/revive-restart-frame This CL adds the V8 debugger part of the restart frame logic as well as some bits for the inspector. The CL is centered around two key pieces: When the user requests a restart, we stash the stack frame ID (aka the stack pointer) and optionally the inlined frame index for optimized frames, and then continue execution. Once execution bubbles back into JS land, we throw a termination exception when a frame restart was requested. Note that the CL doesn't hook up the logic yet to CDP and the CL also does not the actual handling of the termination exception in the unwinder. R=bmeurer@chromium.org, kimanh@chromium.org Bug: chromium:1303521 Change-Id: I12cfb408c66072dd19f8180e530f84c987d1374d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613383Reviewed-by:
Kim-Anh Tran <kimanh@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#80272}
-
Michael Lippautz authored
The map of an object may be gone by the time we try to compute its size for accounting purposes. Bug: chromium:1319217 Change-Id: I93cca766a8cedebf4ed30a3a65fd6eff5bc72bcf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605817Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#80271}
-
Lu Yahan authored
array_buffer is not used by https://chromium-review.googlesource.com/c/v8/v8/+/3605611 ,so should delete USE(array_buffer). And riscv64: Enable atomic ops in TF bultins Change-Id: Ie8ffd3009bfacdbe67a8fe1e417388add70fc296 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616169Reviewed-by:
-
- 28 Apr, 2022 19 commits
-
-
Junliang Yan authored
Change-Id: I23376b2ad0dc8616048f8c9c7122d5bf38fa70d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615013 Commit-Queue: Junliang Yan <junyan@redhat.com> Reviewed-by:
-
Michael Lippautz authored
- Rely on GCCallbacksScope to avoid nesting callbacks. - Use a single entrypoint consistently for all callsites. Change-Id: I6be1f749a2d6bfc9d5db4c84c753e9176472bce2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605821Reviewed-by:
-
Adam Klein authored
This reverts commit a3f66927. Reason for revert: test failures on TSAN/no-concurrent-marking bot: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/8549/overview Original change's description: > [heap] Refactor atomic marking phase > > The atomic marking phase was organized in many distinct smaller > phases. In particular, before http://crrev.com/c/3584115 the marking > phase split into two large separate phases. > > This CL reorganizes marking into two phases that perform regular V8 > heap marking, Oilpan, and ephemerons: > - A parallel phase that likely drains all marking worklists; > - A single-threaded final phase to catch any left overs; > > This avoids artificial splitting in phases and also avoids repeated > starting and joining of jobs. > > Change-Id: I5cccfc5777837d9ece10d8f4925781bf2d07d9da > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602507 > 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@{#80265} Change-Id: I4838e9316bd30f8a0b78fa6a27820d3457e1e579 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3614972 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/main@{#80267}
-
Junliang Yan authored
Change-Id: Iae749161f5a6f2347a64f45579d9bd9d5e0ccaf6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613387Reviewed-by:
-
Michael Lippautz authored
The atomic marking phase was organized in many distinct smaller phases. In particular, before http://crrev.com/c/3584115 the marking phase split into two large separate phases. This CL reorganizes marking into two phases that perform regular V8 heap marking, Oilpan, and ephemerons: - A parallel phase that likely drains all marking worklists; - A single-threaded final phase to catch any left overs; This avoids artificial splitting in phases and also avoids repeated starting and joining of jobs. Change-Id: I5cccfc5777837d9ece10d8f4925781bf2d07d9da Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602507Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
Milad Fa authored
Port b0118171 Original Commit Message: This CL adds a new builtin called "RestartFrameTrampoline". This trampoline is relatively simple: It leaves the current frame and re-invokes the function. This essentially restarts the function and is one of the key components required to bring back the "Restart frame" DevTools debugging feature. The builtin is closely related to the "FrameDropperTrampoline" removed in the CL https://crrev.com/c/2854750. The key difference is that the "FrameDropperTrampoline" dropped to an "arbitrary" frame pointer before restarting the function (arbitrary in the sense that it was provided as an argument). This caused issues as the feature was implemented in a way that the frame pointer wasn't necessarily valid anymore. In comparison, the "RestartFrameTrampoline" relies on the V8 unwinder to drop it in the correct frame first and is then invoked via either the CEntry stub or the deoptimizer (see design doc for details). R=szuend@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: Id742eeaa59a540ec206a92308fb72bb50413e267 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613391Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Milad Farazmand <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/main@{#80264}
-
Leszek Swirski authored
StoreField wasn't emitting a write barrier after performing the store, leading to the usual set of hard-to-debug issues. Now it does. The write barrier requires some of its registers to be in fixed locations, and others to be clobberable. Thsi patch extends the temporaries mechanism to allow requesting a specific temporary, in this case for the slot address scratch register. Bug: v8:7700 Change-Id: I506856071e0f44feafb98c2685ef1b3362b0e41e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613388 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#80263}
-
Dominik Inführ authored
This is a reland of commit 5d235def The previous version of this CL got reverted because the cached size of an invalidated object wasn't up-to-date when performing a GC. Not all size changes go through NotifyObjectLayoutChange, so https://crrev.com/c/3607992 introduced NotifyObjectSizeChange as a bottleneck for object size changes/right-trimming. This method is now used to update the size of invalidated objects. Original change's description: > [heap] Store size with invalidated object > > When updating pointers during a full GC, a page might not be swept > already. In such cases there might be invalid objects and slots recorded > in free memory. Updating tagged slots in free memory is fine even though > it is superfluous work. > > However, the GC also needs to calculate the size of potentially dead > invalid objects in order to be able to check whether a slot is within > that object. But since that object is dead, its map might be dead as > well which makes size calculation impossible on such objects. The CL > changes this to cache the size of invalid objects. A follow-up CL will > also check the marking bit of invalid objects. > > Bug: v8:12578, chromium:1316289 > Change-Id: Ie773d0862a565982957e0dc409630d76552d1a32 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599482 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Patrick Thier <pthier@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80169} Bug: v8:12578, chromium:1316289 Change-Id: I1f7c6070b8e7d116aeb1a8d03d4f87927ab40872 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608632Reviewed-by:
Jakob Linke <jgruber@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Victor Gomes authored
We should just call the builtin while we don't have inlined allocations. Bug: v8:7700 Change-Id: I6da605cc756b0f44fb1366e90e6c0dac60ae9beb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613326 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Camillo Bruni authored
Avoid calculating the checksum on every snapshot deserialization. - Desktop: by default only in release - Android: once per process Most snapshot corruptions happen on android devices but there we also have the highest overhead from calculating the checksum. Findings doc: https://docs.google.com/document/d/e/2PACX-1vQWdJjrZpTL5VjbP_LHH-qQj-9vcmuLez93WPZhoacJT2bTXfCAdJpbexfJWP9jrAI5ek_416uZE6_W/pub Bug: v8:12195 Change-Id: Ic7f2f45a9e8ade31c3774a7b659d9c30769e2b44 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3583983Reviewed-by:
-
Igor Sheludko authored
This is a reland of commit 9d31f866 There were issues with --future flag implications on M1. Original change's description: > [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1) > > ... for V8 code space. The feature is currently disabled. > > In order to use fast W^X permission switching we must allocate > executable pages with readable writable executable permissions (RWX). > However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further > permission changing of RWX memory pages. This means that the code page > headers must be allocated with RWX permissions too because otherwise > it wouldn't be possible to allocate a large code page over the freed > regular code page and vice versa. > > When enabled, the new machinery works as follows: > > 1) when memory region is reserved for allocating executable pages, the > whole region is committed with RWX permissions and then decommitted, > 2) since reconfiguration of RWX page permissions is not allowed on > MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts > to change them, > 3) the request to set RWX permissions in the executable page region > just recommits the pages without changing permissions (see (1), they > were already allocated as RWX and then discarded), > 4) in order to make executable pages inaccessible one must use > OS::DiscardSystemPages() instead of OS::DecommitPages() or > setting permissions to kNoAccess because the latter two are not > allowed by the MacOS (see (2)). > 5) since code space page headers are allocated as RWX pages it's also > necessary to switch between W^X modes when updating the data in the > page headers (i.e. when marking, updating stats, wiring pages in > lists, etc.). The new CodePageHeaderModificationScope class is used > in the respective places. On unrelated configurations it's a no-op. > > The fast permission switching can't be used for V8 configuration with > enabled pointer compression and disabled external code space because > a) the pointer compression cage has to be reserved with MAP_JIT flag > which is too expensive, > b) in case of shared pointer compression cage if the code range will > be deleted while the cage is still alive then attempt to configure > permissions of pages that were previously set to RWX will fail. > > This also CL extends the unmapper unit tests with permissions tracking > for discarded pages. > > Bug: v8:12797 > Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80238} Bug: v8:12797 Change-Id: I0fe86666f31bad37d7074e217555c95900d2afba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610433Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80259}
-
Benoît Lizé authored
There are three ways to parse /proc/self/maps in platform-linux.cc, remove one to use common code. In the process, add a unit test, and fix some issues in the latest iteration of /proc/self/maps parsing. Change-Id: I4701ea49fe8cce53aea0179e194dc48fbebb2ff5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605226 Commit-Queue: Benoit Lize <lizeb@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#80258}
-
Omer Katz authored
For some reason the compiler was optimizing away the reference to the object in WeakContainerTest.ConservativeGCTracesWeakContainer and thus not finding it conservatively. This CL revises the tests such that the compiler is no longer able to optimize references away. Bug: v8:12824 Change-Id: Ie598a1cf1124c2983a6c61fd4e990734d36f5832 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610627Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/main@{#80257}
-
Camillo Bruni authored
Change-Id: Ide8935a02cb64134c3bdeb8b3e38e9a6e043e13c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610432Reviewed-by:
-
Victor Gomes authored
- Supports Float64 Add for SmiAdd bytecode - Adds a Float64Constant and ChangeInt32ToFloat64 nodes - Converts floats to tagged in Phi node inputs - Fixes spill double representation - Fixes materialisation during a deopt of a double in the stack Bug: v8:7700 Change-Id: I9217a64313b4bd5d0015f935c23771ecf9a2c7ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610426 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Simon Zünd authored
Doc: https://bit.ly/revive-restart-frame Context: https://crrev.com/c/3582395 (jumbo CL with the whole feature) This CL adds a new builtin called "RestartFrameTrampoline". This trampoline is relatively simple: It leaves the current frame and re-invokes the function. This essentially restarts the function and is one of the key components required to bring back the "Restart frame" DevTools debugging feature. The builtin is closely related to the "FrameDropperTrampoline" removed in the CL https://crrev.com/c/2854750. The key difference is that the "FrameDropperTrampoline" dropped to an "arbitrary" frame pointer before restarting the function (arbitrary in the sense that it was provided as an argument). This caused issues as the feature was implemented in a way that the frame pointer wasn't necessarily valid anymore. In comparison, the "RestartFrameTrampoline" relies on the V8 unwinder to drop it in the correct frame first and is then invoked via either the CEntry stub or the deoptimizer (see design doc for details). Bug: chromium:1303521 Change-Id: I7bd46620808f8694c2c776b8bcd267e525d5b581 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585944 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
-
Andreas Haas authored
The test is very resource intensive and is therefore not reliable on weaker systems. The limits are the same for all configurations, so it's not a problem if we disable the test for some configurations. R=machenbach@chromium.org Fixes: v8:12836 Change-Id: If187bd3d5d352b1685d3a6e43a76860a263f53de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608631Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#80253}
-
Camillo Bruni authored
* Prefix all isolate variables with i_ for i::Isolate and v8_ for v8::Isolate * Change _DO_NOT_USE macro suffix to _INTERNAL Change-Id: I005efbe0192cf202741448c63a4263e6a4b1fa1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610429 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
-
Victor Gomes authored
Since Sparkplug compiles pretty quickly and it might impact loading time, there is an argument that we should actually use high priority threads for CSP. This adds a flag so that we create a finch experiment to test this hypothesis. Change-Id: Ib8965fbea015ddaeb25503bd92873bfff5daa1ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605245 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#80251}
-
