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
by sirwhinesalot
0 subcomment
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.
by antonchekhov
0 subcomment
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.)
by luafox
1 subcomments
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
by pizlonator
1 subcomments
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
by matthewmueller
1 subcomments
Appreciated the human element paragraph at the end!
by jecel
0 subcomment
If we label the combinations of the seen and scanned bits as:
00: white
10: gray
11: black
then we cam describe it as a very cool variation of the tri-color gc algorithm.
Hacker News