GC incremental

Tue Oct 2 17:28:00 GMT 2001

> From: Jeff Sturm [ mailto:jsturm@one-point.com ]
> 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.
If I get some time, I'll try this.
>> > 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.
How big was the heap for that experiment? The cost tends to be proportional
to the size of the heap, even if you do it right. The question is: How big
is the constant?
>> > 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.
I agree with the "It should be faster" statement. Based on some experiments
with C code, it sometimes is. And it sounds like your code might be a good
example of that.
I doubt that it's realistic to keep the young generation in cache. You
would need to collect too frequently, and the collector still touches too
much other stuff. From what I hear, it doesn't usually work with HotSpot
either.
>> Yet the incremental collector seems to scan the entire heap on each
> collection. Or does it not?
It shouldn't. It should skip pages that haven't been written, which may be
a lot of them. If we could reliably get page dirty information on static
data, it would be even more of them. There's probably further tuning
possible to increase the number of clean heap pages.
With the dumb fallback dirty bit implementation it does scan everything,
since everything always appears dirty. But incremental collection isn't
interesting in that case.
Hans