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 <[EMAIL PROTECTED]> 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 >
