1. 09 Jun, 2021 1 commit
    • Dominik Inführ's avatar
      [heap] Optimize Heap::IsPendingAllocation · 9140d001
      Dominik Inführ authored
      IsPendingAllocation will now load the space from the object's page
      header first and then only check the object against the current LAB
      of that particular space. Previously we were looking up that object
      in the LABs of all spaces.
      
      This new design also makes it feasible to have one dedicated mutex for
      original_top/original_limit (respectively pending_object) for each
      space. This will reduce contention on the mutexes.
      
      Change-Id: I8e7636410259fd03b7970084bfbbaeadb2d8ba61
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2936606
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75054}
      9140d001
  2. 27 May, 2021 1 commit
    • Dominik Inführ's avatar
      [heap] Use base::SharedMutex in Heap::IsPendingAllocation · f2fd431a
      Dominik Inführ authored
      Use a read-write lock for protecting original_top, original_limit and
      pending_object for all spaces. This way Heap::IsPendingAllocation is
      always guaranteed to read a consistent top/limit-pair and also the
      last values for those fields.
      
      The main thread will acquire an exclusive lock to update those fields.
      Concurrent Turbofan threads will use shared locks to read them.
      
      This may be quite expensive on the Turbofan-side, so landing this CL
      should help us figure out how big of a regression this simple fix would
      be. For main thread execution performance is supposed to be okay, since
      this is only used on the allocation slow path.
      
      Bug: v8:11778, chromium:1213266
      Change-Id: I9464f53fd50057ec2540ab5b79f74ee52a5d7500
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903143
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74814}
      f2fd431a
  3. 06 May, 2021 1 commit
  4. 11 Nov, 2020 1 commit
  5. 14 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Change OffThreadIsolate to LocalIsolate · f1589bbe
      Leszek Swirski authored
      This patch introduces a new LocalIsolate and LocalFactory, which use
      LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
      us to remove those classes, as well as the related OffThreadSpace,
      OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
      OffThreadLogger becomes LocalLogger.
      
      LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
      us to additionally remove the concept of "Finish" and "Publish" that the
      OffThreadIsolate had, and allows us to internalize strings directly with
      the newly-concurrent string table (where the implementation can now move
      to FactoryBase).
      
      This patch also removes the off-thread support from the deserializer
      entirely, as well as removing the LocalIsolateWrapper which allowed
      run-time distinction between Isolate and OffThreadIsolate. LocalHeap
      doesn't support the reservation model used by the deserializer, and we
      will likely move the deserializer to use LocalIsolate unconditionally
      once we figure out the details of how to do this.
      
      Bug: chromium:1011762
      
      Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69397}
      f1589bbe
  6. 04 Aug, 2020 1 commit
    • Dominik Inführ's avatar
      Reland "[heap] Refactor allocation observer in AllocationCounter" · 9fff9a73
      Dominik Inführ authored
      This is a reland of b354e344
      
      This CL adds 3 fixes:
      
      * Unprotect code object before creating filler
      * Allows AllocationObserver::Step to add more AllocationObservers
      * Update limit in NewSpace::UpdateLinearAllocationArea
      
      Original change's description:
      > [heap] Refactor allocation observer in AllocationCounter
      >
      > Moves accounting of allocation observers into the AllocationCounter
      > class. This CL removes top_on_previous_step_ for counters that are
      > increased regularly in the slow path of the allocation functions.
      >
      > AdvanceAllocationObservers() informs the AllocationCounter about
      > allocated bytes, InvokeAllocationObservers() needs to be invoked when
      > an allocation step is reached. NextBytes() returns the number of bytes
      > until the next AllocationObserver::Step needs to run.
      >
      > Bug: v8:10315
      > Change-Id: I8b6eb8719ab032d44ee0614d2a0f2645bfce9df6
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320650
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69170}
      
      Bug: v8:10315
      Change-Id: I89ab4d5069a234a293471f613dab16b47d8fff89
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332805Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69216}
      9fff9a73
  7. 03 Aug, 2020 1 commit
  8. 01 Aug, 2020 1 commit
    • Dominik Inführ's avatar
      Revert "[heap] Refactor allocation observer in AllocationCounter" · ef603a9e
      Dominik Inführ authored
      This reverts commit b354e344.
      
      Reason for revert: Clusterfuzz found issues with this CL.
      
      Original change's description:
      > [heap] Refactor allocation observer in AllocationCounter
      > 
      > Moves accounting of allocation observers into the AllocationCounter
      > class. This CL removes top_on_previous_step_ for counters that are
      > increased regularly in the slow path of the allocation functions.
      > 
      > AdvanceAllocationObservers() informs the AllocationCounter about
      > allocated bytes, InvokeAllocationObservers() needs to be invoked when
      > an allocation step is reached. NextBytes() returns the number of bytes
      > until the next AllocationObserver::Step needs to run.
      > 
      > Bug: v8:10315
      > Change-Id: I8b6eb8719ab032d44ee0614d2a0f2645bfce9df6
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320650
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69170}
      
      TBR=ulan@chromium.org,dinfuehr@chromium.org
      
      Change-Id: Icd713207bfb2085421fd82009be24a0211ae86da
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10315
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332667Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69187}
      ef603a9e
  9. 31 Jul, 2020 1 commit
    • Dominik Inführ's avatar
      [heap] Refactor allocation observer in AllocationCounter · b354e344
      Dominik Inführ authored
      Moves accounting of allocation observers into the AllocationCounter
      class. This CL removes top_on_previous_step_ for counters that are
      increased regularly in the slow path of the allocation functions.
      
      AdvanceAllocationObservers() informs the AllocationCounter about
      allocated bytes, InvokeAllocationObservers() needs to be invoked when
      an allocation step is reached. NextBytes() returns the number of bytes
      until the next AllocationObserver::Step needs to run.
      
      Bug: v8:10315
      Change-Id: I8b6eb8719ab032d44ee0614d2a0f2645bfce9df6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320650
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69170}
      b354e344
  10. 05 May, 2020 1 commit
  11. 28 Apr, 2020 1 commit