Comment #10 on issue 2077 by [email protected]: The scavenger GC does not collect independent DOM objects
http://code.google.com/p/v8/issues/detail?id=2077
We start promoting everything aggressively once 25% of to-space is occupied. Which is exactly what happens if from-space was full of weakly reachable objects. At the same time promoting a lot of weakly reachable objects "confuses" heuristics: you can see that mark-sweep is caused because promotion limit was exceeded.
Makes sense. But I guess that this behavior is not desirable. Anyway we want to somehow avoid the current behavior in which _all_ DOM objects are promoted and wait for the mark-sweep GC. Not only does it consume memory, but also the mark-sweep GC can pause one createElement() for 4 seconds. (See Appendix3 in https://docs.google.com/a/google.com/document/d/1IsBZwD9xCPABl9gUn0qeqWf1hWDZsrkulBAa6uiFxM4/edit)
If as Anton says there is only a handful of corner cases we can consider introducing additional weak callbacks API that would be much lighter (e.g. would not have to copy object at all and will invoke weak callbacks "in place").
As far as I measured the performance, the overhead of weakNodeCallback() is not a bottleneck (I've tried to optimize weakNodeCallback() and confirmed that it has no performance impact on the total GC performance). The bottleneck exists inside the mark-sweep GC itself. So our objective would be to avoid the mark-sweep GC run for _all_ DOM objects; in other words, to have the scavenger GC reclaim DOM objects.
there is only a handful of corner cases we can consider introducing additional weak callbacks API
If we want to have the scavenger GC fire weakNodeCallback(), it won't be any longer a corner case. As I mentioned in #4, the scavenger GC needs to run without the knowledge of object groups. Thus, sometimes weakNodeCallback() needs to resurrect a DOM object if the DOM object is still alive in the DOM tree.
-- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
