RE: GC incremental

["Boehm, Hans" <hans_boehm at hp dot com>]

A couple of further observations:

The collector currently write protects the entire heap in incremental mode.
It could arrange to not protect pointerfree objects, which would take care
of the byte array problems (assuming hash synchronization is enabled).  The
down side of that is that I would expect that reprotecting the heap now
becomes appreciably more expensive, since it potentially needs to be done a
page at a time, instead of doing it in a small number of chunks.  But I
haven't measured that cost.  And it would save the time of taking the fault.

Taking this route would require that system calls write only into
pointerfree memory or outside the heap.  Is that an issue for libgcj?  If
not, perhaps this is the right approach?  (It does have the advantage that
failure to obey this rule will result in EFAULT returns from system calls,
and not random dropped objects.)

Re: kernel-based dirty bits

My impression from the Solaris /proc-based dirty bit implementation was that
the interface was suboptimal, but that was pretty much down in the noise.
The real issue was that the call to retrieve the dirty bits seemed to be
implemented under the assumption that performance didn't matter.  The cost
of that one system call ended up accounting for a large fraction of GC pause
time in incremental mode.  (It would be interesting to know if that has
changed since I tried it.)

To justify supporting this in the Linux kernel, we really need two things:

1) A convincing argument that some applications really need it.  In spite of
the bad reputation for long pause times that garbage collectors have
traditionally had, this doesn't seem to be that easy.  Processors have
gotten fast enough that lots of applications don't really seem to care.  You
need fairly large heaps (10s -100s of MB with a modern workstation/server
processor) to get human-noticable pause times.  Clearly there aren't
currently many users of the incremental GC.  That's probably due in part to
the difficulty of using it.  But it would be interesting to me to hear about
applications that need this support.

2) An implementation that incurs essentially no cost for applications that
don't need it.  Based on a previous discussion with David Mosberger, it
seems possible to do it at essentially no cost on Itanium, with a somewhat
limited, but adequate interface.  But this depends on the page table layout,
and is thus very architecture specific.

Hans