why does JNode need to implement VM itself?

It can only make a bootable JVM layer to adopt so many kind of opensource's VM like jikesRVM, openJDK and Harmony etc. so we provide opportunity to compile on the fly and to change VM on the fly !-)
remember the JNode goal:The goal is to get an simple to use and install Java operating system for personal use. Any java application should run on it, fast & secure!

Making VM itself doesn't make any effort on this goal. anyway, I don't prefer to implement VM in its main branch. It's not what Jnode should be. Anyone interest in VM could start a subproject and get involve in it.

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.

Java doesn't support @asm, and I doubt that Ewout would have countenanced hacking the bytecode compiler to do this kind of thing. Besides, since the front-end generates bytecode files it would be difficult to implement the bytecode and native code compilers to support something like @asm.

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.

Stephen and Peter ...
Today after many months the link http://www.jnode.org/node/175 showed me the Jnode Architecture diagram ... dont know why it was missing/not visible for so long though the text mentioned it ....

However everything happens for the better ... i got even more insight into Jnode by your replies .... in fact these could be inserted into the standard documentation what say ... wuld be gr8 help for beginners who could be future committers .....

As I said in that other post (it was reply to you), when I say native method, it's a method with the 'native' qualifier in their signature. So, NativeXXX.class are only needed in JNode when the XXX.class has at least a native method (not matter if it's a class coming from OpenJDK are any other bytecode that need to be executed by JNode VM).

There are still some work needed to make Derby function correctly inside JNode. We had problems reconnecting to a created test database, which lead to a crash of the database. Due to the migration of using OpenJDK in JNode I have not been working on this for some time. I know this doesn't answer your question on the native class matters, but this was ment to inform you.

No, but by letting Derby create the database from the jdbc string when I tryed to connect to the database from a remote client. I properly should have responed to the "Native Database" thread, but I have been on vacation and didn't read all the new postings.