> Thanks Dims. > > I'd again urge to not commit anything until we hash out some > policies. This is an important issue. > > In the meantime, any comments on architectures of some of the VMs? > I'm interest in having a balanced amount of upfront design that > prevents us from preventing participation from unexpected places in > the future... > > geir
I quickly reviewed some of the proposed VMs source code : - mudge is what I would call a 'trivial' VM : it works, but is more focused on code elegancy and architecture that on performances. That's mean it's small and easy to understand. But do a lot of C/C++ calls for each opcode (i.e. the stack is a C++ class) that might not be inlined. It's interesting as a small embedded JVM for scripting purposes. - JCVM is maybe the VM as I would have written it : it's pure C, quite easy, and yet focus on bringing good speed. The interp loop is well optimized but not very defensive : that means that a hole in the bytecode loader verifier could lead to a forged bytecode exploit. It doesn't do JIT, and instead generate C from .class and then call GCC and dynload the binary : that requires a lot of libraries and might not be the approach Harmony want. Also, I'm a bit worried about C code portability : does it compile and run on Win32 using MS compiler for example ? - JikesRVM is a big framework. I like the idea of self-hosting the JIT, for inlining reasons well explained here. Not sure about how it can speed up compared to a good JIT written in pure C however. As a framework, it seems to contain several compilers, maybe focusing on one main implementation would be better. So my choice would be to go for either a stripped JCVM and add JIT to it (it should already work with interpreted, so the JIT can be written in Java or C) or for a stripped Jikes that - while keeping the framework architecture to enable replacement implementation - focus on one main implementation. It's important choice since even if you are not caring about performances right now, this will be in the end the thing that will say if the project is either successful (speed can compete with Sun JVM) or failure (nice implementation, but a "toy JVM"). Nicolas Cannasse
