1. 31 Aug, 2020 1 commit
    • Jake Hughes's avatar
      [heap] Add object start bitmap for conservative stack scanning · 5f6aa2e5
      Jake Hughes authored
      With conservative stack scanning enabled, a snapshot of the call stack
      upon entry to GC will be used to determine part of the root-set. When
      the collector walks the stack, it looks at each value and determines
      whether it could be a potential on-heap object pointer. However, unlike
      with Handles, these on-stack pointers aren't guaranteed to point to the
      start of the object: the compiler may decide hide these pointers, and
      create interior pointers in C++ frames which the GC doesn't know about.
      
      The solution to this is to include an object start bitmap in the header
      of each page. Each bit in the bitmap represents a word in the page
      payload which is set when an object is allocated. This means that when
      the collector finds an arbitrary potential pointer into the page, it can
      walk backwards through the bitmap until it finds the relevant object's
      base pointer. To prevent the bitmap becoming stale after compaction, it
      is rebuilt during object sweeping.
      
      This is experimental, and currently only works with inline allocation
      disabled, and single generational collection.
      
      Bug: v8:10614
      Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195
      Commit-Queue: Anton Bikineev <bikineev@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69615}
      5f6aa2e5
  2. 28 Aug, 2020 3 commits
  3. 27 Aug, 2020 1 commit
  4. 26 Aug, 2020 3 commits
  5. 25 Aug, 2020 7 commits
  6. 24 Aug, 2020 1 commit
  7. 21 Aug, 2020 2 commits
    • Ulan Degenbaev's avatar
      Reland "[heap] Add concurrent marking write barrier" · e0ad32ce
      Ulan Degenbaev authored
      This is a reland of 1dd7f3a9
      
      Original change's description:
      > [heap] Add concurrent marking write barrier
      > 
      > A LocalHeap creates and owns an instance of MarkingBarrier. A pointer to
      > the marking barrier is set to a thread_local variable for a quick access.
      > 
      > WriteBarrier::MarkingSlow fetches the thread_local variable and invokes
      > the write barrier if it is set. Otherwise, it invokes the main thread
      > heap()->marking_barrier().
      > 
      > Each marking barrier has its own local marking worklist that is
      > published during scavenge (for updating pointers) and at finalization
      > of incremental marking.
      > 
      > Typed-slot recording does not work yet because it is not thread-safe.
      > It will be fixed in a subsequent CL.
      > 
      > Bug: v8:10315
      > Change-Id: I221a906436cd91e7405a253ce0eb06cf68046f2c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354809
      > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69448}
      
      Bug: v8:10315
      Change-Id: I155bb0aadd53a5333672fb085b33d8da86f3f336
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364509Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69517}
      e0ad32ce
    • Dominik Inführ's avatar
      [heap] Lock Mutex in ForceEvacuationCandidate · 480128ef
      Dominik Inführ authored
      Lock the mutex of PagedSpace before invoking FreeLinearAllocationArea().
      
      Bug: v8:10315
      Change-Id: If96b9b8b72932590daf3d548be41c20796ed524f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2367857Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69515}
      480128ef
  8. 20 Aug, 2020 3 commits
  9. 19 Aug, 2020 3 commits
  10. 18 Aug, 2020 6 commits
  11. 17 Aug, 2020 1 commit
  12. 14 Aug, 2020 3 commits
  13. 13 Aug, 2020 4 commits
  14. 12 Aug, 2020 2 commits
    • Santiago Aboy Solanes's avatar
      [compiler] Have one unique PersistentHandles container · 64828a54
      Santiago Aboy Solanes authored
      The (now unique)PersistentHandles container follows this path:
        1) PersistentHandles created via PersistentHandlesScope inside of
           CompilationHandleScope
        2) Owned by OptimizedCompilationInfo
        3) Owned by JSHeapBroker
        4) Owned by the broker's LocalHeap
        5) Back to the broker for a brief moment (after tearing down the
          LocalHeap as part of exiting LocalHeapScope)
        6) Back to OptimizedCompilationInfo when exiting the LocalHeapScope.
      
      There is a special case in GenerateCodeForTesting where the JSHeapBroker
      will not be retired in that same method. In this case, we need to
      re-attach the PersistentHandles container to the JSHeapBroker.
      
      The identity map of the persistent & canonical handles also gets passed
      around like the persistent handles. The only difference is that is
      created in the CanonicalHandleScope (i.e step 1) is different).
      
      Bug: v8:7790
      Change-Id: I2da77a7e08f3fd360a46b606c5fbda08c0af27df
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332811
      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>
      Cr-Commit-Position: refs/heads/master@{#69360}
      64828a54
    • Dominik Inführ's avatar
      [heap] Remove ArrayBufferTracker · 3c0fb324
      Dominik Inführ authored
      ArrayBufferTracker was superseded by ArrayBufferList and
      ArrayBufferSweeper. Now that ArrayBufferSweeper is used in production,
      we can remove the unused ArrayBufferTracker mechanism.
      
      Bug: v8:10064
      Change-Id: I479169c76b6c5c634672024f77e689bb64a36504
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339105Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69351}
      3c0fb324