Go GC: Prioritizing low latency and simplicity

Re:Go GC: Prioritizing low latency and simplicity by Gibbon1 on Tuesday September 01, 2015 @04:09AM (#10151251)

My experience is a lot of people/groups get obsessed with one metric in this case average speed. A pauseless GC is always going to be a bit slower than one that pauses once in a blue moon (meaning all the time from the users standpoint). Requires a really strong will to go against that sort of grain.

Just remembered though: Friend who is a Azul developer said that 0x86 processors did not have the correct instructions to support pausesless GC up until very recently.

So probably a chicken and the egg problem.

[ Parent | on HN ]

Re:Go GC: Prioritizing low latency and simplicity by rancur on Tuesday September 01, 2015 @03:36PM (#10155116)

can you open that up more? I'm skeptical. Which instructions?

[ Parent | on HN ]

Re:Go GC: Prioritizing low latency and simplicity by Gibbon1 on Tuesday September 01, 2015 @07:04PM (#10156402)

Over my pay grade, which is why I'm slopping away at ARM Cortex firmware instead of at Azul. I'd ask my friend but he's on vacation. I do know Azul originally ran their JVM on custom processors. (Target market high speed trading systems, etc) I can't see why they would have done that unless older 0x86 etc processors just couldn't do what they needed.

A little internet searching, leads to this and some other stuff. https://www.artima.com/lejava/articles/azul_pauseless_gc.htm...

I think the deal is, if the GC moves something, it can leave a bunch of dangling pointers. Those need to be fixed up to point to the new place before they get dereferenced. Except Azul uses a read barrier to trap when a dangling pointer is dereferenced, so the fix up can be lazy.

[ Parent | on HN ]