status of gcj's boehm collector?

Tue Dec 4 15:32:00 GMT 2001

"Boehm, Hans" <hans_boehm@hp.com> writes:
> The collector does provide for incremental and generational collection, and
> has for a long time. Gcj currently doesn't support that functionality.

"that functionality" == incremental, or "that functionality" == generational,
or both?
> 1) It can only identify modified pages, not individual objects. And new
> objects often reside on the same page as old objects. This means that it
> spends appreciably more time scanning potentially old and modified objects
> than a copying generational collector. The net effect generally seems to be
> that it's a performance (throughput) win only for a minority of programs, or
> if your program pages. (In the latter case buying more memory is probably a
> better solution these days.) It does improve pause times.

This seems to be a reason why an incremental collector with page-level
granularity would have lower throughput than a generational
collector. Am I correct?
> 2) On a platform like Linux modified page information is kept by write
> protecting pages and catching write faults. This works fine if the page is
> modified as the result of an instruction executed by the user program. It
> causes problems if the write occurs as the result of a system call. Thus
> system calls must be suitably protected. There are some hooks in the GC
> library to do this, but libgcj doesn't. Furthermore, those hooks currently
> have problems in multithreaded environments with blocking system calls.
> (This situation is probably somewhat better on Solaris, since there is a way
> to retrieve dirty bits through /proc. We have vague plans to see if we can
> do this faster in Linux/IA64, but that's not going to happen soon.)

Okay, so this means that incremental GC isn't likely to happen. I
think I can live with that. How about generational GC?
 - a