> 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.

>> 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/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).

That's not really a generational collector, and it doesn't achieve the main benefit of one: bump allocation in the nursery.

Golang solves memory fragmentation by allocating more intelligently. I assume you know about tcmalloc?

Go merely adopts a different strategy which quietly fucks you in a different set of circumstances: https://news.ycombinator.com/item?id=15823683

HotSpot's memory fragmentation solution is superior, because it has a semispace copying collector in the nursery.

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.

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.

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.

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.

Sure they can. There’s a separate shared heap which uses atomic ref counting.

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-mem... [2] https://github.com/golang/go/issues/16930