Re: gencgc performance and soft-real time

As a note on what Gerd said about the GC, only precise GCs can be
copying GC--the idea behind a conservative GC is that it checks
everything that *looks* like a pointer because it can't always tell
what is a pointer and what isn't, which is useful when adding garbage
collection to a language like C where there would be little or no
compiler support for it.  On the x86 the garbage collector is a
conservative collector so it cannot assume that everything that looks
like a pointer is in fact a pointer and modify the values, so it leaves
all of the data in place--otherwise it would risk changing an integer
value used in the program merely because it thought the integer was a
pointer.  Since the collector is conservative not all of the garbage
would always be collected, but a precise collector would most likely
create much more overhead in the code on the x86 because there are not
enough registers available to hold the extra state for the garbage
collector and to have separate groups of registers, one for pointers
and one for immediate data.

 - Brian


--- Gerd Moellmann <gerd.moellmann@xxxxxxxxxxx> wrote:
> Luke Gorrie <luke@xxxxxxxxxxxx> writes:
> 
> > What 'scavenge' does is update pointers to objects that were moved
> > during GC. To do this it rummages through and updates objects in
> > generations other than the one that was collected and objects in
> > "static space".  There is an optimization here: a "write-barrier"
> is
> > used to keep track of objects in other generations that have not
> > been modified since the last GC. Those objects can be skipped when
> > scavenging, because they can't point to freshly moved object.
> 
> <aside>
> Let me put that a bit differently, maybe it's helpful.
> 
> Leaving ambiguous roots and generations out for a moment, gencgc is a
> copying GC, which copies from-space objects to a new space.  GC
> starts
> by scavenging roots, which copies from-space objects referenced from
> places known to potentially contain references to live from-space
> objects.  Each time scavenge copies an object, it leaves a forwarding
> pointer behind in the from-space object pointing to the new-space
> copy.  When scavenge later scavenges a reference to a from-space
> object containing such a forwarding pointer, it updates the reference
> to point to the copy in new-space.
> 
> The write-barrier is an optimization of the so-called remembered set,
> that is, the set of references from older to younger generations.
> Without some optimization of the remembered set, one would have to
> scan all of the older generations to find references to live
> from-space objects.
> </aside>
> 
> > The trouble is that the write-barrier optimization is only used for
> > other generations, and not objects in static space -- so all static
> > objects are scavenged every time. This is typically several
> megabytes
> > of data. This is where the GC is spending all that time!
> 
> Could well be.  Since scavenging costs per Mb should be more or less
> constant, I'd expect this to depend on the ratio of the size of
> static
> space to the size of what else needs to be scavenged, and I'd say the
> latter mostly depends on how many live objects there are.  If there
> are few live objects, static space scavenging costs probably outweigh
> other scavenging costs.
> 
> > That's my theory anyway. I've checked by getrusage+printf and by
> > observing the effect of scavenging static space multiple times per
> GC,
> > and both showed that scavenging static space was the "hot
> > spot". Because I'm not actually modifying objects in static space
> (as
> > far as I know), it seems likely we could optimize away all this
> > scavenging and drastically shorten GC times.
> >
> > My first thought was to put a write barrier over static space.
> While I
> > was still struggling to make that work (but never did), Dan Barlow
> > suggested a more holistic approach -- why do we have so many
> objects
> > in static space, and could we not put them into a "tenured"
> generation
> > that doesn't get GC'd instead? That would give us a write-barrier
> for
> > free.
> 
> That would be nice, indeed.  If one does, one should probably move
> static space in the virtual address space so that one doesn't end up
> with an overly large page table, but I don't see anything making that
> impossible in principle, at least at present.
> 
> > Alas, my attention span was not great enough to read enough of
> > gencgc.c and purify.c to understand the full picture, so this is as
> > far as I've gotten.
> > 
> > Is anyone able to shed some more light?
> 
> Any specific questions?  I keep forgetting details, but maybe I can
> help with one or the other thing.
> 
> > (Wouldn't it be wonderful if a little optimization rendered the
> common
> > wisdom that "if response time matters then you mustn't cons"
> > obsolete?)
> 
> He, use dynamic-extent, that's why I wrote it :).
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com