Re: generational GC

[Greg Harvey <Greg dot Harvey at thezone dot net>]

Michael Livshin <mlivshin@bigfoot.com> writes:

> Clark McGrew <mcgrew@ale.physics.sunysb.edu> writes:
> 
> > Probably Greg Harvey knows all of the answers!
> 
> > How's this going to affect performance?
> > I've seen all sorts of arguements that GenGC will speed things up, but
> > is it possible that the write barrier code will slow things down?  

It will slightly, in some places; this is why my changes used a gen
set explicitly when it was needed; the cost in the general case should
be fairly small, though (on the order of two operations per set, if
the object is young; the rare case of setting in an old object is
expensive, but not as bad as the alternative write barrier
implementation... it would take a tremendous number of these to make
up for the decreased mark & sweep times of a generational collector). 

> I'd
> > imagine that chunklets and the mark stack cause make the code less
> > local so there are more cache misses.  

Actually, it improves locality to a large extent; for chunklets (not
the originally proposed chunklets, which were not good in this regard,
but what's in my current tree) all writes during a garbage collection
occur to only a small set of mark pages, which are removed from the
heap; at the cost of an extra dereference to set a mark, there are far
fewer write faults, and the pressure on those pages will cause them to
always be in the cache; the current scheme writes to pretty much every
page.  Lazy sweeping also improves this, since the objects are only
cleared when that page is about to be used anew anyway.

For the mark stack, you're just improving on what
currently happens (the recursion in scm_gc_mark), but causing:

a) less memory to be used.  

b) only one page being written to for most of the gc (the mark stack,
even in large applications, rarely, if ever, grows past the page size)

Overall, there *is* an increase in processor usage, but the increase
is not utterly significant, and it does remove an awful lot of much
slower memory munging.

-- 
Gregh