1. 16 May, 2022 1 commit
    • Nikolaos Papaspyrou's avatar
      heap: Recalculate the object start bitmap if needed · 36610bbd
      Nikolaos Papaspyrou authored
      This CL adds to the existing experimental implementation of the
      object start bitmap, that is evaluated as a mechanism for resolving
      inner pointers (behind the flag v8_enable_conservative_stack_scanning).
      
      It fixes method ObjectStartBitmap::FindBasePtr to ensure that the
      correct base pointer is returned, even if the bitmap is not fully
      populated (e.g., with object evacuation or inline object allocation).
      This method now recalculates the part of the bitmap that is
      required for returning the correct result, by iterating through
      objects of the page. A special constructor has been introduced to the
      PagedSpaceObjectIterator for this purpose.
      
      It also moves the existing inline methods of ObjectStartBitmap to a
      new -inl.h header file, to avoid circular dependencies.
      
      Bug: v8:12851
      Change-Id: Iabd0df020bee3bb63ef9d4888591b25d24d79dd9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3641179Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80538}
      36610bbd
  2. 05 May, 2022 1 commit
  3. 01 Sep, 2020 1 commit
  4. 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