harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Renaud BECHADE" <renaud.bech...@numerix.com>
Subject RE: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Date Fri, 20 May 2005 02:29:46 GMT
>This is why I would like Harmony to have two VMs, one written in java
>and one written in C-or-friends: this would give us
> 1) the goal of making things modular enough to allow to swap things
>around and allow parallel development
> 2) create some internal (and friendly!) competition on speed and
>compliance :-)
> 3) attract two different pools of talents
> 4) allow compensation (easier to experiment in java than in C, harder
>to port java than C)

Having a plugin-based JVM based on a VM that already works (or even /ANY/
JVM if we suppose we do enough bytecode engineering[1] and limit ourselves
to minimum assertions on the runtime - say we only use JNI & Java debugger
interface & reflection to link bytecode with JIT generated code) could do
that, with the added benefit we have a working system NOW (including the
libraries for java 5, that are quite a big bunch of work in themselves, and
the packaging effort). I think this is compatible with the use of an LLVM
based solution too (for instance llvi calls gcj or another VM with the
adequate function pointers so that gcj can in turn call the LLVM-based VM

s/gcj/other vm/. My point is that gcj is working everywhere, really, even
obscure chips, and can potentially execute java5 bytecode (with the adequate
java 5 bytecode -> java normal bytecode + additional meta information in
some format if required), NOW.

That makes 2 VMs, one in C/C++ (bootstrap VM, a hacked version of an
existing one) and one in java (the JIT plugin), and also a common runtime to
develop (which in itself is resource-greedy)

Another point that is unrelated, but what about the "packaging" of the VM?
Do we plan to release it with say Eclipse + Server (JSF + IDE + object DB or
O/R mapping + HSQL DB)? (IMHO this is good way to legitimate it)

[1] ex: the AOP techniques used in JAC enable transparent distributed
deployment, such as for instance A calls B on machine x but in fact B is
working on machine y (and except from the AOP system, x has a jar of A+B, or
an empty shell of B, where a calls B the "usual way")


View raw message