1. 12 Sep, 2018 3 commits
  2. 11 Sep, 2018 2 commits
  3. 17 Aug, 2018 1 commit
  4. 16 Jul, 2018 1 commit
  5. 21 Jun, 2018 2 commits
    • Peter Marshall's avatar
      [gc] Attach page to LocalArrayBufferTracker rather than space · 11926e6e
      Peter Marshall authored
      Each local ABT is logically for one page. We passed the space in to the
      constructor, but this is wrong because the space a page is in can
      change, e.g. for compaction pages.
      
      Instead, pass the page to the local ABT constructor and always get the
      space from this. To do this we need to push the AllocateLocalTracker()
      helper and friends down to Page, rather than its superclass MemoryChunk.
      
      Unfortunately, we need to keep ReleaseLocalTracker() on MemoryChunk even
      though only Pages can have local trackers, because we can't do virtual
      dispatch on MemoryChunk::ReleaseAllocatedMemory() which would allow us
      to clean up the tracker memory nicely for pages only.
      
      We also have to make sure we update external bytes accounting properly
      when swapping spaces, as in SemiSpace::Swap().
      
      Change-Id: Iff02e41dd12a6b04a57fcc32f9e2b4f049fcbc24
      Reviewed-on: https://chromium-review.googlesource.com/1107635
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53930}
      11926e6e
    • Peter Marshall's avatar
      [gc] Store the backing store pointer in the ArrayBufferTracker · 4d93fae9
      Peter Marshall authored
      Currently we have to access the unreachable ArrayBuffer object to get
      the backing store pointer when we want to free it. This means we need
      the original ArrayBuffer object to stay alive until we collect all of
      the pointers to free (currently done sequentially after marking).
      
      We want to move this step to a background task that does not block GC
      finishing - to do that we need the backing store pointers so that the
      original page (where the ArrayBuffers live) can be freed.
      
      Change-Id: Ifaf070d777939cb23c46da637a25d75f9c863bd8
      Reviewed-on: https://chromium-review.googlesource.com/1102434
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53915}
      4d93fae9
  6. 15 May, 2018 1 commit
    • Wez's avatar
      [heap] Replace retained_size() with ExternalBackingStoreBytes(). · aca33312
      Wez authored
      ArrayBuffer memory allocated off-heap was previously tracked by a test-
      only retained_size() field on each LocalArrayBufferTracker.
      
      Changes in off-heap ArrayBuffer memory usage are now reported to the
      Space with which the ArrayBuffer is associated, so that the value is
      cheaply available to include in e.g. GC limit calculations, via a new
      getter, ExternalBackingStoreBytes().
      
      Changes to external ArrayBuffer backing-store allocations are tracked in
      an AtomicNumber associated with each Space, to allow for ArrayBuffers
      being concurrently moved or freed from multiple Pages in the same Space
      during sweeps & compactions.
      
      Bug: chromium:837583
      Change-Id: I8b1b6addd5cd05533d8da55ca813e134bc36e181
      Reviewed-on: https://chromium-review.googlesource.com/1052347
      Commit-Queue: Wez <wez@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53192}
      aca33312
  7. 02 May, 2018 1 commit
    • Michael Lippautz's avatar
      [heap] Fix ArrayBufferTracker accessing already swept byte length · 55d00c95
      Michael Lippautz authored
      The tracker needs to maintain the byte length as there is no order guarantee
      when sweeping pages and the byte length may be a HeapNumber that is stored on a
      different page.
      
      The abstraction for ArrayBuffers is left untouched. We distinguish between the
      following cases:
      1. Regular AB (backing_store and bye_length should be used)
      2. AB allocated using kReservation but not part of wasm
      3. AB allocated using kReservation and part of wasm
      
      In practice, 2. does not exist, but we still maintain "allocation_base" and
      "allocation_length" which fall back to backing_store and byte_length in this
      case. The problematic part is that they look like innocent getters on the
      object but actually refer to different data structures or on-heap objects.
      
      Since 2. does not exist, and 3. looks up the bounds in its own tracker, it is
      fine for ArrayBufferTracker to pass backing_store and tracked byte_length.
      
      Bug: v8:7701
      Change-Id: Ib89d5fe94fce5cef8e5d8343a5415a3b9ad0deba
      Reviewed-on: https://chromium-review.googlesource.com/1039385Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52923}
      55d00c95
  8. 06 Apr, 2018 1 commit
  9. 20 Nov, 2017 3 commits
    • Peter Marshall's avatar
      reland: [heap] Concurrently free ArrayBuffer allocations. · d8981833
      Peter Marshall authored
      Free ArrayBuffer backing stores on a background thread, rather than
      blocking the main thread after processing. Could potentially cause
      contention with the array buffer allocator once JS execution resumes.
      
      The new ArrayBufferCollector class tracks these dead allocations.
      
      Later, the processing of array buffers can happen in parallel.
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux64_tsan_rel;master.tryserver.v8:v8_linux64_tsan_concurrent_marking_rel_ng;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
      
      Bug: v8:6992
      Change-Id: I2b74f008f79521414374f607ed510f66508af160
      Reviewed-on: https://chromium-review.googlesource.com/779182
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49505}
      d8981833
    • Peter Marshall's avatar
      Revert "[heap] Concurrently free ArrayBuffer allocations." · 3b31e5be
      Peter Marshall authored
      This reverts commit b6658ade.
      
      Reason for revert: Breaks TSAN :(
      
      Original change's description:
      > [heap] Concurrently free ArrayBuffer allocations.
      > 
      > Free ArrayBuffer backing stores on a background thread, rather than
      > blocking the main thread after processing. Could potentially cause
      > contention with the array buffer allocator once JS execution resumes.
      > 
      > The new ArrayBufferCollector class tracks these dead allocations.
      > 
      > Later, the processing of array buffers can happen in parallel.
      > 
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > 
      > Bug: v8:6992
      > Change-Id: I49ae4db12ed62d8400ba2bbafeda05a11479d904
      > Reviewed-on: https://chromium-review.googlesource.com/739829
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49485}
      
      TBR=hpayer@chromium.org,mlippautz@chromium.org,petermarshall@chromium.org
      
      Change-Id: If6743b83f871c0fd0d6e83a3083dce0eecd99021
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6992
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/779159Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49488}
      3b31e5be
    • Peter Marshall's avatar
      [heap] Concurrently free ArrayBuffer allocations. · b6658ade
      Peter Marshall authored
      Free ArrayBuffer backing stores on a background thread, rather than
      blocking the main thread after processing. Could potentially cause
      contention with the array buffer allocator once JS execution resumes.
      
      The new ArrayBufferCollector class tracks these dead allocations.
      
      Later, the processing of array buffers can happen in parallel.
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Bug: v8:6992
      Change-Id: I49ae4db12ed62d8400ba2bbafeda05a11479d904
      Reviewed-on: https://chromium-review.googlesource.com/739829
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49485}
      b6658ade
  10. 24 Oct, 2017 1 commit
  11. 11 Oct, 2017 2 commits
  12. 04 Oct, 2017 2 commits
    • Eric Holk's avatar
      Revert "Reland "[wasm] always allocate memory when guard regions are needed"" · 841ca52c
      Eric Holk authored
      This reverts commit 5e76ff5a.
      
      Reason for revert: tsan failures - https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/17574
      
      Original change's description:
      > Reland "[wasm] always allocate memory when guard regions are needed"
      > 
      > This reverts commit 7cf29d8d.
      > 
      > Original change's description:
      > > [wasm] always allocate memory when guard regions are needed
      > >
      > > When using trap handlers, memory references do not get any checks inserted. This
      > > means there is no check for a null memory as happens when the memory size is
      > > 0. Normally this would be correctly caught as an out of bounds access, since the
      > > low memory addresses are not normally mapped. However, if they were mapped for
      > > some reason, we would not catch the out of bounds access.
      > >
      > > The fix is to ensure WebAssembly instances always have a guard region even if
      > > the memory is size 0.
      > >
      > > Bug: chromium:769637
      > 
      > Change-Id: I09fdaea92b7ccb3a6cc9e28392171ec098538a00
      > Reviewed-on: https://chromium-review.googlesource.com/695812
      > Commit-Queue: Eric Holk <eholk@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48293}
      
      TBR=gdeepti@chromium.org,mtrofin@chromium.org,mlippautz@chromium.org,eholk@chromium.org,eholk@google.com,clemensh@chromium.org
      
      Change-Id: I52d5354126158a92602b08c48703d562ac95075b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/699599Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48294}
      841ca52c
    • Eric Holk (eholk)'s avatar
      Reland "[wasm] always allocate memory when guard regions are needed" · 5e76ff5a
      Eric Holk (eholk) authored
      This reverts commit 7cf29d8d.
      
      Original change's description:
      > [wasm] always allocate memory when guard regions are needed
      >
      > When using trap handlers, memory references do not get any checks inserted. This
      > means there is no check for a null memory as happens when the memory size is
      > 0. Normally this would be correctly caught as an out of bounds access, since the
      > low memory addresses are not normally mapped. However, if they were mapped for
      > some reason, we would not catch the out of bounds access.
      >
      > The fix is to ensure WebAssembly instances always have a guard region even if
      > the memory is size 0.
      >
      > Bug: chromium:769637
      
      Change-Id: I09fdaea92b7ccb3a6cc9e28392171ec098538a00
      Reviewed-on: https://chromium-review.googlesource.com/695812
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48293}
      5e76ff5a
  13. 10 Aug, 2017 1 commit
    • Ulan Degenbaev's avatar
      [heap] Refactor object marking state. · 4af9cfcc
      Ulan Degenbaev authored
      This patch merges ObjectMarking and MarkingState. The new marking state
      encapsulates object marking, live byte tracking, and access atomicity.
      
      The old ObjectMarking calls are now replaced with calls to marking
      state. For example:
      ObjectMarking::WhiteToGrey<kAtomicity>(obj, marking_state(obj)
      becomes
      marking_state()->WhiteToGrey(obj)
      
      This simplifies custom handling of live bytes and allows to chose
      atomicity of markbit accesses depending on collector's state.
      
      This also decouples marking bitmap from the marking code, which will
      allows in future to use different data-structure for mark-bits.
      
      Bug: chromium:694255
      Change-Id: Ifb4bc0144187bac1c08f6bc74a9d5c618fe77740
      Reviewed-on: https://chromium-review.googlesource.com/602132
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47288}
      4af9cfcc
  14. 31 May, 2017 1 commit
  15. 30 May, 2017 3 commits
  16. 09 May, 2017 1 commit
  17. 19 Aug, 2016 1 commit
  18. 18 Aug, 2016 1 commit
  19. 05 Jul, 2016 3 commits
  20. 29 Jun, 2016 2 commits
  21. 28 Jun, 2016 1 commit
  22. 27 Jun, 2016 1 commit
  23. 15 Jun, 2016 1 commit
  24. 07 Jun, 2016 1 commit
    • mlippautz's avatar
      Track based on JSArrayBuffer addresses on pages instead of the attached · 839f3fd4
      mlippautz authored
      backing store.
      
      Details of tracking:
      - Scavenge: New space pages are processes in bulk on the main thread
      - MC: Unswept pages are processed in bulk in parallel. All other pages
        are processed by the sweeper concurrently.
      
      BUG=chromium:611688
      LOG=N
      TEST=cctest/test-array-buffer-tracker/*
      CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_tsan_rel,v8_mac64_asan_rel
      
      Review-Url: https://codereview.chromium.org/2036643002
      Cr-Commit-Position: refs/heads/master@{#36798}
      839f3fd4
  25. 02 Jun, 2016 1 commit
  26. 01 Jun, 2016 1 commit
    • mlippautz's avatar
      Track based on JSArrayBuffer addresses on pages instead of the attached · 279e274e
      mlippautz authored
      backing store.
      
      Details of tracking:
      - Scavenge: New space pages are processes in bulk on the main thread
      - MC: Unswept pages are processed in bulk in parallel. All other pages
        are processed by the sweeper concurrently.
      
      BUG=chromium:611688
      LOG=N
      TEST=cctest/test-array-buffer-tracker/*
      CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_tsan_rel,v8_mac64_asan_rel
      
      Review-Url: https://codereview.chromium.org/2026633003
      Cr-Commit-Position: refs/heads/master@{#36653}
      279e274e
  27. 31 May, 2016 1 commit