3 ms·

Typical Go code does not generate a lot of short-lived objects, compared with, say, Java or with typical usage of persistent data structures in functional langu

by fpoling 10y ago

Typical Go code does not generate a lot of short-lived objects, compared with, say, Java or with typical usage of persistent data structures in functional languages. That removes the practical need for generational GC.

weberc2 10y ago
I'm also of the impression that Go's "transactional GC" is similar to a generational GC?
- pcwalton 10y ago
  Sort of, but it sacrifices the main benefit of generational GC by not allowing for bump allocation in the nursery.
  - fpoling 10y ago
    I thought it was compacting/moving GC, not generational one, that allowed bump-allocation.
pcwalton 10y ago
If this were true, then escape analysis wouldn't be so important in Go code. But it is: the lack of it is the reason why gccgo is slow in practice.
- fpoling 10y ago
  I see the importance of escspe analysis as another indication that tyical Go code does not generate a lot of short-lived objects on the heap. It is just the language does not allow to express particular stack-allocation idioms requiring the compiler to infer them. Compare that with Java where rather sofisticated escape analysis does not help much besides allowing to return several things cheaply from a function. Typical code there just does not follow stack-like allocation patterns.