- 25 Feb, 2021 1 commit
-
-
Hannes Payer authored
Change-Id: Ib54d5abad3e67f74d1930af135778e1f201ba28f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712964 Commit-Queue: Hannes Payer <hpayer@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#73050}
-
- 19 Feb, 2021 1 commit
-
-
Frank Emrich authored
This is a reland of https://chromium-review.googlesource.com/c/v8/v8/+/2688058 This CL is part of a series that adds the C++ implementation of SwissNameDictionary, a deterministic property backing store based on Swiss Tables. This CL adds the initialization code, factory functions and a canonical SwissNameDictionary plus all helpers required for that. Bug: v8:11388 Change-Id: I9cf66a3fa755288f7730f55abfb6e6cea82f6b03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2703653 Commit-Queue: Frank Emrich <emrich@google.com> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72857}
-
- 17 Feb, 2021 2 commits
-
-
Bill Budge authored
This reverts commit 2f8a7561. Reason for revert: Speculative revert, lots of segfaults on Arm: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/17781 Original change's description: > [dict-proto] C++ implementation of SwissNameDictionary, pt. 3 > > This CL is part of a series that adds the C++ implementation of > SwissNameDictionary, a deterministic property backing store based on > Swiss Tables. > > This CL adds the initialization code, factory functions and a > canonical SwissNameDictionary plus all helpers required for that. > > Bug: v8:11388 > Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Frank Emrich <emrich@google.com> > Cr-Commit-Position: refs/heads/master@{#72824} Bug: v8:11388 Change-Id: Ia5dae584b0fb452b12c5d64ee63ffa418c83f91b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698758 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#72829}
-
Frank Emrich authored
This CL is part of a series that adds the C++ implementation of SwissNameDictionary, a deterministic property backing store based on Swiss Tables. This CL adds the initialization code, factory functions and a canonical SwissNameDictionary plus all helpers required for that. Bug: v8:11388 Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Frank Emrich <emrich@google.com> Cr-Commit-Position: refs/heads/master@{#72824}
-
- 09 Feb, 2021 1 commit
-
-
Frank Emrich authored
This CL is part of a series that adds the C++ implementation of SwissNameDictionary, a deterministic property backing store based on Swiss Tables. This CL contains most of the boilerplate code for introducing a new instance type. Bug: v8:11388 Change-Id: Id263b8138a8ce4b465fb28d968223d2e1aaf05a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672030Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Frank Emrich <emrich@google.com> Cr-Commit-Position: refs/heads/master@{#72582}
-
- 27 Jan, 2021 1 commit
-
-
Manos Koukoutos authored
This is a reland of b77deeca Changes compared to original: Add explicit narrowing casts in tests for MSVC. Original change's description: > [wasm-gc] Remove abstract rtts > > In the latest wasm-gc spec, rtts of abstract types are no longer > allowed. Consequently, canonical rtts of concrete types always have > a depth of 0. > > Changes: > - Change the immediate argument of rtts to a type index over a heap > type. Abstract it with TypeIndexImmediate in function body decoding. > This affects: > value_type.h, read_value_type(), decoding of relevant opcodes, > wasm subtyping, WasmInitExpr, consume_init_expr(), and > wasm-module-builder.cc. > - In function-body-decoder-impl.h, update rtt.canon to always produce > an rtt of depth 0. > - Pass a unit32_t type index over a HeapType to all rtt-related > utilities. > - Remove infrastructure for abstract-type rtts from the wasm compilers, > setup-heap-internal.cc, roots.h, and module-instantiate.cc. > - Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches > from ref.test, ref.cast and br_on_cast implementations in the wasm > compilers. > - Remove unused 'parent' field from WasmTypeInfo. > - Make the parent argument optional in NewWasmTypeInfo, CreateStructMap, > and CreateArrayMap. > - Use more convenient arguments in IsHeapSubtypeOf. > - Update tests. > > Bug: v8:7748 > Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248 > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72321} Bug: v8:7748 Change-Id: I22b204b486fd185077cd6c7f15d492f5143f48fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2650207 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72355}
-
- 26 Jan, 2021 3 commits
-
-
Clemens Backes authored
This reverts commit b77deeca. Reason for revert: MSVC compile fails: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/16535/overview Original change's description: > [wasm-gc] Remove abstract rtts > > In the latest wasm-gc spec, rtts of abstract types are no longer > allowed. Consequently, canonical rtts of concrete types always have > a depth of 0. > > Changes: > - Change the immediate argument of rtts to a type index over a heap > type. Abstract it with TypeIndexImmediate in function body decoding. > This affects: > value_type.h, read_value_type(), decoding of relevant opcodes, > wasm subtyping, WasmInitExpr, consume_init_expr(), and > wasm-module-builder.cc. > - In function-body-decoder-impl.h, update rtt.canon to always produce > an rtt of depth 0. > - Pass a unit32_t type index over a HeapType to all rtt-related > utilities. > - Remove infrastructure for abstract-type rtts from the wasm compilers, > setup-heap-internal.cc, roots.h, and module-instantiate.cc. > - Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches > from ref.test, ref.cast and br_on_cast implementations in the wasm > compilers. > - Remove unused 'parent' field from WasmTypeInfo. > - Make the parent argument optional in NewWasmTypeInfo, CreateStructMap, > and CreateArrayMap. > - Use more convenient arguments in IsHeapSubtypeOf. > - Update tests. > > Bug: v8:7748 > Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248 > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72321} TBR=ulan@chromium.org,jkummerow@chromium.org,manoskouk@chromium.org Change-Id: I2f0d97f1a34f7c81c5a97d7c37925cb84c66eea3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7748 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2650206Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72322}
-
Manos Koukoutos authored
In the latest wasm-gc spec, rtts of abstract types are no longer allowed. Consequently, canonical rtts of concrete types always have a depth of 0. Changes: - Change the immediate argument of rtts to a type index over a heap type. Abstract it with TypeIndexImmediate in function body decoding. This affects: value_type.h, read_value_type(), decoding of relevant opcodes, wasm subtyping, WasmInitExpr, consume_init_expr(), and wasm-module-builder.cc. - In function-body-decoder-impl.h, update rtt.canon to always produce an rtt of depth 0. - Pass a unit32_t type index over a HeapType to all rtt-related utilities. - Remove infrastructure for abstract-type rtts from the wasm compilers, setup-heap-internal.cc, roots.h, and module-instantiate.cc. - Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches from ref.test, ref.cast and br_on_cast implementations in the wasm compilers. - Remove unused 'parent' field from WasmTypeInfo. - Make the parent argument optional in NewWasmTypeInfo, CreateStructMap, and CreateArrayMap. - Use more convenient arguments in IsHeapSubtypeOf. - Update tests. Bug: v8:7748 Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#72321}
-
Georg Neis authored
Change-Id: I702f8c021490f0538a98cad9a61b1dbae60fb881 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649027Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72314}
-
- 20 Jan, 2021 1 commit
-
-
Victor Gomes authored
Without the adaptor frame, this is dead code. Change-Id: Ica1ee102fcc068a58c5dcbca6122921cd1b5550a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639760Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72185}
-
- 15 Jan, 2021 1 commit
-
-
Santiago Aboy Solanes authored
This reverts commit b3d09001. Reason for revert: https://chromium-review.googlesource.com/c/v8/v8/+/2565511 has to be reverted, and this was a follow-up to that Original change's description: > [objects] Remove uncached internal external string type > > We shouldn't be creating those anymore since they are not thread-safe. > > Bug: v8:7790 > Change-Id: I4546d995fa32eb076c8dfe9d95301fad719c9e07 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615347 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72006} TBR=rmcilroy@chromium.org,leszeks@chromium.org,solanes@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7790 Change-Id: I4eb1a6b8446fa602eeb5bf29fbf1fe57182cdbf3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2627605Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72122}
-
- 11 Jan, 2021 1 commit
-
-
Santiago Aboy Solanes authored
We shouldn't be creating those anymore since they are not thread-safe. Bug: v8:7790 Change-Id: I4546d995fa32eb076c8dfe9d95301fad719c9e07 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615347Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72006}
-
- 19 Nov, 2020 1 commit
-
-
Manos Koukoutos authored
Bug: v8:7748 Change-Id: I5d0cc06fafbe7fc05549a4b8fd7f602eaf838bba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2526382 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#71283}
-
- 17 Nov, 2020 1 commit
-
-
Tobias Tebbi authored
Drive-by change: Fix wrong reference to FixedRangeBodyDescriptor in implementation-visitor.cc TBR: ulan@chromium.org Change-Id: I8a1f468f35c38f5be1f4e8d1cfcc9f0fd2a16381 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540546 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#71223}
-
- 09 Nov, 2020 1 commit
-
-
Tobias Tebbi authored
This is a reland of 26f10ecd Change compared to original CL: The deserializer changes StrongDescriptorArray to DescriptorArray. Since this CL uses separate BodyDescriptors for the two kinds of descriptor arrays, this caused a DCHECK failure when the deserializer changes the map while the object is visited from the concurrent marking thread. Fix this by disabling the corresponding checks. Original change's description: > [torque] allow exported classes with custom C++ class > > Introduce a new annotation @customCppClass that can be used for > non-extern @export classes, that is, generate everything, remove > boilerplate from all the internal lists and switches, but allow > a custom C++ class, which in turn also allows overwriting the generated > print and verify functions. > > Port DescriptorArray and StrongDescriptorArray as an example. > > Bug: v8:7793 > Change-Id: I744e52fb4102ac49c0097f1c95bb17d301975bf0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489687 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70989} Bug: v8:7793 Change-Id: I7505fb111896991d16d7d113704c8c3676669f34 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2526383Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71048}
-
- 05 Nov, 2020 2 commits
-
-
Michael Achenbach authored
This reverts commit 26f10ecd. Reason for revert: GC stress failures: https://crbug.com/v8/11114 Original change's description: > [torque] allow exported classes with custom C++ class > > Introduce a new annotation @customCppClass that can be used for > non-extern @export classes, that is, generate everything, remove > boilerplate from all the internal lists and switches, but allow > a custom C++ class, which in turn also allows overwriting the generated > print and verify functions. > > Port DescriptorArray and StrongDescriptorArray as an example. > > Bug: v8:7793 > Change-Id: I744e52fb4102ac49c0097f1c95bb17d301975bf0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489687 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70989} TBR=ulan@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org Change-Id: I4631db66a76f41cf62b400e8ee64df27e641a320 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793,v8:11114 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2521911Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#70994}
-
Tobias Tebbi authored
Introduce a new annotation @customCppClass that can be used for non-extern @export classes, that is, generate everything, remove boilerplate from all the internal lists and switches, but allow a custom C++ class, which in turn also allows overwriting the generated print and verify functions. Port DescriptorArray and StrongDescriptorArray as an example. Bug: v8:7793 Change-Id: I744e52fb4102ac49c0097f1c95bb17d301975bf0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489687Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70989}
-
- 20 Oct, 2020 1 commit
-
-
Edward Lesmes authored
Generate DIR_METADATA files and remove metadata from OWNERS files for v8. R=jkummerow@chromium.org, ochang@chromium.org, yangguo@chromium.org Bug: chromium:1113033 Change-Id: I82cbb62e438d82dbbc408e87120af39fa9da0afa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476680Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org> Auto-Submit: Edward Lesmes <ehmaldonado@chromium.org> Cr-Commit-Position: refs/heads/master@{#70669}
-
- 19 Oct, 2020 1 commit
-
-
Frank Emrich authored
This changes OrderedHashMap, OrderedHashSet, and OrderedNameDictionary as follows: - Create a dedicated allocation function AllocateEmpty to create zero- element instances of these classes - Fix bugs resulting from using these zero-element versions Further, this CL - provides a canonical empty versions of OrderedNameDictionary - changes the types of the canonical ordered hash table and hash set from FixedArray to the actual subclasses Bug: v8:7569 Change-Id: I0fe1215e7d164617afa777c8b3208a0857ab6edd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476315 Commit-Queue: Frank Emrich <emrich@google.com> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#70604}
-
- 07 Oct, 2020 1 commit
-
-
Leszek Swirski authored
This relands commit 3f4e9bbe. which was a reland of c4a062a9 which was a reland of 28a30c57 which was a reland of 5d7a29c9 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 76ad3ab5 [identity-map] Change resize heuristic This relands commit 77cc96aa [identity-map] Cache the calculated Hash This relands commit bee5b996 [serializer] Remove Deserializer::Initialize This relands commit c8f73f22 [serializer] Cache instance type in PostProcessNewObject This relands commit 4e7c99ab [identity-map] Remove double-lookups in IdentityMap Original change's description: > Reland^3 "[serializer] Allocate during deserialization" > > This is a reland of c4a062a9 > which was a reland of 28a30c57 > which was a reland of 5d7a29c9 > > 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 28a30c57 > > which was a reland of 5d7a29c9 > > > > 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 5d7a29c9 > > > > > > 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}
-
- 05 Oct, 2020 1 commit
-
-
Adam Klein authored
This reverts commit 3f4e9bbe, along with the following dependent changes (reverted to make this a clean revert): 76ad3ab5 [identity-map] Change resize heuristic 77cc96aa [identity-map] Cache the calculated Hash bee5b996 [serializer] Remove Deserializer::Initialize c8f73f22 [serializer] Cache instance type in PostProcessNewObject 4e7c99ab [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 c4a062a9 > which was a reland of 28a30c57 > which was a reland of 5d7a29c9 > > 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 28a30c57 > > which was a reland of 5d7a29c9 > > > > 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 5d7a29c9 > > > > > > 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/+/2451030Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#70328}
-
- 02 Oct, 2020 3 commits
-
-
Leszek Swirski authored
This is a reland of c4a062a9 which was a reland of 28a30c57 which was a reland of 5d7a29c9 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 28a30c57 > which was a reland of 5d7a29c9 > > 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 5d7a29c9 > > > > 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}
-
Clemens Backes authored
This reverts commit c4a062a9. 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 28a30c57 > which was a reland of 5d7a29c9 > > 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 5d7a29c9 > > > > 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/+/2445250Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#70280}
-
Leszek Swirski authored
This is a reland of 28a30c57 which was a reland of 5d7a29c9 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 5d7a29c9 > > 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/+/2444991Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70279}
-
- 01 Oct, 2020 2 commits
-
-
Zhi An Ng authored
This reverts commit 28a30c57. 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 5d7a29c9 > > 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/+/2441608Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70268}
-
Leszek Swirski authored
This is a reland of 5d7a29c9 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}
-
- 30 Sep, 2020 2 commits
-
-
Leszek Swirski authored
This reverts commit 5d7a29c9. Reason for revert: UBSan -- https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/13100 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} TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org Change-Id: I2bd792a24861e8f54897e51522769b50f8f814e2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1075999 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440827 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70231}
-
Leszek Swirski authored
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}
-
- 14 Aug, 2020 1 commit
-
-
Leszek Swirski authored
This patch introduces a new LocalIsolate and LocalFactory, which use LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows us to remove those classes, as well as the related OffThreadSpace, OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle. OffThreadLogger becomes LocalLogger. LocalHeap behaves more like Heap than OffThreadHeap did, so this allows us to additionally remove the concept of "Finish" and "Publish" that the OffThreadIsolate had, and allows us to internalize strings directly with the newly-concurrent string table (where the implementation can now move to FactoryBase). This patch also removes the off-thread support from the deserializer entirely, as well as removing the LocalIsolateWrapper which allowed run-time distinction between Isolate and OffThreadIsolate. LocalHeap doesn't support the reservation model used by the deserializer, and we will likely move the deserializer to use LocalIsolate unconditionally once we figure out the details of how to do this. Bug: chromium:1011762 Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990 Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69397}
-
- 06 Aug, 2020 1 commit
-
-
Leszek Swirski authored
Changes the isolate's string table into an off-heap structure. This allows the string table to be resized without allocating on the V8 heap, and potentially triggering a GC. This allows existing strings to be inserted into the string table without requiring allocation. This has two important benefits: 1) It allows the deserializer to insert strings directly into the string table, rather than having to defer string insertion until deserialization completes. 2) It simplifies the concurrent string table lookup to allow resizing the table inside the write lock, therefore eliminating the race where two concurrent lookups could both resize the table. The off-heap string table has the following properties: 1) The general hashmap behaviour matches the HashTable, i.e. open addressing, power-of-two sized, quadratic probing. This could, of course, now be changed. 2) The empty and deleted sentinels are changed to Smi 0 and 1, respectively, to make those comparisons a bit cheaper and not require roots access. 3) When the HashTable is resized, the old elements array is kept alive in a linked list of previous arrays, so that concurrent lookups don't lose the data they're accessing. This linked list is cleared by the GC, as then we know that all threads are in a safepoint. 4) The GC treats the hash table entries as weak roots, and only walks them for non-live reference clearing and for evacuation. 5) Since there is no longer a FixedArray to serialize for the startup snapshot, there is now a custom serialization of the string table, and the string table root is considered unserializable during weak root iteration. As a bonus, the custom serialization is more efficient, as it skips non-string entries. As a drive-by, rename LookupStringExists_NoAllocate to TryStringToIndexOrLookupExisting, to make it clearer that it returns a non-string for the case when the string is an array index. As another drive-by, extract StringSet into a separate header. Bug: v8:10729 Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104 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@{#69270}
-
- 31 Jul, 2020 1 commit
-
-
Dan Elphick authored
This allows the configuration v8_enable_shared_ro_heap and v8_enable_pointer_compression on Linux and Android, although it still defaults to off. When pointer compression and read-only heap sharing are enabled, sharing is achieved by allocating ReadOnlyPages in shared memory that are retained in the shared ReadOnlyArtifacts object. These ReadOnlyPages are then remapped into the address space of the Isolate ultimately using mremap. To simplify the creation process the ReadOnlySpace memory for the first Isolate is created as before without any sharing. It is only when the ReadOnlySpace memory has been finalized that the shared memory is allocated and has its contents copied into it. The original memory is then released (with PC this means it's just released back to the BoundedPageAllocator) and immediately re-allocated as a shared mapping. Because we would like to make v8_enable_shared_ro_heap default to true at some point but can't make this conditional on the value returned by a method in the code we are yet to compile, the code required for sharing has been mostly changed to use ifs with ReadOnlyHeap::IsReadOnlySpaceShared() instead of #ifdefs except where a compile error would result due to the absence of a class members without sharing. IsReadOnlySpaceShared() will evaluate CanAllocateSharedPages in the platform PageAllocator (with pointer compression and sharing enabled) once and cache that value so sharing cannot be toggled during the lifetime of the process. Bug: v8:10454 Change-Id: I0236d752047ecce71bd64c159430517a712bc1e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267300 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69174}
-
- 23 Jul, 2020 1 commit
-
-
Leszek Swirski authored
This is a reland of 6af09b1b Relanding without changes after fixing the root cause in https://crrev.com/c/2315987 Original change's description: > [offthread] Add a write lock to the string table > > Adds an initial implementation of a concurrency support for the string > table, allowing it to be read without holding a lock, and written to > while holding a lock. > > This is an initial prototype of _roughly_ how the concurrency would > work; there are still a few holes (e.g. around deserialization). This > is predominantly to assess the main-thread runtime impact of the more > complex string table access. > > Bug: v8:10729 > Change-Id: I5c6c35e6fca309efd6ee79804c16972aae1ab3ab > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2306804 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68985} Tbr: verwaest@chromium.org,ishell@chromium.org,ulan@chromium.org Bug: v8:10729 Change-Id: I9ce8882cfbdd40fbe1c7478e171c0785bf2e64d6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315989 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#69025}
-
- 22 Jul, 2020 2 commits
-
-
Maya Lekova authored
This reverts commit 6af09b1b. Reason for revert: Breaks Win debug builder - https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/26384? Original change's description: > [offthread] Add a write lock to the string table > > Adds an initial implementation of a concurrency support for the string > table, allowing it to be read without holding a lock, and written to > while holding a lock. > > This is an initial prototype of _roughly_ how the concurrency would > work; there are still a few holes (e.g. around deserialization). This > is predominantly to assess the main-thread runtime impact of the more > complex string table access. > > Bug: v8:10729 > Change-Id: I5c6c35e6fca309efd6ee79804c16972aae1ab3ab > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2306804 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68985} TBR=ulan@chromium.org,leszeks@chromium.org,ishell@chromium.org,verwaest@chromium.org Change-Id: I001dc81f1d4031bf0451766452a43176df997354 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10729 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312776Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#68988}
-
Leszek Swirski authored
Adds an initial implementation of a concurrency support for the string table, allowing it to be read without holding a lock, and written to while holding a lock. This is an initial prototype of _roughly_ how the concurrency would work; there are still a few holes (e.g. around deserialization). This is predominantly to assess the main-thread runtime impact of the more complex string table access. Bug: v8:10729 Change-Id: I5c6c35e6fca309efd6ee79804c16972aae1ab3ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2306804Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#68985}
-
- 09 Jul, 2020 2 commits
-
-
Jakob Kummerow authored
By introducing a globally known map for each generic type. These maps are never used to allocate objects, they only serve as sentinels for generic heap types. Bug: v8:7748 Change-Id: I950a8c712dc1510759a833fe9122b9e9a6222dc2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288860 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68755}
-
Leszek Swirski authored
Change-Id: I90612ae0e54b46e7147d9a3392783f56da598b2b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287499 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68750}
-
- 03 Jul, 2020 1 commit
-
-
Dan Elphick authored
To get the Isolate from a HeapObject, rather than masking off the MemoryChunk and then loading the heap from the MemoryChunk (which won't work when RO_SPACE is shared between Isolates), get the Isolate by masking off the bottom 32 bits and apply the Isolate bias. Also fixes up a stale comment and makes several methods in RootsTable and Isolate const to support this change. Bug: v8:10454 Change-Id: I5f8eb873d8486b699460223dbe3454a5dcf1854f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280088 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68671}
-
- 29 Jun, 2020 1 commit
-
-
Jakob Kummerow authored
Relanding without changes, revert reason was fixed by: https://chromium-review.googlesource.com/c/v8/v8/+/2272564 Originally reviewed at: https://chromium-review.googlesource.com/c/v8/v8/+/2260566 Original description: RTTs are internally represented as Maps. To store supertype information, this patch introduces a WasmTypeInfo object, which is installed on Wasm objects' Maps and points at both the off-heap type information and the parent RTT. In this patch, rtt.sub always creates a fresh RTT. The canonicalization that the proposal requires will be implemented later. Bug: v8:7748 Change-Id: I7fd4986efa3153ac68037ec418ea617f3f7636e8 Tbr: ulan@chromium.org Tbr: tebbi@chromium.org Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2273123Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#68581}
-
- 26 Jun, 2020 2 commits
-
-
Shu-yu Guo authored
This reverts commit 04ce88ea. Reason for revert: TSAN failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/32135 Original change's description: > [wasm-gc] Implement rtt.sub > > RTTs are internally represented as Maps. To store supertype information, > this patch introduces a WasmTypeInfo object, which is installed on Wasm > objects' Maps and points at both the off-heap type information and the > parent RTT. > In this patch, rtt.sub always creates a fresh RTT. The canonicalization > that the proposal requires will be implemented later. > > Bug: v8:7748 > Change-Id: I8286dd11f520966155cd95c2bd844ec34fccd131 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2260566 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68564} TBR=ulan@chromium.org,jkummerow@chromium.org,tebbi@chromium.org Change-Id: I311732e1ced4de7a58b87d4a9b6056e0d62aa986 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7748 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270734Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#68567}
-
Jakob Kummerow authored
RTTs are internally represented as Maps. To store supertype information, this patch introduces a WasmTypeInfo object, which is installed on Wasm objects' Maps and points at both the off-heap type information and the parent RTT. In this patch, rtt.sub always creates a fresh RTT. The canonicalization that the proposal requires will be implemented later. Bug: v8:7748 Change-Id: I8286dd11f520966155cd95c2bd844ec34fccd131 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2260566 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#68564}
-