STW has to die. I love that the goal is 10ms but in some environments the world has passed you by in 10ms and with STW you've timed out every single connection.<p>I want badly to fall in love with Go, I've enjoyed using it for some of my projects but I've seen serious challenges with more then four cores at very low latency (talking 9ms network RTT) and high QPS.. I cheated in one application and pinned the go process to each cpu and lied to Go and told it there was only one CPU but then you loose all the cool features of channels etc.. That helped some but a Nginx/LuaJIT implementation of the same solution still crushed it on the same box, identical workload.<p>It would be nice if we have to have STW to have it configurable, in some environments swapping memory for latency is fine and should be configurable.<p>The way Zing handles GC for Java acceleration is quite brilliant, not sure how much of that is open technology, but it would be cool to see the Go team reviewing what was learned in the process of maturing Java for low-latency high qps systems.
People use the JVM in soft realtime / financial applications, and the trick is to reduce allocations, especially of objects that are long-lived enough to make it to gen 2.<p>Go is better suited than Java for those kinds of applications, because it's easier to avoid allocations (Java doesn't have stack allocations, but Go does.) Also hard upper limits on GC time are very helpful for those cases where allocations can't be reduced any further. The standard library additionally has a Pool type that allows for reducing pressure on the GC through object reuse.
For those interested in additional technical details of high-performance garbage collection, the book cited (The Garbage Collection Handbook: The Art of Automatic Memory Management) is a <i>fantastic</i> reference. It's one of the best-written technical books I own, and distills much of the modern literature. If you need to do GC performance tuning or reason about memory management issues in the JVM, having this book around will be very useful.
Seems like the 10ms pause thing provokes a much sharper reaction (at least among this crowd) than this little nugget:<p><i>"Hardware provisioning should allow for in-memory heap sizes twice as large as reachable memory."</i><p>So I know "memory is cheap"(TM) but surely a 100% physical RAM overhead for your memory management scheme is worth at least a small amount of hand-wringing. No?
10 milliseconds is far too long for STP for anything in the financial industry. I can see it as also not being great for robotics or several other latency critical industries.<p>It is a shame too. I love writing go
I'm absolutely in love with C++'s RAII scheme but it seems almost no languages use it and, instead, go with a complex garbage collecting scheme that requires pausing.<p>I want to like GO but a language that targets native development but still uses garbage collection just seems like an odd pairing to me. Maybe it's just me especially since I rarely get an opportunity to do native development.
"Quantitatively this means that for adequately provisioned machines limiting GC latency to less than 10 milliseconds (10ms), with mutator (Go application code) availability of more than 40 ms out of every 50 ms" --- once they get there, they should try to make those targets customizable, with default values being 10ms/50ms. That'd be marvellous.
Be fast and use Cheney (copying, double memory) or be slow with Mark&Sweep and only the current memory usage.
Nothing new here.<p>Catching up old GCs via concurrent GC states is fine and tandy, but it is still just catching up, and it requires GC state. Cheney not.
And a typical Cheney GC is 3-10ms not 10-50ms.
Go is a language built on concurrency. Today's computers are usually allocated a lot of memory resources.<p>Garbage collection is required but even a hybrid STW only reduces latency but doesn't eliminate it. Nor is there seemingly any foreseeable way of allowing developers to issue a GC request in a timely fashion.<p>What if, prior to enacting GC, Go concurrently shifted from it's current memory allocation to an exact clone, cleaned up, then shifted back? Or maybe it cleans as it's cloning, enabling a shift to a newer, cleaner allocation? Sure, there would be latency during the switch, but it would be considerably less than stopping everything and waiting for GC to finish.
When there's talk of making sure the GC doesn't take up more than 10ms out of every 50ms, this is only when the GC is actually happening and not during regular running, right?
Curious, how "real time" can a large application get in Go by judiciously working with pre-allocated structs and slices? Perhaps if the underlying system libraries don't require much garbage collection, then you can avoid stopping the world for too long.
As a side issue, are there any plans to switch to gcc as thr main compiler? It can do everything that 6c can do from what I understand, and produces much faster code due to gcc well tuned optimizer.