This reverts commit 6119362077.
Reason for revert: Blocking roll: https://chromium-review.googlesource.com/c/chromium/src/+/3802992/
Original change's description:
> [heap, api] Check assumptions for embedder fields on set
>
> Previously, we would set embedder fields and do type checks (on
> embedder fields) in the GC. This does not work nicely as embedder
> fields contain system pointers whereas we can only operate with
> tag-aligned reads/writes. The end result of assembling pointers was
> somtimes broken for concurrent marking.
>
> In this CL we reverse the mode and check assumptions when writing the
> fields. From Blink we generally only write once and use the fields in
> the GC and via reads multiple times.
>
> We assume, that when running with CppHeap, any pointer on an instance
> field that points into CppHeap, also has the type field set with the
> appropriate tracing information. In debug builds we also verify that
> the embedder field indeed points to the start of an Oilpan object.
>
> Bug: chromium:1337690
> Change-Id: I9f9a8e691cdcf666861a455dcf8f65f2fe80b034
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788206
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82120}
Bug: chromium:1337690
Change-Id: Iaece8f51883c7d001fb18ef48faaf271c48b8f11
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804245
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82127}
This is a strictly code moving change. We move the diffing algorithm
out of liveedit.cc into its own file.
We want to replace the current diffing algorithm and to stay safe we
will ship old and new algorithm side-by-side for a release for easy
revertability. Given that liveedit.cc is already large enough we
extract the diffing algo into a separate file.
R=kimanh@chromium.org
Bug: chromium:1205288
Change-Id: If5ebb6c2dff2f00387c9e2ab87e4bb61d1f1484a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3802687
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82124}
We record Sparkplug compiled into SFI which will be saved in disk cache, once deserializes SFI from disk cache, and the SFI was Sparkplug compiled, we trigger concurrent batch Sparkplug compilation, and directly allocate feedback vector on the first call.
This CL can improve Speedometer2 by +2%.
Change-Id: I89b0ffc6d7a107a1b8c131529e02cd7eb2890888
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3725612
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Tao Pan <tao.pan@intel.com>
Cr-Commit-Position: refs/heads/main@{#82122}
This change adds new functions to BackgroundCompileTask which closely
match those in BackgroundDeserializeTask. These functions allow a caller
to manage background merging of newly compiled content into an existing
Script from the Isolate compilation cache. These functions are not yet
exposed via the API; instead, StressBackgroundCompileThread uses them to
increase test coverage of the merging logic.
Bug: v8:12808
Change-Id: I4d2f429164223785169fe447ce2bdd8beaee00d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793959
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82121}
Previously, we would set embedder fields and do type checks (on
embedder fields) in the GC. This does not work nicely as embedder
fields contain system pointers whereas we can only operate with
tag-aligned reads/writes. The end result of assembling pointers was
somtimes broken for concurrent marking.
In this CL we reverse the mode and check assumptions when writing the
fields. From Blink we generally only write once and use the fields in
the GC and via reads multiple times.
We assume, that when running with CppHeap, any pointer on an instance
field that points into CppHeap, also has the type field set with the
appropriate tracing information. In debug builds we also verify that
the embedder field indeed points to the start of an Oilpan object.
Bug: chromium:1337690
Change-Id: I9f9a8e691cdcf666861a455dcf8f65f2fe80b034
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788206
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82120}
Feedback vector allocation can trigger a GC, and thereby make the
WasmCompileLazyFrame visible for the GC. This CL add stack scanning
for the WasmCompileLazyFrame.
Design doc: http://doc/1peovM6N6C4nSEdC77l4uxU1L0njA0RTaOjy5F12r2CQ
Change-Id: Iec16f50ad2c8ad7e6dcf05f9e620163d3b60ea0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789516
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82119}
As requested in https://chromium-review.googlesource.com/c/v8/v8/+/3794708
No intended behavior change.
Bug: none
Change-Id: I5816ecf6073dc3c0d558d52518e38e4dbee7d562
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3796233
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82117}
This CL fixes issues in YoungGenerationConcurrentMarkingVisitor
(YGCMV) that were discovered during an offline integration test which
uses YGCMV during MinorMC's final pause.
This also adds PopOnHold() to EmptyMarkingWorklist, in order to
process on-hold objects during final pause once concurrent marking is
working.
Bug: v8:13012
Change-Id: Ia4fef101bd974de9f5b031974cdae787dcbd3819
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3803030
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82116}
The type stored in {Result} should not always be the same as derived by
the compiler for the argument to {Decoder::toResult}. If we pass in a
temporary, we most often want it to be stored by value, not by
reference.
This CL enforces this; if requirements change in the future, we can
remove the static assertions and think about how to protect against
accidental UAF when referencing a temporary value.
R=jkummerow@chromium.orgCC=mliedtke@chromium.org
Change-Id: Ia0449e6ed7342319799479b200af35660fccc6d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792115
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82115}
Refactor out the parallel move algorithm into a helper class, and add
stack slot support for cases where stack slots can clobber each other
(e.g. a Phi which is an input to another Phi). Also add some
documentation for how these parallel moves work.
Bug: v8:7700
Change-Id: Ib9bb1cce8287e2ad34b4417b77b148a1ad483268
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3803032
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82113}
clang now complains when a BitField for an enum is too wide.
We could suppress this, but it seems kind of useful from an
uninformed distance, so I made a few bitfields smaller instead.
(For AddressingMode, since its size is target-dependent, I added
an explicit underlying type to the enum instead, which suppresses
the diag on a per-enum basis.)
This is without any understanding of the code I'm touching.
Especially the change in v8-internal.h feels a bit risky to me.
Bug: chromium:1348574
Change-Id: I73395de593045036b72dadf4e3147b5f7e13c958
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3794708
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82109}
Introduce RootVisitor and related class hierarchy to just handle
roots. This avoids the awkard definitions for roots visiation in all
the cases they are not needed.
Change-Id: Ib0912e4bf543db2ecf68caead6929c68d6afdda6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782794
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82107}
Bump the memory size limit of memory64 memories from 4GB to 16GB. Tests
are added for larger sizes (5GB, 16GB).
Drive-by: Improve two decoder errors to properly include the unit,
tested by the new tests.
R=jkummerow@chromium.org
Bug: v8:10949
Change-Id: I99dfc216b9213838784214c0b65ba863831d5884
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789507
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82105}
- No slots are invalidated as all slots are always treated as tagged
or aligned pointers.
- The map is not updated.
Change-Id: Ifb8ffddfa3b626de3233f17f67b46fec36146f2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3795378
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82104}
Make sure to always start at the innermost loop, and to have Jump phis
participate in the lifetime extension.
Bug: v8:7700
Change-Id: Iefb9108519d027782ba9f0ce8c0696fba0a0aa52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793390
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82102}
When an object either gets promoted or evacuated, old-to-shared slots
need to be recorded like we already do for old-to-old or old-to-new.
Bug: v8:11708
Change-Id: Ifb5b3d50a59aa45bf8289e1cd7610bb2f317fd6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3794648
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82096}
The function returns true if the function does not do anything like:
() => {}.
Change-Id: I049d7956c443b5d2bb8017a48547376f13acd0a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3778969
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82093}
In https://crrev.com/c/3764190, V8_COMPILER_IS_MSVC gets used before it
is defined, so it has no effect. Move the V8_COMPILER_IS_MSVC define up
to fix this.
Change-Id: I94c63ad2a8a7555c85730792c1f91e1285a9b77f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3774095
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82090}
zero extending the offset register must happen regardless
of the length of the offset_imm.
We can only use ip as the offset_reg as r0 and and r1
are being used as scratch later on.
Change-Id: I5517f974af40eb014b8e1f58f8e531909c4d466a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3794646
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#82087}
The jump table and far jump table are allocated once per code space, but
the lazy compile table only needs to exist exactly once, and it does not
really matter in which code space we allocate it.
Before dynamic tiering, we could always allocate it in the initial code
space (which was empty at the point when we allocated it), but with
deserialization of a partially tiered module we can end up in a
situation where we first deserialize some TurboFan functions into the
initial code space, and when we later try to allocate the lazy compile
table (when we encounter the first non-serialized function) we do not
have enough space any more in the initial code space.
This CL allows to allocate the lazy compile jump table in any code space
to avoid that failure.
R=thibaudm@chromium.org
Bug: chromium:1348472, chromium:1348214
Change-Id: I58c9a8a6541f2ab7df26ddfd1b65d31cc99337fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792607
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82086}
With this CL, blocks at the end of the ExternalPointerTable that are
completely empty after sweeping will be decommitted to reduce the
table's memory footprint.
Bug: v8:10391
Change-Id: I1002e95a0f9c22400fdd2620047d86738a1f7af4
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/+/3791903
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82085}
Port 781a5b5ad6
Original Commit Message:
Many platform-dependent LiftoffAssembler methods do not use all
parameters. Comment out the name of unused ones, to make it easier to
see which implementation uses which parameters.
Also, remove {is_load_mem} from arm's {LoadInternal}, because it is
unused there.
R=clemensb@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I861df687e373ed7dd302fc5e2e1299f09f899166
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792177
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82084}
This is a reland of commit 07e11a64e4.
The original change removed the fill_thehole_and_call_runtime bailout
in StringBuiltinsAssembler::StringToArray() so when the string
is external and cannot be unpacked, the FixedArray won't be filled
with holes before we call into the runtime, thus failing a
heap verification if a GC happens before the array is filled. This
reland adds back the bailout for this case.
Bug: v8:12718, chromium:1330410
Original change's description:
> [heap] pre-populate the single_character_string_cache
>
> This simplifies the code and removes the runtime overhead of
> spontaneously adding strings to the cache.
>
> Bug: v8:12718
> Change-Id: I2ed49bd82e3baf2563eeb8f463be72c0308c52c5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616553
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#80803}
Change-Id: I25e8724d511a8d0d971fa2a9b6ba8a0eafce4413
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793525
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82082}
If we grow memory (out-of-place, so only without trap handling and only
if the maximum is >1GB) and the previous size is close to the maximum,
then the minimum growth we calculate can be bigger than the allowed
maximum. In this situation, the {std::clamp} has undefined behaviour,
since the provided lower limit is bigger then the upper limit.
Thus apply {std::min} and {std::max} in an order such that {max_pages}
has precedence over {min_growth}.
R=thibaudm@chromium.org
Bug: chromium:1348335
Change-Id: I4f9e9ce10a0685892248eaf0e06ffd2e84b9a069
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793396
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82081}
This fixes some instances of -Wundefined-inline in the C++20 build.
Bug: chromium:1284275
Change-Id: I134e866183e1e42b9726153964af9910d03cd3b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791525
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82080}
Due to popular demand.
As a necessary byproduct, this drops our former experimental in-progress
support for accessing struct fields from JS as `.field0` etc. If we need
something similar in the future, we'll have to build a new mechanism for
it that scales to >1020 fields.
Bug: v8:7748
Change-Id: I08b2051bd9f76cf7128f3d4c74910ca891c38130
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793616
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82079}
So far all OLD_TO_SHARED slots were deleted after a shared GC. The
remembered set was rebuilt in the next shared GC from scratch. This CL
changes this behavior to only remove slots that don't point into the
shared heap anymore.
We still need to remove the full OLD_TO_SHARED slot set for young
generation pages though. During a shared GC we use the OLD_TO_SHARED
remembered set to cache references into the shared heap even for
pages in the young generation to avoid the second new space object
iteration.
Bug: v8:11708
Change-Id: If92fca25e8fe7e7bf5fc5562c974b0d4c121cb02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3790967
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82078}
It also changes Abort to be a ControlNode.
Bug: v8:7700
Change-Id: I836c353f8110140c023c582ea91c456e23196921
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793397
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82076}
The {LiftoffAssembler::Load} method already receives an {i64_offset}
parameter which skips the UXTW (zero extension of 32-bit addresses) in
the memory operand. The same needs to happen on stores.
On 32-bit platforms, we cannot have addresses >=4GB anyway (they would
be detected as OOB before reaching the point in question), so this is
not a problem. On x64, all 32-bit registers are zero-extended already
(which is debug-checked in the generated code), so this is also no
problem (and we just ignore the additional parameter).
R=jkummerow@chromium.org
Bug: v8:10949
Change-Id: I3c2266dde1bf9d182b6759893f7f64540ae12261
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791051
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82074}
This is required by the MVP spec. In the future, it might be possible
to pass values for any immutable fields.
Bug: v8:7748
Change-Id: Ie7705b48e9d6ebb87d5e1b0a2a10556302395db6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793383
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82072}
Many platform-dependent LiftoffAssembler methods do not use all
parameters. Comment out the name of unused ones, to make it easier to
see which implementation uses which parameters.
Also, remove {is_load_mem} from arm's {LoadInternal}, because it is
unused there.
R=jkummerow@chromium.org
Bug: v8:10949
Change-Id: I57281237c493cc35c3cd31d814bca9bef510fdd2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791049
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82070}
If dynamic tiering or lazy compilation is enabled (which is the
default), the initial code space needs to be big enough to also hold the
lazy compilation jump table.
Otherwise a CHECK will fail later when trying to allocate that table (in
UseLazyStub).
R=ahaas@chromium.org
Bug: chromium:1348472, chromium:1348214
Change-Id: If7a091a5782f1b2099d35d1a06292dddbaeb0598
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793389
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82067}
If a value is expected to be in a particular register for a register
merge, allow for it to be moved there from another register, without
expecting it to be spilled.
Bug: v8:7700
Change-Id: I9ef5e77b3a744a6284f4790ec9d5a7c60739a710
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793391
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82066}
In addition to the marking barrier we now also need the shared barrier
for properly tracking the old-to-shared remembered set. So invoke
the full write barrier for set_map and set_map_after_allocation.
Bug: v8:11708
Change-Id: Ic234e7fad3733ab1348298f5fcc2b76e44cf4b8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793388
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82065}
Currently, we canonicalize types for call_indirect by looking in the
current module for a signature of the same shape. This is not enough
as of wasm-gc. Instead, the canonical identifier representing a type
has to be computed via isorecursive canonicalization.
This change is implemented behind a flag for now.
Future work: Also integrate export wrappers with isorecursive
canonical types. We need to store wrappers in instance-independent
storage.
Drive-by:
- Always emit type check for call_indirect. We did not emit a check
only when typed-function-references was enabled, but not gc. This
is not something that will be possible long-term.
- Fix some wasm cctests.
Bug: v8:7748
Change-Id: I7cced187009ac148c833dff5e720a8bb9a717e68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784600
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82064}
Remove the return value from various UpdateSlot methods. These methods
were always returning REMOVE_SLOT anyways.
Bug: v8:11708
Change-Id: I5398f0df14e93e3e74a13aea42d7c422ffc100a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793384
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82061}
We sometimes create jobs that initially hold no work. In those cases,
use CreateJob instead of PostJob.
New background threads will later be spawned when
NotifyConcurrencyIncrease is called.
R=etiennep@chromium.org
Bug: v8:13096
Change-Id: Ieb9f9e03d01af6a72fe5785be72c523a553d0f1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762578
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82060}
This eliminates some "bitwise operation between different enumeration
types" warnings in c++20, where such ops are deprecated.
Bug: chromium:1284275
Change-Id: Ie7f1d5e9430029bc694cef0358d217871670a8d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791964
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82057}
This very large changeset adds support for RISCV32.
Bug: v8:13025
Change-Id: Ieacc857131e6620f0fcfd7daa88a0f8d77056aa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736732
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82053}
CreateJob() doesn't schedule anything until Join() or Notify*() is called. CreateJob().Join() will thus schedule the right number of
workers for the job right away (taking into account the main thread
contributes), whereas PostJob().Join() schedules 1 worker that won't
be necessary once doing Join() and the main thread kicks in.
This has the effect of reducing 1 unnecessary context switch each time
the jobs are schedule.
Bug: chromium:1287665
Change-Id: Ie262f8904cc8ac78d9e5cbd23ef28dc5b013a625
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3746080
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82047}
It was delegating to GetDerivedMap but not handling the possible
error coming from it.
Bug: v8:11111,chromium:1347722
Change-Id: I348ed721281d8edd324f0e364d8ed45602cb9f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791063
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82046}
This is a reland of commit e895b7af73
The unit test has been updated to work correctly when
--stress-incremental-marking is enabled.
Original change's description:
> Background merging of deserialized scripts
>
> Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
> with which an embedder could request that V8 merge newly deserialized
> script data into an existing Script from the Isolate's compilation
> cache. This change implements those new functions. This functionality is
> still disabled by default due to the flag
> merge_background_deserialized_script_with_compilation_cache.
>
> The goal of this new functionality is to reduce memory usage when
> multiple frames load the same script with a long delay between (long
> enough for the script to have been evicted from Blink's in-memory cache
> and for the top-level SharedFunctionInfo to be flushed). In that case,
> there are two Script objects for the same script: one which was found in
> the Isolate compilation cache (the "old" script), and one which was
> recently deserialized (the "new" script). The new script's object graph
> is essentially standalone: it may point to internalized strings and
> readonly objects such as the empty feedback metadata, but otherwise
> it is unconnected to the rest of the heap. The merging logic takes any
> useful data from the new script's object graph and attaches it into the
> old script's object graph, so that the new Script object and any other
> duplicated objects can be discarded. More specifically:
>
> 1. If the new Script has a SharedFunctionInfo for a particular function
> literal, and the old Script does not, then the old Script is updated
> to refer to the new SharedFunctionInfo.
> 2. If the new Script has a compiled SharedFunctionInfo for a particular
> function literal, and the old Script has an uncompiled
> SharedFunctionInfo, then the old SharedFunctionInfo is updated to
> point to the function_data and feedback_metadata from the new
> SharedFunctionInfo.
> 3. If any used object from the new object graph points to a
> SharedFunctionInfo, where the old object graph contains a matching
> SharedFunctionInfo for the same function literal, then that pointer
> is updated to point to the old SharedFunctionInfo.
>
> The document at [0] includes diagrams showing an example merge on a very
> small script.
>
> Steps 1 and 2 above are pretty simple, but step 3 requires walking a
> possibly large set of objects, so this new API lets the embedder run
> step 3 from a background thread. Steps 1 and 2 are performed later, on
> the main thread.
>
> The next important question is: in what ways can the old script's object
> graph be modified during the background execution of step 3, or during
> the time after step 3 but before steps 1 and 2?
>
> A. SharedFunctionInfos can go from compiled to uncompiled due to
> flushing. This is okay; the worst outcome is that the function would
> need to be compiled again later. Such a risk is already present,
> since V8 doesn't keep IsCompiledScopes for every compiled function in
> a background-deserialized script.
> B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
> compilation. This is also okay; the merge completion logic on the
> main thread will just keep this lazily compiled data rather than
> inserting compiled data from the newly deserialized object graph.
> C. SharedFunctionInfos can be cleared from the Script's weak array if
> they are no longer referenced. This is mostly okay, because any
> SharedFunctionInfo that is needed by the background merge is strongly
> referenced and therefore can't be cleared. The only problem arises if
> the top-level SharedFunctionInfo gets cleared, so the merge task must
> deliberately keep a reference to that one.
> D. SharedFunctionInfos can be created if they are needed due to lazy
> compilation of a parent function. This change is somewhat troublesome
> because it invalidates the background thread's work and requires a
> re-traversal on the main thread to update any pointers that should
> point to this lazily compiled SharedFunctionInfo.
>
> At a high level, this change implements three previously unimplemented
> functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
>
> - BackgroundDeserializeTask::SourceTextAvailable, run on the main
> thread, checks whether there is a matching Script in the Isolate
> compilation cache which doesn't already have a top-level
> SharedFunctionInfo. If so, it saves that Script in a persistent
> handle.
> - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
> whether the persistent handle from the first step exists (a fast
> operation which can be called from any thread).
> - BackgroundDeserializeTask::MergeWithExistingScript, run on a
> background thread, performs step 3 of the merge described above and
> generates lists of persistent data describing how the main thread can
> complete the merge.
> - BackgroundDeserializeTask::Finish is updated to perform the merge
> steps 1 and 2 listed above, as well as a possible re-traversal of the
> graph if required due to newly created SharedFunctionInfos in the old
> Script.
>
> The merge logic has nothing to do with deserialization, and indeed I
> hope to reuse it for background compilation tasks as well, so it is all
> contained within a new class BackgroundMergeTask (in compiler.h,cc). It
> uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
> the object visitation that updates pointers to SharedFunctionInfos.
>
> [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
>
> Bug: v8:12808
> Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#81941}
Bug: v8:12808
Change-Id: Id2036dfa4eba8670cac899773d7a906825fa2c50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787266
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#82045}
1. A remainder equal to zero means no deopt.
2. We need the input value in the input register, so we need to treat
rax as a clobbered temporary instead of a fixed input.
Bug: v8:7700
Change-Id: I9a7b7f3cc48e17b262aa7f9084fa864ad505be54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788099
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82044}
While marking uses, record what values are used inside a loop, but
defined outside of it. Then, on the loop end, extend the lifetime of
these values.
Bug: v8:7700
Change-Id: I1bba037be760b4871673ecf0af584f5bf72fc35c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782797
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82040}
Memory64 currently does not use trap handling, so we should not allocate
a guard region (10GB total reservation).
This is implemented by adding a {WasmMemoryFlag} enum in the backing
store header, which replaces the previous {MemoryIndexType}. The flag is
not stored with the backing store, as the backing store does not care
about the index type, and we might want to share the same backing store
for memory32 and memory64 (if sizes permit this).
Instead, we (still) store the flag with the WasmMemoryObject and pass it
to the backing store methods.
R=jkummerow@chromium.org
Bug: v8:10949
Change-Id: I284b85b98d181ba5e8d454b24bfa48f6ac201be5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789506
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82038}
I forgot to remove the -1 when hoisting it.
Bug: v8:7700
Change-Id: I407d387058ef476ae2359f8c3815d6a70fff1b97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791904
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82037}
Register merges participate in the same parallel gap move as phi inputs,
but their allocation is not aware of the phis' existence (since the
register merge allocation sees the register state _before_ phi input
allocation, which is because that's what parallel move requires). This
means that they might move into a register that is used by a Phi, and
possibly will clobber its value.
Avoid this by recording what registers phis move values into during code
gen, and skipping register moves into those registers. Also DCHECK that
the recorded gap moves can't clobber a target register from a previous
gap move. Additionally, add printing for register merges (both in
regalloc tracing and graph printing).
Bug: v8:7700
Change-Id: I8bd4803a30a894c5654e33fc5657ef3fe6cf7a0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791062
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82036}
This is deprecated since 10.5 and replaced by the new callback which
receives more OOM details.
R=mlippautz@chromium.org
Bug: chromium:1323177
Change-Id: I9385da33c3d9227144ebc47d6dddae702701ff82
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789509
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82033}
Strips the Name section off a module.
Change-Id: Ie28b80e610e4a858689f6a8aa01c0855c4c905a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787876
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82029}
Trigger tier-up faster for small functions, while waiting longer
for big functions, while trying to keep the overall amount of
optimization roughly the same.
Change-Id: I279daa21e151e9db20340089f9fa111141c6e645
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779910
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82026}
We visit the pointers in the same order as the ASCII diagram.
Bug: v8:7700
Change-Id: Ia11f49cb84b1d5abf4723aa5604c4a302f4ea79d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789513
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82020}
This method is only called from {AllocateWasmMemory}, so does not need
to be public.
R=jkummerow@chromium.org
Bug: v8:10949
Change-Id: Idf411179b6cf816adc111ceebf79335177e3440b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789502
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82019}
DoubleRegister RegisterMerge could get assigned a Tagged representation
operand if the node in the merge was null.
Also, we had a wrong DCHECK when materialising these moves, as a result
of templatifying the gap move implementation.
Bug: v8:7700
Change-Id: I2a425a6bedf4c67e8acf6c30c877e055b6445b12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3783994
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82018}
This CL includes the following changes:
- Avoid using `UniqueRegister` as much as possible
- Try to group opcodes under Binary or Unary when possible
Some codegen ops had to also be modified to avoid using `Temp`
registers.
Change-Id: Ib21ab7a47f600068c8453d48c3549e481a19c328
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780496
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#82011}
This is a reland of commit 8cb027531c
Original change's description:
> [wasm] Materialize suspender in JS-to-wasm wrapper
>
> Instead of creating the Suspender object in JS and passing it to the
> stack-switching js-to-wasm wrapper, the wrapper now automatically
> creates the Suspender object and forwards it as an extra parameter to
> the wasm function. See:
> https://github.com/WebAssembly/js-promise-integration/pull/1/files
>
> R=ahaas@chromium.org
>
> Bug: v8:12191
> Change-Id: I2badee823f4223a293632f93e7e59f24c49d0820
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779688
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81890}
Bug: v8:12191
Change-Id: Iea233e30aa269279d2fe17f5230c87285c33e232
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780817
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82009}
All objects allocated during Isolate initialization are long living and
should be allocated in old space.
Bug: v8:12612
Change-Id: I394cbaa2ba45750b98bfa219afa0c538552de9c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785148
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82006}
This CL implements MemoryAllocator::LookupChunkContainingAddress, which
will be used for conservative stack scanning. The method determines
whether an address that may be an inner pointer is contained in some
allocated (normal or large) page. To achieve this, the CL introduces a
page database in the memory allocator.
Bug: v8:12851
Change-Id: I8b719a5f1b6e6b374ccf0666c91c2341c5f9856a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784986
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82004}
This change fixes two issues with VTune JIT Profiling API.
1. Update way of setting flag "--no-compact-code-space" to avoid changing flags after initialization v8.
2. Fix a crash from visiting uninitialized ptr.
Change-Id: I4878ffd554ce53630db961fe09b49e081b0091bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787321
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Cr-Commit-Position: refs/heads/main@{#82003}
The RTT type can not be used directly in WebAssembly any more and is treated
as a compiler-internal type for the GC MVP.
Bug: v8:7748
Change-Id: I97cb241e6c46446149cc6ae2b1d535b93402fa76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787877
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82000}
V8 compaction, which currently runs before verification, can update
stack slots, which could lead to more false positives when we scan
compressed pointers on stack. The CL disables the stack verification if
pointer compression. The intent is to investigate if verification can be
moved before compaction.
Bug: chromium:1325007
Change-Id: Idc01df9c58bfbf338b5e95caf5f03a88593c6478
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789381
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81997}
- num_pushed_registers was never set
- parameters_limit need to be update before visiting parameters
- pushed_register_base was off by 1
- added an ASCII diagram
Bug: v8:7700
Change-Id: Ibf02a3007e730ea9de3a86f11e10722a4a1cacaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789380
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81996}
This is a reland of commit 4e935c7ffb
fix a bug on mac for not return correct memory protection key support.
Please see details in comments.
Original change's description:
> [pku][wasm] Refactor PKU usage in Wasm
>
> RwxMemoryWriteScope becomes the bottleneck for both MAP_JIT and PKU
> machinery.
> Wasm and V8 code space will use the same memory protection key.
>
> This is a next step towards adding PKU support for V8 code space.
>
> Bug: v8:13023
> Change-Id: I647f8c09bc41e5ef8a1d74b58a48a43e08454e0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702213
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81947}
Bug: v8:13023
Change-Id: I5b5cc81e7c1502229ce0d2a5574ca34dc23d19d9
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_rel_ng,v8_mac_arm64_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787320
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81994}
From the assembly code(Windows10), we found in the function "JSObject::GetHeaderSize" the __security_check_cookie will be called everytime before return. It is introduced by the stringstream which is used to print the enum string. We can remove the unnecessary __security_check_cookie by removing the stingstream.
Change-Id: I2786e0cf8f216d6a8cb07f502c29018987b3cc43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769433
Reviewed-by: Samuel Groß <saelo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jianxiao Lu <jianxiao.lu@intel.com>
Cr-Commit-Position: refs/heads/main@{#81993}
Refactor the code to use RecursiveMutextGuard to make it more readable
and less error prone.
This is a tentative fix for a rare deadlock that appears in
test-cpu-profiler/CrossScriptInliningCallerLineNumbers.
Bug: v8:11191
Change-Id: Ia32e7f61167f95e0fce142992c83ddff11959222
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779690
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81991}
There are two changes in this patch.
1. We previously added `VerifyRegExpSyntax` in regexp-parser.h to support checking regexp syntax for early errors in SpiderMonkey. Now that V8 is also emitting early errors for regexps (bug v8:896), SpiderMonkey can use the same code as V8.
2. Bug v8:11069 used a std::unordered_map as a cache for range arrays. This is currently the only place in irregexp that can call non-placement new, which SpiderMonkey has a static analysis to detect. Converting this to a ZoneUnorderedMap solves the problem for us, and seems consistent with the rest of irregexp.
Bug: v8:13108
Change-Id: Icedafd7d30fd040760cb0676a7bef8d55853bb93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785444
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81988}
After some solid bike shedding, we decided to rename one part of the
API.
R=jarin@chromium.org
Bug: chromium:1334585
Change-Id: Ie967f9f4947b2c328433e4c4a9d748ad15ae7175
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788095
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81987}
Remove the range check of formatRange, formatRangeToParts on
NumberFormat and selectRange on PluralRules
Bug: v8:10776
Change-Id: Ifede7d61db6414d5b338b22bd188406e5f7d98b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779041
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81984}
Call Intl function which call ICU TimeZone for the calculation
of timezone other than UTC
Bug: v8:11544
Change-Id: Idc355aaeccc0bed026a7117bb366ee914fa29733
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3783074
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81983}
Using the external pointer table when compressing pointers lets us ease
the alignment requirement for the state field from 8-byte-aligned to
4-byte-aligned, as 8-byte alignment is not supported during compaction.
Bug: v8:12547
Change-Id: Ibbcb0d71f09f9bac66acc81459ab71e354ea405f
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3783077
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81979}
This CL moves the external pointer table out of V8_ENABLE_SANDBOX and
into V8_COMPRESS_POINTERS. The external pointer table is also useful
even when not sandboxing external pointers to ease alignment
requirements under pointer compression.
It is onerous for the allocator to support non-tagged-size alignment.
Under pointer compression, tagged is 4 bytes while system pointers are
8 bytes. Because external pointer table indices are 4-bytes, fields that
require natural alignment (e.g. the state field in JSAtomicsMutex) when
the system pointer size is 8-bytes can use an indirection via the
pointer table to ease the alignment restriction back to 4-bytes under
pointer compression.
Bug: v8:10391
Change-Id: Iac1200e40c987128cd6a227cd279ba4dac0e5c56
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3783076
Reviewed-by: Samuel Groß <saelo@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81977}
Similar to the FullGC marking hierarchy (MarkingVisitorBase, with
derived classes MainMarkingVisitor and ConcurrentMarkingVisitor),
this CL introduces YoungGenerationMarkingVisitorBase +
YoungGenerationConcurrentMarkingVisitor, and refactors
YoungGenerationMarkingVisitor to inherit from
YoungGenerationMarkingVisitorBase.
YoungGenerationConcurrentMarkingVisitor dispatches to functions
refactored to ConcurrentMarkingVisitorUtility by the previous CL.
Bug: v8:13012
Change-Id: I0e827eb95732ed9ddf027fe68e25a0839cdda773
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780524
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Cr-Commit-Position: refs/heads/main@{#81976}
Handle the case where getting a value in the iterable object that
encodes the values throws an exception.
R=ahaas@chromium.org
Bug: chromium:1347073
Change-Id: Ie660ab04148d5fd3508397ae6e08130496f61b74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788097
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81974}
When the LeakSanitizer (LSan) runs, it scans all reachable memory
looking for pointers to other (live) objects, then reports all objects
that are still allocated but not reachable as leaked.
When the external pointer table is used, the pointers stored in it do
unfortunately not look like pointers to LSan as they will have some of
the top bits set. As such, LSan ignores them and may afterwards
incorrectly report some referenced objects as leaked.
To fix this, we now use a "shadow table" when LSan is active which
contains the raw pointer for every (tagged) pointer stored in the real
table. LSan can then scan this table and find all references.
Bug: v8:10391
Change-Id: If0c8b042fdd775ac3c8025d5688e62df37532ec3
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/+/3779915
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81972}
{NativeModule::GetJumpTableOffset} is totally independent of the
{NativeModule}, hence should be an independent function. It's now
defined in wasm-module.h, and works only on the WasmModule and the
function index.
{NativeModule::GetCallTargetForFunction} only has a single caller, which
is the wasm instance object, which already has direct access to the jump
table start. Hence we can just add the jump table offset there, and do
not need another helper method. This also makes it more clear that we
are returning a jump table slot.
R=jkummerow@chromium.org
Change-Id: If2e4eb4b3622df08ba905bd10783199bbb59d50a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3781348
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81970}
The implicit copy constructor triggers a deprecation warning if the
struct contains a deprecated field. We can fix this by explicitly
declaring the copy and move constructors and assignment operators
with the deprecation warning disabled.
This CL also adds a test to check that we can indeed call the
constructors and assignment operators, which did not work before.
R=leszeks@chromium.org
Bug: v8:13092
Change-Id: Ia63ff9375de13fc6e5b5a8d59d827a742c99fb39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785145
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81962}
This breaks up the existing {max_mem_pages()} method and the
{kSpecMaxMemoryPages} and {kV8MaxWasmMemoryPages} constants into two
versions for memory32 and memory64, respectively.
For now, the limits are still the same.
Some checks and clamping is moved to earlier places where we still have
the information whether a memory is 32 or 64 bit.
We also store that information in the WasmMemoryObject and use this for
knowing the maximum for growing.
This CL is not supposed to change any observable behaviour.
R=jkummerow@chromium.org
Bug: v8:10949
Change-Id: Ieaca0596d1a24ef2746842954a75188494103eb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782677
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81960}
All its uses are followed by more specific type checks anyway.
Change-Id: Ib3c0ca49d3c9fda672273edbe16e1ec363254e9c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784592
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81959}
Allow calls to not specify a safepoint. When we look up the safepoint
for such a location, we return a default safepoint which just has the
stack slots and no deopt info or pushed registers. This is different to
the TF safepoint elision, which tries to find the _next_ safepoint for a
PC. This allows us to let most calls not specify a safepoint at all, at
the cost of not being able to deduplicate safepoints anymore.
Bug: v8:7700
Change-Id: Ia119f56f40b5af426e0daa521801e6386b28ddb0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3770106
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81958}
This CL refactors WasmInternalFunction to no longer inherit from Foreign
but instead contain a (sandboxed) ExternalPointer field for the call target.
Bug: v8:10391
Change-Id: Iaaf25e635a275d7570e09699be3c8dec6108d4b3
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/+/3782675
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81957}
Avoid allocating dead (zero live range) phis, or their inputs. We should
figure out a way to remove them from the graph entirely, e.g. in a
separate DCE phase, but for now the easiest thing to do is to skip over
them.
Note that we can't eliminate them as part of the current node processing
pass, since that's the thing that records live ranges in the first
place.
Bug: v8:7700
Change-Id: I3e7f1f2214100def9ccc2b3f008852d5d69f548f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784985
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81954}
This is a reland of commit 6925bc095f
Original change's description:
> [heap] Refactor methods and nested class of ConcurrentMarkingVisitor
>
> This CL moves a few methods and nested class SlotSnapshottingVisitor
> from ConcurrentMarkingVisitor to ConcurrentMarkingVisitorUtility.
>
> Methods in ConcurrentMarkingVisitorUtility are now static and instead have a Visitor parameter.
>
> This is preparatory work for adding a
> YoungGenerationConcurrentMarkingVisitor class, which will be able to
> reuse members of ConcurrentMarkingVisitorUtility.
>
> Bug: v8:13012
> Change-Id: I503c20e655578031018a2e37dd92c1d61bbe1686
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779677
> Commit-Queue: Leon Bettscheider <bettscheider@google.com>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81931}
Bug: v8:13012
Change-Id: I05063263d831ef4f3e297289e4210850029f7607
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780500
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Cr-Commit-Position: refs/heads/main@{#81953}
This CL allows the PagedNewSpace to be used with flag
v8_enable_inner_pointer_resolution_osb.
Bug: v8:12612
Bug: v8:12851
Change-Id: I63eea4e75398ffec38e562cce245394c0d2a637c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782670
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81951}
The intial version of the API was replaced with a more ergonomic one
recently.
We can also safely remove the test as the new API guarantees that
tasks are always finished and cancelled.
Bug: chromium:1334585
Change-Id: I9ff8b92fcd73ef821c86de52c40a1d04b15ea918
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780539
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81950}
This reverts commit 4e935c7ffb.
Reason for revert: Breaking on mac arm64: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release/10926/overview
Original change's description:
> [pku][wasm] Refactor PKU usage in Wasm
>
> RwxMemoryWriteScope becomes the bottleneck for both MAP_JIT and PKU
> machinery.
> Wasm and V8 code space will use the same memory protection key.
>
> This is a next step towards adding PKU support for V8 code space.
>
> Bug: v8:13023
> Change-Id: I647f8c09bc41e5ef8a1d74b58a48a43e08454e0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702213
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81947}
Bug: v8:13023
Change-Id: I11c52ac101804ab75b1bb1d4814f083cb1083d5b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780498
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#81949}
RwxMemoryWriteScope becomes the bottleneck for both MAP_JIT and PKU
machinery.
Wasm and V8 code space will use the same memory protection key.
This is a next step towards adding PKU support for V8 code space.
Bug: v8:13023
Change-Id: I647f8c09bc41e5ef8a1d74b58a48a43e08454e0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702213
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81947}
This reverts commit 6925bc095f.
Reason for revert: Speculative revert for roll failures: https://ci.chromium.org/ui/p/chromium/builders/try/linux_optional_gpu_tests_rel/85744/overview
Original change's description:
> [heap] Refactor methods and nested class of ConcurrentMarkingVisitor
>
> This CL moves a few methods and nested class SlotSnapshottingVisitor
> from ConcurrentMarkingVisitor to ConcurrentMarkingVisitorUtility.
>
> Methods in ConcurrentMarkingVisitorUtility are now static and instead have a Visitor parameter.
>
> This is preparatory work for adding a
> YoungGenerationConcurrentMarkingVisitor class, which will be able to
> reuse members of ConcurrentMarkingVisitorUtility.
>
> Bug: v8:13012
> Change-Id: I503c20e655578031018a2e37dd92c1d61bbe1686
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779677
> Commit-Queue: Leon Bettscheider <bettscheider@google.com>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81931}
Bug: v8:13012
Change-Id: If2240b2e0769b04d752caefceb95609c6b950bb2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787373
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81945}
This reverts commit e895b7af73.
Reason for revert: TSAN failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/8468/overview
Original change's description:
> Background merging of deserialized scripts
>
> Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
> with which an embedder could request that V8 merge newly deserialized
> script data into an existing Script from the Isolate's compilation
> cache. This change implements those new functions. This functionality is
> still disabled by default due to the flag
> merge_background_deserialized_script_with_compilation_cache.
>
> The goal of this new functionality is to reduce memory usage when
> multiple frames load the same script with a long delay between (long
> enough for the script to have been evicted from Blink's in-memory cache
> and for the top-level SharedFunctionInfo to be flushed). In that case,
> there are two Script objects for the same script: one which was found in
> the Isolate compilation cache (the "old" script), and one which was
> recently deserialized (the "new" script). The new script's object graph
> is essentially standalone: it may point to internalized strings and
> readonly objects such as the empty feedback metadata, but otherwise
> it is unconnected to the rest of the heap. The merging logic takes any
> useful data from the new script's object graph and attaches it into the
> old script's object graph, so that the new Script object and any other
> duplicated objects can be discarded. More specifically:
>
> 1. If the new Script has a SharedFunctionInfo for a particular function
> literal, and the old Script does not, then the old Script is updated
> to refer to the new SharedFunctionInfo.
> 2. If the new Script has a compiled SharedFunctionInfo for a particular
> function literal, and the old Script has an uncompiled
> SharedFunctionInfo, then the old SharedFunctionInfo is updated to
> point to the function_data and feedback_metadata from the new
> SharedFunctionInfo.
> 3. If any used object from the new object graph points to a
> SharedFunctionInfo, where the old object graph contains a matching
> SharedFunctionInfo for the same function literal, then that pointer
> is updated to point to the old SharedFunctionInfo.
>
> The document at [0] includes diagrams showing an example merge on a very
> small script.
>
> Steps 1 and 2 above are pretty simple, but step 3 requires walking a
> possibly large set of objects, so this new API lets the embedder run
> step 3 from a background thread. Steps 1 and 2 are performed later, on
> the main thread.
>
> The next important question is: in what ways can the old script's object
> graph be modified during the background execution of step 3, or during
> the time after step 3 but before steps 1 and 2?
>
> A. SharedFunctionInfos can go from compiled to uncompiled due to
> flushing. This is okay; the worst outcome is that the function would
> need to be compiled again later. Such a risk is already present,
> since V8 doesn't keep IsCompiledScopes for every compiled function in
> a background-deserialized script.
> B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
> compilation. This is also okay; the merge completion logic on the
> main thread will just keep this lazily compiled data rather than
> inserting compiled data from the newly deserialized object graph.
> C. SharedFunctionInfos can be cleared from the Script's weak array if
> they are no longer referenced. This is mostly okay, because any
> SharedFunctionInfo that is needed by the background merge is strongly
> referenced and therefore can't be cleared. The only problem arises if
> the top-level SharedFunctionInfo gets cleared, so the merge task must
> deliberately keep a reference to that one.
> D. SharedFunctionInfos can be created if they are needed due to lazy
> compilation of a parent function. This change is somewhat troublesome
> because it invalidates the background thread's work and requires a
> re-traversal on the main thread to update any pointers that should
> point to this lazily compiled SharedFunctionInfo.
>
> At a high level, this change implements three previously unimplemented
> functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
>
> - BackgroundDeserializeTask::SourceTextAvailable, run on the main
> thread, checks whether there is a matching Script in the Isolate
> compilation cache which doesn't already have a top-level
> SharedFunctionInfo. If so, it saves that Script in a persistent
> handle.
> - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
> whether the persistent handle from the first step exists (a fast
> operation which can be called from any thread).
> - BackgroundDeserializeTask::MergeWithExistingScript, run on a
> background thread, performs step 3 of the merge described above and
> generates lists of persistent data describing how the main thread can
> complete the merge.
> - BackgroundDeserializeTask::Finish is updated to perform the merge
> steps 1 and 2 listed above, as well as a possible re-traversal of the
> graph if required due to newly created SharedFunctionInfos in the old
> Script.
>
> The merge logic has nothing to do with deserialization, and indeed I
> hope to reuse it for background compilation tasks as well, so it is all
> contained within a new class BackgroundMergeTask (in compiler.h,cc). It
> uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
> the object visitation that updates pointers to SharedFunctionInfos.
>
> [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
>
> Bug: v8:12808
> Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#81941}
Bug: v8:12808
Change-Id: I82a080e6287828445293cb6b4b94a5e8f15eb8f3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787213
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#81943}
Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
with which an embedder could request that V8 merge newly deserialized
script data into an existing Script from the Isolate's compilation
cache. This change implements those new functions. This functionality is
still disabled by default due to the flag
merge_background_deserialized_script_with_compilation_cache.
The goal of this new functionality is to reduce memory usage when
multiple frames load the same script with a long delay between (long
enough for the script to have been evicted from Blink's in-memory cache
and for the top-level SharedFunctionInfo to be flushed). In that case,
there are two Script objects for the same script: one which was found in
the Isolate compilation cache (the "old" script), and one which was
recently deserialized (the "new" script). The new script's object graph
is essentially standalone: it may point to internalized strings and
readonly objects such as the empty feedback metadata, but otherwise
it is unconnected to the rest of the heap. The merging logic takes any
useful data from the new script's object graph and attaches it into the
old script's object graph, so that the new Script object and any other
duplicated objects can be discarded. More specifically:
1. If the new Script has a SharedFunctionInfo for a particular function
literal, and the old Script does not, then the old Script is updated
to refer to the new SharedFunctionInfo.
2. If the new Script has a compiled SharedFunctionInfo for a particular
function literal, and the old Script has an uncompiled
SharedFunctionInfo, then the old SharedFunctionInfo is updated to
point to the function_data and feedback_metadata from the new
SharedFunctionInfo.
3. If any used object from the new object graph points to a
SharedFunctionInfo, where the old object graph contains a matching
SharedFunctionInfo for the same function literal, then that pointer
is updated to point to the old SharedFunctionInfo.
The document at [0] includes diagrams showing an example merge on a very
small script.
Steps 1 and 2 above are pretty simple, but step 3 requires walking a
possibly large set of objects, so this new API lets the embedder run
step 3 from a background thread. Steps 1 and 2 are performed later, on
the main thread.
The next important question is: in what ways can the old script's object
graph be modified during the background execution of step 3, or during
the time after step 3 but before steps 1 and 2?
A. SharedFunctionInfos can go from compiled to uncompiled due to
flushing. This is okay; the worst outcome is that the function would
need to be compiled again later. Such a risk is already present,
since V8 doesn't keep IsCompiledScopes for every compiled function in
a background-deserialized script.
B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
compilation. This is also okay; the merge completion logic on the
main thread will just keep this lazily compiled data rather than
inserting compiled data from the newly deserialized object graph.
C. SharedFunctionInfos can be cleared from the Script's weak array if
they are no longer referenced. This is mostly okay, because any
SharedFunctionInfo that is needed by the background merge is strongly
referenced and therefore can't be cleared. The only problem arises if
the top-level SharedFunctionInfo gets cleared, so the merge task must
deliberately keep a reference to that one.
D. SharedFunctionInfos can be created if they are needed due to lazy
compilation of a parent function. This change is somewhat troublesome
because it invalidates the background thread's work and requires a
re-traversal on the main thread to update any pointers that should
point to this lazily compiled SharedFunctionInfo.
At a high level, this change implements three previously unimplemented
functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
- BackgroundDeserializeTask::SourceTextAvailable, run on the main
thread, checks whether there is a matching Script in the Isolate
compilation cache which doesn't already have a top-level
SharedFunctionInfo. If so, it saves that Script in a persistent
handle.
- BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
whether the persistent handle from the first step exists (a fast
operation which can be called from any thread).
- BackgroundDeserializeTask::MergeWithExistingScript, run on a
background thread, performs step 3 of the merge described above and
generates lists of persistent data describing how the main thread can
complete the merge.
- BackgroundDeserializeTask::Finish is updated to perform the merge
steps 1 and 2 listed above, as well as a possible re-traversal of the
graph if required due to newly created SharedFunctionInfos in the old
Script.
The merge logic has nothing to do with deserialization, and indeed I
hope to reuse it for background compilation tasks as well, so it is all
contained within a new class BackgroundMergeTask (in compiler.h,cc). It
uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
the object visitation that updates pointers to SharedFunctionInfos.
[0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
Bug: v8:12808
Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#81941}
Jump gap moves (for phis and register merges) are emitted as a parallel
move (i.e. treated as a single mapping from registers to registers and
emitted in a way that they don't clobber each other). However, the phi
input allocation was updating the register state as if they were
serialised moves (i.e. a list of moves, one after the other, where each
move could clobber another move's input).
Now the jump phi initialisation doesn't update register state.
Bug: v8:7700
Change-Id: Iecf3211d59d9c416a4449aea22fef633717d92d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784983
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81934}
This CL moves a few methods and nested class SlotSnapshottingVisitor
from ConcurrentMarkingVisitor to ConcurrentMarkingVisitorUtility.
Methods in ConcurrentMarkingVisitorUtility are now static and instead have a Visitor parameter.
This is preparatory work for adding a
YoungGenerationConcurrentMarkingVisitor class, which will be able to
reuse members of ConcurrentMarkingVisitorUtility.
Bug: v8:13012
Change-Id: I503c20e655578031018a2e37dd92c1d61bbe1686
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779677
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81931}
We update RegisterMerge information for DoubleRegister, but don't
actually emit the gap moves for them. This required templatifying some
more code on the register type, and exposing a general LoadToRegister
for ValueNode.
Bug: v8:7700
Change-Id: I7122b5c562bab20d8f912936ff150d15b9cc033f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785003
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81927}
Too often, maglev has an issue during graph building. These are hard to
debug, because failing to build a graph means that no graph can be
printed. This patch adds a tracing printer that dumps out nodes as they
are added to the graph -- it doesn't have the beautiful unicode arrows,
but at least it's something.
Bug: v8:7700
Change-Id: Id6673a9ee2436eac365d6d449dd2fa49bdc354d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780527
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81926}
The new method is not implemented in Chrome or Node, and the issue has
no activity since 2018, so let's rip out the incomplete new API.
Drive-by: Sprinke a few V8_LIKELY and V8_UNLIKELY.
R=mlippautz@chromium.org
Bug: chromium:634547
Change-Id: I0dabad520d459277d7196fa69c1bbceaf4d53596
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780528
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81923}
Whenever PagedNewSpace allocates a page, the page is added to the free
list. Preallocating pages on space initialization means the pages are
added to the free list before the map for free space is initialized.
Then, when allocating from the free list, a DCHECK fails
(free-list.cc:508).
This CL delays page preallocation until `EnsureCurrentCapacity` is
called. When using PagedNewSpace, we will call this method from
`Heap::CreateHeapObjects` after the maps are allocated and before any
allocations in new space are attempted.
Bug: v8:12612
Change-Id: I33f825ddd831640b12e4c0f7b849262a335df51e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780541
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81919}
With this CL the time is measured from when the streaming decoder is
finished until the time when the compilation of all functions of the
streamed module is finished. If the streaming decoder finishes second,
the time gets recorded negatively. This timer should allow us eventually
to check whether the assumption that Liftoff compilation is faster than
downloading module bytes is correct.
R=clemensb@chromium.org
Bug: v8:12924
Change-Id: I2b7fbdef891d1eda77706ffbd20cf223b91b901c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3678839
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81915}
Due to top-byte ignore (TBI) in Arm64, only bits [48, 56) can be used
for type tags as otherwise type-check failures may go unnoticed if they
only leave bits in the top byte set. This CL therefore switches the
external pointer tagging scheme to use 8-bit tags.
Bug: v8:10391
Change-Id: Ia1f379ebc1bbda4117785d2dc119bc8dfa358711
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/+/3776688
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81913}
The return value of StringBuilder::cursor() isn't safe to store across
print operations, because it will become stale if the StringBuilder
needs to grow its buffer. The solution is to store the length() instead,
and recompute the raw pointer from the updated start() when needed.
Change-Id: Id453e39743644a5df9f7cbb8b1acaea7f5890453
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782671
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81912}
This CL fixes two lock-order-inversion warning in the DefaultPlatform.
The problem was that during shutdown locks get taken in the oposite
order than during initialization.
The first two conflicting locks were the WasmEngine lock and the
lock of the DefaultTaskRunner. During WasmEngine initialization, when
the WasmEngine lock is hold, a foreground task is scheduled, which
requires the TaskRunner lock. During shutdown, the task queue of the
TaskRunner gets drained while holding the TaskRunner lock. Thereby
the destructors of the tasks get executed, and the LogCode task of
the WasmEngine thereby acquires the WasmEngine lock.
The second conflict happens between the WasmEngine lock and the
DefaultPlatform lock, where the DefaultPlatform lock is taken during
WasmEngine initialization when the ForegroundTaskrunner is acquired.
During Shutdown, the DefaultPlatform lock was hold while the task
queue was drained, as described above.
Bug: chromium:1346250
Change-Id: Ib67d0c6cad1372e7c592f40bbe68b0ae31b2976b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782796
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81911}
This allows to run a test repeatedly (in the same process) which
always sets the flag(s) to the same value. This also applies to
fuzzers.
The {FlagValue<T>::operator=} is the central bottleneck which is now
used for any flag value updates, either via the FLAG_foo globals, or
via the internal or public API.
R=cbruni@chromium.org
Bug: v8:12887, chromium:1346284
Change-Id: I46662322e1420ee12314544302ad9700523dcf90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780525
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81909}
This is a follow up to Iadf73c294904ec20cefe1053a2969aa1dbb91a39.
Bug: v8:7748
Change-Id: I59390b8c82c4ebed58f2d3130cd9b1578bffdd4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780535
Commit-Queue: Matthias Liedtke <mliedtke@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@google.com>
Cr-Commit-Position: refs/heads/main@{#81908}
This CL changes `scheduleTask` to use a cached ObjectTemplate to
create the JS task objects. Console creates the template lazily upon
first use.
A local micro benchmark that creates 100k task objects shows a
speedup of roughly 4x.
R=jarin@chromium.org
Bug: chromium:1334585
Change-Id: Ice037ad32836fe428b1bcbee15738cb17877a3dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779496
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81906}
A couple of allocation were still going to new space. Since objects
allocated during isolate initialization are long living anyway, we
should pretenure them.
This also untangles preallocating pages in the paged new space.
Bug: v8:12612
Change-Id: Ib63ff4445930afa5969464e6adaef85b314e95ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782802
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81903}
Avoid most of the {is_inline()} checks by having a {data_begin_} pointer
which either points at the inline storage or at the zone-allocated
memory.
This replaces a dynamic branch by a memory indirection, which is
beneficial for big (non-inline) BitVectors. For small BitVectors we will
have to see what the bots say; the hypothesis is that a memory load is
still faster than a dynamic branch.
Apart from better performance, this change allows for simpler code in
many places, including the iterator implementation.
R=jkummerow@chromium.org
Bug: v8:13063
Change-Id: I1e28279d1a438598e0b8403a6a4078c2cd2a4c48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776685
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81902}
Instead of cmov + unconditional store, do a conditional store. At least
on Intel CPUs, this turns out to be significantly faster.
R=jkummerow@chromium.org
Bug: v8:13063
Change-Id: Ib5a89b9b9dbc88ca408a4bafc152d91407bf8d1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776675
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81900}
Drive-by fixes:
* categorize CodeDataContainer objects as kCode,
* when external code space is enabled report CodeDataContainers as
(%s builtin handle),
* replace a sequence of obj.IsXXX() with a respective sequence of
InstanceTypeChecker::IsXXX().
Bug: v8:11880
Change-Id: Ib50b168eb28af5f8388be7f9b9f4feba2ee784af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780534
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81898}
r8, r12, and r15 should be usable as general allocatable registers.
This is a performance experiment. If it causes more regressions than
improvements, we can simply revert it.
Change-Id: I757c06e9d0fc760e900b228b92671d6710bf4560
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782672
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81897}
Make sure AddAllSequenceSlowCallback works on arrays where some
elements cannot be accessed.
Bug: chromium:1338877
Change-Id: Icdf61a305fb208a91832d03ebc47201d8941e41a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3778410
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81896}
Instead of creating the Suspender object in JS and passing it to the
stack-switching js-to-wasm wrapper, the wrapper now automatically
creates the Suspender object and forwards it as an extra parameter to
the wasm function. See:
https://github.com/WebAssembly/js-promise-integration/pull/1/filesR=ahaas@chromium.org
Bug: v8:12191
Change-Id: I2badee823f4223a293632f93e7e59f24c49d0820
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779688
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81890}
The DevTools frontend doesn't want the Wasm module's understanding of
function body offsets (i.e. including locals), but the ranges of
offsets where breakpoints can be set (i.e. only where instructions are).
This patch adjusts the reported offsets accordingly.
A consequence is that we have to report full (start,end) pairs for each
function, instead of being able to dedupe end1==start2 etc.
Bug: v8:12917
Change-Id: I0c7d2d96435cdac2c4553647b7bcc8783bc1798b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780526
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81887}
This CL adds Uint8Array as supported arguments for fast API calls.
It introduces a kUint8 variant to CTypeInfo for use with TypedArrays
only.
Bug: v8:13080
Change-Id: Ie65206078a18acabaafa9c95793f400b8e95373d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3767098
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81886}
This CL adds a new method to the `console` that is available
when DevTools is open. In TypeScript notation the API is:
```
namespace console {
// Creates a new `Task` and associates the current async
// stack trace with the created `Task`.
scheduleTask(name: string): Task;
}
interface Task {
// Executes an arbitrary payload and forwards the return value
// back to the caller. Any async stack trace captured during
// 'f' has the site of the corresponding `scheduleTask` as
// its parent.
run<T>(f: () => T): T;
}
```
The API is a saner user-facing API for our async stack trace
mechanism:
* scheduleAsyncTask corresponds to scheduleTask
* startAsyncTask/stopAsyncTask are called implicitly before `f`
is executed.
* cancelAsyncTask is called implicitly when `Task` is GC'ed
The API is behind the flag --experimental-async-stack-tagging-api
Bug: chromium:1334585
Change-Id: Ic6054279a108756caed6b4b5f2d1fe4a1bdbaf78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776678
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81881}
All ETW Events are controlled by v8_enable_system_instrumentation.
This flag is turned off when perfetto is enabled since traces events
flowing through TRACE_EVENT macros can't be intercepted by Recorder.
Since, stack walking Events don't use TRACE_EVENT it can be turned
back on, when using perfetto. Hence, creating a separate Build Flag
for emitting stack walking event until the recorder is ported.
Bug: v8:11043
Change-Id: I6cdb81400780e54fddf6d6e2476cad29c60483d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3704465
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Suraj Sharma <surshar@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#81879}
Add a second implementation of BalanceDuration which
the nanoseconds could be very large and beyong the precision
could be handled by double and passed in by BigInt, and values
of other time fields are 0.
Bug: v8:11544
Change-Id: Ib794c6c78b81b8338434314fa5033cf1e991d32b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3781117
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81876}
Add a test where the GC gets called during parameter conversion, and fix
two related issues:
- Reorder spilled references so that they are at the top of the stack
before the builtin call
- Add the missing frame marker on the new stack
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: I3f68c675123c726543df6942d110fe06bc6c0efb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780530
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81873}
The CpuProfile previously emitted a CpuProfileMaxSamplesCallbackTask
if there was a sample where V8 could not resolve the stack.
This resulted in a premature "samplebufferfull" events for the
self-profiling API.
Skipping over samples without a resolved stack solves this issue.
Bug: chromium:1334366
Change-Id: If7a375dbf533c391307e8e506b37c0e3705f63b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776680
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81871}
The previous declaration was failing on GCC, because the argument types
did not match the actual constructor. The second parameter needs to be a
reference.
R=jkummerow@chromium.org
Bug: v8:13069
Change-Id: I151b44e05cd8b45da8f737ab84da063e491f3292
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779683
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81866}
Introduce `TraceStrongContainer()` to retain containers strongly. This
makes the use of `Trace(T*)` obsolete as all other use cases should
refer to Member overloads.
Bug: v8:13089
Change-Id: Ib0e762bf3298f1818528e45cc842d14a63f2c684
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779680
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81864}
Some tests and testing infrastructure had to be changed because it
relied on nominal types.
Drive-by: Support function supertypes in wasm-module-builder.js.
Bug: v8:7748
Change-Id: Ife92431d1842ff9de91e296a50421aa48f02c0de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776197
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81862}
In order to make the shared code write barrier thread-safe, we simply
lock the page mutex when appending to the typed_slot_set. We can later
improve this when performance isn't good enough.
Bug: v8:13018
Change-Id: I5e12f83f459f8976c22ec488cfa9b6f16d4a8a8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763867
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81855}
Enable a clang warning that embedders might enable, and fix issues
found by it.
R=ahaas@chromium.org, nicohartmann@chromium.org, mlippautz@chromium.org
Bug: v8:13069
Change-Id: I935f18872178f4421b441f33ef8ab1d8f030dfc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3760443
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81853}
This reverts commit 218d17d3ff.
Reason: Temporary things should be temporary.
Bug: v8:11111
Change-Id: Ic7c9d01d4c75863ceee89efe8493da3a84eb0894
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776683
Auto-Submit: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81851}
Setting the highest bit first saves cost for repeatedly growing the
underlying bitvector.
R=jkummerow@chromium.org
Bug: v8:13063
Change-Id: Ic324caa20c91dd6f55760944c3dafe7f1dc018b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776340
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81849}
Pop the correct number of bytes from the stack on return from the
WasmResume builtin.
R=ahaas@chromium.org
Bug: v8:13078
Change-Id: Ie1fffe1d02baab0ed91deca7dccadf1539068dd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776338
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81848}
Some follow-up after getting rid of `let`.
Change-Id: I073372f4edd0847c4ffa428595a6f74158c87a98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773515
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81844}
This CL hardens a test to avoid static_cast-ing doubles that don't fit
into the 32-bit integer range.
Bug: chromium:1344965
Change-Id: I1f3a05800158cda9dc582bfa4427516932db9679
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776337
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81843}
Now that the main thread has its own LocalHeap, we don't need a
separate instance of MarkingBarrier in Heap for the main thread
anymore. We can just use the MarkingBarrier in
main_thread_local_heap(). This makes code between main and background
threads more uniform.
Bug: v8:13018
Change-Id: I3d2dab1b11815df9a92c2fa7eebf52bf2cb130f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769687
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81841}
Tasks may contain Globals, which have to get destroyed before isolate
shutdown.
R=cbruni@chromium.org
Bug: chromium:1345081
Change-Id: I915baafd870c7bb8475b19736878179d8a22ca5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3770108
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81840}
Normalize flag names, and print boolean flags using the canonical
"--no-<foo>" syntax.
Before (with fuzzing):
Cycle in flag implications:
assert_types -> concurrent_recompilation = 0
stress_concurrent_inlining -> concurrent_recompilation = 1
After (with fuzzing):
Cycle in flag implications:
--assert-types -> --no-concurrent-recompilation
--stress-concurrent-inlining -> --concurrent-recompilation
Before (no fuzzing):
Contradictory flag implications from --assert_types and
--stress_concurrent_inlining for flag concurrent_recompilation
After (no fuzzing):
Contradictory flag implications from --assert-types and
--stress-concurrent-inlining for flag --concurrent-recompilation
R=tebbi@chromium.org
Bug: chromium:1336577
Change-Id: Id82cff4845d845e964c43b922067905b8b378a0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3750935
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81839}
This reverts commit 9981f2e592.
Reason for revert: This CL landed by accident, we decided back then to land a different CL.
Original change's description:
> [d8] quit() should not dispose the isolate
>
> R=cbruni@chromium.org
>
> Bug: chromium:1338150
> Change-Id: I5e5f8ede942dd37112766812a3c84a356f0b6ca9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714355
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81827}
Bug: chromium:1338150
Change-Id: Ib058d90a0c09e7cc65bdecee20580dd9e1f184d9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773776
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81838}
This CL re-structures the write barrier slow path in order to prepare
for adding the shared write barrier. Behavior remains the same in this
CL, only code structure changes a bit (e.g. the branch for when
marking is off, got moved up to the IsMarking() check).
Bug: v8:13018
Change-Id: I991f896abb88e0c85de3123fa67d8f47282f632d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3771840
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81836}
We will provide a replacement for raw pointers in future which should
only be used by backing stores. Any other callsite must go through
Trace(BasicMember<>).
Bug: v8:13089
Change-Id: Ibdae439b44ad94bd7af2532855be941c5334db99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3772328
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81833}
This CL fixes macro-asm to take in scratch registers as arguments.
Change-Id: Ib6070c9a9df050ce201d36027a0be44c77a54ba3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773875
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#81832}
The used_or_unused_instance_size_in_words field already determines
whether the used fields are in- or out-of-object, so we can use it's
value for a fast HasOutOfObjectProperties check rather than using
NumberOfFields (which includes an iteration over the descriptor
array).
Change-Id: I6c5b4f3f793b8df7832def7465106f2af7306759
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718152
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81828}
The suspender is only needed by the wrapper, do not forward it to the JS
import.
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: Id8e9a820491588b40fffb5dfd8706e85a16b8b23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3768410
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81818}
Thread through compressed pointer into write barrier to allow to delay
compression after checking whether a write barrier is actually needed.
Change-Id: If7e6cbb69a57cc9aeeb551c11f685bace4e56c4c
Bug: chromium:1325007
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769826
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81816}
... when external code space is enabled.
Currently this mode is guarded by V8_REMOVE_BUILTINS_CODE_OBJECTS flag
which is set to false until Code-less builtins are supported.
Drive-by:
* remove unnecessary methods from AbstractCode,
* avoid CodeDataContainer <-> Code roundtrips when accessing writable
state of Code objects via CodeT.
Bug: v8:11880
Change-Id: Iae3ff3b2feae68d875cbe9f82a6bb076460dd2f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769832
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81814}
We already generate BTI instructions with
`BaselineAssembler::JumpTarget()` on `VisitSingleBytecode()`, so we
shouldn't need to do it when binding a label.
Bug: v8:13082
Change-Id: Ie4d645a2379c3feb4909be524b42ebd85a8d35af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3771861
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/main@{#81813}
When pointer compression is disabled, and sizeof(Tagged_t) is 8 (eg,
arm64 without pointer compression), the function
extract_first_nonzero_index is never used, which was causing a warning.
Bug: v8:13048
Change-Id: I5a0fba4da4201e3be147632d891d0d9e20cb46eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769694
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81812}
The Code::constant_pool() segfaulted on configurations with disabled
external code space when it was called on mallocced copy of a Code
object.
Bug: v8:11880
Change-Id: I86919002ef080486f1e4532c3a2d3352f4526508
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3772004
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81811}
Thic CL adds a CDP API skeleton that will be used to disassemble WASM
modules using V8's new disassembler.
Bug: v8:12917, chromium:1325626
Change-Id: I4ca81aca923e9716653cd90367e5fad319483aae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3721381
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81809}
This includes several changes:
- avoid a very-unlikely-but-theoretically-possible OOB write
- avoid a somewhat-likely memory leak
- grow the buffer less aggressively for medium-length strings
Change-Id: I877f43d7e2e7cd4778ba8c7c7525ba988301f750
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3771900
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81808}
Notably:
- As per convention, TrapIf/Unless should not return a control node.
- Wasm-gc pipeline should not depend on FLAG_wasm_inlining.
Change-Id: Ic593db1f979bec1cedfd9384b21487fc2763a35b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3771640
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81806}
DropRegisterAtEnd is used to free a register, to make space for the
result of a node. Normally this frees up an input that is dead at the
end of the node's lifetime, but under high local variable pressure, we
might not have a dead value to drop.
In these cases we have to spill a register through the normal spilling
mechanism. Additionally, allow freeing up a blocked free register (i.e.
a temporary) if this is possible.
Bug: v8:7700
Change-Id: I0099751918cf5cb65c2a09337a3f080eb2c4dd14
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769833
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81804}
This CL fixes a bug in the units of the reported metrics for
V8.GC.Cycle.MainThread.Full.Incremental.Mark (ms instead of us).
It also reports incremental marking/sweeping metrics (both for the
unified heap and the C++ managed heap) only when incremental
marking/sweeping were used; otherwise, no zero values are reported.
Bug: chromium:1154636
Bug: chromium:1343507
Change-Id: Ibc0103ea62fa0eeb5f7184280c8514e99a5c21a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3768502
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81803}
Similarly to TF, we inline ToBoolean directly on Maglev generated code.
Most of the code is run as deferred, it "returns" true after 6 simple checks.
ToBoolean is separated in a different function to be used by other nodes
later (e.g. ToBooleanLogicalNot).
Bug: v8:7700
Change-Id: I75d77b60ebfb1bb124c9e98ad381f8aefa0ac665
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769688
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81800}
This CL is part of an effort to enable concurrent marking in MinorMC.
For this purpose we plan to reuse the IncrementalMarking class which
already implements a part of the concurrent marking code for MajorMC
(and is currently coupled with MarkCompactCollector).
We plan to parameterize IncrementalMarking with CollectorBase, which
can be either MinorMarkCompactCollector or MarkCompactCollector, in
a subsequent CL.
Bug: v8:13012
Change-Id: I595bfdcb6e1abaa270d8037d889620433f26a416
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749183
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81797}
The LeftTrimFixedArray will call OnMoveEvent every time. Even though when the profiling is not enabled in user mode, it still need to do some check, and the function call itself has certain overhead. This patch aims to remove the unnecessary check. We only need to check it when the logging status changes.
Change-Id: I0e957860616a18415398f7753ed21caab5a4361f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3751964
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jianxiao Lu <jianxiao.lu@intel.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81794}
This adds a bunch of tracing hooks to the module decoder and uses
them to support "annotated hexdump" output for full modules in wami:
$ out/x64.release/wami my_module.wasm --full-hexdump
Change-Id: I5821d940b5ec236df9708eecd0124172d8893ffd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3754741
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81791}
This file did not include all the headers it needed, so when
https://crrev.com/c/3749178 removed a bunch of headers, the MSVC build
broke. Add in the missing header to address the MSVC compiler falure.
Change-Id: I646787cfde802d8cabe7d61bac2f2066beaec436
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3764190
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81790}
Port d5b3d8e994
Original Commit Message:
This change already landed for x64, now come arm and ia32. The code
already existed for arm64.
The wasm instance got pushed three times in the lazy-compile builtin:
1) as part of the parameters;
2) as a parameter for the runtime function;
3) to load the jump table address after the runtime function;
The third push can be avoided by loading the jump table address after
all parameters get loaded from the stack again.
R=ahaas@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I731473b2d5e08e7ea5841ef589dd3f896b5302db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769698
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81789}
... in order to avoid expensive computation of cage_base for Code
objects and in order to avoid issues with wrong cage base values
computed from Code objects in external code space.
Drive-by: cage-bas'ify some accessors in JSFunction and Code.
This is a step towards Code-less embedded builtins.
Bug: v8:11880
Change-Id: I95dd8bcd4680e09c7463e1bc7d72dcbf9f2e5c1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769831
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81788}
... which might be undefined during initialization.
Bug: v8:13054
Change-Id: Ia3a7a95ffb1133b5d3d299c36bfb3875bcee2dfa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769830
Reviewed-by: Patrick Thier <pthier@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81783}
This change already landed for x64, now come arm and ia32. The code
already existed for arm64.
The wasm instance got pushed three times in the lazy-compile builtin:
1) as part of the parameters;
2) as a parameter for the runtime function;
3) to load the jump table address after the runtime function;
The third push can be avoided by loading the jump table address after
all parameters get loaded from the stack again.
R=clemensb@chromium.org
Bug: v8:13049, v8:12926
Change-Id: Ifdbe943520c031ec5c480798694bcacc490a64bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3764348
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81782}
This is a reland of commit 8218c06158.
Compile errors on mac arm64 are fixed.
Original change's description:
> [wasm] Reset PKRU before spawning new threads
>
> We sometimes hit the DCHECK in the wasm code manager:
> DCHECK_IMPLIES(writable, !MemoryProtectionKeyWritable());
>
> This is because we spawn new threads while having a
> {CodeSpaceWriteScope} open. In the case of PKU, this changes the PKRU
> register to allow writes to the code space, and the value of that
> register is inherited by any new thread. If this thread then tries to
> switch to writable code spaces, it hits the DCHECK. It would hit a
> similar DCHECK when trying to execute code.
>
> We fix this issue by temporarily resetting the PKRU register to
> non-writable while we call the {NotifyConcurrencyIncrease} method. This
> is not a very robust solution, as any new call that potentially happens
> inside a {CodeSpaceWriteScope} needs to do the same, but refactoring the
> code to avoid spawning new threads while being in writable state would
> be a lot of work with other downsides.
>
> R=jkummerow@chromium.org
>
> Bug: v8:13075
> Change-Id: Ibc7270aa597902dc6d9649cb6bcdfce8b1a9bafc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762579
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81729}
Bug: v8:13075
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_compile_rel
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_compile_dbg
Change-Id: I2e634959c969fc022393ae51c391397c7195ee54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769829
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81781}
We check page flags in the deferred write barrier, and bail out early
if pointers to that page are not interesting. Make sure that the slot
register saving happens after that early bailout, to avoid unbalanced
push/pop.
To avoid bugs like this in the future, add a stack size check as a
prefix to every node's code gen.
Bug: v8:7700
Change-Id: I54a00fcbc843d473a1ca1e6cf3d852a0c60621c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769695
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81780}
The stack offsets of cache slots are always positive, but the compiler
does not know that. The lack of this knowledge makes division by the
system pointer size significantly more expensive.
One solution would be to rewrite the division to be an actual right
shift. Another solution is to teach the compiler that offsets are
positive. This CL does the latter.
This reduces the overall Liftoff compile time of the reproducer in the
linked issue by nearly 25%.
R=jkummerow@chromium.org, cbruni@chromium.org
Bug: v8:13063
Change-Id: Ib55b35d407e9909c792ae095a6767aaa03faebdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3760453
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81778}
In {ControlPathState} with {kMultipleInstances}, a node should be able
to be mapped to different states, but not twice to an identical state.
Change-Id: Ida340a6f4f5e891f586d5a90e7ae818f24dfbe98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769693
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81775}
Templetize ControlPathState on whether multiple states are allowed for the same node. Instantiate BranchElimination to allow a single state
per node, and WasmGCOperatorReducer to allow multiple.
This fixes a performance regression caused by crrev.com/c/3717994.
Bug: chromium:1339826
Change-Id: Id52d643daad618f45c3d8509f2a661e177609a0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3754941
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81772}
The sandbox crash filter must be installed after the sandbox has been
initialized, which now happens during V8::Initialize.
Bug: v8:10391
Change-Id: I0103e32f091843415aaff4ec1c9bd93603244144
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/+/3769689
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81771}
Baseline compiler generates instructions for bytecode JumpLoop with
the below layout:
[OSR Check Armed]
[OSR Handle Armed]
[Jump Loop Header]
This CL advances [Jump Loop Header] and the layout will be:
[OSR Check Armed]
[Jump Loop Header]
[OSR Handle Armed]
This can reduce the sizes of loops in baseline code.
Change-Id: I0a3996fddffd33caaef965c05f5c2593ad8951bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3759947
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Cr-Commit-Position: refs/heads/main@{#81762}
- Avoid adding an Invalid type that can never be reached during
traversal;
- Expose class names as object names;
Bug: chromium:1321620
Change-Id: Ie3d9f78d97703535ecf67d56235d564ab6a9a7e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763866
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81758}
