Klein Metacircular Virtual Machine Kit
Work already done
Here's a quick list of what works in Klein today:
- The compiler can produce correct machine code for most Self code (not including code that uses dynamic inheritance). It can also do inlining, and is used statically (but not dynamically yet) to optimize some of the most frequent message-sends.
- The export system can produce a Klein bootstrap image containing a given list of modules. (We have used this to create several Klein images; the two most interesting ones are the full selfVM image, which contains the Klein compiler and object system and enough of the core Self functionality to support them, and the Yoda smallImage, which is a stripped-down image that might someday be suitable for putting on some sort of small device.)
- Reflecting on Klein objects (both inside the Klein image and remotely from the Self image used for development).
- The Klein compiler can run inside Klein, and will dynamically compile uncompiled methods.
- The remote debugging environment allows source- and machine-level viewing and debugging of live Klein objects and processes.
- The incremental update system allows changes to be made to Klein objects (in either a not-yet-running bootstrap image or a live, running image) without needing to rebuild the entire Klein image.
- There is a half-written Self interpreter written in C++, called Yoda. (Some functionality seems to work, including a very rudimentary and unfinished garbage collector.) Yoda is not really part of the main Klein system; it was an experimental offshoot of it that we never got a chance to finish.
Work left to be done
There is a lot of stuff that would need to be done before Klein could be a useful VM for the Self language:
- Performance. We haven't implemented very many of Self's cool optimization tricks yet. Here are some of the things we'd like to do soon:
- Garbage collection. We expect this to be trickier (and more fun!) in Klein than in a normal VM, because of Klein's metacircularity. (For example, what if the GC runs out of memory during a collection? What if the GC moves its own code out from under itself?) An extremely-rudimentary scavenger exists, and passes the first couple of test cases, but it needs to be fleshed out into a full generational collector.
- A lot of primitives (graphics, etc.).
- Floating-point numbers.
- We haven't implemented dependencies yet (which is fine for now because we haven't implemented recompilation either).
- Source-level single-stepping in the debugger. (There is a sometimes-useful approximation implemented now, but not proper source-level single-stepping.)
- Porting the assembler and compiler (so far there's only a PowerPC and SPARC assembler, and only a PowerPC compiler).
- Multiple processes inside Klein.
- Dynamic inheritance (though we hardly ever use it, and it may not be worth the cost).
- Many other things - search for senders of
todo to find some of them.