status of gcj's boehm collector?

Tue Dec 4 11:25:00 GMT 2001

Recently the version of the collector in gcj has been very close to the most
recent on my web site.
The collector does provide for incremental and generational collection, and
has for a long time. Gcj currently doesn't support that functionality. For
some specific applications you might be able to turn it on. For a large
system, it probably wouldn't work.
There are two main issues with it:
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.
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.)
As you implied, whether or not any of this is important seems to depend
hugely on the application. My impression (based on looking at run times for
various heap sizes) is that for some heavily multithreaded applications like
SPECjbb, the current collector probably does roughly as well as any other,
and better than those that have a single-threaded collector. For
single-threaded applications that allocate lots of short-lived wrappers like
yours, it would be interesting to try the generational collector.
Hans
> -----Original Message-----
> From: Adam Megacz [mailto:gcj@lists.megacz.com]
> Sent: Tuesday, December 04, 2001 10:43 AM
> To: java@gcc.gnu.org
> Subject: status of gcj's boehm collector?
>>>> I've been poking around Hans Boehm's web page, and noticed that the
> boehm collector claims to provide both incremental and generational
> collection (on most platforms). However, I also noticed that it says
> that gcj includes an "older" verison of the collector.
>> Does the version included with gcj provide generational collection?
> Incremental collection?
>> Generational collection is rather important for me -- my code
> allocates a lot of tiny, short-lived objects (I use Rhino, which has
> to create zillions of Number() wrappers when talking to host objects).
>> - a
>