HN user
The delta layer is the part I'd want more detail on: once you're doing frequent consolidations against a multi-GB immutable core, what does write ampflication look like? That's usually where "runs in low hundreds of MB" plans get expensive.
Leaning on the original ROM for PRINT/INPUT/FP math is what makes this faithful instead of merely functional, since you inherit the hardware's quirks instead of reimplementing the away. Instruction-level rather than cycle-accurate is also fine here; nobody's timing-attacking a 921 kHz BASIC pocket calc.
You've basically build an LRU page cache with readahead for streaming 21, 504 experts off disk. Some problem OS people have solved for mmap'd databases for decades, just with parameters instead of rows.
The bug itself is almost boring - remove_waiter() clearing current's pi_blocked_on instead of the actual waiter's — which is exactly why it survived 15 years.
The thing that usually pushes you off Postgres is rarely raw throughput, it's two workloads that want opposite tuning on the same box.
That's TLS, crypto, and git-protocol code physically leaving the process that turns your source into machine code, and compiling the fetcher in ReleaseSafe while the compiler itself doesn't is the right call for code parsing untrusted network input.
This is the trick that kills the dual-write bug in money-movement systems: co-locate the checkpoint with the write so a mid-workflow crach can't leave you half-commited.
Bounds and div-by-zero are the easy wins; the real tax with contract systems is the loop invariant Z3 can't infer on its own, where you end up hand-writing an `ensures` longer than the function body. What's the gnarliest invariant you had to spell out by hand to get one of those kernels to verify?
Curious how you're handling supervision after the switch. The remoteproc unit you converted by hand is the part that gets interesting: when it crashes, what restarts it, and what guarantees it came up only after its dependencies were actually ready rather than just launched? That dependency ordering and the cgroup resource accounting are the real work, and OpenRC hands both back to you.
Quick one on the benchmark: was the 2.8GB peak virtual or resident? Go reserves a large virtual arena it mostly never faults in, so RSS tends to be a fraction of the virtual peak, and if Postgres headroom was getting squeezed off the virtual number you were sizing against memory the kernel never actually charges for.
Those cores aren't idle for lack of software, anything embarrasingly parallel eats all 144 fine.