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}

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}

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: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80286}

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}

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}

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}

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}

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: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80281}

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}

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}

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: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80278}

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: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80277}

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: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80276}

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: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80275}

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}

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}

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}

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}

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: 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}

Change-Id: I23376b2ad0dc8616048f8c9c7122d5bf38fa70d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615013
Commit-Queue: Junliang Yan <junyan@redhat.com>
Reviewed-by: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80269}

- 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: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80268}

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}

Change-Id: Iae749161f5a6f2347a64f45579d9bd9d5e0ccaf6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613387Reviewed-by: Milad Farazmand <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80266}

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: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80265}

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}

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 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: 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}

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: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80260}

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: 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/+/3610627Reviewed-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}

Change-Id: Ide8935a02cb64134c3bdeb8b3e38e9a6e043e13c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610432Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80256}

- 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}

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}

* 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: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80252}

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}

... from ArgumentsAdaptorFrame to InlinedExtraArguments.

Change-Id: I772e0546dd50282a4cd14723625fd5bf774f424c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3609968Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80250}

Bug: chromium:1320126
Change-Id: Ieab14e0793e64c607ffee656eed66efe31be65f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610434Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80249}