1. 08 Mar, 2021 1 commit
  2. 19 Feb, 2021 1 commit
  3. 20 Nov, 2020 1 commit
  4. 16 Nov, 2020 1 commit
  5. 16 Oct, 2020 1 commit
  6. 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
  7. 05 Oct, 2020 2 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
  8. 02 Oct, 2020 3 commits
    • 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
    • Clemens Backes's avatar
      Revert "Reland^2 "[serializer] Allocate during deserialization"" · a81da102
      Clemens Backes authored
      This reverts commit c4a062a9.
      
      Reason for revert: TSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33504
      
      Original change's description:
      > Reland^2 "[serializer] Allocate during deserialization"
      >
      > This is a reland of 28a30c57
      > which was a reland of 5d7a29c9
      >
      > The crashes were from calling RegisterDeserializerFinished on a null
      > Isolate pointer, for a deserializer that was never initialised
      > (specifically, ReadOnlyDeserializer when ROHeap is shared).
      >
      > Original change's description:
      > > Reland "[serializer] Allocate during deserialization"
      > >
      > > This is a reland of 5d7a29c9
      > >
      > > This reland shuffles around the order of checks in Heap::AllocateRawWith
      > > to not check the new space addresses until it's known that this is a new
      > > space allocation. This fixes an UBSan failure during read-only space
      > > deserialization, which happens before the new space is initialized.
      > >
      > > It also fixes some issues discovered by --stress-snapshot, around
      > > serializing ThinStrings (which are now elided as part of serialization),
      > > handle counts (I bumped the maximum handle count in that check), and
      > > clearing map transitions (the map backpointer field needed a Smi
      > > uninitialized value check).
      > >
      > > Original change's description:
      > > > [serializer] Allocate during deserialization
      > > >
      > > > This patch removes the concept of reservations and a specialized
      > > > deserializer allocator, and instead makes the deserializer allocate
      > > > directly with the Heap's Allocate method.
      > > >
      > > > The major consequence of this is that the GC can now run during
      > > > deserialization, which means that:
      > > >
      > > >   a) Deserialized objects are visible to the GC, and
      > > >   b) Objects that the deserializer/deserialized objects point to can
      > > >      move.
      > > >
      > > > Point a) is mostly not a problem due to previous work in making
      > > > deserialized objects "GC valid", i.e. making sure that they have a valid
      > > > size before any subsequent allocation/safepoint. We now additionally
      > > > have to initialize the allocated space with a valid tagged value -- this
      > > > is a magic Smi value to keep "uninitialized" checks simple.
      > > >
      > > > Point b) is solved by Handlifying the deserializer. This involves
      > > > changing any vectors of objects into vectors of Handles, and any object
      > > > keyed map into an IdentityMap (we can't use Handles as keys because
      > > > the object's address is no longer a stable hash).
      > > >
      > > > Back-references can no longer be direct chunk offsets, so instead the
      > > > deserializer stores a Handle to each deserialized object, and the
      > > > backreference is an index into this handle array. This encoding could
      > > > be optimized in the future with e.g. a second pass over the serialized
      > > > array which emits a different bytecode for objects that are and aren't
      > > > back-referenced.
      > > >
      > > > Additionally, the slot-walk over objects to initialize them can no
      > > > longer use absolute slot offsets, as again an object may move and its
      > > > slot address would become invalid. Now, slots are walked as relative
      > > > offsets to a Handle to the object, or as absolute slots for the case of
      > > > root pointers. A concept of "slot accessor" is introduced to share the
      > > > code between these two modes, and writing the slot (including write
      > > > barriers) is abstracted into this accessor.
      > > >
      > > > Finally, the Code body walk is modified to deserialize all objects
      > > > referred to by RelocInfos before doing the RelocInfo walk itself. This
      > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
      > > > during a RelocInfo walk.
      > > >
      > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
      > > > size rather than byte size -- the size is expected to be tagged-aligned
      > > > anyway, so now we get an extra few bits in the size encoding.
      > > >
      > > > Bug: chromium:1075999
      > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
      > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#70229}
      > >
      > > Bug: chromium:1075999
      > > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70267}
      >
      > Tbr: jgruber@chromium.org,ulan@chromium.org
      > Bug: chromium:1075999
      > Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70279}
      
      TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org
      
      Change-Id: Ib2f01db4cd9b55639d6a4af971bda865edb45e84
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1075999
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445250Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70280}
      a81da102
    • Leszek Swirski's avatar
      Reland^2 "[serializer] Allocate during deserialization" · c4a062a9
      Leszek Swirski authored
      This is a reland of 28a30c57
      which was a reland of 5d7a29c9
      
      The crashes were from calling RegisterDeserializerFinished on a null
      Isolate pointer, for a deserializer that was never initialised
      (specifically, ReadOnlyDeserializer when ROHeap is shared).
      
      Original change's description:
      > Reland "[serializer] Allocate during deserialization"
      >
      > This is a reland of 5d7a29c9
      >
      > This reland shuffles around the order of checks in Heap::AllocateRawWith
      > to not check the new space addresses until it's known that this is a new
      > space allocation. This fixes an UBSan failure during read-only space
      > deserialization, which happens before the new space is initialized.
      >
      > It also fixes some issues discovered by --stress-snapshot, around
      > serializing ThinStrings (which are now elided as part of serialization),
      > handle counts (I bumped the maximum handle count in that check), and
      > clearing map transitions (the map backpointer field needed a Smi
      > uninitialized value check).
      >
      > Original change's description:
      > > [serializer] Allocate during deserialization
      > >
      > > This patch removes the concept of reservations and a specialized
      > > deserializer allocator, and instead makes the deserializer allocate
      > > directly with the Heap's Allocate method.
      > >
      > > The major consequence of this is that the GC can now run during
      > > deserialization, which means that:
      > >
      > >   a) Deserialized objects are visible to the GC, and
      > >   b) Objects that the deserializer/deserialized objects point to can
      > >      move.
      > >
      > > Point a) is mostly not a problem due to previous work in making
      > > deserialized objects "GC valid", i.e. making sure that they have a valid
      > > size before any subsequent allocation/safepoint. We now additionally
      > > have to initialize the allocated space with a valid tagged value -- this
      > > is a magic Smi value to keep "uninitialized" checks simple.
      > >
      > > Point b) is solved by Handlifying the deserializer. This involves
      > > changing any vectors of objects into vectors of Handles, and any object
      > > keyed map into an IdentityMap (we can't use Handles as keys because
      > > the object's address is no longer a stable hash).
      > >
      > > Back-references can no longer be direct chunk offsets, so instead the
      > > deserializer stores a Handle to each deserialized object, and the
      > > backreference is an index into this handle array. This encoding could
      > > be optimized in the future with e.g. a second pass over the serialized
      > > array which emits a different bytecode for objects that are and aren't
      > > back-referenced.
      > >
      > > Additionally, the slot-walk over objects to initialize them can no
      > > longer use absolute slot offsets, as again an object may move and its
      > > slot address would become invalid. Now, slots are walked as relative
      > > offsets to a Handle to the object, or as absolute slots for the case of
      > > root pointers. A concept of "slot accessor" is introduced to share the
      > > code between these two modes, and writing the slot (including write
      > > barriers) is abstracted into this accessor.
      > >
      > > Finally, the Code body walk is modified to deserialize all objects
      > > referred to by RelocInfos before doing the RelocInfo walk itself. This
      > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
      > > during a RelocInfo walk.
      > >
      > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
      > > size rather than byte size -- the size is expected to be tagged-aligned
      > > anyway, so now we get an extra few bits in the size encoding.
      > >
      > > Bug: chromium:1075999
      > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70229}
      >
      > Bug: chromium:1075999
      > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70267}
      
      Tbr: jgruber@chromium.org,ulan@chromium.org
      Bug: chromium:1075999
      Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70279}
      c4a062a9
  9. 01 Oct, 2020 2 commits
    • Zhi An Ng's avatar
      Revert "Reland "[serializer] Allocate during deserialization"" · c7c0e790
      Zhi An Ng authored
      This reverts commit 28a30c57.
      
      Reason for revert: Broke Test262 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/38638?
      
      Original change's description:
      > Reland "[serializer] Allocate during deserialization"
      >
      > This is a reland of 5d7a29c9
      >
      > This reland shuffles around the order of checks in Heap::AllocateRawWith
      > to not check the new space addresses until it's known that this is a new
      > space allocation. This fixes an UBSan failure during read-only space
      > deserialization, which happens before the new space is initialized.
      >
      > It also fixes some issues discovered by --stress-snapshot, around
      > serializing ThinStrings (which are now elided as part of serialization),
      > handle counts (I bumped the maximum handle count in that check), and
      > clearing map transitions (the map backpointer field needed a Smi
      > uninitialized value check).
      >
      > Original change's description:
      > > [serializer] Allocate during deserialization
      > >
      > > This patch removes the concept of reservations and a specialized
      > > deserializer allocator, and instead makes the deserializer allocate
      > > directly with the Heap's Allocate method.
      > >
      > > The major consequence of this is that the GC can now run during
      > > deserialization, which means that:
      > >
      > >   a) Deserialized objects are visible to the GC, and
      > >   b) Objects that the deserializer/deserialized objects point to can
      > >      move.
      > >
      > > Point a) is mostly not a problem due to previous work in making
      > > deserialized objects "GC valid", i.e. making sure that they have a valid
      > > size before any subsequent allocation/safepoint. We now additionally
      > > have to initialize the allocated space with a valid tagged value -- this
      > > is a magic Smi value to keep "uninitialized" checks simple.
      > >
      > > Point b) is solved by Handlifying the deserializer. This involves
      > > changing any vectors of objects into vectors of Handles, and any object
      > > keyed map into an IdentityMap (we can't use Handles as keys because
      > > the object's address is no longer a stable hash).
      > >
      > > Back-references can no longer be direct chunk offsets, so instead the
      > > deserializer stores a Handle to each deserialized object, and the
      > > backreference is an index into this handle array. This encoding could
      > > be optimized in the future with e.g. a second pass over the serialized
      > > array which emits a different bytecode for objects that are and aren't
      > > back-referenced.
      > >
      > > Additionally, the slot-walk over objects to initialize them can no
      > > longer use absolute slot offsets, as again an object may move and its
      > > slot address would become invalid. Now, slots are walked as relative
      > > offsets to a Handle to the object, or as absolute slots for the case of
      > > root pointers. A concept of "slot accessor" is introduced to share the
      > > code between these two modes, and writing the slot (including write
      > > barriers) is abstracted into this accessor.
      > >
      > > Finally, the Code body walk is modified to deserialize all objects
      > > referred to by RelocInfos before doing the RelocInfo walk itself. This
      > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
      > > during a RelocInfo walk.
      > >
      > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
      > > size rather than byte size -- the size is expected to be tagged-aligned
      > > anyway, so now we get an extra few bits in the size encoding.
      > >
      > > Bug: chromium:1075999
      > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70229}
      >
      > Bug: chromium:1075999
      > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70267}
      
      TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org
      
      Change-Id: Ieed68332ef6a7ad36db061e3f48be0f28673d7a2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1075999
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2441608Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70268}
      c7c0e790
    • Leszek Swirski's avatar
      Reland "[serializer] Allocate during deserialization" · 28a30c57
      Leszek Swirski authored
      This is a reland of 5d7a29c9
      
      This reland shuffles around the order of checks in Heap::AllocateRawWith
      to not check the new space addresses until it's known that this is a new
      space allocation. This fixes an UBSan failure during read-only space
      deserialization, which happens before the new space is initialized.
      
      It also fixes some issues discovered by --stress-snapshot, around
      serializing ThinStrings (which are now elided as part of serialization),
      handle counts (I bumped the maximum handle count in that check), and
      clearing map transitions (the map backpointer field needed a Smi
      uninitialized value check).
      
      Original change's description:
      > [serializer] Allocate during deserialization
      >
      > This patch removes the concept of reservations and a specialized
      > deserializer allocator, and instead makes the deserializer allocate
      > directly with the Heap's Allocate method.
      >
      > The major consequence of this is that the GC can now run during
      > deserialization, which means that:
      >
      >   a) Deserialized objects are visible to the GC, and
      >   b) Objects that the deserializer/deserialized objects point to can
      >      move.
      >
      > Point a) is mostly not a problem due to previous work in making
      > deserialized objects "GC valid", i.e. making sure that they have a valid
      > size before any subsequent allocation/safepoint. We now additionally
      > have to initialize the allocated space with a valid tagged value -- this
      > is a magic Smi value to keep "uninitialized" checks simple.
      >
      > Point b) is solved by Handlifying the deserializer. This involves
      > changing any vectors of objects into vectors of Handles, and any object
      > keyed map into an IdentityMap (we can't use Handles as keys because
      > the object's address is no longer a stable hash).
      >
      > Back-references can no longer be direct chunk offsets, so instead the
      > deserializer stores a Handle to each deserialized object, and the
      > backreference is an index into this handle array. This encoding could
      > be optimized in the future with e.g. a second pass over the serialized
      > array which emits a different bytecode for objects that are and aren't
      > back-referenced.
      >
      > Additionally, the slot-walk over objects to initialize them can no
      > longer use absolute slot offsets, as again an object may move and its
      > slot address would become invalid. Now, slots are walked as relative
      > offsets to a Handle to the object, or as absolute slots for the case of
      > root pointers. A concept of "slot accessor" is introduced to share the
      > code between these two modes, and writing the slot (including write
      > barriers) is abstracted into this accessor.
      >
      > Finally, the Code body walk is modified to deserialize all objects
      > referred to by RelocInfos before doing the RelocInfo walk itself. This
      > is because RelocInfoIterator uses raw pointers, so we cannot allocate
      > during a RelocInfo walk.
      >
      > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
      > size rather than byte size -- the size is expected to be tagged-aligned
      > anyway, so now we get an extra few bits in the size encoding.
      >
      > Bug: chromium:1075999
      > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70229}
      
      Bug: chromium:1075999
      Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70267}
      28a30c57
  10. 30 Sep, 2020 2 commits
    • Leszek Swirski's avatar
      Revert "[serializer] Allocate during deserialization" · 74f3665c
      Leszek Swirski authored
      This reverts commit 5d7a29c9.
      
      Reason for revert: UBSan -- https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/13100
      
      Original change's description:
      > [serializer] Allocate during deserialization
      >
      > This patch removes the concept of reservations and a specialized
      > deserializer allocator, and instead makes the deserializer allocate
      > directly with the Heap's Allocate method.
      >
      > The major consequence of this is that the GC can now run during
      > deserialization, which means that:
      >
      >   a) Deserialized objects are visible to the GC, and
      >   b) Objects that the deserializer/deserialized objects point to can
      >      move.
      >
      > Point a) is mostly not a problem due to previous work in making
      > deserialized objects "GC valid", i.e. making sure that they have a valid
      > size before any subsequent allocation/safepoint. We now additionally
      > have to initialize the allocated space with a valid tagged value -- this
      > is a magic Smi value to keep "uninitialized" checks simple.
      >
      > Point b) is solved by Handlifying the deserializer. This involves
      > changing any vectors of objects into vectors of Handles, and any object
      > keyed map into an IdentityMap (we can't use Handles as keys because
      > the object's address is no longer a stable hash).
      >
      > Back-references can no longer be direct chunk offsets, so instead the
      > deserializer stores a Handle to each deserialized object, and the
      > backreference is an index into this handle array. This encoding could
      > be optimized in the future with e.g. a second pass over the serialized
      > array which emits a different bytecode for objects that are and aren't
      > back-referenced.
      >
      > Additionally, the slot-walk over objects to initialize them can no
      > longer use absolute slot offsets, as again an object may move and its
      > slot address would become invalid. Now, slots are walked as relative
      > offsets to a Handle to the object, or as absolute slots for the case of
      > root pointers. A concept of "slot accessor" is introduced to share the
      > code between these two modes, and writing the slot (including write
      > barriers) is abstracted into this accessor.
      >
      > Finally, the Code body walk is modified to deserialize all objects
      > referred to by RelocInfos before doing the RelocInfo walk itself. This
      > is because RelocInfoIterator uses raw pointers, so we cannot allocate
      > during a RelocInfo walk.
      >
      > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
      > size rather than byte size -- the size is expected to be tagged-aligned
      > anyway, so now we get an extra few bits in the size encoding.
      >
      > Bug: chromium:1075999
      > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70229}
      
      TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org
      
      Change-Id: I2bd792a24861e8f54897e51522769b50f8f814e2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1075999
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440827
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70231}
      74f3665c
    • Leszek Swirski's avatar
      [serializer] Allocate during deserialization · 5d7a29c9
      Leszek Swirski authored
      This patch removes the concept of reservations and a specialized
      deserializer allocator, and instead makes the deserializer allocate
      directly with the Heap's Allocate method.
      
      The major consequence of this is that the GC can now run during
      deserialization, which means that:
      
        a) Deserialized objects are visible to the GC, and
        b) Objects that the deserializer/deserialized objects point to can
           move.
      
      Point a) is mostly not a problem due to previous work in making
      deserialized objects "GC valid", i.e. making sure that they have a valid
      size before any subsequent allocation/safepoint. We now additionally
      have to initialize the allocated space with a valid tagged value -- this
      is a magic Smi value to keep "uninitialized" checks simple.
      
      Point b) is solved by Handlifying the deserializer. This involves
      changing any vectors of objects into vectors of Handles, and any object
      keyed map into an IdentityMap (we can't use Handles as keys because
      the object's address is no longer a stable hash).
      
      Back-references can no longer be direct chunk offsets, so instead the
      deserializer stores a Handle to each deserialized object, and the
      backreference is an index into this handle array. This encoding could
      be optimized in the future with e.g. a second pass over the serialized
      array which emits a different bytecode for objects that are and aren't
      back-referenced.
      
      Additionally, the slot-walk over objects to initialize them can no
      longer use absolute slot offsets, as again an object may move and its
      slot address would become invalid. Now, slots are walked as relative
      offsets to a Handle to the object, or as absolute slots for the case of
      root pointers. A concept of "slot accessor" is introduced to share the
      code between these two modes, and writing the slot (including write
      barriers) is abstracted into this accessor.
      
      Finally, the Code body walk is modified to deserialize all objects
      referred to by RelocInfos before doing the RelocInfo walk itself. This
      is because RelocInfoIterator uses raw pointers, so we cannot allocate
      during a RelocInfo walk.
      
      As a drive-by, the VariableRawData bytecode is tweaked to use tagged
      size rather than byte size -- the size is expected to be tagged-aligned
      anyway, so now we get an extra few bits in the size encoding.
      
      Bug: chromium:1075999
      Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70229}
      5d7a29c9
  11. 27 Jul, 2020 1 commit
  12. 01 Jul, 2020 1 commit
  13. 11 Oct, 2019 1 commit
  14. 09 Jul, 2019 1 commit
  15. 03 Jul, 2019 1 commit
  16. 23 May, 2019 1 commit
  17. 20 May, 2019 1 commit
  18. 06 May, 2019 1 commit
  19. 03 May, 2019 1 commit
    • Sigurd Schneider's avatar
      Revert "Reland "[json] Speed up json parsing"" · 47fccbfd
      Sigurd Schneider authored
      This reverts commit bbd740f0.
      
      Reason for revert: blocks lkgr due to layout test failure:
      https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/31607
      
      Original change's description:
      > Reland "[json] Speed up json parsing"
      > 
      > This is a reland of b0c4a876
      > 
      > Original change's description:
      > > [json] Speed up json parsing
      > >
      > > - scan using raw data pointers + GC callback
      > > - scan using scanner tables
      > > - cap internalizing large string values
      > > - inline fast transitioning logic
      > >
      > > Fixes previous CL by moving AllowHeapAllocation to callers of
      > > ReportUnexpectedCharacter where needed to make it clear we need to exit.
      > >
      > > Tbr: ulan@chromium.org
      > > Change-Id: Icfbb7cd536e0fbe153f34acca5d0fab6b5453d71
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591778
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#61159}
      > 
      > Tbr: verwaest@chromium.org
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
      > Change-Id: Ic7d0057178c649fc45b8c8f4587ee9128e351515
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593292
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61179}
      
      TBR=ulan@chromium.org,ishell@google.com,verwaest@google.com,ishell@chromium.org,verwaest@chromium.org
      
      Change-Id: I3ae8f9ce8214bebe7fab9d87c5daf8cdfdb94199
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594438
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61194}
      47fccbfd
  20. 02 May, 2019 3 commits
  21. 30 Apr, 2019 4 commits
  22. 09 Jan, 2019 1 commit
  23. 26 Dec, 2018 1 commit
  24. 20 Dec, 2018 1 commit
  25. 29 Nov, 2018 2 commits
  26. 27 Nov, 2018 1 commit
  27. 22 Nov, 2018 1 commit
    • Shiyu Zhang's avatar
      Reland "Create a fast path to get migration target when updating map" · 69232ba6
      Shiyu Zhang authored
      This is a reland of 6ec90ece
      
      Original change's description:
      > Reland "Create a fast path to get migration target when updating map"
      >
      > This is a reland of c285380c
      >
      > Original change's description:
      > > Create a fast path to get migration target when updating map
      > >
      > > During map updating, store the pointer to new map in the
      > > raw_transitions slot of the old map that is deprecated from map
      > > transition tree. Thus, we can get the migration target directly
      > > instead of TryReplayPropertyTransitions when updating map.
      > >
      > > This can improve Speedometer2.0 Elm-TodoMVC case by ~5% on ATOM
      > > Chromebook and ~9% on big-core Ubuntu.
      > >
      > > Change-Id: I56f9ce5183bbdd567b964890f623ef0ceed9b7db
      > > Reviewed-on: https://chromium-review.googlesource.com/1233433
      > > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#56303}
      >
      > Change-Id: Idf0b7716b92a6a15bfe58721c2c34dbd02b31137
      > Reviewed-on: https://chromium-review.googlesource.com/c/1270261
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
      > Cr-Commit-Position: refs/heads/master@{#56588}
      
      Change-Id: Iad23455f66c83340430370be6670bac493c638a1
      Reviewed-on: https://chromium-review.googlesource.com/c/1309305
      Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57705}
      69232ba6
  28. 13 Nov, 2018 1 commit
  29. 05 Nov, 2018 1 commit