Hacker News Reader

Comment by geodel | Hacker News Reader

This is interesting

  – (Azul GPGC: 100's of Gig's w/10msec)
  – (Stock full GC pause: 10's of Gig's w/10sec)
  – (IBM Metronome: 100's Megs w/10microsec)

Some how these numbers are hard to come by in Java land where any request for hard numbers receives response like Java GCs are 'generational', 'state of the art', 'best in industry' etc. All the technical arguments while true of course but they do not tell numbers.

View on HN

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

"Supposedly?" I would have thought inevitably.

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

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

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

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

Reply on news.ycombinator.com