I think when comparing numbers like that you might need throughput figures as well. Supposedly there is a tradeoff between GC pauselessness and throughput.

Azul's GC required a read-barrier (some instructions to be executed on every pointer read) - which cost something like 5% performance on an X86. In exchange max GC pause time is something in the low microsecond range (I helped implement the Azul JVM and portions of the GC relating to starting and stopping threads)

A friend of mine that worked for Azul said that older 0x86 processors didn't support the instructions that they needed. Which is why originally they built their own hardware. I'm uncertain what those are, but my impression is you can't do what they needed with a single atomic word access.

There's a talk somewhere (by Cliff again) on how the Azul chips differed from x86. Intel seems really slow to add features useful for high level GCd languages but apparently nowadays x86 has caught up which is why they don't bother making their own chips anymore.

No change to the X86, instead user-mode TLB handler from RedHat allows ptr-swizzeling, that plus some careful planning and the read barrier fell to 2 X86 ops - with acceptable runtime costs. Cliff

Yes, it's being discussed recently https://news.ycombinator.com/item?id=12044044

"Supposedly?" I would have thought inevitably.

Well I've never implemented a GC or built a processor specifically for implementing GC on.

I've seen stock full GC pauses take 10 minutes with 10s of gigs, so there is a lot of variability there