A deep dive into the Go memory allocator and garbage collector

Re:A deep dive into the Go memory allocator and garbage coll... by barrkel on Friday August 31, 2018 @05:42AM (#17884194)

Most generational GCs will work better if you don't reuse objects - reuse extends lifetime and increases probability of promotion to an old generation, slower to scan. (Go's GC is not generational today, AFAIK.) I'd take any recommendations along those lines as last resort techniques to reduce pressure on critical path loops. And a more sophisticated runtime may allocate such temporaries in registers or on the stack.

In other words, you're tuning to today's runtime if you reuse heavily. Those techniques may not age well, and will harm readability and maintainability.

[ Parent | on HN ]

Re:A deep dive into the Go memory allocator and garbage coll... by ainar-g on Friday August 31, 2018 @08:15AM (#17884852)

>Go's GC is not generational today, AFAIK.

It isn't, and will probably never be. The Go runtime developers have actually implemented and tested a generational GC, but found that it's not useful, and even harmful at times, to the goal of having fast, low-latency, concurrent garbage collector. Mostly because most short-lived objects are allocated on stack, and the escape analysis is getting better with each release.

See https://blog.golang.org/ismmkeynote.

[ Parent | on HN ]

Re:A deep dive into the Go memory allocator and garbage coll... by pcwalton on Friday August 31, 2018 @11:02AM (#17886122)

The generational GC that the Go team implemented does not offer one of the primary benefits of generational GC: bump allocation in the nursery. Without that benefit, it's an unfair comparison.

This benefit is directly relevant to this thread, because bump allocation in the nursery makes the allocation fast path somewhere on the order of 6 instructions.

[ Parent | on HN ]