[Pharo-project] Azul Pauseless GC

Andres Valloud avalloud at smalltalk.comcastbiz.net
Mon Feb 28 11:20:54 CET 2011

>> What kind of documentation do you mean?
> A paper about the GC algorithm, the name of the algorithm?

There are some docs that state what happens, the docs come with the VM 
sources.  But, basically, when the IGC is marking, then writes into 
marked objects mark objects.  This allows mark stack consistency.  You 
can mark incrementally until the mark stack is empty.  Then you can zero 
out weak references that are gone (and deal with ephemerons).  After 
that, you can also sweep dead object bodies and put them back into the 
corresponding free block "lists".

The VisualWorks implementation is somewhat complex because there are 
many moving parts.  The IGC marks whatever is in old space.  Perm space 
("permanent" old objects) are assumed to never be garbage, so they 
aren't even marked.  New objects are not marked either because they are 
managed more efficiently by the new space scavenger.  There are remember 
tables that allow you to do all of this effectively.  Special care must 
be taken when tenuring new objects into old space if they were 
referenced from a marked object in the remember table for new space.  In 
64 bit systems, the class table is weak so you have to treat it as a 
special case.  Etcetera :)...

> Their target is/was mainly financial/trade applications huge heaps,
> on huge and expensive custom hardware. Order of 1000 cores per box
> with a 54-core custom chip.

Wow... I wonder what happens when (not if) it crashes.

> I guess it is some variation of a three-color incremental mark/sweep?

IIRC, "three-color" refers to "not marked, marked, and scanned".  If so, 
yes, it's sort of like that.

> One of the tricks they are pulling for that is that they return the
> memory page to the OS, and thus, they run into a trap when ever
> someone is referring to an old object address. Then, when that
> occurs they just fix the address to the new one. (as far as I
> remember...)

Oh, ok.  With such huge images, the likelyhood of any page being 
accessed must not be overly high.  I suspect they may have to have some 
sort of "mark stack" that cannot be paged out to make that possible.


More information about the Pharo-project mailing list