Posted by Andres Valloud-4 on Feb 28, 2011; 8:41am
URL: https://forum.world.st/Azul-Pauseless-GC-tp3326066p3327624.html

> 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?

Andres.