1. 13 May, 2020 1 commit
  2. 12 May, 2020 1 commit
  3. 08 May, 2020 2 commits
  4. 07 May, 2020 1 commit
  5. 06 May, 2020 1 commit
  6. 28 Apr, 2020 1 commit
  7. 20 Apr, 2020 1 commit
  8. 08 Apr, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] remove HasIndexedField and cleanup internal class lists · 25808bbc
      Tobias Tebbi authored
      The two refactorings are somewhat orthogonal, but intersect at the
      class and instance type list generation, which is why it's easier to
      put them in one CL.
      
      For the removal of HasIndexedField, the removal is motivated by the
      fact that is no longer necessary, and that using a flag to store this
      kind of information is hacky.
      
      For the class list changes, this is a cleanup in that we no longer
      generate third-order macros, but instead normal macro lists.
      There is a functional change and bug-fix in that we no longer include
      abstract classes in lists that refer to instance types or maps. It's
      still somewhat broken though, so I can't test abstract internal classes
      yet, though. Coming in a follow-up CL.
      
      TBR=ulan@chromium.org
      
      Bug: v8:7793
      Change-Id: Ided8591370570ca3810d7991f53177ca32e03048
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108034
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67056}
      25808bbc
  9. 09 Mar, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] Generate GC object visitors for Torque classes · 4f4d73f2
      Tobias Tebbi authored
      In the process:
      
      * Augment C++-generated Torque classes with SizeFor methods to
        calculate size of instances.
      
      * Add a new "@generateBodyDescriptor" annotation that causes Torque to
        generate C++ BodyDescriptors code that can be used to visit objects
        compatible with existing V8 mechanisms, e.g. GC
      
      * Fully automate C++ macro machinery so that adding non-extern Torque
        class doesn't require any C++ changes, including ensuring generation
        of instance types and proper boilerplate for validators and
        printers.
      
      * Make handling of @export a true annotation, allowing the modifier to
        be used on class declarations.
      
      * Add functionality such that classes with the @export annotation are
        available to be used from C++. Field accessors for exported classes
        are public and factory methods are generated to create instances of
        the objects from C++.
      
      * Change the Torque compiler such that Non-exported classes implicitly
        have the @generateBodyDescriptor annotation added and causes both
        verifiers and printers to be generated.
      
      * Switch non-extern Torque classes from using existing Struct-based
        machinery to being first-class classes that support more existing
        Torque class features.
      
      Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66621}
      4f4d73f2
  10. 24 Feb, 2020 1 commit
  11. 18 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Assign CoverageInfo an instance type · 6ce65b96
      Seth Brenith authored
      This allows CoverageInfo to be distinguished from other kinds of
      FixedArray at runtime. I also updated it to use untagged data since it
      only stores ints, since that seems like the generally right thing to do
      (even though I doubt anybody allocates enough of these to notice the
      reduced GC work).
      
      Related Torque changes:
      - Allow structs containing untagged data to be used as class fields.
        This requires classifying them into the tagged or untagged sections of
        the class layout, and checking that their alignment requirements are
        met when stored in a packed array.
      - Generate a struct containing struct field offsets, so we can ensure
        that the layouts defined in Torque and C++ code match. Of course it
        would be nice to generate a lot more (indexed accessors, synchronized
        accessors, GC visitors, etc.), but we can't do it all at once.
      
      Change-Id: I29e2a2afe37e4805cd80e3a84ef9edfe7ca7bb6b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047399Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66318}
      6ce65b96
  12. 17 Feb, 2020 1 commit
  13. 12 Feb, 2020 1 commit
  14. 14 Jan, 2020 1 commit
  15. 10 Jan, 2020 1 commit
    • Seth Brenith's avatar
      [torque] move more bitfield definitions to Torque · 87c16da5
      Seth Brenith authored
      This change moves the definitions of the bitfield flags used by Symbol
      and Map to Torque. Symbol could directly follow the pattern established
      by SharedFunctionInfo, but Map required some other changes:
      - Until now, Torque bitfield definitions have required unsigned types. I
        thought that this would be the least-surprising behavior, since we
        never sign-extend when decoding bitfield values. However, I believe
        that the amount of churn involved in making ElementsKind be unsigned
        outweighs the benefit we were getting from this restriction (and
        similar difficulties are likely to arise in converting other bitfield
        structs to Torque), so this CL updates Torque to allow signed bitfield
        values.
      - If we try to make Map extend from all of the generated classes that
        define its flags, we end up with class sizing problems because some
        compilers only apply empty base class optimization to the first in a
        row of empty base classes. We could work around this issue by
        generating macros instead of classes, but I took this as an
        opportunity for a minor clean-up instead: rather than having bitfield
        definitions for several different bitfield structs all jumbled
        together in Map, they can be split up. I think this makes the code a
        little easier to follow, but if others disagree I'm happy to implement
        macro generation instead.
      
      Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65701}
      87c16da5
  16. 18 Nov, 2019 1 commit
  17. 15 Nov, 2019 1 commit
  18. 30 Oct, 2019 1 commit
  19. 24 Oct, 2019 1 commit
  20. 22 Oct, 2019 1 commit
  21. 17 Oct, 2019 1 commit
    • Toon Verwaest's avatar
      Reland^2 "[runtime] Move Context::native_context to the map" · 3cad6bf5
      Toon Verwaest authored
      This is a reland of c7c47c68.
      
      This makes TSAN happy in addition to:
      
      Previously I presumed that the context read from a frame in the profiler was
      a valid context. Turns out that on non-intel we're not guaranteed that the
      frame is properly set up. In the case we looked at, the profiler took a
      sample right before writing the frame marker indicating a builtin frame,
      causing the "context" pointer from that frame to be a bytecode array. Since
      we'll read random garbage on the stack as a possible context pointer, I made
      the code reading the native context from it a little more defensive.
      
      Bug: v8:9860
      Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org
      
      Original change's description:
      > [runtime] Move Context::native_context to the map
      >
      > Remove the native context slot from contexts by making context maps
      > native-context-specific. Now we require 2 loads to go from a context to the
      > native context, but we have 1 field fewer to store when creating contexts.
      >
      > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64296}
      
      Change-Id: I4d0ab4cbbb23a9ae616407f17ef8f35a0b68ddb4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864654
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64360}
      3cad6bf5
  22. 16 Oct, 2019 2 commits
    • Sathya Gunasekaran's avatar
      Revert "Reland "[runtime] Move Context::native_context to the map"" · 38301e7b
      Sathya Gunasekaran authored
      This reverts commit c7c47c68.
      
      Reason for revert: breaks TSAN
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738
      
      Original change's description:
      > Reland "[runtime] Move Context::native_context to the map"
      > 
      > This is a reland of f05bae1e
      > 
      > Previously I presumed that the context read from a frame in the profiler was
      > a valid context. Turns out that on non-intel we're not guaranteed that the
      > frame is properly set up. In the case we looked at, the profiler took a
      > sample right before writing the frame marker indicating a builtin frame,
      > causing the "context" pointer from that frame to be a bytecode array. Since
      > we'll read random garbage on the stack as a possible context pointer, I made
      > the code reading the native context from it a little more defensive.
      > 
      > Bug: v8:9860
      > 
      > Original change's description:
      > > [runtime] Move Context::native_context to the map
      > >
      > > Remove the native context slot from contexts by making context maps
      > > native-context-specific. Now we require 2 loads to go from a context to the
      > > native context, but we have 1 field fewer to store when creating contexts.
      > >
      > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
      > > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#64296}
      > 
      > Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64314}
      
      TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com
      
      Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9860
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64316}
      38301e7b
    • Toon Verwaest's avatar
      Reland "[runtime] Move Context::native_context to the map" · c7c47c68
      Toon Verwaest authored
      This is a reland of f05bae1e
      
      Previously I presumed that the context read from a frame in the profiler was
      a valid context. Turns out that on non-intel we're not guaranteed that the
      frame is properly set up. In the case we looked at, the profiler took a
      sample right before writing the frame marker indicating a builtin frame,
      causing the "context" pointer from that frame to be a bytecode array. Since
      we'll read random garbage on the stack as a possible context pointer, I made
      the code reading the native context from it a little more defensive.
      
      Bug: v8:9860
      
      Original change's description:
      > [runtime] Move Context::native_context to the map
      >
      > Remove the native context slot from contexts by making context maps
      > native-context-specific. Now we require 2 loads to go from a context to the
      > native context, but we have 1 field fewer to store when creating contexts.
      >
      > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64296}
      
      Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64314}
      c7c47c68
  23. 15 Oct, 2019 2 commits
  24. 08 Oct, 2019 1 commit
  25. 01 Oct, 2019 1 commit
  26. 23 Sep, 2019 1 commit
  27. 16 Sep, 2019 1 commit
  28. 12 Sep, 2019 1 commit
  29. 11 Sep, 2019 2 commits
  30. 09 Sep, 2019 1 commit
    • Ulan Degenbaev's avatar
      Reland x6 [arraybuffer] Rearchitect backing store ownership · b6b7de0d
      Ulan Degenbaev authored
      This reverts commit 9da34831
      
      Original change's description:
      > "Reland x4 [arraybuffer] Rearchitect backing store ownership"
      >
      > This is a reland of bc33f5ae
      >
      > Contributed by titzer@chromium.org
      >
      > Original change's description:
      > > [arraybuffer] Rearchitect backing store ownership
      > >
      > > This CL completely rearchitects the ownership of array buffer backing stores,
      > > consolidating ownership into a {BackingStore} C++ object that is tracked
      > > throughout V8 using unique_ptr and shared_ptr where appropriate.
      > >
      > > Overall, lifetime management is simpler and more explicit. The numerous
      > > ways that array buffers were initialized have been streamlined to one
      > > Attach() method on JSArrayBuffer. The array buffer tracker in the
      > > GC implementation now manages std::shared_ptr<BackingStore> pointers,
      > > and the construction and destruction of the BackingStore object itself
      > > handles the underlying page or embedder-allocated memory.
      > >
      > > The embedder API remains unchanged for now. We use the
      > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
      > > keep the backing store alive properly, even in the case of aliases
      > > from live heap objects. Thus the embedder has a lower chance of making
      > > a mistake. Long-term, we should move the embedder to a model where they
      > > manage backing stores using shared_ptr to an opaque backing store object.
      >
      > TBR=yangguo@chromium.org
      >
      > BUG=v8:9380,v8:9221,chromium:986318
      >
      > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
      > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      
      > Cr-Commit-Position: refs/heads/master@{#63041}
      
      TBR=yangguo@chromium.org
      
      Change-Id: I3cc4bb80081c662b1751234bc16a821c20e744be
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792166
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63617}
      b6b7de0d
  31. 03 Sep, 2019 1 commit
  32. 30 Aug, 2019 1 commit
    • Ulan Degenbaev's avatar
      Revert "Reland x5 [arraybuffer] Rearchitect backing store ownership" · 9da34831
      Ulan Degenbaev authored
      This reverts commit 62e16830.
      
      Reason for revert: it will be relanded after branch
      
      Original change's description:
      > Reland x5 [arraybuffer] Rearchitect backing store ownership
      > 
      > This reverts commit 8fdb2387.
      > 
      > Original change's description:
      > > "Reland x4 [arraybuffer] Rearchitect backing store ownership"
      > >
      > > This is a reland of bc33f5ae
      > >
      > > Contributed by titzer@chromium.org
      > >
      > > Original change's description:
      > > > [arraybuffer] Rearchitect backing store ownership
      > > >
      > > > This CL completely rearchitects the ownership of array buffer backing stores,
      > > > consolidating ownership into a {BackingStore} C++ object that is tracked
      > > > throughout V8 using unique_ptr and shared_ptr where appropriate.
      > > >
      > > > Overall, lifetime management is simpler and more explicit. The numerous
      > > > ways that array buffers were initialized have been streamlined to one
      > > > Attach() method on JSArrayBuffer. The array buffer tracker in the
      > > > GC implementation now manages std::shared_ptr<BackingStore> pointers,
      > > > and the construction and destruction of the BackingStore object itself
      > > > handles the underlying page or embedder-allocated memory.
      > > >
      > > > The embedder API remains unchanged for now. We use the
      > > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
      > > > keep the backing store alive properly, even in the case of aliases
      > > > from live heap objects. Thus the embedder has a lower chance of making
      > > > a mistake. Long-term, we should move the embedder to a model where they
      > > > manage backing stores using shared_ptr to an opaque backing store object.
      > >
      > > TBR=yangguo@chromium.org
      > >
      > > BUG=v8:9380,v8:9221,chromium:986318
      > >
      > > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
      > > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#63041}
      > 
      > TBR=yangguo@chromium.org,clemensh@chromium.org,mstarzinger@chromium.org
      > 
      > Change-Id: Iba55c7ab71e5642b5cb6aeb699d6fc9cf9061486
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771795
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63461}
      
      TBR=ulan@chromium.org,mlippautz@chromium.org
      
      Change-Id: Id8f67a68ab398032eb2975b1b24ee125394d9c4b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776095Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63471}
      9da34831
  33. 29 Aug, 2019 1 commit
    • Ulan Degenbaev's avatar
      Reland x5 [arraybuffer] Rearchitect backing store ownership · 62e16830
      Ulan Degenbaev authored
      This reverts commit 8fdb2387.
      
      Original change's description:
      > "Reland x4 [arraybuffer] Rearchitect backing store ownership"
      >
      > This is a reland of bc33f5ae
      >
      > Contributed by titzer@chromium.org
      >
      > Original change's description:
      > > [arraybuffer] Rearchitect backing store ownership
      > >
      > > This CL completely rearchitects the ownership of array buffer backing stores,
      > > consolidating ownership into a {BackingStore} C++ object that is tracked
      > > throughout V8 using unique_ptr and shared_ptr where appropriate.
      > >
      > > Overall, lifetime management is simpler and more explicit. The numerous
      > > ways that array buffers were initialized have been streamlined to one
      > > Attach() method on JSArrayBuffer. The array buffer tracker in the
      > > GC implementation now manages std::shared_ptr<BackingStore> pointers,
      > > and the construction and destruction of the BackingStore object itself
      > > handles the underlying page or embedder-allocated memory.
      > >
      > > The embedder API remains unchanged for now. We use the
      > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
      > > keep the backing store alive properly, even in the case of aliases
      > > from live heap objects. Thus the embedder has a lower chance of making
      > > a mistake. Long-term, we should move the embedder to a model where they
      > > manage backing stores using shared_ptr to an opaque backing store object.
      >
      > TBR=yangguo@chromium.org
      >
      > BUG=v8:9380,v8:9221,chromium:986318
      >
      > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
      > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63041}
      
      TBR=yangguo@chromium.org,clemensh@chromium.org,mstarzinger@chromium.org
      
      Change-Id: Iba55c7ab71e5642b5cb6aeb699d6fc9cf9061486
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771795Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63461}
      62e16830
  34. 20 Aug, 2019 1 commit
  35. 12 Aug, 2019 1 commit
  36. 05 Aug, 2019 1 commit
    • Ulan Degenbaev's avatar
      Revert ""Reland x4 [arraybuffer] Rearchitect backing store ownership"" · 8fdb2387
      Ulan Degenbaev authored
      This reverts commit 5611f70b.
      
      Reason for revert: flaky tests: v8:9588, v8:9587
      
      Original change's description:
      > "Reland x4 [arraybuffer] Rearchitect backing store ownership"
      > 
      > This is a reland of bc33f5ae
      > 
      > Contributed by titzer@chromium.org
      > 
      > Original change's description:
      > > [arraybuffer] Rearchitect backing store ownership
      > >
      > > This CL completely rearchitects the ownership of array buffer backing stores,
      > > consolidating ownership into a {BackingStore} C++ object that is tracked
      > > throughout V8 using unique_ptr and shared_ptr where appropriate.
      > >
      > > Overall, lifetime management is simpler and more explicit. The numerous
      > > ways that array buffers were initialized have been streamlined to one
      > > Attach() method on JSArrayBuffer. The array buffer tracker in the
      > > GC implementation now manages std::shared_ptr<BackingStore> pointers,
      > > and the construction and destruction of the BackingStore object itself
      > > handles the underlying page or embedder-allocated memory.
      > >
      > > The embedder API remains unchanged for now. We use the
      > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
      > > keep the backing store alive properly, even in the case of aliases
      > > from live heap objects. Thus the embedder has a lower chance of making
      > > a mistake. Long-term, we should move the embedder to a model where they
      > > manage backing stores using shared_ptr to an opaque backing store object.
      > 
      > TBR=yangguo@chromium.org
      > 
      > BUG=v8:9380,v8:9221,chromium:986318
      > 
      > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
      > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63041}
      
      TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,clemensh@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9380, v8:9221, chromium:986318
      Change-Id: Ic7381239f4e90d0c437b7e47a5ac6e8bce60f882
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1736747Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63081}
      8fdb2387