1. 23 Aug, 2022 1 commit
  2. 16 Aug, 2022 1 commit
    • Michael Lippautz's avatar
      Reland "[heap] Rework Worklist base type" · 30691690
      Michael Lippautz authored
      This is a reland of commit a19316d9
      
      - Revert malloc_usable_size() changes temporarily to land them in
        isolation.
      - Add cosmetics from https://crrev.com/c/3827876
      
      Original change's description:
      > [heap] Rework Worklist base type
      >
      > Worklist uses a singly-linked list of segments to hold entries.
      > Segment size was based on a compile-time constant but already stored
      > in the segment itself.
      >
      > Rework the segments to query `malloc_usable_size()` on allocation and
      > adjust the capacity properly. For PartitionAlloc, it turns out that
      > there's ~20% more capacity available for the 64-element segments.
      >
      > This slows down actual allocation of the segments with the upside of
      > improving utilization and requiring 20% less segments.
      >
      > Change-Id: Ib8595c3fb9fb75b02e4022f6c525bb59a2df7ab7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3826047
      > Commit-Queue: Anton Bikineev <bikineev@chromium.org>
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Anton Bikineev <bikineev@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#82432}
      
      Change-Id: Ic8c5257cfe3c347b11eea5c513ca7f62e09f637f
      Bug: v8:13193
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829475Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82493}
      30691690
  3. 12 Aug, 2022 2 commits
    • Nico Hartmann's avatar
      Revert "[heap] Rework Worklist base type" · 54ef0d87
      Nico Hartmann authored
      This reverts commit a19316d9.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/22670/overview
      
      Original change's description:
      > [heap] Rework Worklist base type
      >
      > Worklist uses a singly-linked list of segments to hold entries.
      > Segment size was based on a compile-time constant but already stored
      > in the segment itself.
      >
      > Rework the segments to query `malloc_usable_size()` on allocation and
      > adjust the capacity properly. For PartitionAlloc, it turns out that
      > there's ~20% more capacity available for the 64-element segments.
      >
      > This slows down actual allocation of the segments with the upside of
      > improving utilization and requiring 20% less segments.
      >
      > Change-Id: Ib8595c3fb9fb75b02e4022f6c525bb59a2df7ab7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3826047
      > Commit-Queue: Anton Bikineev <bikineev@chromium.org>
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Anton Bikineev <bikineev@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#82432}
      
      Change-Id: I14994e11ff5ffaba70b93d977d40dd2f6e9e5d35
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829474
      Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#82438}
      54ef0d87
    • Michael Lippautz's avatar
      [heap] Rework Worklist base type · a19316d9
      Michael Lippautz authored
      Worklist uses a singly-linked list of segments to hold entries.
      Segment size was based on a compile-time constant but already stored
      in the segment itself.
      
      Rework the segments to query `malloc_usable_size()` on allocation and
      adjust the capacity properly. For PartitionAlloc, it turns out that
      there's ~20% more capacity available for the 64-element segments.
      
      This slows down actual allocation of the segments with the upside of
      improving utilization and requiring 20% less segments.
      
      Change-Id: Ib8595c3fb9fb75b02e4022f6c525bb59a2df7ab7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3826047
      Commit-Queue: Anton Bikineev <bikineev@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82432}
      a19316d9
  4. 09 Mar, 2022 1 commit
    • Dominik Inführ's avatar
      [heap] Improve accounting of PagedSpace::CommittedPhysicalMemory() · 25981026
      Dominik Inführ authored
      Instead of using the high water mark for determining this metric, we use
      a bitset for all active/used system pages on a V8 heap page. Each time
      when allocating a LAB on a page, we add the pages of that memory range
      to that bitset. During sweeping we rebuild that bitset from scratch and
      replace it with the old one in case free pages are discarded by the GC.
      We DCHECK here that the sweeper only ever removes pages. This has the
      nice benefit of ensuring that we don't miss any allocations (like we
      do now for concurrent allocations).
      
      CommittedPhysicalMemory for a page is then calculated by counting the
      set bits in the bitset and multiplying it with the system page size.
      This should be simpler to verify and track the "real" effective size
      more precisely.
      
      One case where we are partially less precise than the current
      implementation is for LABs. In order to reduce complexity we now treat
      all pages of a LAB allocation as active immediately. In the current
      implementation we tried to only account the actual used part of the LAB
      when changing the LAB later. This is more complex to track correctly
      but also doesn't account the currently used LAB in effective size.
      
      Change-Id: Ia83df9ad5fbb852f0717c4c396b5074604bd21e9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497363Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79428}
      25981026
  5. 02 Dec, 2021 1 commit
  6. 20 Oct, 2020 1 commit
  7. 10 Sep, 2020 3 commits
    • Omer Katz's avatar
      Reland "Reland "cppgc, heap: Don't eagerly allocate worklist segments"" · 5b9889d9
      Omer Katz authored
      This is a reland of f25cb50a
      
      Removed the problematic tests.
      The problem with the test was that we try to pop from an empty segment.
      GCC flags that as accessing beyond the array (i.e. index is uint16_t
      equivalent of -1). Preceding the actual pop is a DCHECK that asserts
      the segment isn't empty. In practice, since we have the DCHECK and
      access to the segment is always via a Local, this shouldn't be a
      problem.
      Unfortunately, GCC flags the access regardless. The DCHECK goes through
      a function pointer so GCC cannot determine that in our unittest the
      DCHECK would crash if index is 0 and the access would not happen (The
      indirection was added to allow for test DCHECK handlers that don't
      crash, so we can't mark the function pointer as noreturn).
      
      Drive-by: Segment::Pop and Segment::Push rely on the their Local
      counterparts checking of emptiness/fullness, so we should always
      access segments via Locals. Making the Segment ctor private.
      
      Original change's description:
      > Reland "cppgc, heap: Don't eagerly allocate worklist segments"
      >
      > This is a reland of c99147c6
      >
      > Original change's description:
      > > cppgc, heap: Don't eagerly allocate worklist segments
      > >
      > > Bug: chromium:1056170
      > > Change-Id: I75a6b5f52bfe8dd71abc086e5d1e060759ad7fc0
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391254
      > > Commit-Queue: Omer Katz <omerkatz@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#69778}
      >
      > Bug: chromium:1056170
      > Change-Id: I4633da065976a6b2710d2f23b946fd2af0e65c83
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401425
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Omer Katz <omerkatz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69806}
      
      Bug: chromium:1056170
      Change-Id: I7a122d1a2d20cd4e7c824d249975b4d3df30e03e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403251Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69829}
      5b9889d9
    • Maya Lekova's avatar
      Revert "Reland "cppgc, heap: Don't eagerly allocate worklist segments"" · 68b788ca
      Maya Lekova authored
      This reverts commit f25cb50a.
      
      Reason for revert: Fails compilation on gcc https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20gcc%20-%20debug/9026?
      
      Original change's description:
      > Reland "cppgc, heap: Don't eagerly allocate worklist segments"
      > 
      > This is a reland of c99147c6
      > 
      > Original change's description:
      > > cppgc, heap: Don't eagerly allocate worklist segments
      > >
      > > Bug: chromium:1056170
      > > Change-Id: I75a6b5f52bfe8dd71abc086e5d1e060759ad7fc0
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391254
      > > Commit-Queue: Omer Katz <omerkatz@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#69778}
      > 
      > Bug: chromium:1056170
      > Change-Id: I4633da065976a6b2710d2f23b946fd2af0e65c83
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401425
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Omer Katz <omerkatz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69806}
      
      TBR=ulan@chromium.org,mlippautz@chromium.org,omerkatz@chromium.org
      
      Change-Id: I004173e2a82518a88e68eae3a6f7e96656c0ad7e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1056170
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403249Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69809}
      68b788ca
    • Omer Katz's avatar
      Reland "cppgc, heap: Don't eagerly allocate worklist segments" · f25cb50a
      Omer Katz authored
      This is a reland of c99147c6
      
      Original change's description:
      > cppgc, heap: Don't eagerly allocate worklist segments
      >
      > Bug: chromium:1056170
      > Change-Id: I75a6b5f52bfe8dd71abc086e5d1e060759ad7fc0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391254
      > Commit-Queue: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69778}
      
      Bug: chromium:1056170
      Change-Id: I4633da065976a6b2710d2f23b946fd2af0e65c83
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401425Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69806}
      f25cb50a
  8. 09 Sep, 2020 1 commit