When deleting a JSObject's last property, only that particular slot
in the old-to-new rememebered set needs to be deleted. The object's
slots don't need to be invalidated anymore since V8 doesn't use
unboxed doubles anymore. While the runtime could install another
property at this address, it will therefore always be a tagged pointer.
Bug: v8:12578, chromium:1316289
Change-Id: Ief072f58e53501c1c1f01c902e21467a37ccdc3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620274
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80303}
This is a reland of commit a3f66927f9
The reland addresses a few CHECKs that were too agressive and also
properly adjusts Oilpan's marking configurations depending on V8's
flags.
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: I26648da361b92d787c173aa9d390100ce8958728
Bug: chromium:1320896
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616519
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80301}
... not exceeding the maximum size of the backing store
before ReplacementStringBuilder in StringReplaceGlobalRegExpWithString.
Bug: v8:12843
Change-Id: I3ccf07a4e6de35a3a571ebfccc34e54eb27a0819
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616555
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#80298}
We weren't really translating between location (line and column number)
and source position (character offset) consistently, especially when it
came to inline <script>s. There were also inconsistencies between what
Debugger.getPossibleBreakpoints and Debugger.setBreakpointByUrl would
do.
With this CL, we are now consistently operating under the following
assumptions:
(1) For inline <scripts>s with a //@ sourceURL annotation, we assume
that the line and column number that comes in via the protocol is
in terms of the source text of the script.
(2) For inline <script>s without said annotation, we assume that the
line and column numbers are in terms of the surrounding document.
This is finally aligned with how the DevTools front-end operates.
Fixed: chromium:1319828
Change-Id: I98c4ef04b34a97caf060ff4f32690b135edb6ee6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610622
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80292}
This reverts commit 23b2d571a7.
Reason for revert: Breaks the V8 roll https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/1000394/
Original change's description:
> Reland "[heap] Store size with invalidated object"
>
> This is a reland of commit 5d235def26
>
> 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/+/3608632
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80262}
Bug: v8:12578, chromium:1316289
Change-Id: I88b73ebe09bb923ba4ac57b0dbdceb08a1badd99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616730
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Owners-Override: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80291}
This reverts commit 9145388055.
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 91da38831d
>
> 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/+/3615219
Reviewed-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}
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/+/3616721
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80286}
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/+/3545181
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: George Wort <george.wort@arm.com>
Cr-Commit-Position: refs/heads/main@{#80282}
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/+/3616518
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80281}
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: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80279}
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: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80274}
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/+/3613383
Reviewed-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}
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}
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/+/3616169
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80270}
- 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/+/3605821
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80268}
This reverts commit a3f66927f9.
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}
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}
Port b011817158
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/+/3613391
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80264}
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}
This is a reland of commit 5d235def26
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/+/3608632
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80262}
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: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80261}
This is a reland of commit 9d31f8663a
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/+/3610433
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80259}
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}
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/+/3610627
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80257}
- 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: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80255}
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: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80254}
