3 ms·

What don't you like about Go's GC? Compared to Hotspot, it doesn't STW; it makes a different throughput/latency tradeoff that is more suited for its applicatio

by mappu 9y ago

What don't you like about Go's GC? Compared to Hotspot, it doesn't STW; it makes a different throughput/latency tradeoff that is more suited for its application domain; and it's actually needed a lot less often because the compiler can put many objects on the stack. A generational collector is currently under development (but won't be in 1.10).

openasocket 9y ago
Hotspot has several GC algorithms available, FYI. And the term "stop the world" is misleading, it doesn't fully capture the nuance of garbage collection. Any GC algorithm that does compaction will require some sort of blocking. You can do compaction incrementally, so you only lock small sections of the heap at a time, but that would still be considered "stop the world" despite being orders of magnitude faster than the naive case. Go GC gets to make the claim that it doesn't "stop the world" because it doesn't do heap compaction. Which will become a major problem when dealing with large in-memory data structures or certain usage patterns. And the fact that they still don't have a generational collector is concerning.
- tychver 9y ago
  Erlang has a really nice solution here by using a separate heap per Erland "process", and because they're owned by that process, can do a copying/compacting GC without having to take any kind of locking. Ruby's Guilds could adopt a similar idea and avoid STW GC there too.
  - openasocket 9y ago
    Again, the term "stop the world" is misleading, there are a variety of compaction strategies that greatly minimize locking. There are even realtime GC implementations for the JVM. Erlang's solution is interesting, but remember in Erlang processes can't share memory, they only have message passing. So you never have to worry about multiple threads writing to the same data structure at once, which is what makes compaction hard.
    - tychver 9y ago
      Sure they can. There’s a separate shared heap which uses atomic ref counting.
twic 9y ago
As a Java aficionado, i have a lot of respect for Go's GC. It may not be as sophisticated as the JVM options, but it has a laserlike focus on low pause time, and does a phenomenal job of delivering it, given how much less development effort has gone into it. It's really lit a fire under the JVM developers, at Oracle and Red Hat, to improve the realtime collectors in the JVM. Not IBM or Azul, though, their JVMs already have kickass realtime collectors.
pcwalton 9y ago
> Compared to Hotspot, it doesn't STW Stop the world typically happens during compaction phases. Golang "solves" this by just not doing any compaction. That's certainly a big tradeoff. > it makes a different throughput/latency tradeoff that is more suited for its application domain I don't really agree. While low latency is nice for consistency, low throughput means you may have to buy more servers to handle your load. That isn't always a win. > and it's actually needed a lot less often because the compiler can put many objects on the stack HotSpot can, and does, do this too! > A generational collector is currently under development (but won't be in 1.10). Does it? Do you have a link? I haven't found any information about this.
- nurettin 9y ago
  Golang solves memory fragmentation by allocating more intelligently. I assume you know about tcmalloc?
  - tychver 9y ago
    Go merely adopts a different strategy which quietly fucks you in a different set of circumstances: https://news.ycombinator.com/item?id=15823683 https://news.ycombinator.com/item?id=15823683
  - pcwalton 9y ago
    HotSpot's memory fragmentation solution is superior, because it has a semispace copying collector in the nursery.
- remus 9y ago
  >> A generational collector is currently under development (but won't be in 1.10). > Does it? Do you have a link? https://docs.google.com/document/d/1gCsFxXamW8RRvOe5hECz98Ftk-tcRRJcDFANj2VwCB0/edit https://docs.google.com/document/d/1gCsFxXamW8RRvOe5hECz98Ft... This is the original proposal, although I believe it has evolved significantly during development (in testing some of the proposed ideas didn't pan out as expected).
  - 9y ago
julenx 9y ago
In a memory constrained environment, we recently noticed the throughput/latency tradeoff being made by the GC, but having to say that this behavior was not obvious in the first place and we had to dive into the source code to understand things better (which is a good benefit of go being open source, as already stated in the article). The bottom line is that the scavenger will allow the OS to claim free memory only at least 5 minutes after it was GC'ed. For us the solution was to "force" releasing the free memory to the OS [1], and even since then things have been much smoother in the context of our particular app. On this topic, there's an open issue [2] to look at making the scavenger more prompt and aggressive. [1] https://medium.com/samsara-engineering/running-go-on-low-memory-devices-536e1ca2fe8f https://medium.com/samsara-engineering/running-go-on-low-mem... [2] https://github.com/golang/go/issues/16930 https://github.com/golang/go/issues/16930

