Wow… this is an excellent article. I’ve always been fascinated by GCs (well, as long as I’ve known what they are), and I just love seeing this kind of technical but accessible explanation of how they work, their bottlenecks, and a great new idea about solving those bottlenecks. This is exactly the kind of article that I hope to see every time I load up hacker news
If you haven't read about the CHICKEN lisp gc, ask your fave AI "How does the CHICKEN lisp Cheney on the M.T.A. garbage collector work?" It allocates heap objects on the stack and when out of stack, starts a new heap/stack copying live objects. Everything runs as continuations which is the reference to the song with similar lyrics. Since both stack and recent heap objects are contiguous it has great CPU cache use.
Acceleration by using the x86 AVX-512 extensions is especially compelling. Since ARM64 processors are becoming pervasive in server-side systems, is-there/will-there-be any optimization using the ARM64 NEON vector instructions in current or future Go versions? (The NEON instructions are 128-bit, instead of 512 bits in the AVX-512 set, but may still be useful.)
the two little slide decks showing each garbage collector in action are simply wonderful, and really help communicate how this improves go's GC situation
A (usually) small amount of memory that is the standard size all the memory management hardware and software use. Often 16Kb or 4Kb. If physical memory gets mapped to logical address space, address space marked read only, data swapped in or out, or logical address space gets mapped to other hardware (say GPU memory or a network card's buffer) it's usually done by page.
Kubernetes as a whole is the best example I can think of, given that it's deployed in most modern tech companies and every cloud provider offers a managed service.
Wow… this is an excellent article. I’ve always been fascinated by GCs (well, as long as I’ve known what they are), and I just love seeing this kind of technical but accessible explanation of how they work, their bottlenecks, and a great new idea about solving those bottlenecks. This is exactly the kind of article that I hope to see every time I load up hacker news
If you haven't read about the CHICKEN lisp gc, ask your fave AI "How does the CHICKEN lisp Cheney on the M.T.A. garbage collector work?" It allocates heap objects on the stack and when out of stack, starts a new heap/stack copying live objects. Everything runs as continuations which is the reference to the song with similar lyrics. Since both stack and recent heap objects are contiguous it has great CPU cache use.
Acceleration by using the x86 AVX-512 extensions is especially compelling. Since ARM64 processors are becoming pervasive in server-side systems, is-there/will-there-be any optimization using the ARM64 NEON vector instructions in current or future Go versions? (The NEON instructions are 128-bit, instead of 512 bits in the AVX-512 set, but may still be useful.)
the two little slide decks showing each garbage collector in action are simply wonderful, and really help communicate how this improves go's GC situation
This is very cool.
I've already been using bitvector SIMD for the sweep portion of mark/sweep. It's neat to see that tracing can be done this way.
VGF2P8AFFINEQB FTW
Wut? Oh boy https://www.felixcloutier.com/x86/gf2p8affineqb
vector, galois field, 2 to the power of 8, affine transformation.
there's also the inverse: https://www.felixcloutier.com/x86/gf2p8affineinvqb
Appreciated the human element paragraph at the end!
Yep, it's awesome how Michael keeps crediting collaborators, given how much of the work is his. Good job!
What's a page?
A (usually) small amount of memory that is the standard size all the memory management hardware and software use. Often 16Kb or 4Kb. If physical memory gets mapped to logical address space, address space marked read only, data swapped in or out, or logical address space gets mapped to other hardware (say GPU memory or a network card's buffer) it's usually done by page.
https://en.wikipedia.org/wiki/Page_%28computer_memory%29
I wonder if it can be abused with malicious actors that can arrange the RAM to be filled with pages containing just one alive object.
what revenue / profitable google services are actually relying on golang ?
Kubernetes as a whole is the best example I can think of, given that it's deployed in most modern tech companies and every cloud provider offers a managed service.