This makes more progress on incremental marking when there is a lot of
pretenured allocation going on, as in the JSON parser. It reduces the peak
memory use on a recent example:
erikcorry-macbookpro2:v8 erikcorry$ ./out/x64.release/d8 --test
--random-seed=181912476 --trace-gc regress-3976.js | grep biggest
[90088] 108 ms: Mark-sweep 19.3 (52.1) -> 18.5 (55.1) MB, 14.3 ms (+
9.2 ms
in 170 steps since start of marking, biggest step 0.1 ms) [GC interrupt]
[GC in
old space requested].
[90088] 490 ms: Mark-sweep 130.5 (156.1) -> 121.2 (158.1) MB, 61.3 ms
(+
57.1 ms in 701 steps since start of marking, biggest step 0.3 ms) [GC
interrupt]
[GC in old space requested].
[90088] 1135 ms: Mark-sweep 508.8 (542.9) -> 51.2 (103.9) MB, 33.8 ms
(+ 1.3
ms in 13 steps since start of marking, biggest step 0.2 ms) [GC interrupt]
[GC
in old space requested].
[90088] 1338 ms: Mark-sweep 228.5 (265.9) -> 51.2 (102.9) MB, 12.4 ms
(+ 1.1
ms in 12 steps since start of marking, biggest step 0.2 ms) [GC interrupt]
[GC
in old space requested].
[90088] 1538 ms: Mark-sweep 228.4 (264.9) -> 51.2 (102.9) MB, 12.5 ms
(+ 1.1
ms in 12 steps since start of marking, biggest step 0.2 ms) [GC interrupt]
[GC
in old space requested].
[90088] 1738 ms: Mark-sweep 229.5 (266.9) -> 51.2 (103.9) MB, 12.9 ms
(+ 1.1
ms in 13 steps since start of marking, biggest step 0.2 ms) [GC interrupt]
[GC
in old space requested].
[90088] 1961 ms: Mark-sweep 228.5 (265.9) -> 51.2 (102.9) MB, 12.1 ms
(+ 1.3
ms in 12 steps since start of marking, biggest step 0.2 ms) [GC interrupt]
[GC
in old space requested].
erikcorry-macbookpro2:v8 erikcorry$ ./out/x64.release/d8-oldspacestep --test
--random-seed=181912476 --trace-gc regress-3976.js | grep biggest
[90095] 91 ms: Mark-sweep 19.3 (52.1) -> 18.5 (55.1) MB, 14.1 ms (+
8.5 ms
in 170 steps since start of marking, biggest step 0.1 ms) [GC interrupt]
[GC in
old space requested].
[90095] 364 ms: Mark-sweep 103.6 (129.1) -> 94.7 (131.1) MB, 34.8 ms (+
59.2 ms in 1042 steps since start of marking, biggest step 0.2 ms) [GC
interrupt] [GC in old space requested].
[90095] 885 ms: Mark-sweep 380.6 (414.9) -> 51.2 (102.9) MB, 25.2 ms
(+ 1.0
ms in 15 steps since start of marking, biggest step 0.2 ms) [GC interrupt]
[GC
in old space requested].
[90095] 1064 ms: Mark-sweep 209.1 (245.9) -> 51.2 (100.9) MB, 16.6 ms
(+ 1.3
ms in 15 steps since start of marking, biggest step 0.2 ms) [GC interrupt]
[GC
in old space requested].
[90095] 1232 ms: Mark-sweep 209.1 (245.9) -> 51.1 (101.9) MB, 10.9 ms
(+ 0.9
ms in 15 steps since start of marking, biggest step 0.1 ms) [GC interrupt]
[GC
in old space requested].
[90095] 1396 ms: Mark-sweep 209.1 (245.9) -> 51.1 (100.9) MB, 10.7 ms
(+ 0.9
ms in 15 steps since start of marking, biggest step 0.1 ms) [GC interrupt]
[GC
in old space requested].
[90095] 1562 ms: Mark-sweep 209.1 (245.9) -> 51.1 (101.9) MB, 10.8 ms
(+ 0.9
ms in 15 steps since start of marking, biggest step 0.1 ms) [GC interrupt]
[GC
in old space requested].
[90095] 1726 ms: Mark-sweep 209.1 (245.9) -> 51.1 (100.9) MB, 10.8 ms
(+ 0.9
ms in 15 steps since start of marking, biggest step 0.1 ms) [GC interrupt]
[GC
in old space requested].
[90095] 1890 ms: Mark-sweep 209.1 (245.9) -> 51.1 (101.9) MB, 10.8 ms
(+ 0.9
ms in 15 steps since start of marking, biggest step 0.1 ms) [GC interrupt]
[GC
in old space requested].
Incremental marking pauses caused by allocation are slightly lower at 0.2ms
on a
Mac which as a rule of thumb will be 2ms on a phone.
https://codereview.chromium.org/1040233003/diff/1/src/heap/incremental-marking.cc
File src/heap/incremental-marking.cc (right):
https://codereview.chromium.org/1040233003/diff/1/src/heap/incremental-marking.cc#newcode839
src/heap/incremental-marking.cc:839: Start(PREVENT_COMPACTION);
Time to revisit this TODO if we didn't already today?
https://codereview.chromium.org/1040233003/diff/1/src/heap/spaces.cc
File src/heap/spaces.cc (left):
https://codereview.chromium.org/1040233003/diff/1/src/heap/spaces.cc#oldcode2379
src/heap/spaces.cc:2379: old_linear_size);
This was basically wrong, basing the step on the size of one allocation
plus what was left of the old linear allocation area, but ignoring the
rest of the new linear allocation area.
https://codereview.chromium.org/1040233003/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