by mappu 9y ago

openasocket 9y ago

Hotspot has several GC algorithms available, FYI. And the term "stop the world" is misleading, it doesn't fully capture the nuance of garbage collection. Any GC algorithm that does compaction will require some sort of blocking. You can do compaction incrementally, so you only lock small sections of the heap at a time, but that would still be considered "stop the world" despite being orders of magnitude faster than the naive case. Go GC gets to make the claim that it doesn't "stop the world" because it doesn't do heap compaction. Which will become a major problem when dealing with large in-memory data structures or certain usage patterns. And the fact that they still don't have a generational collector is concerning.

tychver 9y ago
Erlang has a really nice solution here by using a separate heap per Erland "process", and because they're owned by that process, can do a copying/compacting GC without having to take any kind of locking. Ruby's Guilds could adopt a similar idea and avoid STW GC there too.
- openasocket 9y ago
  Again, the term "stop the world" is misleading, there are a variety of compaction strategies that greatly minimize locking. There are even realtime GC implementations for the JVM. Erlang's solution is interesting, but remember in Erlang processes can't share memory, they only have message passing. So you never have to worry about multiple threads writing to the same data structure at once, which is what makes compaction hard.
  - tychver 9y ago
    Sure they can. There’s a separate shared heap which uses atomic ref counting.

twic 9y ago

As a Java aficionado, i have a lot of respect for Go's GC. It may not be as sophisticated as the JVM options, but it has a laserlike focus on low pause time, and does a phenomenal job of delivering it, given how much less development effort has gone into it. It's really lit a fire under the JVM developers, at Oracle and Red Hat, to improve the realtime collectors in the JVM. Not IBM or Azul, though, their JVMs already have kickass realtime collectors.

pcwalton 9y ago

> Compared to Hotspot, it doesn't STW Stop the world typically happens during compaction phases. Golang "solves" this by just not doing any compaction. That's certainly a big tradeoff. > it makes a different throughput/latency tradeoff that is more suited for its application domain I don't really agree. While low latency is nice for consistency, low throughput means you may have to buy more servers to handle your load. That isn't always a win. > and it's actually needed a lot less often because the compiler can put many objects on the stack HotSpot can, and does, do this too! > A generational collector is currently under development (but won't be in 1.10). Does it? Do you have a link? I haven't found any information about this.

nurettin 9y ago
Golang solves memory fragmentation by allocating more intelligently. I assume you know about tcmalloc?
- tychver 9y ago
  Go merely adopts a different strategy which quietly fucks you in a different set of circumstances: https://news.ycombinator.com/item?id=15823683 https://news.ycombinator.com/item?id=15823683
- pcwalton 9y ago
  HotSpot's memory fragmentation solution is superior, because it has a semispace copying collector in the nursery.
remus 9y ago
>> A generational collector is currently under development (but won't be in 1.10). > Does it? Do you have a link? https://docs.google.com/document/d/1gCsFxXamW8RRvOe5hECz98Ftk-tcRRJcDFANj2VwCB0/edit https://docs.google.com/document/d/1gCsFxXamW8RRvOe5hECz98Ft... This is the original proposal, although I believe it has evolved significantly during development (in testing some of the proposed ideas didn't pan out as expected).
- 9y ago

julenx 9y ago

In a memory constrained environment, we recently noticed the throughput/latency tradeoff being made by the GC, but having to say that this behavior was not obvious in the first place and we had to dive into the source code to understand things better (which is a good benefit of go being open source, as already stated in the article). The bottom line is that the scavenger will allow the OS to claim free memory only at least 5 minutes after it was GC'ed. For us the solution was to "force" releasing the free memory to the OS [1], and even since then things have been much smoother in the context of our particular app. On this topic, there's an open issue [2] to look at making the scavenger more prompt and aggressive. [1] https://medium.com/samsara-engineering/running-go-on-low-memory-devices-536e1ca2fe8f https://medium.com/samsara-engineering/running-go-on-low-mem... [2] https://github.com/golang/go/issues/16930 https://github.com/golang/go/issues/16930