4 ms·

Huge improvements to the GC in this release, illustrated in this slide deck linked from the notes: https://talks.golang.org/2015/go-gc.pdf https://talks.golang.

• easytiger 11y ago
  > Tell people that GC is not a barrier with Go’s low latency GC If you have a time target of 350us, then a 3 millisecond pause means you are dead. So you either write Go in such a fashion as to not create junk or use c++. Systems and time sensitive languages cannot have GC.
  • duaneb 11y ago
    > Systems and time sensitive languages cannot have GC. This is not true, as not all GCs are stop-the-world, and all GC systems have some sort of pool system allowing you to manage/batch your allocations and sweeps. Root all your allocations for the inner loop, and unroot them/trigger a release when ready.
    • pcwalton 11y ago
      > This is not true, as not all GCs are stop-the-world, and all GC systems have some sort of pool system allowing you to manage/batch your allocations and sweeps. Root all your allocations for the inner loop, and unroot them/trigger a release when ready. Not for all allocations. You can manually do it for a subset of them, but pooling all allocations is generally extremely impractical. How do you, for example, pool the allocations that closures or defer perform?
      • duaneb 11y ago
        > How do you, for example, pool the allocations that closures or defer perform? It's a strange area that demands reliable or stable performance but uses closures and exceptions, two ways to inject a healthy amount of noise into your understanding of the program, and certainly blows the upper bound on "arbitrary wait time" to huge. I haven't been presented with a problem yet that allowed you to complain about GC with respect to latency where you would want implicit allocations happening all over the case....
        • pcwalton 11y ago
          You can't get away from exceptions in Go. Closures, maybe, depending on the code you're writing (though I doubt it), but the highly dynamic semantics of defer makes it impossible to avoid.
  • Zikes 11y ago
    Are there GC'd languages that can get to 350us?
    • seiji 11y ago
      Erlang doesn't share data between VM processes (green threads) and each process has its own heap, so you don't need to stop-the-world. Your GC can run concurrently with other live processes while still serving clients. Erlang also gives you the ability to manually invoke the garbage collector per-process so you can run it at more optimal times of your own choosing. Related: http://www.evanmiller.org/why-i-program-in-erlang.html http://www.evanmiller.org/why-i-program-in-erlang.html
  • bbrazil 11y ago
    While GC is always going to take some resources, the new Go 1.5 GC will bring the latency down such that a lot more use cases will be able to consider it. Going from seconds to milliseconds is huge.
  • cwzwarich 11y ago
    It is going to be difficult to achieve a hard 350 us minimum latency requirement on a general-purpose OS with a virtual memory system, regardless of the allocator you are using.
    • iofj 11y ago
      That you need to unmount swap (and change the overcommit memory setting) is a given, even for soft-real-time. Hard realtime linux systems do that as a basic given, and all real-time code I've ever seen was C, C++ or SmallTalk, and effectively bypasses the kernel entirely.
      • proveanegative 11y ago
        Is there an Azul equivalent for SmallTalk?