There's some evidence from the gcbench benchmark (which is not enough evidence!) that opportunistically reaping the ZCT significantly reduces heap occupancy and garbage collection time. I tried inserting a call to ReapZCT in the no-work-pending case in IncrementalMark (in the new policy code); this cut the size of the heap (not just the GC'd heap) for the benchmark by astonishing 65%, and reduced GC time by 25%. However it also increased the ZCT reap time by more than that, so the result was slight slowdown. On the other hand, with those kinds of numbers we can afford to increase L, and if the ZCT reaper can be made not to do a reap of everything every time it's called but instead perform its work incrementally (see bug #499968 also) then we may be able to throttle that. This benchmark is very biased to this optimization because it has a single object size (so reaping the ZCT very effectively recycles memory, fragmentation is probably close to zero) so we should not expect results like that in general, but it wants investigating. (All results on MacOS X.)

The huge reduction is only in the blocks allocated to the heap; the blocks used by the heap, and allocated to the GC and used by the GC, are about the same (though a little reduced). So what we are probably seeing is that prompter freeing results in somewhat more efficient block use, which in this case results in not having to allocate more memory from the OS.

There are already two attempts at opportunistic reaping implemented. One is a callback from GC::SetStackEnter, which reaps the ZCT on an "edge". This callback can result in a huge number of reaps (an increase by 300% in the number of reaps on the Phosphate benchmark) without any discernible benefit (the extra reaps slow that program down, while the number of objects reclaimed increases only very slightly). Another is in the player's PopActionContext function, but that does not seem to be triggered much. While these callbacks are correct in spirit, it is not right to force a reap by external agent. The policy code should be in charge of forcing reaps. The external agents should provide hints (eg, "edge"), but there's no sense in doing back-to-back reaps if there's been no ZCT activity or the ZCT is very nearly empty: the spilling of the registers to the stack is not free. So the callbacks should become advisory. Another problem with the implemented opportunistic reaping is that they benefit only applications that frequently pop the GC context; computational applications will not benefit. This may not be a big deal (if the ZCT does not fill up then there may not be much to gain from reaping anyway) but as the GCBench example shows, reaping sometimes keeps GC at bay.

This is the right idea but the reaper might need a throttle for the case where there are a lot of pinned objects; or, it might be desirable to avoid the items added just prior to the call. Both of those will become easier with a slightly different ZCT design that will probably emerge from the work on optimizing ZCT::Add and ZCT::Remove.

This is a mass change. Every comment has "assigned-to-new" in it. I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

The ZCT is probably going away post-Serrano.

Tamarin is a dead project now. Mass WONTFIX.

Tamarin isn't maintained anymore. WONTFIX remaining bugs.