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