1. 16 Oct, 2020 1 commit
    • Dominik Inführ's avatar
      Reland "[compiler, heap] Create LocalHeap outside of ExecuteJob" · de914c75
      Dominik Inführ authored
      This is a reland of 44708a5b
      
      Original change's description:
      > [compiler, heap] Create LocalHeap outside of ExecuteJob
      >
      > Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
      > pass its reference as argument to ExecuteJob. This allows us to create
      > LocalHeap differently for the main and background thread, e.g. by
      > passing an additional argument to the constructor in the future.
      > It will be required in the future anyways when the main thread will
      > have its own LocalHeap/LocalIsolate.
      >
      > Extending the scope of LocalHeap, also made
      > HandleBase::IsDereferenceAllowed more precise and uncovered two
      > potential issues: heap accesses in
      > OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
      > with --code-comments.
      >
      > LocalHeap can now be created in the parked state. Also fixed a data
      > race with LocalHeap's destructor publishing write barrier entries
      > without holding the lock.
      >
      > Bug: v8:10315
      > Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70521}
      
      Bug: v8:10315
      Change-Id: I4c459fd6dfb98d47fc9941c0dc6864bf5a1d2d3e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474788Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70560}
      de914c75
  2. 15 Oct, 2020 2 commits
    • Georg Neis's avatar
      Revert "[compiler, heap] Create LocalHeap outside of ExecuteJob" · 04c85d7c
      Georg Neis authored
      This reverts commit 44708a5b.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33692
      
      Original change's description:
      > [compiler, heap] Create LocalHeap outside of ExecuteJob
      >
      > Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
      > pass its reference as argument to ExecuteJob. This allows us to create
      > LocalHeap differently for the main and background thread, e.g. by
      > passing an additional argument to the constructor in the future.
      > It will be required in the future anyways when the main thread will
      > have its own LocalHeap/LocalIsolate.
      >
      > Extending the scope of LocalHeap, also made
      > HandleBase::IsDereferenceAllowed more precise and uncovered two
      > potential issues: heap accesses in
      > OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
      > with --code-comments.
      >
      > LocalHeap can now be created in the parked state. Also fixed a data
      > race with LocalHeap's destructor publishing write barrier entries
      > without holding the lock.
      >
      > Bug: v8:10315
      > Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70521}
      
      TBR=ulan@chromium.org,neis@chromium.org,leszeks@chromium.org,solanes@chromium.org,dinfuehr@chromium.org
      
      Change-Id: I9dd1f8ca6237d5716b6d8938cef0ee3f642f3166
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10315
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474118Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70522}
      04c85d7c
    • Dominik Inführ's avatar
      [compiler, heap] Create LocalHeap outside of ExecuteJob · 44708a5b
      Dominik Inführ authored
      Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
      pass its reference as argument to ExecuteJob. This allows us to create
      LocalHeap differently for the main and background thread, e.g. by
      passing an additional argument to the constructor in the future.
      It will be required in the future anyways when the main thread will
      have its own LocalHeap/LocalIsolate.
      
      Extending the scope of LocalHeap, also made
      HandleBase::IsDereferenceAllowed more precise and uncovered two
      potential issues: heap accesses in
      OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
      with --code-comments.
      
      LocalHeap can now be created in the parked state. Also fixed a data
      race with LocalHeap's destructor publishing write barrier entries
      without holding the lock.
      
      Bug: v8:10315
      Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70521}
      44708a5b
  3. 13 Oct, 2020 1 commit
  4. 08 Oct, 2020 1 commit
  5. 07 Oct, 2020 2 commits
    • Santiago Aboy Solanes's avatar
      [compiler] Use StringToDouble without allocation · af00c261
      Santiago Aboy Solanes authored
      We had a way to do string to double without allocation that we were
      using on StringData. Reuse that on StringRef for Strings that can
      access the heap.
      
      BUg: v8:7790
      Change-Id: I30e6dace3fbf05eb8672ff1bad46f6c6d6fe1d6d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2450013Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70384}
      af00c261
    • 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
  6. 06 Oct, 2020 1 commit
  7. 05 Oct, 2020 3 commits
    • 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
    • Santiago Aboy Solanes's avatar
      [cleanup] Clean up SYNCHRONIZED_ACCESSORS macro naming and its uses · c7c8472d
      Santiago Aboy Solanes authored
      We can use tag dispatching to distinguish between the synchronized and
      non-synchronized accessors. Also eliminated the need of adding explicit
      "synchronized" in the name when using the macros.
      
      As a note, we currently have one case of using both relaxed and
      synchronized accessors (Map::instance_descriptors).
      
      Cleaned up:
       * BytecodeArray::source_position_table
       * Code::code_data_container
       * Code::source_position_table
       * FunctionTemplateInfo::call_code
       * Map::instance_descriptors
       * Map::layout_descriptor
       * SharedFunctionInfo::function_data
      
      Bug: v8:7790
      Change-Id: I5a502f4b2df6addb6c45056e77061271012c7d90
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424130
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70306}
      c7c8472d
    • Leszek Swirski's avatar
      [identity-map] Remove double-lookups in IdentityMap · 4e7c99ab
      Leszek Swirski authored
      Remove the pattern of calling 'Find' followed by 'Set' for IdentityMap,
      with a single 'FindOrInsert' that explicitly returns whether an existing
      entry was found, or the entry was inserted. This replaces 'Get', which
      would return either an initialised or uninitialised entry (and callers
      would rely on default initialisation to check this).
      
      Also replace 'Set' with 'Insert', which explicitly requires that the
      element didn't exist before. This matches expectations where it was
      used (where those weren't replaced wholesale with 'FindOrInsert'), and
      makes the naming consistent with 'FindOrInsert'.
      
      Change-Id: I8fb76f4ac14fb92b88474965aafb1ace5fb79145
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2443135
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70300}
      4e7c99ab
  8. 30 Sep, 2020 2 commits
  9. 29 Sep, 2020 2 commits
  10. 28 Sep, 2020 2 commits
  11. 24 Sep, 2020 1 commit
  12. 17 Sep, 2020 2 commits
  13. 16 Sep, 2020 1 commit
  14. 15 Sep, 2020 4 commits
  15. 11 Sep, 2020 4 commits
  16. 10 Sep, 2020 7 commits
  17. 09 Sep, 2020 1 commit
    • Georg Neis's avatar
      [turbofan] Make fewer assumptions about children of a serialized object · fb481bc9
      Georg Neis authored
      1) Strengthen the ObjectData::As* cast methods to check that the kind
      is kSerializedHeapObject, because otherwise the data object is not
      a subclass instance and the cast is invalid.
      
      2) Fix errors revealed by (1) and pave way for moving away from
      serialization. These changes are mechanical except for a needed
      refactoring of ContextRef::previous.
      
      Details regarding (2):
      
      Change (1) revealed a large number of places where we incorrectly casted
      object data. This went unnoticed so far because in the end we accessed
      the object through the corresponding ObjectRef interface which did the
      right thing depending on the data kind.
      
      These bugs were introduced when kUnserializedReadOnlyHeapObject was
      added, but they also affect the new kNeverSerializedHeapObject and would
      become show stoppers as we move more objects to the latter kind. The CL
      fixes all the issues that I found except one:
      
      There's still one place left where we assume a particular subclass
      instance for now (marked with a TODO). This is not a bug at the moment
      but will cause CHECK failures once we move the corresponding object type
      to never-serialized. A rewrite of map serialization might be needed to
      resolve that.
      
      Note:
      With the changes in (2) we lose some type safety in the implementation
      of the *Data classes. With some extra work that could be avoided.
      However, I think it's not worth it because (i) these classes are
      expected to be removed (and in the meantime to not change much), and
      (ii) their wrapper *Ref classes still ensure type safety.
      
      Bug: v8:7790
      Change-Id: I9a5d03fa2f61e03c9c0ab4ac7f9869603d5be1d9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398537Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Auto-Submit: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69775}
      fb481bc9
  18. 08 Sep, 2020 3 commits