[Pharo-project] Azul Pauseless GC

Andres Valloud avalloud at smalltalk.comcastbiz.net
Mon Feb 28 09:41:41 CET 2011

> Is VisualWorks' GC documented somewhere?

What kind of documentation do you mean?

> However, you might want to read the VEE'05 paper directly, the GC
> they use is 'nothing-like' a typical incremental GC. The read-barrier
> is the key here, and that is a rather exotic approach due to its
> constant overhead on standard systems.

I thought they get away with the extra expenditure because they can hide 
it under a multicore CPU (with the associated mutex section overhead 
etc), and because they have a compacting IGC that allows their very 
large images to run.  Probably it's a design decision to support huge apps.

> So, just in case VisualWorks is actually using something similar, a
> reference to a paper or some such would be great.

VisualWorks' IGC can mark and sweep incrementally.  It does not compact 
incrementally, either.  Somewhere in the source documentation there's an 
assertion that the read barriers to do that would be painful, so 
compaction is left to the stop-the-world GC.  The rest is pretty 
similar, including things like the targeted pause times (I'm almost done 
with an overhaul of that bit of the IGC implementation, actually).

Now, if you had a read check to see whether the object body was 
forwarded or not, then you could also compact incrementally. 
Unfortunately, checking before every read would probably cost you 
performance wise (plus: what happens when you want to forward an object 
body referenced by another thread in registers in the middle of an 
optimized section?).  So, depending on the application, it might be 
better to avoid stopping the world, while in other cases it might be 
preferable to skip the IGC completely and using the stop-the-world GC.

Finally, I am curious as to what kind of applications need on the order 
of 1TB of address space in a single "image".  Those image scales impose 
specific performance penalties e.g.: the IGC has to be more complex.  I 
wonder if those apps couldn't be written in a more "agent-like" manner 
to substitute controlled inter-image communication for the IGC 
complexities that affect the runtime in a pervasive way.  Do you know 
what kind of apps are those?


More information about the Pharo-project mailing list