harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Cannasse" <ncanna...@motion-twin.com>
Subject Re: JIRA and SVN
Date Fri, 20 May 2005 01:04:20 GMT
> 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

View raw message