Posted by Stefan Marr-4 on Feb 28, 2011; 9:29am
URL: https://forum.world.st/Azul-Pauseless-GC-tp3326066p3327671.html

Hi Andres:


On 28 Feb 2011, at 09:41, Andres Valloud wrote:

>> Is VisualWorks' GC documented somewhere?
>
> What kind of documentation do you mean?
A paper about the GC algorithm, the name of the algorithm?

>
>> 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.
Their target is/was mainly financial/trade applications hugh heaps, on hugh and expensive custom hardware. Order of 1000cores per box with a 54-core custom chip.



>> 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).
I guess it is some variation of a three-color incremental mark/sweep?


> 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?).
That is the whole point of their design.
They have a hardware read barrier, and they use traps do make that possible.
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...)


> 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.
As I said, they are after big financial and commerce applications, the stories Cliff Click is usually telling is that if they would need to do a GC in pre-Christmas load situations their customers would lose a lot of sales...
Everything is plain old Java, no idea what kind of custom solutions those companies built on top of that.

Best regards
Stefan


--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525