Status: New
Owner: ----
New issue 2077 by [email protected]: The scavenger GC does not collect
independent DOM objects
http://code.google.com/p/v8/issues/detail?id=2077
Consider the following JavaScript:
for (var i = 0; i < 1000000; i++) {
document.createIndependentElement();
}
Here, assume that createIndependentElement() creates an element marked as
independent and weak.
The expected behavior of GC is as follows:
(1) A new DOM object is created in the FROM space of the new space.
(2) The first scavenger runs. It copies the DOM object to the TO space of
the new space, and calls back weakNodeCallback() in V8 binding.
(3) weakNodeCallback() disposes the persistent handle of the DOM object.
(4) The second scavenger runs. The scavenger deletes the DOM object.
The actual behavior of GC is as follows:
(1) A new DOM object is created in the FROM space of the new space.
(2) The first scavenger runs. It copies the DOM object to the TO space of
the new space, and calls back weakNodeCallback() in V8 binding.
(3) weakNodeCallback() disposes the persistent handle of the DOM object.
(4) The second scavenger does not run, and the DOM object is promoted to
the old space.
(5) Mark & sweep GC runs and it deletes the DOM object.
How to reproduce:
(1) Prepare the following JavaScript code:
for (var i = 0; i < 3000000; i++) {
document.createElement("div");
}
(2) Comment out the following line of
WebKit/Source/WebCore/bindings/scripts/CodeGeneratorV8.pm:
// if (!hasDependentLifetime) // Comment out this line. This marks
all DOM objects as independent. This is wrong, but is OK just to observe
the behavior of GC
wrapperHandle.MarkIndependent();
(3) Build chrome. Start chrome with the --js-flags="--trace-gc" option.
Open the JavaScript that we prepared in (1).
(4) We can get the following output:
4111 ms: Scavenge 2.3 (37.0) -> 2.1 (38.0) MB, 1 / 3 ms [allocation
failure].
4133 ms: Mark-sweep 3.4 (40.0) -> 2.4 (40.0) MB, 5 / 9 ms [allocation
failure] [promotion limit reached].
4155 ms: Scavenge 4.2 (40.0) -> 4.2 (40.0) MB, 4 / 5 ms [allocation
failure].
4189 ms: Scavenge 6.8 (41.0) -> 6.3 (42.0) MB, 7 / 9 ms [allocation
failure].
4234 ms: Mark-sweep 9.0 (43.0) -> 3.7 (43.0) MB, 13 / 19 ms [allocation
failure] [promotion limit reached].
4333 ms: Scavenge 10.8 (44.0) -> 10.8 (47.0) MB, 23 / 31 ms [allocation
failure].
Increasing marking speed to 3 due to high promotion rate
4408 ms: Mark-sweep 15.1 (49.0) -> 5.4 (47.0) MB, 22 / 32 ms (+ 1 ms in
10 steps since start of marking, biggest step 0.217041 ms) [StackGuard GC
request] [GC in old space requested].
4610 ms: Scavenge 19.6 (49.0) -> 19.6 (54.0) MB, 47 / 64 ms [allocation
failure].
Increasing marking speed to 3 due to high promotion rate
4664 ms: Mark-sweep 22.6 (55.0) -> 4.0 (45.0) MB, 15 / 23 ms (+ 1 ms in
10 steps since start of marking, biggest step 0.218994 ms) [StackGuard GC
request] [GC in old space requested].
5076 ms: Scavenge 32.4 (54.0) -> 32.4 (61.0) MB, 95 / 134 ms
[allocation failure].
Increasing marking speed to 3 due to high promotion rate
5125 ms: Mark-sweep 34.9 (62.0) -> 3.6 (46.0) MB, 12 / 22 ms (+ 1 ms in
8 steps since start of marking, biggest step 0.218018 ms) [StackGuard GC
request] [GC in old space requested].
5530 ms: Scavenge 32.0 (55.0) -> 32.0 (61.0) MB, 98 / 133 ms
[allocation failure].
Increasing marking speed to 3 due to high promotion rate
5578 ms: Mark-sweep 34.5 (62.0) -> 3.6 (46.0) MB, 12 / 21 ms (+ 1 ms in
8 steps since start of marking, biggest step 0.219971 ms) [StackGuard GC
request] [GC in old space requested].
5983 ms: Scavenge 32.0 (55.0) -> 32.0 (61.0) MB, 98 / 134 ms
[allocation failure].
Increasing marking speed to 3 due to high promotion rate
6031 ms: Mark-sweep 34.5 (62.0) -> 3.6 (46.0) MB, 12 / 21 ms (+ 1 ms in
8 steps since start of marking, biggest step 0.217041 ms) [StackGuard GC
request] [GC in old space requested].
6440 ms: Scavenge 32.0 (55.0) -> 32.0 (61.0) MB, 99 / 135 ms
[allocation failure].
Increasing marking speed to 3 due to high promotion rate
6488 ms: Mark-sweep 34.5 (62.0) -> 3.6 (46.0) MB, 12 / 21 ms (+ 1 ms in
8 steps since start of marking, biggest step 0.227051 ms) [StackGuard GC
request] [GC in old space requested].
The above output means that the second scavenger GC does not run, and all
DOM object deletions are conducted by the mark & sweep GC.
Note: In the above output, the overhead of the scavenger GC is unacceptably
large. This is due to the overhead of calling back weakNodeCallback(). I am
trying to reduce the overhead in another bug.
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
