GC incremental

Tue Oct 2 16:56:00 GMT 2001

On Mon, 1 Oct 2001, Boehm, Hans wrote:
> Taking this route would require that system calls write only into
> pointerfree memory or outside the heap. Is that an issue for libgcj?

I think that would work with the current libgcj, assuming hash
synchronization. I have no idea whether there exists other CNI
code that could break.
> 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.)

On my Solaris 7 uniprocessor, GC_read_dirty completes in about 7 ms.
> 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.

Good point. I don't think incremental collection is terribly important to
us. We can easily withstand up to 500ms or so pause times. I suspect
generations could be much more useful however.
Our app retains 50MB or more of long-lived objects which are rarely
modified, and also creates about 1.5-3.0MB of garbage per request. If the
heap were divided into two generations, a minor collection would usually
be sufficient to reclaim enough heap. It should be faster, and much of
the younger generation could be kept resident in cache.
Yet the incremental collector seems to scan the entire heap on each
collection. Or does it not?
Jeff