1. 23 Feb, 2022 1 commit
  2. 18 Feb, 2022 1 commit
    • Michael Achenbach's avatar
      Revert "[shared-struct] Prototype JS shared structs" · c1078b5e
      Michael Achenbach authored
      This reverts commit 1025bf26.
      
      Reason for revert: https://crbug.com/v8/12645
      
      Original change's description:
      > [shared-struct] Prototype JS shared structs
      >
      > Unlike the Stage 1 proposal, for simplicity the prototype does not add
      > any new syntax, instead opting for exposing a SharedStructType
      > constructor which takes an array of field names. This type constructor
      > returns constructors for shared structs.
      >
      > Shared structs can be shared across Isolates, are fixed layout, have no
      > prototype, have no .constructor, and can only store primitives and
      > other shared structs.
      >
      > The initial prototype does not have TurboFan support.
      >
      > Bug: v8:12547
      > Change-Id: I23bdd819940b42139692bcdb53d372099b0d4426
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3390643
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79156}
      
      Bug: v8:12547
      Change-Id: I44f2b8bb7487b4d39ba1282585e0b2282501230f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3474676
      Auto-Submit: Michael Achenbach <machenbach@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Owners-Override: Michael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79170}
      c1078b5e
  3. 17 Feb, 2022 1 commit
  4. 07 Feb, 2022 1 commit
    • Thibaud Michaud's avatar
      [wasm] Fix typing of stack-switching wrappers · 08b3da7f
      Thibaud Michaud authored
      - Suspender.suspendOnReturnedPromise expects a function with type
      [ti*]->[externref] and returns a function with the same type.
      - Suspender.returnPromiseOnSuspend expects a function with type
      [ti*]->[to] and returns a function with type [ti*]->[externref].
      
      Changes:
      - Check the wrapped function's return types
      - Skip type checking of return types when importing a wrapper (and
      assert that the return type is externref)
      - Add special case for WebAssembly.Function.type of a
      WasmExportedFunction: it currently returns the signature declared by
      the module. Change the return type to externref if this is a
      stack-switching export.
      
      Bug: v8:12191
      Change-Id: I6619c306e9613825ad1b021cb3400d73cd684656
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3435190Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78973}
      08b3da7f
  5. 25 Jan, 2022 1 commit
  6. 27 Dec, 2021 1 commit
    • Patrick Thier's avatar
      [turbofan] Introduce Type for Class Constructors · b014d0ba
      Patrick Thier authored
      This CL splits the TF type for JSFunction into CallableFunction and
      ClassConstructor. This differentiation allows us to lower calls to the
      CallFunction Builtin only for functions that we can actually call.
      Class Constructors are special, as they are callable but should raise
      an exception if called.
      By not lowering class constructors to calls to CallFunction (but the
      more generall Call) builtin, we can remove the checks for class
      constructors from CallFunction (in a follow-up CL).
      
      Bug: chromium:1262750
      Change-Id: I399967eb03b2f20d2dcb67aef2243b32c9d3174e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350457Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78445}
      b014d0ba
  7. 18 Nov, 2021 1 commit
  8. 02 Nov, 2021 1 commit
  9. 28 Oct, 2021 1 commit
    • Tobias Tebbi's avatar
      Reland "[turbofan] extend type asserts to cover all JS types" · 392078fb
      Tobias Tebbi authored
      This is a reland of 45227ffd
      Differences:
      - Handle one more flags conflict in variants.py.
      - Disallow %VerifyType without --concurrent-recompilation.
      
      Original change's description:
      > [turbofan] extend type asserts to cover all JS types
      >
      > Extend type assertions to all types covering JavaScript values.
      > This is achieved by allocating type representations on the heap using
      > newly defined HeapObject subclasses. To allocate these in the compiler,
      > we disable concurrent compilation for the --assert-types flag for now.
      >
      > Fix two type errors that came up with the existing tests:
      > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
      >    OtherObject.
      > 2. OperationTyper::NumberToString(Type) can type the result as the
      >    HeapConstant Factory::zero_string(). However, NumberToString does
      >    not always produce this string. To avoid regressions, the CL keeps
      >    the HeapConstant type and changes the runtime and builtin code to
      >    always produce the canonical "0" string.
      >
      > A few tests were failing because they check for truncations to work
      > and prevent deoptimization. However, AssertType nodes destroy all
      > truncations (which is by design), so these tests are incompatible
      > and now disabled for the assert_types variant.
      >
      > Drive-by fix: a few minor Torque issues that came up.
      >
      > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77565}
      
      Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035
      Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77596}
      392078fb
  10. 27 Oct, 2021 2 commits
    • Maya Lekova's avatar
      Revert "[turbofan] extend type asserts to cover all JS types" · 54f90462
      Maya Lekova authored
      This reverts commit 45227ffd.
      
      Reason for revert: Breaks on gc_stress mode, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/35988/overview
      
      Original change's description:
      > [turbofan] extend type asserts to cover all JS types
      >
      > Extend type assertions to all types covering JavaScript values.
      > This is achieved by allocating type representations on the heap using
      > newly defined HeapObject subclasses. To allocate these in the compiler,
      > we disable concurrent compilation for the --assert-types flag for now.
      >
      > Fix two type errors that came up with the existing tests:
      > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
      >    OtherObject.
      > 2. OperationTyper::NumberToString(Type) can type the result as the
      >    HeapConstant Factory::zero_string(). However, NumberToString does
      >    not always produce this string. To avoid regressions, the CL keeps
      >    the HeapConstant type and changes the runtime and builtin code to
      >    always produce the canonical "0" string.
      >
      > A few tests were failing because they check for truncations to work
      > and prevent deoptimization. However, AssertType nodes destroy all
      > truncations (which is by design), so these tests are incompatible
      > and now disabled for the assert_types variant.
      >
      > Drive-by fix: a few minor Torque issues that came up.
      >
      > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77565}
      
      Change-Id: Ia779a11fc811846194c7a8d1e40b372b265e7ea4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247034
      Auto-Submit: Maya Lekova <mslekova@chromium.org>
      Owners-Override: Maya Lekova <mslekova@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#77566}
      54f90462
    • Tobias Tebbi's avatar
      [turbofan] extend type asserts to cover all JS types · 45227ffd
      Tobias Tebbi authored
      Extend type assertions to all types covering JavaScript values.
      This is achieved by allocating type representations on the heap using
      newly defined HeapObject subclasses. To allocate these in the compiler,
      we disable concurrent compilation for the --assert-types flag for now.
      
      Fix two type errors that came up with the existing tests:
      1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
         OtherObject.
      2. OperationTyper::NumberToString(Type) can type the result as the
         HeapConstant Factory::zero_string(). However, NumberToString does
         not always produce this string. To avoid regressions, the CL keeps
         the HeapConstant type and changes the runtime and builtin code to
         always produce the canonical "0" string.
      
      A few tests were failing because they check for truncations to work
      and prevent deoptimization. However, AssertType nodes destroy all
      truncations (which is by design), so these tests are incompatible
      and now disabled for the assert_types variant.
      
      Drive-by fix: a few minor Torque issues that came up.
      
      Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77565}
      45227ffd
  11. 08 Oct, 2021 1 commit
  12. 29 Sep, 2021 1 commit
  13. 14 Sep, 2021 2 commits
  14. 29 Jul, 2021 1 commit
  15. 17 Jun, 2021 1 commit
  16. 19 May, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Use kAssumeMemoryFence in two critical ref creation spots · 1e2b9c5e
      Jakob Gruber authored
      Using kAssumeMemoryFence works around the fact that the graph stores
      handles (and not refs). The assumption is that any handle inserted
      into the graph is safe to read; but we don't preserve the reason why
      it is safe to read. Thus we must over-approximate here and assume the
      existence of a memory fence.
      
      Note this is only valid if all spots that insert handles into the
      graph ensure that the handle can safely be read.
      
      In the future, we should consider having the graph store ObjectRefs or
      ObjectData pointer instead, which would make new ref construction here
      unnecessary.
      
      Bug: v8:7790,chromium:1209798
      Change-Id: Ic22340ea9f34a24be530a3c62c8309d25e108f3f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902742Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74653}
      1e2b9c5e
  17. 18 May, 2021 1 commit
  18. 17 May, 2021 1 commit
  19. 04 May, 2021 1 commit
  20. 04 Mar, 2021 1 commit
  21. 02 Mar, 2021 1 commit
  22. 09 Feb, 2021 1 commit
  23. 04 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      [literals] Add a dedicated regexp boilerplate type · e79b841b
      Jakob Gruber authored
      ... and mark it as never-serialized wrt turbofan serialization.
      
      Until this CL, the JSRegExp type was used as both for plain
      user-visible regexp objects, and for internal regexp boilerplate
      descriptions. Boilerplates are special: they are never exposed to the
      user, they are only referenced from the feedback vector, they are
      immutable.
      
      To clarify this distinction, this CL introduces a dedicated struct
      type RegExpBoilerplateDescription to hold the regexp boilerplate
      description.
      
      This makes Turbofan serialization simpler: boilerplates can be
      accessed through direct reads since they are immutable. TF has no
      special requirements on JSRegExp objects (it never reads into these
      objects) and thus serializing only the references as a JSObjectRef is
      fine.
      
      Bug: v8:7790
      Change-Id: I33b337fcfcf861a02bc6be6d0c6311d07cf05718
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656257Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72522}
      e79b841b
  24. 19 Jan, 2021 1 commit
  25. 15 Jan, 2021 1 commit
  26. 11 Jan, 2021 1 commit
  27. 16 Dec, 2020 2 commits
  28. 20 Nov, 2020 1 commit
  29. 10 Nov, 2020 2 commits
  30. 09 Nov, 2020 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] allow exported classes with custom C++ class" · bd75b0ba
      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: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71048}
      bd75b0ba
  31. 05 Nov, 2020 2 commits
  32. 02 Nov, 2020 1 commit
  33. 07 Oct, 2020 1 commit
    • Leszek Swirski's avatar
      Reland^4 "[serializer] Allocate during deserialization" · 3c508b38
      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: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70366}
      3c508b38
  34. 05 Oct, 2020 1 commit
    • Adam Klein's avatar
      Revert "Reland^3 "[serializer] Allocate during deserialization"" · a10ec2be
      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: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70328}
      a10ec2be
  35. 02 Oct, 2020 1 commit
    • Leszek Swirski's avatar
      Reland^3 "[serializer] Allocate during deserialization" · 3f4e9bbe
      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: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70288}
      3f4e9bbe