Re: generational GC

[Michael Livshin <mlivshin at bigfoot dot com>]

Clark McGrew <mcgrew@ale.physics.sunysb.edu> writes:

> Probably Greg Harvey knows all of the answers!

I'm not Greg, but I'll try. ;)

> 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?  I'd
> imagine that chunklets and the mark stack cause make the code less
> local so there are more cache misses.  Does that have a big affect?
> This is not criticism, it just seems like GenGC is a lot of work
> unless "certain" to make guile faster.

1.  chunklets vs. locality.

chunklets are bad for locality in the sense that there will be a
1-cell hole per every 8 cells (or maybe even less, it all depends on
how much info a chunklet header is to hold).

OTOH, chunklets are good for locality at GC time, because all the
marking is done in chunklet headers, and you don't need to touch the
actual data cells for that.

finally chunklets are more GDB-friendly.  this is a big consideration
for me, but it may of course not be a big consideration for you.

finally finally, the discussion as to the approptiateness of chunklets
has a meaning only when the appropriateness of GenGC is questioned
too.  for GenGC, they are pretty much a requirement.

2.  explicit mark stack vs. locality.

I don't see any reason how locality might be affected, but maybe I
just miss something?

3.  do we relly need GenGC?

yes, if we assume that the generational assumptions hold.  if you use
set! and set-{car,cdr}! a lot, GenGC may well lose, yes.

I do think that GenGC should be a compile-time option.

-- 
:FATAL ERROR -- ILLEGAL ERROR-