1. 01 Feb, 2021 1 commit
  2. 11 Nov, 2020 1 commit
  3. 29 Oct, 2020 1 commit
  4. 01 Oct, 2020 1 commit
  5. 21 Sep, 2020 1 commit
    • Ulan Degenbaev's avatar
      [heap] Fix tracking of code pages for V8 stack unwinder (attempt #2) · b24d8de1
      Ulan Degenbaev authored
      When a compaction space allocates a new code page, that pages needs to
      be added to the Isolate::code_pages_ array used for stack unwinding.
      Since the array is owned by the main thread, compaction thread cannot
      directly modify it. Because of that code pages are added upon merging
      of the compaction space to the main space in MergeLocalSpace.
      
      The bug was that all code pages coming from the compaction space
      were added to the code_pages_ array. However, some of the pages are
      not newly allocated but merely borrowed from the main space.
      
      This CL keeps track of all newly allocated paged by a compaction space.
      
      Bug: v8:10900
      Change-Id: Iff3ff5d608df60fb752d2e0ffc29e51f2d967936
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418718
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70023}
      b24d8de1
  6. 18 Sep, 2020 2 commits
    • Maya Lekova's avatar
      Revert "[heap] Fix tracking of code pages for V8 stack unwinder" · 027e5888
      Maya Lekova authored
      This reverts commit af5f437c.
      
      Reason for revert: Seems to break TSAN - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33286?
      
      Original change's description:
      > [heap] Fix tracking of code pages for V8 stack unwinder
      > 
      > When a compaction space allocates a new code page, that pages needs to
      > be added to the Isolate::code_pages_ array used for stack unwinding.
      > Since the array is owned by the main thread, compaction thread cannot
      > directly modify it. Because of that code pages are added upon merging
      > of the compaction space to the main spage in MergeLocalSpace.
      > 
      > The bug was that all code pages coming from the compaction space
      > were added to the code_pages_ array. However, some of the pages are
      > not newly allocated but merely borrowed from the main space.
      > 
      > This CL introduces a new page flag for marking pages that are borrowed
      > during compaction and skips them in MergeLocalSpace.
      > 
      > Bug: v8:10900
      > Change-Id: I786dc5747bd7c785ae58dfd8b841c00774efb15e
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416500
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69992}
      
      TBR=ulan@chromium.org,jkummerow@chromium.org,dinfuehr@chromium.org
      
      Change-Id: I13f8b64014750af95423166152dc9bee8cec12d0
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10900
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418395Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69993}
      027e5888
    • Ulan Degenbaev's avatar
      [heap] Fix tracking of code pages for V8 stack unwinder · af5f437c
      Ulan Degenbaev authored
      When a compaction space allocates a new code page, that pages needs to
      be added to the Isolate::code_pages_ array used for stack unwinding.
      Since the array is owned by the main thread, compaction thread cannot
      directly modify it. Because of that code pages are added upon merging
      of the compaction space to the main spage in MergeLocalSpace.
      
      The bug was that all code pages coming from the compaction space
      were added to the code_pages_ array. However, some of the pages are
      not newly allocated but merely borrowed from the main space.
      
      This CL introduces a new page flag for marking pages that are borrowed
      during compaction and skips them in MergeLocalSpace.
      
      Bug: v8:10900
      Change-Id: I786dc5747bd7c785ae58dfd8b841c00774efb15e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416500Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69992}
      af5f437c
  7. 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
  8. 13 Aug, 2020 2 commits
  9. 12 Aug, 2020 1 commit
  10. 11 Aug, 2020 1 commit
  11. 05 Aug, 2020 1 commit
    • Dominik Inführ's avatar
      [heap] Remove PagedSpace::SizeOfObjects · ab8368df
      Dominik Inführ authored
      PagedSpace::SizeOfObjects() then returns exactly the same value as
      PagedSpace::Size(). SizeOfObjects() used to deduct the current LAB,
      however this is now more difficult with local heaps. Accessing the
      main thread LAB from concurrent threads causes a data race. Also
      LocalHeaps have their own LAB, which should be deducted as well to be
      uniform with the main thread. However this would be tricky and expensive.
      The simpler solution is to do not deduct the main thread LAB anymore.
      
      Bug: v8:10315
      Change-Id: I3c47e1a65caca9395737251aa694b295e78c7fb5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336090
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69245}
      ab8368df
  12. 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
  13. 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
  14. 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
  15. 27 Jul, 2020 1 commit
  16. 24 Jul, 2020 1 commit
  17. 14 Jul, 2020 1 commit
  18. 13 Jul, 2020 1 commit
  19. 03 Jul, 2020 1 commit
  20. 02 Jul, 2020 2 commits
  21. 18 Jun, 2020 1 commit
    • Dan Elphick's avatar
      Reland "[heap] Make ReadOnlySpace use bump pointer allocation" · 32b911f9
      Dan Elphick authored
      This reverts commit f78d69fa.
      
      With https://chromium-review.googlesource.com/c/v8/v8/+/2243216,
      incorrect MemoryChunk::FromHeapObject uses are now fixed.
      
      Original change's description:
      > Revert "[heap] Make ReadOnlySpace use bump pointer allocation"
      > 
      > This reverts commit 81c34968 and also
      > 490f3580 which depends on the former.
      > 
      > Reason for revert: Break CFI tests in chromium https://ci.chromium.org/p/chromium/builders/ci/Linux%20CFI/17438
      > Original change's description:
      > > [heap] Make ReadOnlySpace use bump pointer allocation
      > >
      > > This changes ReadOnlySpace to no longer be a PagedSpace but instead it
      > > is now a BaseSpace. BasicSpace is a new base class that Space inherits
      > > from and which has no allocation methods and does not dictate how the
      > > pages should be held.
      > >
      > > ReadOnlySpace unlike Space holds its pages as a
      > > std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses
      > > BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and
      > > cannot be held in a heap::List. This is desirable since with pointer
      > > compression we would like to remap these pages to different memory
      > > addresses which would be impossible with a heap::List.
      > >
      > > Since ReadOnlySpace no longer uses most of the code from the other
      > > Spaces it makes sense to simplify its memory allocation to use a simple
      > > bump pointer and always allocate a new page whenever an allocation
      > > exceeds the remaining space on the final page.
      > >
      > > Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060
      > > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#68137}
      > 
      > TBR=ulan@chromium.org,delphick@chromium.org
      > 
      > # Not skipping CQ checks because original CL landed > 1 day ago.
      > 
      > Change-Id: I68c9834872e55eb833be081f8ff99b786bfa9894
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232552
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68211}
      
      TBR=ulan@chromium.org,delphick@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: Id5b3cce41b5dec1dca816c05848d183790b1cc05
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250254Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68407}
      32b911f9
  22. 09 Jun, 2020 1 commit
  23. 05 Jun, 2020 1 commit
    • Dan Elphick's avatar
      Revert "[heap] Make ReadOnlySpace use bump pointer allocation" · f78d69fa
      Dan Elphick authored
      This reverts commit 81c34968 and also
      490f3580 which depends on the former.
      
      Reason for revert: Break CFI tests in chromium https://ci.chromium.org/p/chromium/builders/ci/Linux%20CFI/17438
      Original change's description:
      > [heap] Make ReadOnlySpace use bump pointer allocation
      >
      > This changes ReadOnlySpace to no longer be a PagedSpace but instead it
      > is now a BaseSpace. BasicSpace is a new base class that Space inherits
      > from and which has no allocation methods and does not dictate how the
      > pages should be held.
      >
      > ReadOnlySpace unlike Space holds its pages as a
      > std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses
      > BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and
      > cannot be held in a heap::List. This is desirable since with pointer
      > compression we would like to remap these pages to different memory
      > addresses which would be impossible with a heap::List.
      >
      > Since ReadOnlySpace no longer uses most of the code from the other
      > Spaces it makes sense to simplify its memory allocation to use a simple
      > bump pointer and always allocate a new page whenever an allocation
      > exceeds the remaining space on the final page.
      >
      > Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68137}
      
      TBR=ulan@chromium.org,delphick@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: I68c9834872e55eb833be081f8ff99b786bfa9894
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232552
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68211}
      f78d69fa
  24. 04 Jun, 2020 1 commit
  25. 03 Jun, 2020 2 commits
    • Dan Elphick's avatar
      [heap] Make ReadOnlySpace use bump pointer allocation · 81c34968
      Dan Elphick authored
      This changes ReadOnlySpace to no longer be a PagedSpace but instead it
      is now a BaseSpace. BasicSpace is a new base class that Space inherits
      from and which has no allocation methods and does not dictate how the
      pages should be held.
      
      ReadOnlySpace unlike Space holds its pages as a
      std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses
      BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and
      cannot be held in a heap::List. This is desirable since with pointer
      compression we would like to remap these pages to different memory
      addresses which would be impossible with a heap::List.
      
      Since ReadOnlySpace no longer uses most of the code from the other
      Spaces it makes sense to simplify its memory allocation to use a simple
      bump pointer and always allocate a new page whenever an allocation
      exceeds the remaining space on the final page.
      
      Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68137}
      81c34968
    • Dan Elphick's avatar
      [heap] Move MemoryChunk fields to BasicMemoryChunk · ae489dec
      Dan Elphick authored
      This moves several fields that will be needed by ReadOnlySpace pages
      when it stops using MemoryChunk into BasicMemoryChunk.
      
      Additionally AllocationStats is moved from spaces.h into
      allocation-stats.h.
      
      Bug: v8:10473, v8:10454
      Change-Id: I76a66565a260126e629bd7588a5418267dfa8423
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228722Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68134}
      ae489dec
  26. 20 May, 2020 1 commit
  27. 19 May, 2020 1 commit
  28. 18 May, 2020 2 commits
  29. 15 May, 2020 1 commit
  30. 14 May, 2020 1 commit