If you like well-documented bootstrap processes, I can recommend this:

https://github.com/fosslinux/live-bootstrap/blob/master/part...

The steps go from a binary seed of a few hundred bytes to (almost) gcc. It is still being actively developed as part of the Bootstrappable Builds project:

https://www.bootstrappable.org/

A PDF containing a graph of the process:

https://github.com/oriansj/talk-notes/blob/master/live-boots...

> I wonder if we could reduce binary size with a dead-simple scheduler and GC

For many CLIs I think even a brain-dead bump allocator would work

musl automatically uses a bump allocator if free is not referenced in the program.

Interesting. I couldn't find any documentation for how this happens (does it need compiler/linker support to know whether free is used?), but I did find the source code for this __simple_malloc: https://git.musl-libc.org/cgit/musl/tree/src/malloc/lite_mal...

That's really cool!

Though, I'm curious... don't a lot of malloc implementations use a bump allocator if a simple fragmentation heuristic is below some limit? Presumably musl down inside malloc() has a static bool (or a static function pointer) it uses to keep track if dlsym() has ever returned the address of free(). How much faster is the musl implementation than an implementation using a simple fragmentation heuristic? Presumably, they're both well-predicted conditional branches (and/or indirect branch targets well predicted by the BTB).

Musl's implementation only works for statically linked programs.

A programming language professor working on interpreters once said - for short-living processes the most effective and efficient garbage processing might be... not to and terminating the process. The OS will collect all garbage at once very quickly. So why bother time spending being smart?