harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Heath <steve.he...@gmail.com>
Subject Re: [arch] The Third Way : C/C++ and Java and lets go forward
Date Tue, 24 May 2005 10:39:26 GMT
If I've missed someone saying the same as me, my apologies..

You *can* code a VM in 100% Java, it just takes some other technology
(e.g. C or another JVM) to bootstrap the process. I'm just not sure
how useful it will be to do this. That question aside, here's how you
would do it from the ground-up (which I'm *not* suggesting should be
the approach for harmony - harmony should build on existing work
if/where possible).

We have 3 technologies in this example: native, C and Java

Code a Java->native compiler in C 
Code a Java->native compiler in Java 
Compile the second compiler using the first.
Throw away your first compiler - look ma, no C!
Compile the second compiler using itself (just because, ok!)
Code a JVM in Java
Compile the JVM using your Java compiler
Potentially re-use the second compiler as your JIT

Yep, there are other scenarios where you could achieve the same and
short-cut some of the steps, e.g. run the second compiler on an
existing JVM. There are also gaps I've intentionally left: GC in the
compiler, for instance. But you get the picture.

Having said all that, my personal opinion is to do as Geir said and
write/borrow a kernel which is written in C. Java is a very high level
language and I personally wouldn't feel I'd have the control over the
machine to make a powerful and fast VM.

Java for business programming, C for machine programming.

On 5/24/05, Dalibor Topic <robilad@kaffe.org> wrote:
> Archie Cobbs wrote:
> > Nick Lothian wrote:
> >
> >> According to http://www.csc.uvic.ca/~csc586a/Ass1.pdf JamVm lacks a
> >> bytecode verifier, too.
> >
> >
> > Seems like most O/S VM's don't have one (including JC)...
> Gcj, leading the way, has two, or three by now :) Kaffe and CacaoJVM
> also have their own implementations, and JikesRVM as well, afaik.
> The plan for Kaffe is to merge in the gcjx verifier, and try to
> standardise on a commonly maintained verifier component, to make sure we
> fix the security issues once, instead of fixing them everywhere:)
> cheers,
> dalibor topic

View raw message