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
Google Cloud products including GKE (Kubernetes), Cloud Run/Functions, the gcloud CLI, and a number of other utilities and control plane components sit it direct revenue paths. In the case of Cloud Run/Functions (Go support) and GKE, those products generate direct revenue, and the amount is much higher than you would think.
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
Thanks for this question! We added a couple sentences to the blog post to explain what a page is. In general, a page is a region of memory that has a large-ish fixed power-of-two size and is also aligned to its size. Virtual memory structures memory around pages, which are typically 4 KiB to 64 KiB depending on the hardware. The Go memory manager, and many other memory managers, also structure memory around pages, which may or may not match the hardware page size. In Go, pages are always 8 KiB and aligned to 8 KiB.
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.)
Congratulations to Michael Knyszek and Austin Clements for writing an absolutely top tier blog post that is as clear as it gets. I wish my writing was this good. I don't even use Go and it was still 100% a great use of my time to read this.
I'm a long-time fan of matcha and wrote the initial prototype that demonstrated Green Tea was viable while cafe crawling in Yokohama and drinking lots of matcha. "Matcha" didn't seem like a great name for a garbage collector, but matcha is a form of green tea and "Green Tea GC" rolled off the tongue, so I called my prototype Green Tea and the name stuck.
Good collectors are language independent. Bad collectors like Mark & Sweep are just needed for stable extern pointers, like in ffi callbacks.
All better languages use a modern copying collector, if they have enough memory. It's also compacting, and doesn't stop the world. I think lisps just do mark & sweep on phones or embedded, and the mentioned ffi callbacks.
22 comments
[ 4.6 ms ] story [ 48.8 ms ] threadI'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
00: white
10: gray
11: black
then we cam describe it as a very cool variation of the tri-color gc algorithm.
https://en.wikipedia.org/wiki/Tracing_garbage_collection#Tri...
All better languages use a modern copying collector, if they have enough memory. It's also compacting, and doesn't stop the world. I think lisps just do mark & sweep on phones or embedded, and the mentioned ffi callbacks.