Change-Id: I7df25ca2c7caabed429cfdc0b4aab0aeb5e03fcd
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463222
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70926}
This adds a first simple version of the inspector fuzzer, which is a
stripped-down version of the inspector-test executable. The fuzzer
generates inputs which are compatible with inspector-test.
There are still memory leaks, and the fuzzer will probably run into
timeouts most of the time. Both of this will be addressed in follow-ups.
R=szuend@chromium.org, machenbach@chromium.org
Bug: chromium:1142437
Change-Id: I4d13da460f571d791a3642b0705a1f07b442c11b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505722
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70922}
This CL splits the class definitions per .tq file, to realize the
following relationship:
A class defined in src/objects/foo.tq has a C++ definition in
src/objects/foo.h. Torque then generates:
- torque-generated/src/objects/foo-tq.inc
An include file (no proper header) to be included in src/objects/foo.h
containing the Torque-generated C++ class definition.
- torque-generated/src/objects/foo-tq-inl.inc
An include file (no proper header) to be included in
src/objects/foo-inl.h containing inline function definitions.
- torque-generated/src/objects/foo-tq.cc
A source file including src/objects/foo-inl.h that contains non-inline
function definitions.
Advantages of this approach:
- Avoid big monolithic headers and preserve the work that went into
splitting objects.h
- Moving a definition to Torque keeps everything in the same place
from a C++ viewpoint, including a fully Torque-generated C++ class
definition.
- The Torque-generated include files do not need to be independent
headers, necessary includes or forward declarations can just be added
to the headers that include them.
Drive-by changes:
A bunch of definitions and files had to be moved or created to realize
a consistent 1:1 relationship between .tq files and C++ headers.
Bug: v8:7793
TBR: hpayer@chromium.org
Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70853}
This is a reland of 90ea9b35cb
Original change's description:
> cppgc: Port backing store compaction.
>
> This CL ports the existing backing store compaction algorithm from
> blink. It does not attempt to improve on the existing algorithm.
>
> Currently only unified heap uses the compaction implementation. It is
> never triggered through standalone GCs.
>
> The compaction implementation resides within an internal "subtle" namespace.
>
> Bug: v8:10990
> Change-Id: I4aa781db1b711e7aafc34234c4fb142de84394d7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485228
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70714}
Bug: v8:10990
Change-Id: I527c2042a26648d058bfe4d355527cce9a3eeadc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2492331
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70736}
This reverts commit 90ea9b35cb.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20-%20debug/31274?
Original change's description:
> cppgc: Port backing store compaction.
>
> This CL ports the existing backing store compaction algorithm from
> blink. It does not attempt to improve on the existing algorithm.
>
> Currently only unified heap uses the compaction implementation. It is
> never triggered through standalone GCs.
>
> The compaction implementation resides within an internal "subtle" namespace.
>
> Bug: v8:10990
> Change-Id: I4aa781db1b711e7aafc34234c4fb142de84394d7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485228
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70714}
TBR=mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
Change-Id: Iadae1ee0c6c0400f0e1a0a3805be5316a1d4b979
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10990
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2492330
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70716}
This CL ports the existing backing store compaction algorithm from
blink. It does not attempt to improve on the existing algorithm.
Currently only unified heap uses the compaction implementation. It is
never triggered through standalone GCs.
The compaction implementation resides within an internal "subtle" namespace.
Bug: v8:10990
Change-Id: I4aa781db1b711e7aafc34234c4fb142de84394d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485228
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70714}
The Cobalt project has its own Starboard equivalent of libc APIs like
`malloc` and `free`. This CL introduces the wrappers for some libc
functions. In followup CLs, for example occurences of malloc will all
be replaced by base::Malloc in V8.
See b/156155426 for more information.
Bug: v8:10927
Change-Id: Ida3d161a1da56755b681e18b4827e277e6cb4c4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416150
Commit-Queue: John Xu <johnx@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: John Xu <johnx@google.com>
Cr-Commit-Position: refs/heads/master@{#70702}
Follow the marker pattern where actual logic is moved into a dedicated
state class and the visitors merely forward to that class.
Change-Id: Id3c6b7414343da82759bdba3dbb8286adee44cf4
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480502
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70680}
This is a reland of 403390ec60
Original change's description:
> [ia32] Remove arguments adaptor frame
>
> Change-Id: Id66d2c57fc92c00b033bc53231313f477cceca75
> Bug: v8:10201
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448463
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70652}
Bug: v8:10201
Change-Id: I2c50b22fbe565e8ad6a510c02bfbd79c145d284e
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485225
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70663}
Change-Id: Id66d2c57fc92c00b033bc53231313f477cceca75
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448463
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70652}
This reverts commit fba14bde5f.
Reland fixes:
- const vector<const string> -> const vector<string>
Original message:
The following implements a snapshotting algorithm for C++ objects that
also filters strongly-connected components (SCCs) of only "hidden"
objects that are not (transitively) referencing any non-hidden
objects.
C++ objects come in two versions.
a. Named objects that have been assigned a name through NameProvider.
b. Unnamed objects, that are potentially hidden if the build
configuration requires Oilpan to hide such names. Hidden objects have
their name set to NameProvider::kHiddenName.
The main challenge for the algorithm is to avoid blowing up the final
object graph with hidden nodes that do not carry information. For that
reason, the algorithm filters SCCs of only hidden objects, e.g.:
... -> (object) -> (object) -> (hidden) -> (hidden)
In this case the (hidden) objects are filtered from the graph. The
trickiest part is maintaining visibility state for objects referencing
other objects that are currently being processed.
Main algorithm idea (two passes):
1. First pass marks all non-hidden objects and those that transitively
reach non-hidden objects as visible. Details:
- Iterate over all objects.
- If object is non-hidden mark it as visible and also mark parent
as visible if needed.
- If object is hidden, traverse children as DFS to find non-hidden
objects. Post-order process the objects and mark those objects as
visible that have child nodes that are visible themselves.
- Maintain an epoch counter (StateStorage::state_count_) to allow
deferring the visibility decision to other objects in the same
SCC. This is similar to the "lowlink" value in Tarjan's algorithm
for SCC.
- After the first pass it is guaranteed that all deferred
visibility decisions can be resolved.
2. Second pass adds nodes and edges for all visible objects.
- Upon first checking the visibility state of an object, all deferred
visibility states are resolved.
For practical reasons, the recursion is transformed into an iteration.
We do not use plain Tarjan's algorithm to avoid another pass over
all nodes to create SCCs.
Follow ups:
1. Adding wrapper nodes for cpp objects that are wrappables for V8
wrappers.
2. Adding detachedness information.
Bug: chromium:1056170
Change-Id: Ib47df5c912c57d644d052f209276e9d926cece0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480362
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70577}
This reverts commit 02849fd9de.
Reason for revert: Breaks Win64 MSVC bot and closes the tree - https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/15416
Original change's description:
> cppgc-js: Add snapshot for C++ objects
>
> The following implements a snapshotting algorithm for C++ objects that
> also filters strongly-connected components (SCCs) of only "hidden"
> objects that are not (transitively) referencing any non-hidden
> objects.
>
> C++ objects come in two versions.
> a. Named objects that have been assigned a name through NameProvider.
> b. Unnamed objects, that are potentially hidden if the build
> configuration requires Oilpan to hide such names. Hidden objects have
> their name set to NameProvider::kHiddenName.
>
> The main challenge for the algorithm is to avoid blowing up the final
> object graph with hidden nodes that do not carry information. For that
> reason, the algorithm filters SCCs of only hidden objects, e.g.:
> ... -> (object) -> (object) -> (hidden) -> (hidden)
> In this case the (hidden) objects are filtered from the graph. The
> trickiest part is maintaining visibility state for objects referencing
> other objects that are currently being processed.
>
> Main algorithm idea (two passes):
> 1. First pass marks all non-hidden objects and those that transitively
> reach non-hidden objects as visible. Details:
> - Iterate over all objects.
> - If object is non-hidden mark it as visible and also mark parent
> as visible if needed.
> - If object is hidden, traverse children as DFS to find non-hidden
> objects. Post-order process the objects and mark those objects as
> visible that have child nodes that are visible themselves.
> - Maintain an epoch counter (StateStorage::state_count_) to allow
> deferring the visibility decision to other objects in the same
> SCC. This is similar to the "lowlink" value in Tarjan's algorithm
> for SCC.
> - After the first pass it is guaranteed that all deferred
> visibility decisions can be resolved.
> 2. Second pass adds nodes and edges for all visible objects.
> - Upon first checking the visibility state of an object, all deferred
> visibility states are resolved.
>
> For practical reasons, the recursion is transformed into an iteration.
> We do not use plain Tarjan's algorithm to avoid another pass over
> all nodes to create SCCs.
>
> Follow ups:
> 1. Adding wrapper nodes for cpp objects that are wrappables for V8
> wrappers.
> 2. Adding detachedness information.
>
> Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962
> Bug: chromium:1056170
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70567}
TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
Change-Id: I64a2cf2259bdaed81f6e0f92bdcc7a1f0df4d197
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479471
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70571}
This is a reland of ff61743fb0
Original change's description:
> [heap] Refactor marking weak object worklists
>
> This CL extracts weak object worklist related code into separate files
> and uses a macro to specify all weak object worklists in a generic way.
>
> The motivation of the refactoring is twofold:
> 1) We can now enforce that each weak object worklist is updated after
> Scavenge. (Forgetting to define the update function causes a link
> time error.)
> 2) The reduced boilerplate will be useful for transitioning to the
> new ::heap::base::Worklist.
>
> Change-Id: Ic80a7ccca010c09370d6525f43d78de24192f8ea
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442624
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70308}
Change-Id: I8a9f39e53ef4123dd28a1da6f7992cdff341f694
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461741
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70568}
The following implements a snapshotting algorithm for C++ objects that
also filters strongly-connected components (SCCs) of only "hidden"
objects that are not (transitively) referencing any non-hidden
objects.
C++ objects come in two versions.
a. Named objects that have been assigned a name through NameProvider.
b. Unnamed objects, that are potentially hidden if the build
configuration requires Oilpan to hide such names. Hidden objects have
their name set to NameProvider::kHiddenName.
The main challenge for the algorithm is to avoid blowing up the final
object graph with hidden nodes that do not carry information. For that
reason, the algorithm filters SCCs of only hidden objects, e.g.:
... -> (object) -> (object) -> (hidden) -> (hidden)
In this case the (hidden) objects are filtered from the graph. The
trickiest part is maintaining visibility state for objects referencing
other objects that are currently being processed.
Main algorithm idea (two passes):
1. First pass marks all non-hidden objects and those that transitively
reach non-hidden objects as visible. Details:
- Iterate over all objects.
- If object is non-hidden mark it as visible and also mark parent
as visible if needed.
- If object is hidden, traverse children as DFS to find non-hidden
objects. Post-order process the objects and mark those objects as
visible that have child nodes that are visible themselves.
- Maintain an epoch counter (StateStorage::state_count_) to allow
deferring the visibility decision to other objects in the same
SCC. This is similar to the "lowlink" value in Tarjan's algorithm
for SCC.
- After the first pass it is guaranteed that all deferred
visibility decisions can be resolved.
2. Second pass adds nodes and edges for all visible objects.
- Upon first checking the visibility state of an object, all deferred
visibility states are resolved.
For practical reasons, the recursion is transformed into an iteration.
We do not use plain Tarjan's algorithm to avoid another pass over
all nodes to create SCCs.
Follow ups:
1. Adding wrapper nodes for cpp objects that are wrappables for V8
wrappers.
2. Adding detachedness information.
Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70567}
Cppgc exposes EphemeronPair that contains a WeakMember key and a Member
value and can be used to denote ephemeron semantics in the standalone
library.
Tracing EphemeronPairs goes through TraceEphemeron that is exposed on
the api for the blink usecase.
Bug: chromium:1056170
Change-Id: I9fbaa284fa2034248cdf36ea8b0cd5be6a55f676
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467842
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70525}
Add histogram for time-to-collection. As a drive-by change also
move CollectionBarrier into its own class and rename V8.TimeToSafepoint
to V8.StopTheWorld such that the histogram name and the trace file entry
now have the same name.
Bug: v8:10315
Change-Id: I86e2a9592d10316d04bc8cab37ff548067aadf78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465840
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70489}
Manual copy and paste of all code found in the namespace base. I didn't
change any of the implementation code. Pull in a new file for optimized
ARM implementation.
Added a list of adaptions made to document what is different from
chromium.
Change-Id: I88b4af45437506cf57755e48fdfc88027a5aed33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436610
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70452}
Adds a cross-thread reference for strongly and weakly retaining
objects on a thread other than the thread that owns the object.
The intended use of the reference is by setting it up on the
originating thread, holding the object alive from another thread, and
ultimately accessing the object again on the originating thread.
The reference has known caveats:
- It's unsafe to use when the heap may terminate;
- It's unsafe to transitively reach through the graph because of
compaction;
Change-Id: I84fbdde69a099eb54af5b93c34e2169915b17e64
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436449
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70428}
Adds NameProvider to allow specifying names of objects. The
corresponding internal NameTrait is registered with the GCInfo object.
Use name infrastructure to provide a hint on encountering an unmarked
object in the marking verifier.
Bug: chromium:1056170
Change-Id: I95bb290660f5905500f861bd5cc85148a1b47184
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454087
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70400}
This reverts commit bbecd8d5b3.
Reason for revert: https://bugs.chromium.org/p/v8/issues/detail?id=10999
Original change's description:
> [heap] Turn on RO_SPACE sharing for pointer compression
>
> Makes the read-only space sharing the default even with pointer
> compression if on Linux, Android or Chrome OS.
>
> This won't have any immediate impact on Chrome since the platform page
> allocator in chrome does not yet support allocation and remapping of
> shared pages.
>
> Bug: v8:10454
> Change-Id: I3bc57080827efe38095a4bb1d02a53518727056a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454077
> Auto-Submit: Dan Elphick <delphick@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70383}
TBR=rmcilroy@chromium.org,delphick@chromium.org
Change-Id: I0e96f6b901adeb5569a545eb24b15fb8d45bf544
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10454
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460806
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70396}
Makes the read-only space sharing the default even with pointer
compression if on Linux, Android or Chrome OS.
This won't have any immediate impact on Chrome since the platform page
allocator in chrome does not yet support allocation and remapping of
shared pages.
Bug: v8:10454
Change-Id: I3bc57080827efe38095a4bb1d02a53518727056a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454077
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70383}
This adds a flag behind which we want to do the work towards allowing
prototype objects to stay in dict/"slow" mode rather than switching
them back to fast mode
Bug: v8:7569
Change-Id: I3c963dea5d01be3c348810f40f8610fc2a488819
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2450015
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Frank Emrich <emrich@google.com>
Cr-Commit-Position: refs/heads/master@{#70367}
This relands commit 3f4e9bbe43.
which was a reland of c4a062a958
which was a reland of 28a30c578c
which was a reland of 5d7a29c90e
The change had an issue that embedders implementing heap tracing (e.g.
Unified Heap with Blink) could be passed an uninitialized pointer if
marking happened during deserialization of an object containing such a
pointer. Because of the 0xdeadbed0 uninitialized filler value, these
embedders would then receive the value 0xdeadbed0deadbed0 as the
'pointer', and crash on dereference.
There is, however, special handling already for null pointers in heap
tracing, also for dealing with not-yet initialized values. So, we can
make the uninitialized Smi filler be 0x00000000, and that will make such
embedded fields have a nullptr representation, making them follow the
normal uninitialized value bailouts.
In addition, it relands the following dependent changes, which are
relanding unchanged and are followup performance improvements.
Relanding them in the same change should allow for cleaner reverts
should they be needed.
This relands commit 76ad3ab597
[identity-map] Change resize heuristic
This relands commit 77cc96aa48
[identity-map] Cache the calculated Hash
This relands commit bee5b996aa
[serializer] Remove Deserializer::Initialize
This relands commit c8f73f2266
[serializer] Cache instance type in PostProcessNewObject
This relands commit 4e7c99abda
[identity-map] Remove double-lookups in IdentityMap
Original change's description:
> Reland^3 "[serializer] Allocate during deserialization"
>
> This is a reland of c4a062a958
> which was a reland of 28a30c578c
> which was a reland of 5d7a29c90e
>
> Fixes TSAN errors from non-atomic writes in the deserializer. Now all
> writes are (relaxed) atomic.
>
> Original change's description:
> > Reland^2 "[serializer] Allocate during deserialization"
> >
> > This is a reland of 28a30c578c
> > which was a reland of 5d7a29c90e
> >
> > The crashes were from calling RegisterDeserializerFinished on a null
> > Isolate pointer, for a deserializer that was never initialised
> > (specifically, ReadOnlyDeserializer when ROHeap is shared).
> >
> > Original change's description:
> > > Reland "[serializer] Allocate during deserialization"
> > >
> > > This is a reland of 5d7a29c90e
> > >
> > > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > > to not check the new space addresses until it's known that this is a new
> > > space allocation. This fixes an UBSan failure during read-only space
> > > deserialization, which happens before the new space is initialized.
> > >
> > > It also fixes some issues discovered by --stress-snapshot, around
> > > serializing ThinStrings (which are now elided as part of serialization),
> > > handle counts (I bumped the maximum handle count in that check), and
> > > clearing map transitions (the map backpointer field needed a Smi
> > > uninitialized value check).
> > >
> > > Original change's description:
> > > > [serializer] Allocate during deserialization
> > > >
> > > > This patch removes the concept of reservations and a specialized
> > > > deserializer allocator, and instead makes the deserializer allocate
> > > > directly with the Heap's Allocate method.
> > > >
> > > > The major consequence of this is that the GC can now run during
> > > > deserialization, which means that:
> > > >
> > > > a) Deserialized objects are visible to the GC, and
> > > > b) Objects that the deserializer/deserialized objects point to can
> > > > move.
> > > >
> > > > Point a) is mostly not a problem due to previous work in making
> > > > deserialized objects "GC valid", i.e. making sure that they have a valid
> > > > size before any subsequent allocation/safepoint. We now additionally
> > > > have to initialize the allocated space with a valid tagged value -- this
> > > > is a magic Smi value to keep "uninitialized" checks simple.
> > > >
> > > > Point b) is solved by Handlifying the deserializer. This involves
> > > > changing any vectors of objects into vectors of Handles, and any object
> > > > keyed map into an IdentityMap (we can't use Handles as keys because
> > > > the object's address is no longer a stable hash).
> > > >
> > > > Back-references can no longer be direct chunk offsets, so instead the
> > > > deserializer stores a Handle to each deserialized object, and the
> > > > backreference is an index into this handle array. This encoding could
> > > > be optimized in the future with e.g. a second pass over the serialized
> > > > array which emits a different bytecode for objects that are and aren't
> > > > back-referenced.
> > > >
> > > > Additionally, the slot-walk over objects to initialize them can no
> > > > longer use absolute slot offsets, as again an object may move and its
> > > > slot address would become invalid. Now, slots are walked as relative
> > > > offsets to a Handle to the object, or as absolute slots for the case of
> > > > root pointers. A concept of "slot accessor" is introduced to share the
> > > > code between these two modes, and writing the slot (including write
> > > > barriers) is abstracted into this accessor.
> > > >
> > > > Finally, the Code body walk is modified to deserialize all objects
> > > > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > > > during a RelocInfo walk.
> > > >
> > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > > > size rather than byte size -- the size is expected to be tagged-aligned
> > > > anyway, so now we get an extra few bits in the size encoding.
> > > >
> > > > Bug: chromium:1075999
> > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#70229}
Bug: chromium:1075999
Change-Id: Ib514a4ef16bd02bfb60d046ecbf8fae1ead64a98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452689
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70366}
This CL introduces concurrent marking to the cppgc library.
The CL includes:
(*) Split MarkingState to mutator thread and concurrent thread.
(*) Split MarkingVisitor to mutator thread and concurrent thread.
(*) Introduce ConcurrentMarker for managing concurrent marking.
(*) Update unified heap to support concurrent marking as well.
See slides 13 and 14 in the following link for class hierarchies:
https://docs.google.com/presentation/d/1uDiEjJ-f1VziBKmYcvpw2gglP47M53bwj1L-P__l9QY/
Bug: chromium:1056170
Change-Id: I6530c2b21613011a612773d36fbf37416c23c5e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424348
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70352}
This reverts commit ff61743fb0.
Reason for revert: speculative revert for crbug.com/1135472
Original change's description:
> [heap] Refactor marking weak object worklists
>
> This CL extracts weak object worklist related code into separate files
> and uses a macro to specify all weak object worklists in a generic way.
>
> The motivation of the refactoring is twofold:
> 1) We can now enforce that each weak object worklist is updated after
> Scavenge. (Forgetting to define the update function causes a link
> time error.)
> 2) The reduced boilerplate will be useful for transitioning to the
> new ::heap::base::Worklist.
>
> Change-Id: Ic80a7ccca010c09370d6525f43d78de24192f8ea
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442624
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70308}
TBR=ulan@chromium.org,dinfuehr@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I552423106b516bcc79d067cda390c188a717b125
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452711
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70351}
The new flags are
- v8_enable_atomic_object_field_writes that makes field write operations
relaxed atomic.
- v8_enable_atomic_marking_state that makes the marking state and the
write-barrier thread-safe.
The motivation is that we want to disable atomic object fields while
keeping the marking states thread-safe. This allows us to increase
TSAN coverage for background compilation and streaming tasks while
keeping the write-barrier used by the tasks thread-safe.
Bug: v8:10988
Change-Id: I11d66954dda4bf36d24c5e6f14ee5bc7a0f86094
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448467
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70329}
This reverts commit 3f4e9bbe43, along
with the following dependent changes (reverted to make this a clean revert):
76ad3ab597 [identity-map] Change resize heuristic
77cc96aa48 [identity-map] Cache the calculated Hash
bee5b996aa [serializer] Remove Deserializer::Initialize
c8f73f2266 [serializer] Cache instance type in PostProcessNewObject
4e7c99abda [identity-map] Remove double-lookups in IdentityMap
Reason for revert: major crash spike on Canary (https://crbug.com/1135027)
Original change's description:
> Reland^3 "[serializer] Allocate during deserialization"
>
> This is a reland of c4a062a958
> which was a reland of 28a30c578c
> which was a reland of 5d7a29c90e
>
> Fixes TSAN errors from non-atomic writes in the deserializer. Now all
> writes are (relaxed) atomic.
>
> Original change's description:
> > Reland^2 "[serializer] Allocate during deserialization"
> >
> > This is a reland of 28a30c578c
> > which was a reland of 5d7a29c90e
> >
> > The crashes were from calling RegisterDeserializerFinished on a null
> > Isolate pointer, for a deserializer that was never initialised
> > (specifically, ReadOnlyDeserializer when ROHeap is shared).
> >
> > Original change's description:
> > > Reland "[serializer] Allocate during deserialization"
> > >
> > > This is a reland of 5d7a29c90e
> > >
> > > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > > to not check the new space addresses until it's known that this is a new
> > > space allocation. This fixes an UBSan failure during read-only space
> > > deserialization, which happens before the new space is initialized.
> > >
> > > It also fixes some issues discovered by --stress-snapshot, around
> > > serializing ThinStrings (which are now elided as part of serialization),
> > > handle counts (I bumped the maximum handle count in that check), and
> > > clearing map transitions (the map backpointer field needed a Smi
> > > uninitialized value check).
> > >
> > > Original change's description:
> > > > [serializer] Allocate during deserialization
> > > >
> > > > This patch removes the concept of reservations and a specialized
> > > > deserializer allocator, and instead makes the deserializer allocate
> > > > directly with the Heap's Allocate method.
> > > >
> > > > The major consequence of this is that the GC can now run during
> > > > deserialization, which means that:
> > > >
> > > > a) Deserialized objects are visible to the GC, and
> > > > b) Objects that the deserializer/deserialized objects point to can
> > > > move.
> > > >
> > > > Point a) is mostly not a problem due to previous work in making
> > > > deserialized objects "GC valid", i.e. making sure that they have a valid
> > > > size before any subsequent allocation/safepoint. We now additionally
> > > > have to initialize the allocated space with a valid tagged value -- this
> > > > is a magic Smi value to keep "uninitialized" checks simple.
> > > >
> > > > Point b) is solved by Handlifying the deserializer. This involves
> > > > changing any vectors of objects into vectors of Handles, and any object
> > > > keyed map into an IdentityMap (we can't use Handles as keys because
> > > > the object's address is no longer a stable hash).
> > > >
> > > > Back-references can no longer be direct chunk offsets, so instead the
> > > > deserializer stores a Handle to each deserialized object, and the
> > > > backreference is an index into this handle array. This encoding could
> > > > be optimized in the future with e.g. a second pass over the serialized
> > > > array which emits a different bytecode for objects that are and aren't
> > > > back-referenced.
> > > >
> > > > Additionally, the slot-walk over objects to initialize them can no
> > > > longer use absolute slot offsets, as again an object may move and its
> > > > slot address would become invalid. Now, slots are walked as relative
> > > > offsets to a Handle to the object, or as absolute slots for the case of
> > > > root pointers. A concept of "slot accessor" is introduced to share the
> > > > code between these two modes, and writing the slot (including write
> > > > barriers) is abstracted into this accessor.
> > > >
> > > > Finally, the Code body walk is modified to deserialize all objects
> > > > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > > > during a RelocInfo walk.
> > > >
> > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > > > size rather than byte size -- the size is expected to be tagged-aligned
> > > > anyway, so now we get an extra few bits in the size encoding.
> > > >
> > > > Bug: chromium:1075999
> > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#70229}
> > >
> > > Bug: chromium:1075999
> > > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#70267}
> >
> > Tbr: jgruber@chromium.org,ulan@chromium.org
> > Bug: chromium:1075999
> > Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70279}
>
> Tbr: jgruber@chromium.org,ulan@chromium.org
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
> Bug: chromium:1075999
> Change-Id: I0b9b11644aebc4cc8b07c62a0f765b24e4d73d89
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445872
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70288}
TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org,dinfuehr@chromium.org
Bug: chromium:1075999, chromium:1135027
Change-Id: I5d0d9e49c0302d94ff7291834f5f18e7a0839eb7
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2451030
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70328}
This change adds a new code generator, which supports a subset of the
instructions supported by the existing CSAGenerator, and instead of
generating CSA it generates runtime C++ code. The new generator is used
to generate a set of Torque macros that return slices to indexed fields.
These new macros should be sufficient to eventually support
Torque-generated field accessors, BodyDescriptors, verifier functions,
and postmortem field inspection in debug_helper.
Bug: v8:7793
Change-Id: Ife2d25cfd55a08238c625a8b04aca3ff2a0f4c63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429566
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70313}
This CL extracts weak object worklist related code into separate files
and uses a macro to specify all weak object worklists in a generic way.
The motivation of the refactoring is twofold:
1) We can now enforce that each weak object worklist is updated after
Scavenge. (Forgetting to define the update function causes a link
time error.)
2) The reduced boilerplate will be useful for transitioning to the
new ::heap::base::Worklist.
Change-Id: Ic80a7ccca010c09370d6525f43d78de24192f8ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442624
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70308}
Remove a spurious assert probably introduced by a bad merge that
disallowed RO_SPACE sharing when pointer compression is enabled.
Change-Id: I8a59a242667252dcbb098e5be405ac67a4e01a3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445877
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70290}
This is a reland of c4a062a958
which was a reland of 28a30c578c
which was a reland of 5d7a29c90e
Fixes TSAN errors from non-atomic writes in the deserializer. Now all
writes are (relaxed) atomic.
Original change's description:
> Reland^2 "[serializer] Allocate during deserialization"
>
> This is a reland of 28a30c578c
> which was a reland of 5d7a29c90e
>
> The crashes were from calling RegisterDeserializerFinished on a null
> Isolate pointer, for a deserializer that was never initialised
> (specifically, ReadOnlyDeserializer when ROHeap is shared).
>
> Original change's description:
> > Reland "[serializer] Allocate during deserialization"
> >
> > This is a reland of 5d7a29c90e
> >
> > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > to not check the new space addresses until it's known that this is a new
> > space allocation. This fixes an UBSan failure during read-only space
> > deserialization, which happens before the new space is initialized.
> >
> > It also fixes some issues discovered by --stress-snapshot, around
> > serializing ThinStrings (which are now elided as part of serialization),
> > handle counts (I bumped the maximum handle count in that check), and
> > clearing map transitions (the map backpointer field needed a Smi
> > uninitialized value check).
> >
> > Original change's description:
> > > [serializer] Allocate during deserialization
> > >
> > > This patch removes the concept of reservations and a specialized
> > > deserializer allocator, and instead makes the deserializer allocate
> > > directly with the Heap's Allocate method.
> > >
> > > The major consequence of this is that the GC can now run during
> > > deserialization, which means that:
> > >
> > > a) Deserialized objects are visible to the GC, and
> > > b) Objects that the deserializer/deserialized objects point to can
> > > move.
> > >
> > > Point a) is mostly not a problem due to previous work in making
> > > deserialized objects "GC valid", i.e. making sure that they have a valid
> > > size before any subsequent allocation/safepoint. We now additionally
> > > have to initialize the allocated space with a valid tagged value -- this
> > > is a magic Smi value to keep "uninitialized" checks simple.
> > >
> > > Point b) is solved by Handlifying the deserializer. This involves
> > > changing any vectors of objects into vectors of Handles, and any object
> > > keyed map into an IdentityMap (we can't use Handles as keys because
> > > the object's address is no longer a stable hash).
> > >
> > > Back-references can no longer be direct chunk offsets, so instead the
> > > deserializer stores a Handle to each deserialized object, and the
> > > backreference is an index into this handle array. This encoding could
> > > be optimized in the future with e.g. a second pass over the serialized
> > > array which emits a different bytecode for objects that are and aren't
> > > back-referenced.
> > >
> > > Additionally, the slot-walk over objects to initialize them can no
> > > longer use absolute slot offsets, as again an object may move and its
> > > slot address would become invalid. Now, slots are walked as relative
> > > offsets to a Handle to the object, or as absolute slots for the case of
> > > root pointers. A concept of "slot accessor" is introduced to share the
> > > code between these two modes, and writing the slot (including write
> > > barriers) is abstracted into this accessor.
> > >
> > > Finally, the Code body walk is modified to deserialize all objects
> > > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > > during a RelocInfo walk.
> > >
> > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > > size rather than byte size -- the size is expected to be tagged-aligned
> > > anyway, so now we get an extra few bits in the size encoding.
> > >
> > > Bug: chromium:1075999
> > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#70229}
> >
> > Bug: chromium:1075999
> > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70267}
>
> Tbr: jgruber@chromium.org,ulan@chromium.org
> Bug: chromium:1075999
> Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70279}
Tbr: jgruber@chromium.org,ulan@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
Bug: chromium:1075999
Change-Id: I0b9b11644aebc4cc8b07c62a0f765b24e4d73d89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445872
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70288}
This reverts commit c4a062a958.
Reason for revert: TSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33504
Original change's description:
> Reland^2 "[serializer] Allocate during deserialization"
>
> This is a reland of 28a30c578c
> which was a reland of 5d7a29c90e
>
> The crashes were from calling RegisterDeserializerFinished on a null
> Isolate pointer, for a deserializer that was never initialised
> (specifically, ReadOnlyDeserializer when ROHeap is shared).
>
> Original change's description:
> > Reland "[serializer] Allocate during deserialization"
> >
> > This is a reland of 5d7a29c90e
> >
> > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > to not check the new space addresses until it's known that this is a new
> > space allocation. This fixes an UBSan failure during read-only space
> > deserialization, which happens before the new space is initialized.
> >
> > It also fixes some issues discovered by --stress-snapshot, around
> > serializing ThinStrings (which are now elided as part of serialization),
> > handle counts (I bumped the maximum handle count in that check), and
> > clearing map transitions (the map backpointer field needed a Smi
> > uninitialized value check).
> >
> > Original change's description:
> > > [serializer] Allocate during deserialization
> > >
> > > This patch removes the concept of reservations and a specialized
> > > deserializer allocator, and instead makes the deserializer allocate
> > > directly with the Heap's Allocate method.
> > >
> > > The major consequence of this is that the GC can now run during
> > > deserialization, which means that:
> > >
> > > a) Deserialized objects are visible to the GC, and
> > > b) Objects that the deserializer/deserialized objects point to can
> > > move.
> > >
> > > Point a) is mostly not a problem due to previous work in making
> > > deserialized objects "GC valid", i.e. making sure that they have a valid
> > > size before any subsequent allocation/safepoint. We now additionally
> > > have to initialize the allocated space with a valid tagged value -- this
> > > is a magic Smi value to keep "uninitialized" checks simple.
> > >
> > > Point b) is solved by Handlifying the deserializer. This involves
> > > changing any vectors of objects into vectors of Handles, and any object
> > > keyed map into an IdentityMap (we can't use Handles as keys because
> > > the object's address is no longer a stable hash).
> > >
> > > Back-references can no longer be direct chunk offsets, so instead the
> > > deserializer stores a Handle to each deserialized object, and the
> > > backreference is an index into this handle array. This encoding could
> > > be optimized in the future with e.g. a second pass over the serialized
> > > array which emits a different bytecode for objects that are and aren't
> > > back-referenced.
> > >
> > > Additionally, the slot-walk over objects to initialize them can no
> > > longer use absolute slot offsets, as again an object may move and its
> > > slot address would become invalid. Now, slots are walked as relative
> > > offsets to a Handle to the object, or as absolute slots for the case of
> > > root pointers. A concept of "slot accessor" is introduced to share the
> > > code between these two modes, and writing the slot (including write
> > > barriers) is abstracted into this accessor.
> > >
> > > Finally, the Code body walk is modified to deserialize all objects
> > > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > > during a RelocInfo walk.
> > >
> > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > > size rather than byte size -- the size is expected to be tagged-aligned
> > > anyway, so now we get an extra few bits in the size encoding.
> > >
> > > Bug: chromium:1075999
> > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#70229}
> >
> > Bug: chromium:1075999
> > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70267}
>
> Tbr: jgruber@chromium.org,ulan@chromium.org
> Bug: chromium:1075999
> Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70279}
TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org
Change-Id: Ib2f01db4cd9b55639d6a4af971bda865edb45e84
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1075999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445250
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70280}
This is a reland of 28a30c578c
which was a reland of 5d7a29c90e
The crashes were from calling RegisterDeserializerFinished on a null
Isolate pointer, for a deserializer that was never initialised
(specifically, ReadOnlyDeserializer when ROHeap is shared).
Original change's description:
> Reland "[serializer] Allocate during deserialization"
>
> This is a reland of 5d7a29c90e
>
> This reland shuffles around the order of checks in Heap::AllocateRawWith
> to not check the new space addresses until it's known that this is a new
> space allocation. This fixes an UBSan failure during read-only space
> deserialization, which happens before the new space is initialized.
>
> It also fixes some issues discovered by --stress-snapshot, around
> serializing ThinStrings (which are now elided as part of serialization),
> handle counts (I bumped the maximum handle count in that check), and
> clearing map transitions (the map backpointer field needed a Smi
> uninitialized value check).
>
> Original change's description:
> > [serializer] Allocate during deserialization
> >
> > This patch removes the concept of reservations and a specialized
> > deserializer allocator, and instead makes the deserializer allocate
> > directly with the Heap's Allocate method.
> >
> > The major consequence of this is that the GC can now run during
> > deserialization, which means that:
> >
> > a) Deserialized objects are visible to the GC, and
> > b) Objects that the deserializer/deserialized objects point to can
> > move.
> >
> > Point a) is mostly not a problem due to previous work in making
> > deserialized objects "GC valid", i.e. making sure that they have a valid
> > size before any subsequent allocation/safepoint. We now additionally
> > have to initialize the allocated space with a valid tagged value -- this
> > is a magic Smi value to keep "uninitialized" checks simple.
> >
> > Point b) is solved by Handlifying the deserializer. This involves
> > changing any vectors of objects into vectors of Handles, and any object
> > keyed map into an IdentityMap (we can't use Handles as keys because
> > the object's address is no longer a stable hash).
> >
> > Back-references can no longer be direct chunk offsets, so instead the
> > deserializer stores a Handle to each deserialized object, and the
> > backreference is an index into this handle array. This encoding could
> > be optimized in the future with e.g. a second pass over the serialized
> > array which emits a different bytecode for objects that are and aren't
> > back-referenced.
> >
> > Additionally, the slot-walk over objects to initialize them can no
> > longer use absolute slot offsets, as again an object may move and its
> > slot address would become invalid. Now, slots are walked as relative
> > offsets to a Handle to the object, or as absolute slots for the case of
> > root pointers. A concept of "slot accessor" is introduced to share the
> > code between these two modes, and writing the slot (including write
> > barriers) is abstracted into this accessor.
> >
> > Finally, the Code body walk is modified to deserialize all objects
> > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > during a RelocInfo walk.
> >
> > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > size rather than byte size -- the size is expected to be tagged-aligned
> > anyway, so now we get an extra few bits in the size encoding.
> >
> > Bug: chromium:1075999
> > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70229}
>
> Bug: chromium:1075999
> Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70267}
Tbr: jgruber@chromium.org,ulan@chromium.org
Bug: chromium:1075999
Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70279}
This reverts commit 28a30c578c.
Reason for revert: Broke Test262 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/38638?
Original change's description:
> Reland "[serializer] Allocate during deserialization"
>
> This is a reland of 5d7a29c90e
>
> This reland shuffles around the order of checks in Heap::AllocateRawWith
> to not check the new space addresses until it's known that this is a new
> space allocation. This fixes an UBSan failure during read-only space
> deserialization, which happens before the new space is initialized.
>
> It also fixes some issues discovered by --stress-snapshot, around
> serializing ThinStrings (which are now elided as part of serialization),
> handle counts (I bumped the maximum handle count in that check), and
> clearing map transitions (the map backpointer field needed a Smi
> uninitialized value check).
>
> Original change's description:
> > [serializer] Allocate during deserialization
> >
> > This patch removes the concept of reservations and a specialized
> > deserializer allocator, and instead makes the deserializer allocate
> > directly with the Heap's Allocate method.
> >
> > The major consequence of this is that the GC can now run during
> > deserialization, which means that:
> >
> > a) Deserialized objects are visible to the GC, and
> > b) Objects that the deserializer/deserialized objects point to can
> > move.
> >
> > Point a) is mostly not a problem due to previous work in making
> > deserialized objects "GC valid", i.e. making sure that they have a valid
> > size before any subsequent allocation/safepoint. We now additionally
> > have to initialize the allocated space with a valid tagged value -- this
> > is a magic Smi value to keep "uninitialized" checks simple.
> >
> > Point b) is solved by Handlifying the deserializer. This involves
> > changing any vectors of objects into vectors of Handles, and any object
> > keyed map into an IdentityMap (we can't use Handles as keys because
> > the object's address is no longer a stable hash).
> >
> > Back-references can no longer be direct chunk offsets, so instead the
> > deserializer stores a Handle to each deserialized object, and the
> > backreference is an index into this handle array. This encoding could
> > be optimized in the future with e.g. a second pass over the serialized
> > array which emits a different bytecode for objects that are and aren't
> > back-referenced.
> >
> > Additionally, the slot-walk over objects to initialize them can no
> > longer use absolute slot offsets, as again an object may move and its
> > slot address would become invalid. Now, slots are walked as relative
> > offsets to a Handle to the object, or as absolute slots for the case of
> > root pointers. A concept of "slot accessor" is introduced to share the
> > code between these two modes, and writing the slot (including write
> > barriers) is abstracted into this accessor.
> >
> > Finally, the Code body walk is modified to deserialize all objects
> > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > during a RelocInfo walk.
> >
> > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > size rather than byte size -- the size is expected to be tagged-aligned
> > anyway, so now we get an extra few bits in the size encoding.
> >
> > Bug: chromium:1075999
> > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70229}
>
> Bug: chromium:1075999
> Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70267}
TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org
Change-Id: Ieed68332ef6a7ad36db061e3f48be0f28673d7a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1075999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2441608
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70268}
This is a reland of 5d7a29c90e
This reland shuffles around the order of checks in Heap::AllocateRawWith
to not check the new space addresses until it's known that this is a new
space allocation. This fixes an UBSan failure during read-only space
deserialization, which happens before the new space is initialized.
It also fixes some issues discovered by --stress-snapshot, around
serializing ThinStrings (which are now elided as part of serialization),
handle counts (I bumped the maximum handle count in that check), and
clearing map transitions (the map backpointer field needed a Smi
uninitialized value check).
Original change's description:
> [serializer] Allocate during deserialization
>
> This patch removes the concept of reservations and a specialized
> deserializer allocator, and instead makes the deserializer allocate
> directly with the Heap's Allocate method.
>
> The major consequence of this is that the GC can now run during
> deserialization, which means that:
>
> a) Deserialized objects are visible to the GC, and
> b) Objects that the deserializer/deserialized objects point to can
> move.
>
> Point a) is mostly not a problem due to previous work in making
> deserialized objects "GC valid", i.e. making sure that they have a valid
> size before any subsequent allocation/safepoint. We now additionally
> have to initialize the allocated space with a valid tagged value -- this
> is a magic Smi value to keep "uninitialized" checks simple.
>
> Point b) is solved by Handlifying the deserializer. This involves
> changing any vectors of objects into vectors of Handles, and any object
> keyed map into an IdentityMap (we can't use Handles as keys because
> the object's address is no longer a stable hash).
>
> Back-references can no longer be direct chunk offsets, so instead the
> deserializer stores a Handle to each deserialized object, and the
> backreference is an index into this handle array. This encoding could
> be optimized in the future with e.g. a second pass over the serialized
> array which emits a different bytecode for objects that are and aren't
> back-referenced.
>
> Additionally, the slot-walk over objects to initialize them can no
> longer use absolute slot offsets, as again an object may move and its
> slot address would become invalid. Now, slots are walked as relative
> offsets to a Handle to the object, or as absolute slots for the case of
> root pointers. A concept of "slot accessor" is introduced to share the
> code between these two modes, and writing the slot (including write
> barriers) is abstracted into this accessor.
>
> Finally, the Code body walk is modified to deserialize all objects
> referred to by RelocInfos before doing the RelocInfo walk itself. This
> is because RelocInfoIterator uses raw pointers, so we cannot allocate
> during a RelocInfo walk.
>
> As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> size rather than byte size -- the size is expected to be tagged-aligned
> anyway, so now we get an extra few bits in the size encoding.
>
> Bug: chromium:1075999
> Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70229}
Bug: chromium:1075999
Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70267}
