Re:Go GC: Solving the Latency Problem in Go 1.5
by fauigerzigerk on Thursday July 09, 2015 @10:41AM
(#9858077)
>Memory overhead: A non-copying GC has none
Do you have any idea what could make the Go folks ask for "in-memory heap sizes twice as large as reachable memory"? This seems to be completely at odds with what you are saying.
Re:Go GC: Solving the Latency Problem in Go 1.5
by rurban on Thursday July 09, 2015 @11:59AM
(#9858676)
Why? Reserving virtual memory has nothing to do with actual memory usage.
Re:Go GC: Solving the Latency Problem in Go 1.5
by fauigerzigerk on Thursday July 09, 2015 @01:28PM
(#9859361)
It would be great if they really mean virtual memory, but I very much doubt it as it makes no sense as a goal and is inconsistent with mentioning "Hardware provisioning".
So they need to scan the complete heap, while a good copying collector (e.g. a two-finger Cheney with forwarding pointers) would only need to scan the stack and some roots. My GC needs ~4ms on normal heap sizes, the fastest M&S GC's need ~150ms. But I haven't found a good version besides the Azul one, which works fine threaded.
Memory overhead: A non-copying GC has none. Lookup a GC book or explanation. Refcounts have plenty: 1 word per object. malloc has plenty for its free-list management, growing with the heap size.
A semi-space GC is different as it reserves for every heap segment a mirror segment. A fast version reserves max heap and divides it by 2, so can use max 2GB of 4GB. A normal version can do that incrementally.
Java has a huge memory overhead from the kernel and run-time alone, not so the GC, but since they have various swappable GC's you need space for that. You can write better and smaller run-times with GC which do run circles around Java, .NET, Go or Ruby. As I said mine needs ~4ms, the fastest java is ~20 - 150ms. v8 has a good one, but I don't know their stats out of my head.