Re: status of gcj's boehm collector?

[Adam Megacz <gcj at lists dot megacz dot com>]

"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