Apologies if self-promo is not allowed.

This is a project I’ve been hacking on-and-off on for some years. The main point of intrigue is that the kernel doesn’t use traditional message passing for inter-process communication (IPC), instead allowing threads to be moved between processes. Compared to a typical synchronous message passing implementation, thread migration can be more parallel (several threads can enter the same process at the same time versus messages having to wait in a mailbox to be read) while being roughly as performant single-thread. I’ve benchmarked my kernel on real RISC-V hardware to roughly be on par with seL4. Thread migration could potentially also be significantly sped up with hardware: https://dl.acm.org/doi/10.1145/3064176.3064197

Personally, I also find that thread migration has some soft benefits, like easy userspace scheduling, being easy to implement and arguably allowing better resource distribution, that are more difficult to demonstrate but are probably worth bringing up. The major downside is that some of the flexibility of message passing is lost, message passing between networked computers is straightforward and asynchronous messages can allow the sender thread to do other things while it waits, which both require extra effort with thread migration (but are at least doable).

The idea itself is not exactly new, the first implementation of thread migration I could find is from 1994, in an experimental PA-RISC port of the Mach kernel, where the migrating thread model was retrofitted to a remote procedure call (RPC) mechanism that was previously built on message passing: https://www.usenix.org/conference/usenix-winter-1994-technical-conference/evolving-mach-30-migrating-thread-model

According to the article, thread migration made the RPC mechanism ~5x faster while requiring only about half the source lines of code. Unfortunately, the port never really went anywhere and Mach as a whole kind of disappeared. A form of it still lives on in GNU Hurd, but only the message passing parts.

Beyond that, I could really only find one other semi-active project using migrating threads, the COMPOSITE project: https://www2.seas.gwu.edu/~gparmer/publications/ospert10.pdf COMPOSITE was designed for thread migration, but targets a more niche use-case of predictable systems, which it argues thread migration is better suited for than message passing. Some design decisions place limitations on how the kernel can be used, for example each process is required to allocate execution stacks for however many threads the process is willing to host at the same time, which is not really an issue if you have full control over the system but can cause slowdowns and extra resource usage if you’re trying to use it as a general-purpose operating system.

I have a blog post which is something of a technical overview if anyone is curious: https://metanimi.dy.fi/blog/kmi/

The kernel itself is in fairly good shape, but I don’t really have a proper userspace for it quite yet, sorry. That’s something I’m semi-actively working on.