Bug 56356 – JavaScriptCore needs a Generational Garbage Collector

• Status: RESOLVED
• Resolution: WONTFIX
• Component: JavaScriptCore

[Alan Tam]

As long-lived data intensive web applications become a norm, there are a common and legitimate use cases for having a large set of long-lived (JSValue) objects. This hurts the GC performance because such objects are constantly added to the conservative set during each Heap::reset() call, as triggered by lack of space during allocate() as well as collectAllGarbage(). In additional to slower overall performance, it also causes sluggishness if Heap::reset() calls happen too frequently.

A Generational GC allows more frequent collections of recently created (temporary) objects, allowing the long-lived objects stay untouched for a longer period of time.

[Alexey Proskuryakov]

Yes, this is mentioned in <http://www.webkit.org/projects/javascript/index.html>.

Are you planning to work on this soon? Otherwise, tracking this as a bug doesn't really help.

[Alan Tam]

From my experience with other open source projects, they don't mind having a bug tracking future features, so that other people who stumble upon the need for such a feature can track the progress by CC-ing themselves.

I am pretty new to webkit, so just tell me if there is a more appropriate way to do things. I don't mind if recommend, say, closing this bug as LATER.

[Alexey Proskuryakov]

I'll defer making a decision about this particular bug to Geoff. This is not really a feature or enhancement request - the enhancement request here is "please make JavaScriptCore even faster", which may or may not require this particular technique.

[Gavin Barraclough]

I think I'm going to close this bug.  We're constantly investigating the direction we should be going with the garbage collector, we're currently focussed on concurrent and incremental collection.  Generational may or may not fit into this picture, the complexity of a generational, concurrent, incremental collector might result in overhead that makes this undesirable.

This bug is not necessarily on the wrong track, but it might not be the direction we want to take, it isn't directly actionable, and isn't tracking actual work.  Hope this sounds like a reasonable conclusion.