harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo Kumpera <kump...@gmail.com>
Subject Re: Compilation of other languages
Date Sat, 14 May 2005 20:31:59 GMT
On 5/14/05, acoliver@apache.org <acoliver@apache.org> wrote:
> 2. Interpreting other bytecodes with the HarmonyVM - this is quite
> possible and might even be done in a performant way.  By tweaking your
> primordial classloader or having multiple primordial classloaders.
> HarmonyVM may already require its own instruction set for reinterpreting
> bytecodes into type-specfic bytecodes and other thing needed for
> optimization.  Its not that much of a stretch to have a slightly larger
> instruction set which encumpasses both say .NET IL and JAVA IL and finds
> common ground between them.  The difficulty is of course JNI vs .NET
> unsafe code and the likes.  You're also not necessarily breaking a lot
> of new ground (http://www.ikvm.net/).  Though doing it deeper inside the
> VM could give you more opportunities for optimization.

The java class file and it's bytecode instruction set is fair for
good, it's good to write interpreter, but suck for writing a JIT VM.
Same goes for ,net cli, but is even worse for interpreting.

GCJ does a better job compiling from java sources than .class files. I
have a hard time understanding why the JVM is a stack machine instead
of a RISC-like machine. It's possible to give the same garantees of
the java verifier for a register VM with the benefits that the time to
JIT will be a LOT smaller and better code could be produced with less
effort. There's no reason why the class file cannot carry information
about target independant optimizations (tips for partial redundancy
elimination, value ranges, etc).


Rodrigo

Mime
View raw message