1. 10 Feb, 2021 1 commit
    • Georg Neis's avatar
      Revert "[compiler] Directly read PropertyCells" · 87df0b7e
      Georg Neis authored
      This reverts commit 42cd9eb7.
      
      Reason for revert: Clusterfuzz issues, e.g.
      https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
      
      Original change's description:
      > [compiler] Directly read PropertyCells
      >
      > Main changes:
      >
      > - Introduce a new broker data kind kBackgroundSerialized for objects
      >   that can be serialized in the background (when direct reads are on).
      >   (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
      >   in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
      > - Make PropertyCell use that new kind.
      > - Introduce a bottleneck in runtime code for changes to PropertyCells
      >   and make sure that a certain protocol is followed that allows
      >   concurrent reads from the background thread.
      > - Improve interface of PropertyCell in various ways.
      >
      > Bug: v8:7790
      > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72586}
      
      TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
      
      Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
      Bug: v8:7790
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72619}
      87df0b7e
  2. 09 Feb, 2021 3 commits
  3. 29 Jan, 2021 1 commit
  4. 28 Jan, 2021 1 commit
    • Marja Hölttä's avatar
      Revert "Reland [super] Store home object in Context instead of JSFunction" · 12f8ac47
      Marja Hölttä authored
      This reverts commit f6450b97.
      
      Reason for revert: ClusterFuzz bugs
      
      Original change's description:
      > Reland [super] Store home object in Context instead of JSFunction
      >
      > 1) Computed property keys (esp functions in them) shouldn't be inside
      > the object literal scope.
      >
      > 2) I was using an imprecise "maybe uses super" and storing it to
      > preparse data. This won't fly, since it pollutes sister scopes and
      > leads to confusion wrt whether an object literal needs a home object
      > or not. Made it precise (mostly cancelling changes in the original CL).
      >
      > 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
      > this_function (which made it used) -> inconsistent scopes between
      > parsing and preparsing.
      >
      > 4) MultipleEntryBlockContextScope was messing up the accumulator
      >
      > Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
      >
      > This saves memory (the home object doesn't need to be stored for each
      > method, but only once per class) and hopefully makes the home object
      > a constant in the optimized code.
      >
      > Detailed documentation of the changes:
      > https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
      >
      > Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
      > Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Marja Hölttä <marja@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72169}
      
      TBR=marja@chromium.org,leszeks@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9237
      Bug: chromium:1167918
      Bug: chromium:1167981
      Bug: chromium:1167988
      Bug: chromium:1168055
      Bug: chromium:1171195
      Bug: chromium:1171600
      Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72391}
      12f8ac47
  5. 20 Jan, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Begin porting ScopeInfo to Torque · ecaac329
      Seth Brenith authored
      This change adds Torque field definitions for ScopeInfo and begins to
      use the Torque-generated accessors in some places. It does not change
      the in-memory layout of ScopeInfo.
      
      Torque compiler changes:
      
      - Fix an issue where the parser created constexpr types for classes
        based on the class name rather than the `generates` clause. This meant
        that generated accessors referred to the imaginary type HashTable
        rather than the real C++ type FixedArray.
      - Don't pass Isolate* through the generated runtime functions that
        implement Torque macros. Maybe we'll need it eventually, but we don't
        right now and it complicates a lot of things.
      - Don't emit `kSomeFieldOffset` if some_field has an unknown offset.
        Instead, emit a member function `SomeFieldOffset()` which fetches the
        slice for some_field and returns its offset.
      - Emit an `AllocatedSize()` member function for classes which have
        complex length expressions. It fetches the slice for the last field
        and performs the multiply&add to compute the total object size.
      - Emit field accessors for fields with complex length expressions, using
        the new offset functions.
      - Fix a few minor bugs where Torque can write uncompilable code.
      
      With this change, most code still treats ScopeInfo like a FixedArray, so
      I would like to follow up with some additional changes:
      
      1. Generate a GC visitor for ScopeInfo and use it
      2. Generate accessors for struct-typed fields (indexed or otherwise),
         and use them
      3. Get rid of the FixedArray-style get and set accessors; use
         TaggedField::load and similar instead
      4. Inherit from HeapObject rather than FixedArrayBase to remove the
         unnecessary `length` field
      
      After that, there will only be one ugly part left: initialization. I
      think it's possible to generate a factory function that takes a bunch of
      iterator parameters and returns a fully-formed, verifiably correct
      ScopeInfo instance, but doing so is more complicated than the four
      mostly-mechanical changes listed above.
      
      Bug: v8:7793
      Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72187}
      ecaac329
  6. 19 Jan, 2021 3 commits
  7. 18 Jan, 2021 2 commits
    • Seth Brenith's avatar
      [heap-profiler][torque] Report types of all internal objects · e3f8b5db
      Seth Brenith authored
      Heap-profiler changes:
      
      Currently, a whole lot of types are all reported as just "system" in
      heap snapshots. With this change, we can use Torque-generated macro
      lists to easily report type names such as "system / BytecodeArray".
      Those objects still show up in a single category named "(system)" in the
      dev tools UI, so they don't clutter the output. For V8 developers or
      anybody who is interested in an extra-detailed view, this change also
      includes a runtime flag that instructs V8 to upgrade nodes of type
      kHidden to type kNative. After a snapshot is collected with this flag
      enabled, the dev tools UI then shows each internal object type
      separately.
      
      Torque changes:
      
      Currently, Torque emits several macro lists containing pairs of
      (ClassName, CLASS_NAME_TYPE) which can be used to associate instance
      types with Torque class names. However, some Torque classes are not
      included in any of these three lists. In cases like the heap profiler,
      it would be nice to easily generate a complete list including every
      instance type, so this CL includes two changes:
      
      - Include classes in TORQUE_INSTANCE_CHECKERS_MULTIPLE_FULLY_DEFINED
        even if they're not marked `extern`. I'm not sure what exactly we
        were hoping to accomplish in filtering by extern-ness, but it's
        simpler not to and slightly reduces clutter in a couple of files that
        use that macro list.
      - Add a fourth macro list for the previously-ignored category: classes
        which have their own instance type (are not `abstract`), and have
        subtypes, but do not have their fields defined in Torque. This list
        contains just a single item (HashTable), but I like the consistency of
        generating the full set of lists.
      
      Change-Id: Ib24953e12ed13ce353206bbec23a52d8f684dfcc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610172
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72138}
      e3f8b5db
    • Marja Hölttä's avatar
      [super] Store home object in Context instead of JSFunction · 4d5b878b
      Marja Hölttä authored
      This saves memory (the home object doesn't need to be stored for each
      method, but only once per class) and hopefully makes the home object
      a constant in the optimized code.
      
      Detailed documentation of the changes:
      https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
      
      Bug: v8:9237
      Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72137}
      4d5b878b
  8. 16 Dec, 2020 2 commits
  9. 08 Dec, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Make runtime macros inlinable · 6b5f4208
      Seth Brenith authored
      Currently, all runtime C++ code generated for Torque macros all goes
      into a single .cc file and corresponding header. This is simple, but
      limits how we can use that generated code. For example, field accessors
      are generally expected to be inlinable at compilation time (not relying
      on LTO).
      
      This change updates the Torque compiler to output runtime C++ code into
      the same *-tq-inl.inc files that contain implementations of member
      functions for generated classes. All Torque macros transitively called
      from the top-level macros are included in the same file, to avoid any
      need for these generated files to #include each other. These macros are
      emitted within per-file namespaces to avoid multiple-definition build
      failures.
      
      Bug: v8:7793
      Change-Id: Ic9ac3748c5020a05304773a66d7249efdc56b080
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565067
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71664}
      6b5f4208
  10. 30 Nov, 2020 1 commit
    • Seth Brenith's avatar
      Require the first three fields of ScopeInfo to be present · 2bbf3333
      Seth Brenith authored
      ScopeInfo objects generally start with three fields: flags, parameter
      count, and local variable count. But a single read-only ScopeInfo
      instance has none of those fields. This is the empty ScopeInfo, which is
      used for contexts that don't correspond to any scope (the native context
      and contexts for builtin functions). Since there is only ever a single
      instance of the empty ScopeInfo, the memory savings of omitting these
      fields is trivial, and we can simplify logic somewhat by including them.
      Rather than checking for length to be zero, this change introduces a new
      flag indicating that a ScopeInfo instance is the empty one.
      
      On its own, this change doesn't provide a whole lot of value. However,
      it sets us up for two further improvements, which are consistent with
      the goals outlined in [1]:
      
      1. We should fully describe ScopeInfo fields in Torque. Getting rid of
      the requirement to check for emptiness would substantially simplify the
      indexed field expressions.
      
      2. ScopeInfo shouldn't inherit from FixedArray, and shouldn't begin with
      a `length` field when the length can be computed from the other fields.
      This would save a small amount of heap memory and avoid any possibility
      of a mismatch between the two ways of computing the length.
      
      [1] https://docs.google.com/document/d/1tiGK7_lubxPHnInI2vscUwMHfadn8gIEa1apmI8HxR4/edit#heading=h.n63k76b3zfwa
      
      Bug: v8:8952
      Change-Id: I018127698a5d91fb2a91684bc3aec2e27ee27c41
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2561598Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71500}
      2bbf3333
  11. 20 Nov, 2020 1 commit
  12. 19 Nov, 2020 1 commit
  13. 16 Nov, 2020 1 commit
  14. 13 Nov, 2020 1 commit
  15. 11 Nov, 2020 1 commit
  16. 10 Nov, 2020 2 commits
  17. 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
  18. 05 Nov, 2020 2 commits
  19. 03 Nov, 2020 1 commit
  20. 02 Nov, 2020 1 commit
  21. 29 Oct, 2020 1 commit
  22. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      This CL splits the class definitions per .tq file, to realize the
      following relationship:
      A class defined in src/objects/foo.tq has a C++ definition in
      src/objects/foo.h. Torque then generates:
      
      - torque-generated/src/objects/foo-tq.inc
        An include file (no proper header) to be included in src/objects/foo.h
        containing the Torque-generated C++ class definition.
      
      - torque-generated/src/objects/foo-tq-inl.inc
        An include file (no proper header) to be included in
        src/objects/foo-inl.h containing inline function definitions.
      
      - torque-generated/src/objects/foo-tq.cc
        A source file including src/objects/foo-inl.h that contains non-inline
        function definitions.
      
      Advantages of this approach:
      - Avoid big monolithic headers and preserve the work that went into
        splitting objects.h
      - Moving a definition to Torque keeps everything in the same place
        from a C++ viewpoint, including a fully Torque-generated C++ class
        definition.
      - The Torque-generated include files do not need to be independent
        headers, necessary includes or forward declarations can just be added
        to the headers that include them.
      
      Drive-by changes:
      A bunch of definitions and files had to be moved or created to realize
      a consistent 1:1 relationship between .tq files and C++ headers.
      
      
      Bug: v8:7793
      TBR: hpayer@chromium.org
      Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  23. 27 Oct, 2020 1 commit
  24. 22 Oct, 2020 2 commits
  25. 16 Oct, 2020 2 commits
    • Igor Sheludko's avatar
      [runtime] Fix sorted order of DescriptorArray entries · 518d67ad
      Igor Sheludko authored
      ... and add respective regression tests.
      
      This CL also adds similar regression tests for TransitionArray but it
      doesn't have the same issue as DescriptorArray.
      
      Bug: chromium:1133527
      Change-Id: I668a90f126d76af0a39816ce8697cb29bc65d01b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465833Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70570}
      518d67ad
    • Pierre Langlois's avatar
      [heap] Make maximum regular code object size a runtime value. · f4376ec8
      Pierre Langlois authored
      Executable V8 pages include 3 reserved OS pages: one for the writable
      header and two as guards. On systems with 64k OS pages, the amount of
      allocatable space left for objects can then be quite smaller than the
      page size, only 64k for each 256k page.
      
      This means regular code objects cannot be larger than 64k, while the
      maximum regular object size is fixed to 128k, half of the page size. As
      a result code object never reach this limit and we can end up filling
      regular pages with few large code objects.
      
      To fix this, we change the maximum code object size to be runtime value,
      set to half of the allocatable space per page. On systems with 64k OS
      pages, the limit will be 32k.
      
      Alternatively, we could increase the V8 page size to 512k on Arm64 linux
      so we wouldn't waste code space. However, systems with 4k OS pages are
      more common, and those with 64k pages tend to have more memory available
      so we should be able to live with it.
      
      Bug: v8:10808
      Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Cr-Commit-Position: refs/heads/master@{#70569}
      f4376ec8
  26. 15 Oct, 2020 1 commit
  27. 13 Oct, 2020 1 commit
  28. 08 Oct, 2020 1 commit
  29. 07 Oct, 2020 2 commits
    • Camillo Bruni's avatar
      [runtime][module] Change Module::Reset order · 7be8692e
      Camillo Bruni authored
      Allocating in the right spot leaves the Module in an invalid state.
      Do allocations before resetting a module.
      
      Drive-by-fix: make module verification check failures easier to debug.
      
      Bug: v8:10985
      Change-Id: I6fc32c96441958755bfb32b3004e1bb616dc7d98
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452533Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70369}
      7be8692e
    • 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