News for hackers. Stuff that matters.
Re:Why Did Symbolics Fail? (2009) by aidenn0 on Wednesday February 26, 2014 @04:00PM (#7307763)
I can't find a reference for this, but I seem to recall that Azul uses virtualization features of modern CPUs to decrease the read-barrier overhead; if that is correct, then that's a case of the general-purpose hardware fortuitously getting features to out-compete special-purpose hardware.
Re:Why Did Symbolics Fail? (2009) by hga on Wednesday February 26, 2014 @05:29PM (#7308586)
No, the older version of their GC used bulk VM operations, but not virtualization features, and there was still a penalty reported ... errr, I can't find it now. Probably in a Clifford Click blog posting. I just skimmed the new edition of Jones' GC book (http://www.amazon.com/gp/product/1420082795/), published before it could consider the newer one; it talks about the changes needed on stock hardware but I didn't see any estimation of costs while glancing through it. (I'm not searching any more right now because it's obsolete.)

The base papers are:

Pauseless GC, uses a read barrier instruction in their custom 64 bit RISC chips: https://www.usenix.org/legacy/events/vee05/full_papers/p46-c...

And the newer one that they're using in that old hardware and the software on commodity hardware Zing JVM, the Continuously Concurrent Compacting Collector (C4), which I have not studied (the paper was published 2 weeks after the Joplin tornado trashed my apartment and rather disrupted my life): http://www.azulsystems.com/sites/default/files/images/c4_pap...

It's possible they figured out how to minimize or eliminate the penalties of the original software read barrier they applied to the Pauseless system in C4 (or perhaps in relation to their custom vs. newer commodity hardware); I just did a quick skim of the relevant part of the C4 paper and a few keywords and couldn't tell.

This is all great stuff that I hope to get back to soon....