There is still a couple of things that worries me. Given that they were mostly three working on Klein and that they never achieve a level of performance similar to their C++ implementation, I feel that the problem of boostrapping a system efficiently (in terms of development time) to achieve both simplicity and performance is not completely understood and therefore risky.
This worries me as well. The benefits they aim to achieve have not been demonstrated in any *objective* way, as of yet. They have spent years developing this system, and it still does not seem complete.
I can't completely nail it yet, but there is something that makes meta-circular implementation of live systems a lot harder to think about than plain layered systems with different "languages" for each of the layers.
It's the isolation of concepts that's missing. If you implement a VM in a language, to run another language, there is a clear separation between the host language and the implemented language. If the system is metacircular, things become much more blurred. Furthermore, it adds extra complexity in several areas... For example:
1. Our system, for example, will need to implement multithreading in JavaScript, if we intend for the VM itself to have a compilation thread, even though the JS spec does not intend for the language to be multithreaded.
2. We must make sure that the compiler can never break its own code while optimizing itself. We must also make sure that the GC, if written in JavaScript, cannot break itself.
3. We must carefully implement language extensions to allow for introspection and low level "unsafe" operation, even though this was never intended to be done in JavaScript.
4. We need some kind of explicit way of bootstrapping the system... We need a way for the system to generate an external image of itself.
To be successful, I think we will have to learn as much as we can from other projects. Talking about tools, I think the Maxine VM inspector is really interesting.
We need to pay extra attention to debugging. I was talking, for example, about the VM having a "debug" mode where it can generate some validation code (extra runtime checks)... But I don't know if we should launch ourself into a full-fledged GUI-based class browser, etc. We should make it possible to generate dumps of generated machine code and intermediate representations, however.
Still interesting to note that Sun lost interest in the Klein project but still kept the idea of meta-cicularity...
More or less. The Sun Java VM is implemented in C. That being said, I think they lost interest in SmallTalk and derivatives... They have their own business agenda involving Java.
I think that like microkernels, meta-circularity in a VM is an idea that sounds nice in theory, but might be very hard to do well in practice... Just like no mainstream OS are truly microkernel based, no mainstream language implementations employ meta-circular VMs.
I'm willing to give this a try, but I have serious doubts that we will be able to perform as well as a C based implementation, starting from a language as hard to optimize as JavaScript. I'm hoping we can get *decent* performance, and offset the compilation cost through the use of a compilation thread and compiled code caching.
I think the *one* true advantage of having a meta-circular JS implementation will be the fact that some important parts of our implementation (such as dataflow analyses, code generation), will be significantly easier to write in JavaScript than in C/C++. I also know that this will be publishable if we can get it working well.
- Maxime