So they had to work with a few algorithms and tweaks. I wonder if there would be value in exposing the GC (and alloc) iface so others can implement without recompiling the language. I would love to toy with a pluggable GC. Last I looked at .Net's when it was open sourced, it was a gargantuan cpp file. I know LLVM has it somewhat pluggable. We can see a lot of Go GC's work at https://github.com/golang/go/blob/master/src/runtime/mgc.go but at quick glance, I couldn't see how I could plug in an alternative impl. Surely they had to build an experimentation abstraction to test their ideas, right? Or are GC's just so specialized and use so much internal knowledge that extracting a common iface is unreasonable?
Also,
> The math is absolutely fascinating, ping me for the design docs
The latest versions of OpenJDK have a pluggable GC interface, at the source level at least - you can't literally drop a DLL into a directory and load it dynamically, but the source code is modularised quite well and there are several different GC engines available to be chosen at startup.
Good to know, I knew that I could choose different ones at runtime via java args, but unaware there was a runtime interface. I see cpp code at [0] and some adjacent impls. is there a single C-level h file or is it cpp only? Any hello-world trivial impl?
The hello world collector is called Epsilon. Epsilon is the simplest possible collector: it never collects at all.
The next one up in complexity is called the serial collector. It's a stop the world mark/sweep design straight out of the 1980s, but it can be quite effective for small programs like command line tools, simple GUI apps etc because there's no heap overhead and no runtime overhead when not collecting.
After that you get into the more advanced algorithms. In order they'd be parallel, CMS, G1, Shenandoah/ZGC.
The different engines can be found one level up, here:
Ah yes, I saw the adjacent impls, didn't check deeper to see Epsilon was exactly what I was looking for. Thanks. I see even the ifaces are GPL sadly as are the impls. I am not sure the classpath exception applies to the interfaces. And I fear even reading/learning from the impls lest I want to use my GPL-gained knowledge on a distributed, non-GPL project.
GPL doesn't affect knowledge, only code. You can go work on proprietary software using things you learned by reading GPLd code, don't worry about that.
Also,
> The math is absolutely fascinating, ping me for the design docs
Ping! Publish them please.