why does JNode need to implement VM itself?

A microkernel (in the classic sense) is a minimal operating system that understands how to manage / map memory and device registers, how to manage and schedule "processes" and (maybe) "threads" ... and not a lot more. In particular, it does NOT understand hardware devices, file systems, network stacks, keyboard / mouse / graphics services, and most of the things that you normally expect an OS to provide. These things are provided by a various "service" processes that run on top of the microkernel. Each of these services typically runs in its own virtual address space and communicates via some IPC mechanism.

A typical JVM runs within a user process managed by a regular operating system. It expects the operating system to provide support for hardware devices, file systems, networking, consoles, graphics hardware and much more. If you look in the OpenJDK sources for SCSI drivers, Ext2 drivers, X11 server and so on, you won't find them!

If you try to run a classical JVM on a classical microkernel, there is a big gap between what the microkernel provides and what the JVM requires. If you tried to fill that gap in Java, you'd be implementing each of these services in its own little JVM, with each of them talking to each other via IPC. I don't see any real potential advantages in doing this compared with (say) just running a Sun JDK on Linux. It might be an interesting project ... but we are doing something more interesting.

In JNode, we've decided to put everything into one virtual address space, currently 1-to-1 with the physical address space. With everything in one address space, we don't have the overhead of marshalling data, switching TLBs and so on each time we talk to a system service. A "call into the kernel" is just a plain procedure call. The assumption is that the JVM implementation and Java security prevents different actors in the same address space from interfering with each other. (It turns out that this is not entirely true, and that is why we are implementing Isolates.)

At the base of JNode there is a nanokernel written in assembler that does LESS than a classical microkernel. It deals with setting up hardware after entry from the bootstrap, dispatching interrupts, Java thread switching and similar very low level things that cannot be expressed in Java. There's also a fair bit of assembler support for getting Unsafe.debug(...) output to the PC console and the serial port. But all of this amounts to just a couple of thousand lines assembler. That's probably less than 0.01% of the codebase when you include classlib.

The rest of JNode is ALL implemented in Java. The OS kernel layer that includes scheduling, memory management / GC, native code compiler, device drivers, file systems, network and graphics stacks, and so on. On top of that is the applications layer that includes the shell and command interpreter + command line apps, and the JNode 'desktop' + gui-based apps.

We use OpenJDK and (previously Classpath) in an interesting way. Roughly speaking, the OpenJDK codebase consists of pure Java code that implement the platform independent aspects of the Java Class Library, and 'native' method calls that deal with platform interactions. When OpenJDK is used as part of a typical JVM on (say) Linux, the 'native' methods (which are implemented in C / C++) make system calls into the OS kernel to do I/O, create processes, read the system clock and so on. In JNode, the OpenJDK "native" method calls are vectored to JNode-specific Java code that (ultimately) implements the scheduler, the device drivers, the file system, and so on. This is all Java code, apart from the nanokernel. Indeed, there is probably a less non-Java code in JNode than there is in (for example) a Sun JRE.

I'll give some of my thoughts to your question.

First of, I'd actually state that JNode/the JVM is completly written in Java. The assembly code can be considered as a bootstrapper, but it's not really used during runtime. As our compiler can emit native opcodes it's a question of how you view on it. As I'd count the stuff emitted by our JIT to be Java code, I'd state JNode is running 100% Java code (Especially as it intrigue people ).

There are other projects having the idea of running an existing jvm on an existing kernel. As Steve said, JNode's idea is different, we want plain Java and I'll give you some ideas as to why this (can) make more sense than having an existing kernel as the base:

• We have very cheap InterProcessComunication as we have one huge linear address space (Especially with a microkernel IPC would be much more expensive)
• We do not need TLB flushes, the pagetable does not change on task switches (probably less cache misses).
• We can compile optimized kernel code for hotspots. You can not do that with existing native code.
• This e.g. can lead to driver code inlined to userlevel code.
• We already have all advantages now that a microkernel would bring us, without the cons.

I hope I gave some usefull points that give you more insight.