Hacker Read

fpoling | karma 3725 | avg karma 2.76 · 2016-10-29 09:29:48+00:00

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 | karma 4751 | avg karma 1.26 · 2016-10-29 14:53:53

I'm also of the impression that Go's "transactional GC" is similar to a generational GC?

pcwalton | karma 42908 | avg karma 5.48 · 2016-10-29 17:25:16+00:00

Sort of, but it sacrifices the main benefit of generational GC by not allowing for bump allocation in the nursery.

fpoling | karma 3725 | avg karma 2.76 · 2016-10-30 09:41:38+00:00

I thought it was compacting/moving GC, not generational one, that allowed bump-allocation.

pcwalton | karma 42908 | avg karma 5.48 · 2016-10-29 17:22:17+00:00

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.

_0w8t | karma 1 | avg karma 0.0 · 2016-10-30 04:37:43

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.

reply