1. 16 Oct, 2017 1 commit
    • Michael Lippautz's avatar
      [heap] Unify incremental and main marking visitor · 4b42656d
      Michael Lippautz authored
      With parallel marking enabled, both visitors have to be equal wrt. to
      actual visitation.
      
      The differences are captured by template parameters:
      - Retaining path tracing which we only do for full GCs.
      - Incremental marking of FixedArray.
      
      CQ_INCLUDE_TRYBOTS=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: chromium:694255, chromium:750084
      Change-Id: I177aeb0ee4f6a35e2f592ba257c9ddc14f88fd99
      Reviewed-on: https://chromium-review.googlesource.com/704935
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48582}
      4b42656d
  2. 13 Oct, 2017 1 commit
  3. 12 Oct, 2017 2 commits
  4. 11 Oct, 2017 1 commit
  5. 10 Oct, 2017 1 commit
    • Michael Lippautz's avatar
      [heap] Introduce on-hold concurrent marking work list · b7e6eb92
      Michael Lippautz authored
      When hitting objects that are allocated in the most recent lienar
      allocation area, the concurrent marker currently has to bail out to the
      main thread.
      
      However, we only have to delay processing those objects until we are at
      a safepoint, e.g. IM::Step(). With this change we flush those
      on-hold-objects back to the shared queue upon performing an incremental
      marking step.
      
      Bug: chromium:694255
      Change-Id: I25647d0fc581a5c4de0346bc394dc51062f65f70
      Reviewed-on: https://chromium-review.googlesource.com/707315
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48424}
      b7e6eb92
  6. 09 Oct, 2017 1 commit
  7. 06 Oct, 2017 2 commits
  8. 04 Oct, 2017 1 commit
    • Michael Lippautz's avatar
      [heap] MC: Parallel marking for the atomic pause · f46a92c2
      Michael Lippautz authored
      Reuse existing concurrent marking infrastructure for marking in the
      atomic pause.
      
      Details:
      - Do not stop concurrent marking when entering the atomic pause.
      - Start concurrent marking when it was off. This is required for
        non-incremental MC GCs.
      - Use atomic marking state in MC.
      - Transition through grey and avoid white->black.
      
      CQ_INCLUDE_TRYBOTS=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: chromium:750084
      Change-Id: I9f84661e69beac6254494907bdfe94e865b1e3ab
      Reviewed-on: https://chromium-review.googlesource.com/690002
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48281}
      f46a92c2
  9. 29 Sep, 2017 1 commit
  10. 26 Sep, 2017 1 commit
  11. 19 Sep, 2017 1 commit
  12. 14 Sep, 2017 1 commit
    • Ulan Degenbaev's avatar
      [heap] Fix black allocation. · 97b2a814
      Ulan Degenbaev authored
      This patch ensures that an object returned by AllocateRaw is marked
      black if black allocation starts during the object allocation.
      
      This fixes the following issue:
      1) Generated code requests allocation of size N for folded allocation.
      2) Runtime gets a free list node at address A of size N+M and sets up
         a linear allocation area with top = A+N and limit = A+N+M.
      3) Runtime invokes the allocation observer that starts incremental marking
         and start black allocation. The area [A+N, A+N+M) is marked black.
      4) Runtime returns a white object at address A as the allocation result.
      5) Generated code moves the top pointer to A and does bump pointer
         allocations of white objects from A to A+N+M.
      6) Object allocated new A+N can have the impossible marbit pattern.
      
      Bug: chromium:694255
      Change-Id: I09ceebc97a510fa5fe4ff20706bc46a99f8b7cf4
      Reviewed-on: https://chromium-review.googlesource.com/638338
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48005}
      97b2a814
  13. 23 Aug, 2017 1 commit
  14. 22 Aug, 2017 2 commits
  15. 21 Aug, 2017 1 commit
  16. 17 Aug, 2017 2 commits
    • Ulan Degenbaev's avatar
      [heap] Sync write barrier stub with runtime for concurrent marking. · 6e5606ef
      Ulan Degenbaev authored
      This also starts black allocation earlier if concurrent marking compile
      time flag is on.
      
      Bug: chromium:694255
      Change-Id: I73c02676e5149fae10e5f9301ad585926e223a1d
      Reviewed-on: https://chromium-review.googlesource.com/618893Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47412}
      6e5606ef
    • Ulan Degenbaev's avatar
      [heap] New live byte tracking. · dfc6b4dd
      Ulan Degenbaev authored
      This patch changes how space size and capacity are updated in GC:
      - space capacity changes only when a page added/removed from the space.
      - space size is reset to zero before sweeping and incremented by
        page->live_bytes_count_ for each to-be-swept page.
      - space size is refined after sweeping using the accurate
        page->allocated_bytes counter produces by the sweeper.
      
      Invariants:
      1. space.capacity = sum [page.size | for page in space].
      2. After marking, before sweeping:
         a) space.size = sum [page.live_bytes_count | for page in space].
      3. After sweeping, before marking ends:
         a) space.size = sum [page.allocated_bytes | for page in space].
         b) page.allocated_bytes >= (sum [object.size | for object in page] +
               page.linear_allocation_area).
         c) page.area_size = (page.allocated_bytes + page.wasted_memory +
               sum [free_list_entry.size | for free_list_entry in page].
      
      3.b becomes equality if the mutator is not doing array trimming,
      object slack tracking during sweeping.
      
      Bug: chromium:694255
      Change-Id: Ic8d16a8171187a113fee2df8bf3c2a4c5e77bc08
      Reviewed-on: https://chromium-review.googlesource.com/618889
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47409}
      dfc6b4dd
  17. 14 Aug, 2017 2 commits
  18. 11 Aug, 2017 1 commit
  19. 10 Aug, 2017 3 commits
  20. 04 Aug, 2017 1 commit
  21. 03 Aug, 2017 1 commit
  22. 01 Aug, 2017 1 commit
  23. 29 Jul, 2017 1 commit
  24. 27 Jul, 2017 1 commit
  25. 24 Jul, 2017 1 commit
  26. 20 Jul, 2017 1 commit
  27. 19 Jul, 2017 1 commit
    • Ulan Degenbaev's avatar
      [heap] Instrument mark-compact to track retaining paths for debugging. · 40c34606
      Ulan Degenbaev authored
      This patch adds a new intrinsic: %DebugTrackRetainingPath(object).
      Calling the intrinsic in JS code saves a weak reference to the given
      object in GC internal table of tracked objects.
      
      Each subsequent full GC prints to stdout the retaining path for each
      tracked object (if it is still alive). The retaining path is the real
      path that the marker took from the root set to the tracked object.
      
      This is useful for investigating of memory leaks:
      1) Add %DebugTrackRetainingPath(leaking_object) in JS code.
      For example:
        function foo() {
          let x = { bar: "bar"};
          %DebugTrackRetainingPath(x);
          return () => { return x; }
        }
      
        let closure = foo();
        gc();
      
      2) Run d8 with --allow-natives-syntax --track-retaining-path --expose-gc.
      
      3) Check the retaining path in stdout.
      
      For more detailed inspection, run d8 in gdb and set breakpoint in
      
      v8: :internal::Heap::PrintRetainingPath.
      Change-Id: I01a0faac1e009bc6c321fa75613900b49d2b036f
      Reviewed-on: https://chromium-review.googlesource.com/575972
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46766}
      40c34606
  28. 17 Jul, 2017 1 commit
  29. 14 Jul, 2017 1 commit
  30. 13 Jul, 2017 1 commit
  31. 12 Jul, 2017 1 commit
  32. 10 Jul, 2017 2 commits