This is needed to simplify concurrent sweeping for MinorMC.
Also: move evacuation verifiers to a separate file so that they can be
used from heap.cc as well.
Bug: v8:12612
Change-Id: I2a738a31e83a357f4fdded8a30ccb2ff6ba70553
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3932720
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83557}
The CL sligthly generalizes SlotSet by parameterizing it with slot size.
SlotSet is abstracted into BasicSlotSet, which is moved to heap::base::.
V8 GC related parts stay in slot-set.h
Bug: chromium:1029379
Change-Id: I093332b77682d2b31e61a91d4b0110fa95b5c908
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695595
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83553}
Detach the marking state from the collectors and move them to heap.
Also update users to access via heap and reduce dependencies on the
collectors.
This is a prerequisite for moving sweeper to the heap, which is needed
for concurrent sweeping in MinorMC.
Bug: v8:12612
Change-Id: Ia0bb2b7566b24eeb0d75c911edbfd626f07dad0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925548
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83542}
The ASM argument -mmark-bti-property is not supported in GNU toolchain
assembler, so it breaks the build. Only pass it for Clang.
Bug: chromium:819294
Change-Id: Ib5a485fa74fd75c88582292c8648d742fa25e709
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3930160
Commit-Queue: José Dapena Paz <jdapena@igalia.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83497}
The `v8_control_flow_integrity` build flag was already on by default in
Chromium on those platforms, by depending on
`arm_control_flow_integrity`. We should also turn it on by default when
building V8 standalone.
Co-authored-by: Richard Townsend <richard.townsend@arm.com>
Bug: v8:10026, v8:12963
Change-Id: I361a6426f44e569c08c763cf84a687ca70b89f08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829068
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/main@{#83458}
Implementation of property sequences for regular expressions is unused
(likely since switching to icu).
Bug: v8:11935
Change-Id: Ic4cf6219de8d6eb99464292a20f637e1fd423341
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3920135
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83451}
This is a reland of commit 70de8dd17f
Uses a version of python coverage available on arm.
Original change's description:
> [Python3] Clean up python2 holdovers
>
> Cq-Include-Trybots: luci.v8.try.triggered:v8_android_arm64_n5x_rel_ng_triggered
> Bug: v8:9871
> Change-Id: I889fad886339e754ffee4e11cc06bc594e30641d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913200
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Liviu Rau <liviurau@google.com>
> Cr-Commit-Position: refs/heads/main@{#83391}
Bug: v8:9871
Change-Id: I4a2eddc09e1a57cc9847b68caac8a9f98c14d222
Cq-Include-Trybots: luci.v8.try.triggered:v8_odroid_arm_rel_ng_triggered
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913027
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83401}
This change makes the default configuration of standalone V8 builds
(again) reflect the default configuration of V8 in Chromium builds.
Bug: v8:10391
Change-Id: Ia98492a283772ebfde43f0edbfdff05319ac4352
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913345
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83390}
- Use non-idle tasks to be able to process finalizers on time.
- Only process finalizers while concurrent marking is still running.
Bug: v8:13294
Change-Id: I1a2812c3fc350ea679c4c916c230cf736f2aa3ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3904648
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83367}
- Add Turboshaft to the wasm pipeline (behind a flag).
- Add a few operators.
- Implement SimplifyLoopsPhase, which ensures each loop has at most
two inputs.
- Remove the unneeded effect argument from
{FlagContinuation::FromTrap}.
Bug: v8:12783
Change-Id: I03a3f8cf3af40fc75bf57cfbad973b754b13dd8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899126
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83365}
This moves the existing PGO code to a separate cc file with a separate
header. As the implementation will be further extended in follow-up CLs,
it's better to have it separated.
R=jkummerow@chromium.org
Bug: v8:13209
Change-Id: I7b7b5bf9c8d3d542dae734f3874499dccee152a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899321
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83250}
For frame inspection (i.e. not deoptimization), no RegisterValues are
available to TranslatedState and thus any register-allocated value is
unavailable.
Stack trace collection require `function` and `receiver` values to be
available and thus stack-allocated. Both are immutable and have fixed
stack slots so this is not a problem; we just lost track of the receiver
inside Maglev when function parameters were wrapped inside exception Phi
nodes.
We solve this for now by special-casing the `receiver` to reuse the
InitialValue node instead of creating a new Phi.
Bug: v8:7700
Change-Id: I4f4de9a643b98e2fcbc7ee7a53688cc97a8d6f1d
Fixed: chromium:1359428
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3893856
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83164}
v8_multi_arch_build toggles v8_enable_pointer_compression, but some
other flags are set depending on v8_enable_pointer_compression.
Previously the v8_multi_arch_build condition was resetting some of these
in its branch, but we can make this simpler by moving the pointer
compression toggle earlier, immediately after the default pointer
compression setting.
Change-Id: Ie5f4e73f947b693d4ba2abe4e1cf30009a2bbb2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3890918
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83154}
This is a reland of commit 49c5967830
The non-deterministic snapshot issue has been fixed by using the correct
field size for CodeDataContainers in serializer.cc.
Original change's description:
> [sandbox] Fold V8_SANDBOXED_EXTERNAL_POINTERS into V8_ENABLE_SANDBOX
>
> Now that all external pointers have been sandboxed,
> V8_SANDBOXED_EXTERNAL_POINTERS is no longer needed. This change also
> shrinks external pointer slots to 32 bits when the sandbox is enabled.
>
> Bug: v8:10391
> Change-Id: Iccbef27ac107b988cb23fe9ef66da6fe0bae087a
> 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/+/3869269
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83083}
Bug: v8:10391
Change-Id: I29870404406902d99ba6016c570cc0c4d05c6c85
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/+/3887899
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83130}
In the process, switch to using the Fuchsia GN SDK templates for
building the component and package.
gni/v8.cmx is retained temporarily until out-of-tree consumers have been
updated.
Bug: v8:12589
Change-Id: If08cfcbf579696482e7cd60a8b8b80bcc4c7dab2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3885881
Auto-Submit: Greg Thompson <grt@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Greg Thompson <grt@chromium.org>
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83106}
In the process, switch to using the Fuchsia GN SDK templates for
building the component and package.
Bug: v8:12589
Change-Id: I9b5a82accb0da2067e83bc80d691133550ce82cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3879501
Auto-Submit: Greg Thompson <grt@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83084}
Now that all external pointers have been sandboxed,
V8_SANDBOXED_EXTERNAL_POINTERS is no longer needed. This change also
shrinks external pointer slots to 32 bits when the sandbox is enabled.
Bug: v8:10391
Change-Id: Iccbef27ac107b988cb23fe9ef66da6fe0bae087a
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/+/3869269
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83083}
This CL fixes redesigns the current API, which does not correctly
manage lifetimes of the shared object conveyors.
See design doc at
https://docs.google.com/document/d/1TV6agY9dafVJFvdPrUAGbEvos8wL2WDnsmf84n3OJVU/edit?usp=sharing
This CL also removes the incorrect behavior of serializing all shared
strings by sharing instead of copying. Shared strings may be sent to
another process, which should still work.
Bug: v8:12547
Change-Id: I7413abd2d871fd3d52c9b433445cfa1d03e4a732
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3868713
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83044}
The src/wasm/stacks.h file became progressively bigger, create a
cc file for it and move some function definitions there.
R=clemensb@chromium.org
Bug: v8:12191
Change-Id: I6880a4e11884856bd2f4d777cb745a3c06c71841
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3874936
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83039}
Fixes the use of v8_enable_fast_mksnapshot on platforms that
aren't ia32 or x64. This was introduced by
https://chromium-review.googlesource.com/c/v8/v8/+/3863281
Change-Id: I0d18c2d16dae4937baa40ee336d8c246a8b77889
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3867408
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: George Wort <george.wort@arm.com>
Cr-Commit-Position: refs/heads/main@{#82945}
This CL adds src/base/container-utils.h wich contains a few utilities
to make working with containers easier by providing a few additional
functions (e.g. contains, all_equal, ...) that are not (yet) shipped
with C++ standard containers.
Change-Id: I365b88c4286bf58bcac32c7bb89a5b0a98fc3509
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3865966
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82907}
- Remove TruncateInt64ToInt32 instead of translating to Turboshaft, since it has no effect. Removing it simplifies pattern-matching in optimizations.
- Change how exception handling is done in Turboshaft: The exception value is obtained as the result of `CatchExceptionOp` instead of a special projection. This simplifies projections.
- Add `TupleOp` as the counterpart to `ProjectionOp`, which is useful
for lowerings of operations that have multiple outputs.
- Split BinopOp into WordBinopOp and FloatBinopOp because they have quite different semantics and many kinds only exist for one of them.
- rename IntegerUnary to WordUnary and other occurences of
Integer/Integral
- rename ChangeOp::Kind::kUnsignedFloatTruncate` to `kJSFloatTruncate`
because it actually has JS wrap-around semantics.
- move/add representation DCHECKs to operation constructors.
- add some convinience helpers to `AssemblerInterface`.
- Add a mechanism to check which operations are supported by the machine.
Drive-by fix: Abort current block in OptimizationPhase::VisitBlock if
we lower to a block-terminator.
Bug: v8:12783
Change-Id: Ib738accccd22fb1606d9dab86f57ac1e739fcec2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3857449
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82857}
The 2GB cage caused new OOMs on M106. While those issues are being
investigated, this CL returns the 4GB back. The pointer compression is
still enabled.
Bug: chromium:1325007, chromium:1354660
Change-Id: I4fa4fabece2910ca84913d8df201acfbdf4b26e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3865004
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82834}
This implementation sticks closely to what Ignition-to-Turbofan (and now
Sparkplug-to-TF) does. OSR is detected in the TieringManager by having
optimized code available, without having entered it. The osr_urgency is
increased to enable OSR for increasing loop depths. When a candidate
JumpLoop backedge is reached, we call into runtime to trigger OSR
compilation.
JumpLoop also detects the availability of cached OSR'd code. When a
matching OSR code object is available, Maglev 1) deoptimizes s.t. the
unoptimized frame layout is reconstructed, and 2) delegates the actual
OSR tierup to the unoptimized tier. For purposes of 1), we add a new
DeoptimizeReason that causes a one-time eager deopt without invalidating
any code.
Drive-by: Annotate OSR for more --trace-opt output.
Todo: Refactor non-Sparkplug-specific bits of the BaselineAssembler
into a generic spot that both SP and ML can use.
Bug: v8:7700
Change-Id: I6ebab2df8b87f9f70ffb78162a3c1226ec545468
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3859850
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82816}
Shared values need to be kept alive while being conveyed across threads (i.e. by
postMessage). Currently they are meant to be conveyed through the
serializer/deserializer by the embedder via API. This both clunky and
the embedder has no good choice for what to do, because the most natural
choice is v8::Global and it is not designed to be threadsafe.
This CL removes the API and transparently handles conveying shared
values by using a wrapper around PersistentHandles called
SharedValueConveyors. Any isolate can own the conveyor provided it
outlives the receipt of the message by the receiving isolate. For
simpler lifetime management, the shared isolate currently owns all
conveyors.
Bug: v8:12547
Change-Id: I8f71b2faa0f8a1973f8b97ffccf4f5ad230f4e16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3857453
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82795}
This CL only moves method definitions from heap.cc into the new file
heap-verifier.cc. Apart from this code is not changed.
Bug: v8:11708
Change-Id: Ice7e5f12c6370bc05b82b3a7bd15f94292c4235f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3856260
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82761}
- Move StringForwardingTable implementation to own compilation unit.
- Refactoring preparing for layout change (Introduce explicit record
class to make transition from contiguous Tagged_t fields to a
heterogeneous record layout easier).
- Replace RootVisitor pattern for transitioning/cleanup during GC with
callback.
- Minor cleanups.
Bug: v8:12957
Change-Id: Iae343393f470130eac0c54148a1303b67fb95aa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3845635
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82730}
There is somes flag errors in the comments, which clarify how to
use pgo for builtin.
Change-Id: I0c418aee57adb7c6774735d32fc63a143bee5c7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3849654
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
Cr-Commit-Position: refs/heads/main@{#82650}
Now that V8_SANDBOXED_POINTERS is enabled by default on every platform
if the sandbox is enabled, it is no longer necessary to have a separate
option to enable/disable sandboxed pointers.
Bug: chromium:1218005
Change-Id: I2ab4c7c758010007765a3b0595357ddecfe9f258
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/+/3840937
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82587}
Since the overall motionmark regression is minor (<0.5%), we decided to
get benefits of pointer compression on M1. The CL can also slightly
regress speedometer2 (~0.3%).
Bug: chromium:1325007
Change-Id: Ib278f0e82e0ebde563caac79b9f32edfe2d09a53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840301
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82586}
Pointer compression regresses binary size on Fuchsia by about 300K.
However, the change improves Oilpan memory by 15-20% (2-4% of PMF),
which is beneficial for memory-impoverished platforms.
Bug: chromium:1325007
Fuchsia-Binary-Size: See commit description.
Change-Id: Ie16fd992e45e29e264549a960e9755ec58da1691
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829313
Reviewed-by: Wez <wez@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82572}
This allows V8 to be compiled without zlib.
Currently we use zlib for 3 features:
1. Snapshot compression. The cl asserts v8_snapshot_compression
implies v8_use_zlib.
2. Compression of translation arrays (experimental flag). The runtime
flag is only enabled if v8_use_zlib.
3. Snapshot checksums. We fallback to a simple Fletcher algorithm if
v8_use_zlib is false.
Change-Id: If043c3c21bba4d734573d7e1199d3ddf17b84f41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3833817
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82527}
M1 is known to have regression in MotionMark.
Fuchsia fails due to binary size increase.
Bug: chromium:1325007
Change-Id: I599c53bf1318dfcc7b40764e89df81b972374ed3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3835682
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82517}
- Move InnerPointerToCodeCache to using internal callbacks.
- Refactor internal and external callbacks to use a unified interface.
Bug: v8:13184
Change-Id: If0006d324b0433f5d6bbf00b6d0fc1a2589227bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3834583
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82515}
M1 still seems to have some performance regressions on
MotionMark/multiply.
Bug: chromium:1325007
Change-Id: I12ce44b8cef646f09a3c74ba533dfee8dffdd2ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829540
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82485}
The CL aims to check if PC is causing a Speedometer regression. The
previous reland was part of the roll that broke builtin PGOs, which
cause large Speedometer2 regression. Now we want to disable and then
reenable pointer compression on M1 just to make sure that there are no
performance regressions caused by PC.
Bug: chromium:1325007
Change-Id: I2442218322d3b045bc5518b03730f57aa2091ebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827875
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82435}
StringConstantXXX were introduced when we switched to concurrent
compilation, as a way to build strings in Turbofan in a background
thread, without having to actually allocate them on the main heap
from the background. See https://crrev.com/c/1221807.
Now that we have local heaps, we can actually allocate strings from
the background, making StringConstantXXX useless.
Moreover, we would fold constant string concatenations into
ConsString, which sounds a bit dubious for performance. Now, small
constant string concatenations will be folded into SeqStrings, while
larger ones will remain ConsString, just to avoid the quadratic
worst-case.
Change-Id: I0479d16aa5691c9d774187c4cc0d03ff4fe2b4f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811291
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82381}
- Add explicit --turbo-profiling-output and --turbo-profiling-input
- Rename --turbo-profiling-log-file to --turbo-profiling-input
- No longer log PGO data to v8.log
- Add runtime %GetAndResetTurboProfilingData helper function for
more controlled logging within chrome
- Rewrite generate.py script to use more python3
Bug: v8:10470
Change-Id: Ib817b5c3793a0a7ae77103075ea2d6f6d0282150
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820381
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82350}
This is a reland of commit 6953b5550e
The reland fixes tests that retrieved the stack start from a
non-inlined frame's fp. This does not work in certain configurations
as the resulting marker is too low to consider the first local
variables in subsequent calls.
The fix uses an inline frame address for the tests to get an upper
bound of stack addresses to consider.
Original change's description:
> [handles] Remove precise on-stack representation of global handles
>
> Since https://crrev.com/c/3806439 on-stack traced handles are marked
> conservatively when being used in combination with CppHeap.
>
> This change removes the precise on-stack representation of the
> internal traced nodes as they nodes would anyways be marked
> conservatively. The effects are:
> - cheaper representation (just a single node space);
> - uniform handling: no checks to distinguish on-stack vs on-heap;
> - no brittleness around cleaning on-stack handles when the event loop
> is empty;
>
> Change-Id: Id859623bfed77a66bdd064ea8065536264515eae
> Bug: v8:13141
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812039
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82306}
Bug: v8:13141
Change-Id: I53ece36220e99d02be6df18f83c18450e5d5037b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820585
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82342}
This reverts commit 6953b5550e.
Reason for revert: Failing on CI: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20full%20debug/22876/overview
Original change's description:
> [handles] Remove precise on-stack representation of global handles
>
> Since https://crrev.com/c/3806439 on-stack traced handles are marked
> conservatively when being used in combination with CppHeap.
>
> This change removes the precise on-stack representation of the
> internal traced nodes as they nodes would anyways be marked
> conservatively. The effects are:
> - cheaper representation (just a single node space);
> - uniform handling: no checks to distinguish on-stack vs on-heap;
> - no brittleness around cleaning on-stack handles when the event loop
> is empty;
>
> Change-Id: Id859623bfed77a66bdd064ea8065536264515eae
> Bug: v8:13141
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812039
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82306}
Bug: v8:13141
Change-Id: I5ebb2ed9eeec1394c2dd48504e91f6ff789b0711
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820584
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82313}
Since https://crrev.com/c/3806439 on-stack traced handles are marked
conservatively when being used in combination with CppHeap.
This change removes the precise on-stack representation of the
internal traced nodes as they nodes would anyways be marked
conservatively. The effects are:
- cheaper representation (just a single node space);
- uniform handling: no checks to distinguish on-stack vs on-heap;
- no brittleness around cleaning on-stack handles when the event loop
is empty;
Change-Id: Id859623bfed77a66bdd064ea8065536264515eae
Bug: v8:13141
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812039
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82306}
All the known issues (GPU bot failures) have been fixed.
Original change's description:
> cppgc: Enable pointer compression by default on Desktop
>
> The CL enables pointer compression in Oilpan.
>
> For sherrifs: the CL may cause some slight perf regressions (likely
> blink_perf.*), due to slightly higher cost of compression and
> decomrpession.
>
> Speedometer2 is not expected to regress, as was checked locally. Such a
> slight performance degradation is compensated by memory savings that are
> expected to be around 10-20% of Oilpan committed size (~2.5-5% of Renderer
> PMF).
Bug: chromium:1325007
Change-Id: I52572ba30459dcdfd6219cfdc9e8f2f836fb95ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791061
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82260}
Some wasm interpreter tests are failing since instructions generated
by gcc such as *multiply and and* (fmadds) create intermediate
results bigger than 8 bytes which doesn't match other architectures,
hence the resulting output differs.
Port commit 13314a207e
co-authors: Jun Yuan Tan <junyuan.tan@starfivetech.com>
Change-Id: I18c0b659f30df84bb30daa176368a7e81b51063e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811139
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82240}
This is a reland of commit 2055c3b482
Original change's description:
> [infra] Enable sandbox for x64 and arm64 builders and add a set of builders with Sandbox off
>
> Bug: v8:13058
> Change-Id: If9d500f46f02ed3588d2b0e3904567c61aaddd12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810184
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82213}
Bug: v8:13058
Change-Id: I315fd1cd5c36464b1a15c635c8f31825769c3eb0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812042
Auto-Submit: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82221}
This is a reland of commit 491de34bcc
co-authors: Ji Qiu <qiuji@iscas.ac.cn>
Alvise De Faveri Tron <elvisilde@gmail.com>
Usman Zain <uszain@gmail.com>
Zheng Quan <vitalyankh@gmail.com>
Original change's description:
> [riscv32] Add RISCV32 backend
>
> 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}
Bug: v8:13025
Change-Id: I220fae4b8e2679bdc111724e08817b079b373bd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807124
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82198}
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}
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}
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}
This is a follow-up to https://chromium-review.googlesource.com/c/v8/v8/+/3776693
The previous CL accidentally didn't manage to enable
the PGO build because `v8_optimized_debug` is true in
release builds.
Bug: v8:10470
Change-Id: I66ec74e71eb697aa48b981d78ad526f4b8c5a917
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784989
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81971}
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 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}
This reverts commit c3f18ae6ab.
Reason for revert: Speculative revert for https://luci-milo.appspot.com/ui/inv/build-8807661142690641489/test-results?q=conformance%2Fogles%2FGL%2FgreaterThanEqual%2FgreaterThanEqual_001_to_008.html
Original change's description:
> Reland "cppgc: Enable pointer compression by default on Desktop"
>
> - The data race on atomic memcpying/memsetting was fixed;
> - All the known alignment issues in Blink were fixed;
> - Several perf optimizations were applied.
>
> Original change's description:
> > cppgc: Enable pointer compression by default on Desktop
> >
> > The CL enables pointer compression in Oilpan.
> >
> > For sherrifs: the CL may cause some slight perf regressions (likely
> > blink_perf.*), due to slightly higher cost of compression and
> > decomrpession.
> >
> > Speedometer2 is not expected to regress, as was checked locally. Such a
> > slight performance degradation is compensated by memory savings that are
> > expected to be around 10-20% of Oilpan committed size (~2.5-5% of Renderer
> > PMF).
>
> Bug: chromium:1325007
> Change-Id: I5fa9a06cb1fa5141f4e2b22e710007e2404a176b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762567
> Auto-Submit: Anton Bikineev <bikineev@chromium.org>
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81914}
Bug: chromium:1325007
Change-Id: I15baa011500a2156871277c644a004b9cacfd5f4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3783991
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#81930}
- The data race on atomic memcpying/memsetting was fixed;
- All the known alignment issues in Blink were fixed;
- Several perf optimizations were applied.
Original change's description:
> cppgc: Enable pointer compression by default on Desktop
>
> The CL enables pointer compression in Oilpan.
>
> For sherrifs: the CL may cause some slight perf regressions (likely
> blink_perf.*), due to slightly higher cost of compression and
> decomrpession.
>
> Speedometer2 is not expected to regress, as was checked locally. Such a
> slight performance degradation is compensated by memory savings that are
> expected to be around 10-20% of Oilpan committed size (~2.5-5% of Renderer
> PMF).
Bug: chromium:1325007
Change-Id: I5fa9a06cb1fa5141f4e2b22e710007e2404a176b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762567
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81914}
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}
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}
By making "v8_heap_base_headers" a "v8_header_set" instead of
a "v8_source_set".
Reported by Paul Harris on v8-users@.
Change-Id: I33263230631766e73f5d13aab497c47c98f807b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776339
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81845}
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}
To work properly and securely, the sandbox requires cooperation from the
Embedder, for example in the form of a custom ArrayBufferAllocator and
later on custom type tags for external objects. As such, it likely does
not make sense to enable the sandbox by default everywhere.
Bug: v8:10391, v8:13058
Change-Id: Ief2720122f70b9a1bc3f2e6802e60b5b95b855d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3771841
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81805}
Add the build flag `v8_enable_pointer_compression_8gb` which will enable
aligning all alocations to at least 8 bytes, instead of 4. The build
flag will affect tagged values (Smis and compressed pointers) that are
now aligned to 4 bytes. This new alignment is needed to support larger
V8 cages, with sizes of 8GB and larger.
Bug: v8:13070
Change-Id: I15fe1e0c8e0a105e831b756f502a4fcbf72f45a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3757891
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Teo Dutu <teodutu@google.com>
Cr-Commit-Position: refs/heads/main@{#81748}
The header is only slightly refactored:
* function names are slightly shortened,
* global functions and enums are converted to static methods and enums
of a MemoryProtectionKey class.
This is a first step towards adding PKU support for V8 code space.
Bug: v8:13023
Change-Id: Iebcb075b07286d18d6834fbcf6697327f08c9f50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762584
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81732}
This CL does the following:
- It enables (i.e. allocates and initializes) the per-Isolate
ExternalPointerTable when the sandbox is enabled.
- It refactors the list of external pointer tags to mark them as
"sandboxed" or "unsandboxed". An unsandboxed external pointer has a
null tag.
- It changes V8_SANDBOXED_EXTERNAL_POINTERS to now essentially just
enable sandboxing for all available tags.
- It modifies all low-level external pointer accessors to perform the
ExternalPointerLookup only if the tag is non-zero and otherwise treat
the slot as containing a raw pointer.
This now allows rolling out external pointer sandboxing incrementally
(separately for each external pointer type), which will in turn allow
for more precise performance measurements of the impact of the sandbox.
Note: when an external pointer tag is now marked as sandboxed (and
V8_SANDBOXED_EXTERNAL_POINTERS is not enabled), the underlying slots are
still 64-bits in size. This simplifies the implementation as we would
otherwise need to deal with variably-sized external pointer slots. Local
benchmarking suggests that the benefits from 32-bit external pointer
slots are insignificant on typical benchmarks, so this should be ok.
Drive-by: rename kExternalPointerSize to kExternalPointerSlotSize to
make it more clear what it refers to (the on-heap storage size). Also
delete CodeStubAssembler::InitializeExternalPointerField as it is not
currently used and the implementation is fairly inefficient.
Bug: v8:10391
Change-Id: I7c38729c7e9048d737a1a8ced84749f5b1f7feab
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/+/3736447
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81636}
