On: Sub-millisecond GC pauses in Go 1.8

[_0w8t]

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.

[pcwalton → _0w8t]

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 → pcwalton]

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.

[weberc2 → _0w8t]

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

[pcwalton → weberc2]

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

[_0w8t → pcwalton]

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