Re: GC incremental

[minyard at acm dot org]

"Boehm, Hans" <hans_boehm@hp.com> writes:

> In general, I wouldn't expect a lot of improvement in overall GC overhead
> out of the incremental/generational mode.  Based on my experiments, it helps
> or hurts depending on the application.  The real reson to use it is to
> reduce GC latency.  If you don't currently have a problem with the GC
> latency, I wouldn't go down this road.

Yes, unless you have (soft) real-time requirements or a huge memory
space, incremental modes won't help you very much and will probably
hurt.

> 
> The real way to avoid the system call issues is to put dirty bit maintenance
> in the kernel.  AFAIK, only Solaris currently does that.  And (based on now
> very old experiments) that had a very slow implementation, making it much
> less useful.  Based on conversations with David Mosberger, it sounds like it
> might be possible to do this right on some Linux platforms.  But it hasn't
> been done, and I haven't heard from many potential users.

I had talked with the GCJ maintainers at Red Hat about this.  It
wouldn't be very hard to do, but it will be custom for every processor
architecture.

Instead of the way Solaris did it, I had envisioned the kernel trap
handlers making the page writable and enqueuing the page id in a queue
so it could be read out of a device.  You would have a blocking read
that would wait until the queue was full or it was sent a signal, then
it would read the pages out and process them.  I'm not sure if this is
that great, but it has to be better than scanning a huge table of
bitmaps (that's the way I remember Solaris did it).

-Corey