Skip to content

V
V8
Switch branch/tag
  1. 21 Jan, 2016 1 commit
  3. 12 Jan, 2016 1 commit
    • mlippautz's avatar
      [heap] Use HashMap as scratchpad backing store · 55422bdd
      mlippautz authored 
      We use a scratchpad to remember visited allocation sites for post processing
(making tenure decisions). The previous implementation used a rooted FixedArray
with constant length (256) to remember all sites. Updating the scratchpad is a
bottleneck in any parallel/concurrent implementation of newspace evacuation.

The new implementation uses a HashMap with allocation sites as keys and
temporary counts as values. During evacuation we collect a local hashmap of
visited allocation sites. Upon merging the local hashmap back into a global one
we update potential forward pointers of compacted allocation sites.  The
scavenger can directly enter its entries into the global hashmap. Note that the
actual memento found count is still kept on the AllocationSite as it needs to
survive scavenges and full GCs.

BUG=chromium:524425
LOG=N
R=hpayer@chromium.org

Review URL: https://codereview.chromium.org/1535723002

Cr-Commit-Position: refs/heads/master@{#33233}
      55422bdd
  5. 08 Jan, 2016 1 commit
  7. 18 Dec, 2015 1 commit
    • mlippautz's avatar
      [heap] Move to LAB-based allocation for newspace evacuation. · a4e3a3b6
      mlippautz authored 
      This CL prepare newspace evacuation for parallel execution wrt. to actual
allocations. The priority for allocations is:
* Try to allocate from LAB if objects are below kMaxLabObjectSize
* Allocate directly (synchronized) from newspace for larger objects.
* Fall back to old space allocation (which will be backed by a local compaction
  space in future).

Semantical change: Previously we did fall back to regular new space promotion if
we are OOM in old space. With this CL we fall back to new space promotion, which
could fail because of fragmentation, again leading to an old space allocation
that finally bails into OOM.

Newspace evacuation is still single threaded and requires further changes to
allocation site tracking.

BUG=chromium:524425
LOG=N

Review URL: https://codereview.chromium.org/1487853002

Cr-Commit-Position: refs/heads/master@{#32970}
      a4e3a3b6
  9. 16 Dec, 2015 1 commit
    • mlippautz's avatar
      Reland of "[cctest] Add tests for aborting compaction of pages" · 2bb51df9
      mlippautz authored 
      Tests for
* aborting a full page.
* partially aborting a page.
* partially aborting a page with pointers between aborted pages.
* partially aborting a page with store buffer entries.

Also introduces force_oom() which prohibits a old space to
expand

BUG=chromium:524425
LOG=N

CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel,v8_linux_nosnap_dbg,v8_win_nosnap_shared_rel,v8_win_nosnap_shared_compile_rel

Review URL: https://codereview.chromium.org/1518803005

Cr-Commit-Position: refs/heads/master@{#32899}
      2bb51df9
  11. 03 Dec, 2015 1 commit
  13. 02 Dec, 2015 1 commit
  15. 01 Dec, 2015 1 commit
  17. 27 Nov, 2015 1 commit
  19. 24 Nov, 2015 1 commit
  21. 20 Nov, 2015 1 commit
  23. 19 Nov, 2015 1 commit
  25. 18 Nov, 2015 1 commit
    • ofrobots's avatar
      [heap] make inline-allocation-observers precise · 0514fa20
      ofrobots authored 
      Now that we no longer require AllocationInfo::limit to be aligned [1], we can do
more accurate inline-allocation-observation. This lets us get notified when the
next allocation that crosses the step-size boundary is allocated.

Fixed the test-cases. They make significantly more sense now given the step
sizes and the number of times we get notifications. For example, with a step
size of 512, an allocation of 16kb results in 32 notifications instead of 30
now.

[1] https://codereview.chromium.org/1444883003

R=hpayer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1448913003

Cr-Commit-Position: refs/heads/master@{#32091}
      0514fa20
  27. 13 Nov, 2015 1 commit
    • ishell's avatar
      Avoid manual object's body traversal in GC. · 5ba9ea18
      ishell authored 
      This CL introduces the following visitors:
1) RecordMigratedSlotVisitor which simplifies MarkCompactCollector::MigrateObject().
2) IteratePointersToFromSpaceVisitor which simplifies Heap::IteratePointersToFromSpace().
3) FindPointersToNewSpaceVisitor which simplifies StoreBuffer::IteratePointersToNewSpace().

These changes make the object's body descriptors the one and only place that knows how to traverse the object.

Review URL: https://codereview.chromium.org/1441453002

Cr-Commit-Position: refs/heads/master@{#31992}
      5ba9ea18
  29. 11 Nov, 2015 1 commit
    • ofrobots's avatar
      [heap] make inline allocation step size dynamic · f5836617
      ofrobots authored 
      Presently the inline allocation step is a static value defined to be the minimum
of the step sizes over all the observers. The step occur every (approx.) step
byte. This is unfair to observers whose steps are not evenly divisible by the
min step size. For example, consider two observers with steps sizes of 512 and
576 bytes. Across 16kb allocated, you would expect the first observer to be hit
approximately 32 times, and the second observer to be hit approximately 28
times.

In reality, the observers get notified 30 and 15 times respectively. The reason
is that each step is 512 bytes, and since 576 is not evenly divisible by 512,
it gets notified much less frequently.

This CL fixes the problem by making the next step size be the minimum (over all
observers) of the remaining bytes to get to the step, making the steps fair.

BUG=
R=hpayer@chromium.org,ulan@chromium.org

Review URL: https://codereview.chromium.org/1427973006

Cr-Commit-Position: refs/heads/master@{#31948}
      f5836617
  31. 05 Nov, 2015 1 commit
    • ofrobots's avatar
      [heap] inline allocation steps refactor · 7b704c4f
      ofrobots authored 
      Expose the steps for incremental marking and idle scavenge more directly in
NewSpace. Adjust the NewSpace and Heap interfaces to allow callers to be more
clear about how they are interacting with inline allocation steps. This refactor
prepares the ground for more consumers of inline allocation steps (e.g. sampling
heap profiler.)

R=hpayer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1404523002

Cr-Commit-Position: refs/heads/master@{#31814}
      7b704c4f
  33. 04 Nov, 2015 1 commit
  35. 02 Nov, 2015 1 commit
  37. 23 Oct, 2015 1 commit
  39. 22 Oct, 2015 1 commit
  41. 21 Oct, 2015 3 commits
    • mlippautz's avatar
      Reland "[heap] Divide available memory upon compaction tasks" · 218c06e8
      mlippautz authored 
      This reverts commit a31cef44.

Original message:

[heap] Divide available memory upon compaction tasks
- Fairly (round-robin) divide available memory upon compaction tasks.
- Ensure an upper limit (of memory) since dividing is O(n) for n free-space
  nodes.
- Refill from free lists managed by sweeper once a compaction space becomes
  empty.

Assumption for dividing memory: Memory in the free lists is sparse upon starting
compaction (which means that only few nodes are available), except for memory
reducer GCs, which happen in idle time though (so it's less of a problem).

BUG=chromium:524425
LOG=N

Review URL: https://codereview.chromium.org/1421583002

Cr-Commit-Position: refs/heads/master@{#31443}
      218c06e8
    • mlippautz's avatar
      Revert of "[heap] Divide available memory upon compaction tasks" (patchset #5... · a31cef44
      mlippautz authored 
      Revert of "[heap] Divide available memory upon compaction tasks" (patchset #5 id:90008 of https://codereview.chromium.org/1415733004/ )

Reason for revert:
Failing again: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/2183

Original issue's description:
> Reland of "[heap] Divide available memory upon compaction tasks"
>
> This reverts commit cf71c28f.
>
> Original message:
>
> [heap] Divide available memory upon compaction tasks
> - Fairly (round-robin) divide available memory upon compaction tasks.
> - Ensure an upper limit (of memory) since dividing is O(n) for n free-space
>   nodes.
> - Refill from free lists managed by sweeper once a compaction space becomes
>   empty.
>
> Assumption for dividing memory: Memory in the free lists is sparse upon starting
> compaction (which means that only few nodes are available), except for memory
> reducer GCs, which happen in idle time though (so it's less of a problem).
>
> BUG=chromium:524425
> LOG=N
>
> Committed: https://crrev.com/63f42ecb965d04877f45043c1416170b6f79b962
> Cr-Commit-Position: refs/heads/master@{#31436}

TBR=hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425

Review URL: https://codereview.chromium.org/1405273003

Cr-Commit-Position: refs/heads/master@{#31439}
      a31cef44
    • mlippautz's avatar
      Reland of "[heap] Divide available memory upon compaction tasks" · 63f42ecb
      mlippautz authored 
      This reverts commit cf71c28f.

Original message:

[heap] Divide available memory upon compaction tasks
- Fairly (round-robin) divide available memory upon compaction tasks.
- Ensure an upper limit (of memory) since dividing is O(n) for n free-space
  nodes.
- Refill from free lists managed by sweeper once a compaction space becomes
  empty.

Assumption for dividing memory: Memory in the free lists is sparse upon starting
compaction (which means that only few nodes are available), except for memory
reducer GCs, which happen in idle time though (so it's less of a problem).

BUG=chromium:524425
LOG=N

Review URL: https://codereview.chromium.org/1415733004

Cr-Commit-Position: refs/heads/master@{#31436}
      63f42ecb
  43. 19 Oct, 2015 1 commit
  45. 16 Oct, 2015 2 commits
  47. 15 Oct, 2015 2 commits
  49. 13 Oct, 2015 2 commits
  51. 08 Oct, 2015 2 commits
    • mlippautz's avatar
      [heap] Free list refactoring of finding nodes. · deccbde1
      mlippautz authored 
      R=ulan@chromium.org
BUG=chromium:524425
LOG=N

Review URL: https://codereview.chromium.org/1394863002

Cr-Commit-Position: refs/heads/master@{#31183}
      deccbde1
    • mlippautz's avatar
      [heap] Remove unswept bytes counter · 93e93983
      mlippautz authored 
      This change removes the unswept free bytes counter.

The new approach
- directly decrements allocated memory and capacity before sweeping (using live
  bytes from the marker), and
- adds back capacity during refilling a free list.

This is another pre-work for moving around free lists while keeping the counters
in a sane state.

The previous approach allowed us to nail down how much memory is to-be-swept.
However, there were no users of this as we only used it do decrement it from
allocated memory (which still accounted for dead objects).  If we want to keep
track of unswept free bytes in a space during compaction we can introduce a
separate new concurrent counter for this purpose.

BUG=chromium:524425
LOG=N

Review URL: https://codereview.chromium.org/1380723002

Cr-Commit-Position: refs/heads/master@{#31175}
      93e93983
  53. 07 Oct, 2015 1 commit
  55. 01 Oct, 2015 2 commits
  57. 25 Sep, 2015 4 commits
  59. 24 Sep, 2015 1 commit