On Sep 23, 2008, at 1:00 PM, Geoffrey Garen wrote:

Hi.

...

SquirrelFish seems to use a conservative garbage collector with two heaps - primary heap and number heap. Is there any plan to implement an accurate garbage collector?

Yes, we'd like to do better than a conservative collector. Are you interested in contributing?

Just to clarify as always: 1) JavaScriptCore's garbage collector is only partially conservative - it is conservative on the machine stack and on the VM register file. The latter is probably practically fixable by either storing call frames in a separate stack or recording where they are, the former is not easy to fix without large changes. The garbage collector is exact on the heap (JS objects know what they reference and non-JS objects must explicitly make themselves GC roots if they hold a JS value). 2) The conservative scan is not really the expensive part of GC. 3) The key thing that we think would be an improvement would be moving to a generational copying/compacting collector, as this would make allocation cheaper, make collection cheaper, and reduce fragmentation. Copying collectors are not really compatible with a true conservative scan, but they could be pseudo-conservative by scanning for indirect handles on the stack (though perhaps it would be easy enough to see what handles are live without that). To summarize, what we really need is a generational collector, and to achieve that we may have to abandon our partially-conservative strategy (though in my opinion it is great for a mark-sweep collector).

...

However, I am not sure how much the gabage collector affects the overall performance of JavaScript.

The two cases where GC tends to show up are: (1) numerics tests that allocate a lot of number cells; (2) applications that have large object heaps.

I would add that it is generally not all that hot on benchmarks yet, though it is on some selected ones. We can also make some improvements to the current GC, namely trying to avoid GC allocation for numbers and improving the performance of marking with a mark stack. Regards, Maciej

On Sep 23, 2008, at 11:42 PM, Geoffrey Garen wrote:

...

1) JavaScriptCore's garbage collector is only partially conservative - it is conservative on the machine stack and on the VM register file. The latter is probably practically fixable by either storing call frames in a separate stack or recording where they are

I think we'd still need to do a conservative mark of the register file, since registers can be uninitialized upon entry to a function. Maybe we could arrange to conservatively mark only the top call frame, though, if we resolved other problems like allocating unused registers.

We'll have to fix this to be able to have a copying collector, because while we could use the handle approach for stack-only references from C ++ code, it seems unworkable for every VM register to hold a handle and not an actual JS value. - Maciej