Michael Knyszek

Happy to see someone outside Google rebuild/verify Go toolchains. Thanks @agwa.name! www.agwa.name/blog/post/ve...

"So far, Source Spotter has successfully reproduced every toolchain since Go 1.21.0, for every architecture and operating system. As of publication time, that's 2,672 toolchains!"

For some added fun, also see go.dev/cl/715362, wherein I discover that VPCOMPRESSQ is horrifically slow on AMD Zen 4, but only with a memory destination.

And thanks to @lemire.bsky.social for writing about this, which made this much faster to track down!

“The Green Tea Garbage Collector” by Michael Knyszek and Austin Clements — https://go.dev/blog/greenteagc

#golang

I can certainly see how that would be frustrating. I referenced the closed-as-dupe issues in the new issue as well, thanks for pointing them out!

Filed github.com/golang/go/issues/75967.

Not to speak for the person who closed it, but it's probably still accurate that nobody plans to work on it in the near future. However, opening a proper the feature request or proposal and leaving it open seems reasonable.

There might just be a misunderstanding here. That issue was about naming a flag that didn't end up making it in. In that context, it makes sense to close the issue, I think.

I'd love to hear from folks about your experiences. Do you use execution tracing often. If not, is it due to lack of need, lack of documentation, missing information, tooling issues, etc?

Go's execution tracer is a woefully underutilized tool. It contains tons of information about what is happening at any given moment that you won't get with a profile.

In addition to showing flight recording capabilities, this post provides a nice example of how to use tracing to diagnose a problem.

“Flight Recorder in Go 1.25” by Carlos Amedee and Michael Knyszek — https://go.dev/blog/flight-recorder

#golang

YouTube video by GopherCon Europe Testing Time (and other asynchronous code) - Damien Neil | GopherCon EU 2025

The GopherCon EU videos are online. I really enjoyed @misago.org’s about testing/synctest. But there were so many good talks, maybe watch them all?

youtu.be/oIC3zhTAOsY

#gopherconeu #golang

YouTube video by GopherCon Europe Faster Go Maps With Swiss Tables - Michael Pratt | GopherCon EU 2025

My GopherCon EU talk about Swiss Table maps is now available!

youtu.be/aqtIM5AK9t4

Nice!!

What if Go’s garbage collector could just run faster?

Join @michael.express from the Go Team for a deep dive into Green Tea — a new experimental parallel mark algorithm designed to speed up Go’s garbage collector through better cache locality and SIMD.

www.gophercon.com/agenda/sessi...

Significant Bits | Read/Write/Nil with Michael Knyszek and Michael Pratt Please read important erratum at end of these notes!Astute listeners will notice that this is the first episode in over a year. I recorded not one but two awesome interviews...and then failed to ed...

Thanks @commaok.xyz for hosting @michael.express and I to talk about a fun bug in Go’s new Green Tea GC and the tools we used to investigate.

sigpod.dev/6

runtime: green tea garbage collector · Issue #73581 · golang/go Green Tea 🍵 Garbage Collector Authors: Michael Knyszek, Austin Clements Updated: 2 May 2025 This issue tracks the design and implementation of the Green Tea garbage collector. As of the last update...

Please try it... 🙏 Instructions here: github.com/golang/go/is...

runtime: green tea garbage collector · Issue #73581 · golang/go Green Tea 🍵 Garbage Collector Authors: Michael Knyszek, Austin Clements Updated: 2 May 2025 This issue tracks the design and implementation of the Green Tea garbage collector. As of the last update...

New experimental garbage collector for Go programs! github.com/golang/go/is...

is that a pen plotter drawing by Michael Fogleman, maybe? (www.michaelfogleman.com/plotter/)

Agreed. It's already a niche tool and having it actually cause a real problem is likely even rarer than that.

It could be useful to us working on std, I guess?

The sketch doesn't currently report issues related to the tiny allocator, but yeah, I'm thinking that such a GODEBUG could.

If such a debugging mode would be useful, what would be the most helpful information for debugging? Stack trace where the finalizer was applied? The object's type?

How often do people run into the SetFinalizer footguns in Go? (Accidental cycle, for example.)

Would a GODEBUG that does something slow but tells you when you've made a mistake be useful to you? (Maybe even just for tests, to prevent a regression?)

Sketch: go-review.googlesource.com/c/go/+/634599