[gclist] More GC comments, please?

[Chris Smith]

Thanks to everyone who has helped me with questions here in the past.  In
my continuing quest to understand gc, I hope my questions are becoming
more intelligent.  Here's some more questions that I'd like some help on.

1) Can anyone tell me if it (a) is feasible, and (b) has been done and
documented somewhere, to implement a generational collector that copies
the new generation, and marks and sweep older generations?

My latest idea (maybe good, maybe bad, but I've either been missing a lot 
or it isn't widely discussed in the introductory GC lit) is to write a
collector that collects the new object area in a single stop-and-copy
manner, and concurrently works on collecting older objects via mark-sweep.
It seems to me that due to the low promotion rate of objects in the first
generation, copying would be ideal specifically there.

Furthermore, it gets the fast allocation time of implicit reclamation very
well, and the longer time of finding space for an object in a fragmented
heap is postponed until incremental operation later.  I could also
use a "bag of pages" collector, as one person on the list suggested to me 
earlier (albeit for different reasons), to make allocation times smaller
grabbing space for tenured garbage.

Also, concurrently collecting objects that stay in the same place avoids
the need for a read barrier (or a Nettles/O'Toole style mutation log),
instead leaving any sort of mutator cooperation to the specific case where
pointers are stored into objects.  Since I won't have hardware support for
my collector, the barrier efficiency is very important to me.

Are there any subtle problems with this idea?  Will the concurrent
collector in the background screw up any locality advantages for
generational copying collection, or are modern caches and VM systems
smarter than all that?

2) Is it feasible to bound the time for execution of a small collection by
bounding the size of the new object area?  The only place I've seen
something like this discussed is in the Nettles/O'Toole article I just
read, which implies that their desired bound (50 ms) could be done that
way.  Would it be possible for a larger time slot, or is the collection
cycle bad in the worst case?

3) A general question about promotion policies.  Has anyone considered
what empirically happens to an object AFTER a pointer to it gets stored in
an older generation?  Intuitive, I would think that it would have a much
higher probability of surviving for a long time, but I wouldn't know how
to start an empirical test of such a thing.  What would happen if I were
to (drumroll) tenure an object as soon as a pointer gets stored into it
from an older generation?  Especially since the new generation here is 
really just a hack to get better allocation performance and locality
from an otherwise concurrent collector.  This eliminates the x-gen pointer
problem, but at what cost in terms of unnecessarily promoting objects?
(The object doesn't need to get moved immediately, which would require
synchronization, but it can get marked for immediate tenuring at the start
of the next collection cycle.)

Chris Smith
Computer Science Major
University of Oklahoma