Synthesis kernel and OS design

[Schol-R-LEA]

moved from "Designs of Microkernels".

Synthesis (which was sort of a hybrid kernel, but an unusual one) reportedly improved IPC dramatically, but did so with a very kernel unusual design combined with batching and 'folding' (pre-computing) both system calls and serial IPC messages. While it showed an improvement on two specific platforms for both IPC and system services compared to contemporary kernel designs, AFAICT no one has tested whether it would show the same improvement on present-day stock hardware.

Ooh! I've added Synthesis to my list of things to study. The concept of pre-computing always puzzles me though. Is it like caching generated code?

While generated code was the core idea in Synthesis, by way of what Dr. Massalin calls 'quajects', in the case of 'folding' she was referring mainly to finding commonalities with which the calls could be simplified or even eliminated, analogous to the process of simplifying an algebraic equation. By simplifying an operation which would have required multiple layers and multiple system calls, before any of the calls are made, it could reduce the number of context switches needed, or at least that's the idea.

It has been described as similar to currying, but without specifically being in a FP model.

The Synthesis papers can be found here (for an overview - note that these are from before Alexia Massalin transitioned, and thus have her deadname in the attribution), here (for the dissertation itself), and here (for a discussion on the I/O and threading performance), with the Sony workstation implementation discussed here. A somewhat easier to read HTML version of the primary dissertation can be found here.

Some additional discussion can be found on the old Portland Patterns Repository wiki. There's also this 2019 article suggesting that the design be revisited.

[eekee]

Thanks! I've started reading the first paper. I like the ideas. Section 2.3 both blew my mind and made me wonder why they would make it that way in the first place. The good bit is the task switch code path being reduced to 10 instructions. The bit I don't get is why each element in the queue has two bits of code attached in the first place. Why can't one routine do it without a jump in the middle and without being duplicated for every task? (Duplicated? Looks like it: "Each element in the queue contains two short sequences of code: stopjob and startjob." Emphasis mine.) All the same, I don't see anything wrong with factoring invariants or collapsing layers.

(I wonder if C[++] compilers these days can factor invariants, perhaps based on the const term? Stray thought. And I'm not exactly keen on const anyway; it's like a virus.)

Edit: Oh of course, runtime code creation will mean lots of bits of code attached to processes. It makes sense now. (I'm reading the blog post calling for it to be looked at again.)

[eekee]

I've been thinking a few things.

I can use some of Synthesis' tricks without run-time code generation. Routines for likely common cases can be pre-built. But it may be pointless, compilation can be very fast these days.

Synthesis techniques could be transparent to some languages. They of course would in OO languages where open returns a file object with methods, but they would also be transparent in Forth where you essentially put a file reference on the stack and then a word to do something with it. If that doesn't sound so direct, it's no different to how you use variables in Forth. Both are <data> <reference> <action>.

The kernel of simple Forth systems is essentially a compiler and REPL; everything that we think of as a kernel may be outside that. I think Synthesis-type optimizations are a natural fit to such a kernel... but my thoughts are starting to get muddled so I'll leave it at that. Edit: It was something to do with the Forth practice of defining wrappers for the smallest things. I think the compiler can optimize those.