Status: Accepted
Owner: ----
CC: [email protected], [email protected], [email protected]
Labels: Type-Bug Priority-Medium
New issue 2101 by [email protected]: V8's GC heuristics are fragile
http://code.google.com/p/v8/issues/detail?id=2101
Version: 20.0.1117.0 (Official Build 133939) canary
OS: all (Mac, Linux, Windows)
What steps will reproduce the problem?
1. Run Chrome with the command line arguments: --js-flags="--trace-gc".
2. Visit http://codeflow.org/issues/gc_subarray.html (also attached to bug
report)
3. Open the console.
4. Watch the printed output to the terminal.
What is the expected output? What do you see instead?
Normally, for this test case, V8 determines after a few seconds that
young-generation scavenges are taking too long, and adjusts the size of the
young generation and the marking speed. In this "good" scenario, these sort
of numbers are printed to the terminal:
Limited new space size due to high promotion rate: 1 MB
Increasing marking speed to 3 due to high promotion rate
60226 ms: Scavenge 6.8 (26.4) -> 6.5 (26.4) MB, 6 / 8 ms [allocation
failure].
60626 ms: Mark-sweep 7.3 (26.4) -> 1.7 (26.4) MB, 6 / 14 ms [allocation
failure] [promotion limit reached].
61169 ms: Scavenge 2.7 (26.4) -> 2.7 (26.4) MB, 8 / 11 ms [allocation
failure].
61576 ms: Scavenge 3.4 (26.4) -> 3.1 (26.4) MB, 6 / 8 ms [allocation
failure].
61989 ms: Scavenge 3.9 (26.4) -> 3.6 (26.4) MB, 6 / 8 ms [allocation
failure].
62385 ms: Scavenge 4.4 (26.4) -> 4.1 (26.4) MB, 6 / 8 ms [allocation
failure].
and the page will print output like the following to the console:
[runtime: 5.64s] gc'ed 69ms, good frames: 336, bad frames: 1
[runtime: 9.89s] gc'ed 119ms, good frames: 587, bad frames: 2
However, if the console is opened at just the wrong time, the first two
lines will not be printed, indicating that V8's GC heuristics failed. In
this situation, scavenges will be ten times as expensive:
9408 ms: Scavenge 13.5 (23.4) -> 11.5 (27.4) MB, 65 / 89 ms [allocation
failure].
9805 ms: Mark-sweep 12.4 (27.4) -> 1.7 (25.4) MB, 6 / 13 ms (+ 2 ms in
9 steps since start of marking, biggest step 0.426025 ms) [StackGuard GC
request] [GC in old space requested].
14092 ms: Scavenge 9.5 (25.4) -> 9.5 (25.4) MB, 85 / 114 ms [allocation
failure].
17305 ms: Scavenge 15.3 (25.4) -> 13.3 (29.4) MB, 63 / 86 ms [allocation
failure].
17733 ms: Mark-sweep 14.2 (29.4) -> 1.9 (28.4) MB, 7 / 14 ms (+ 2 ms in
8 steps since start of marking, biggest step 0.414062 ms) [StackGuard GC
request] [GC in old space requested].
22016 ms: Scavenge 9.6 (28.4) -> 9.6 (28.4) MB, 85 / 113 ms [allocation
failure].
25245 ms: Scavenge 15.4 (28.4) -> 13.5 (29.4) MB, 65 / 85 ms [allocation
failure].
25741 ms: Mark-sweep 14.4 (29.4) -> 2.0 (28.4) MB, 8 / 15 ms (+ 2 ms in
10 steps since start of marking, biggest step 0.406982 ms) [StackGuard GC
request] [GC in old space requested].
30030 ms: Scavenge 9.7 (28.4) -> 9.7 (28.4) MB, 85 / 113 ms [allocation
failure].
and the page will print output like the following to the console:
[runtime: 9.24s] gc'ed 91ms, good frames: 548, bad frames: 1
[runtime: 13.92s] gc'ed 116ms, good frames: 824, bad frames: 2
[runtime: 17.13s] gc'ed 88ms, good frames: 1013, bad frames: 3
[runtime: 21.84s] gc'ed 115ms, good frames: 1291, bad frames: 4
[runtime: 25.07s] gc'ed 86ms, good frames: 1480, bad frames: 5
[runtime: 29.86s] gc'ed 114ms, good frames: 1762, bad frames: 6
[runtime: 33.07s] gc'ed 87ms, good frames: 1951, bad frames: 7
[runtime: 37.82s] gc'ed 114ms, good frames: 2233, bad frames: 8
Note that the application measures GC time fairly accurately by measuring
the duration between calls to its callback.
If one waits until the application has warmed up before opening the
console, the problem doesn't occur.
It is possible that the Inspector specifically is interfering with V8's GC
heuristics, and that this problem only occurs when the developer tools are
opened at the wrong time. However, I have a feeling that this may be a
general problem where if a large amount of object allocations happen at the
wrong time (which I assume occurs when the console is opened), V8's GC
heuristics fail, resulting in reduced performance for applications with
high allocation rates.
Please investigate this. If the issue is related specifically to the
Inspector, feel free to close it.
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
