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.

I don't see your point.

If you want operating systems to run the JVM of your choice, they already exist. They are called Linux, Windows and so on.

Or you could port the JVM(s) of your choice to run on a micro-kernel OS like Mach, L2, etc and build all of the OS services in Java.

But that's not we are doing.

Can you please explain this ....

a little bit more Stephen? Similar to the above idea it did strike me as and when i am increasingly giving a thought to jnode as why not just have a existing jvm ported to run above a microkernel ....

from you answer what is not clear to a beginner on jnode like me is What are we doing? since u have said that's not we are doing.....

is it that we are writing a OS from scratch ... kernel the jvm and also the JavaAPI modified or tuned to run on this new JVM ...

also are v writing a kernel newly altogether?

i know that EP (founder of JNODE) aimed to write the JVM completely in java?
So is it that the current JVM is totally in JAVA? or is it that its little assembly and rest JAVA?

i guess total JAVA would never ever be possible as of today ... thats what i feel ... (bold statement from a beginner on jnode) ... correct me ...

JVM on a microkernel

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.

A Java nanokernel

"a nanokernel written in assembler that (...) deals with (...) very low level things that cannot be expressed in Java"

As done for C language, we can defined native methods to be in-lined
which handler one assembler instruction.

For example:

   @asm("lgdtl (gdtr)") native static void setGDTR(long gdtr);

But that's not Java

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.

Java support annotations. But long term _extra_ feature.

Java support any annotation.
So we can write an "asm" annotation.

At first time, retention Policy could be SOURCE,
so that a tool extracts them to generate corresponding asm files.

Later retention Policy could be changed to CLASS,
so that a JIT compiler can use them.

Today we use unix/windows tool to build Jnode.
But in long time we could expect building it on a full java host, so with an assembler written in java.
Isn't Jnode's goal?

That would work ...

... as a way to supply an implementation of a native method. But we already have mechanisms that do this, by vectoring to native methods implemented in the assembler files.

Besides, some of the assembler stuff could not be handled this way; e.g the code that gets called to set up things before any Java executes, the code that vectors hardware interrupts, etc.

JNode kernel

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 Smiling).

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.

Thank you ...

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 .....

Also, one more clarification with reference to http://www.jnode.org/node/3045 and its replies ....

Do every single class in Sun J2SE will need to have a corresponding NativeXXX.class in Jnode?

What/Why is NativeXXX ? I do have some idea on why/what but would like to have it from the experts ... the thirst never dies ...Smiling

As I said in that other post

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).


my blog : en français, in english or both

Sorry Fabien

Got it now .... how silly of me not to have understood in the first go ...
God give me some quick understandings else these GURUS are gonna go BALD soon tearing their hair apart ....

so coming back to the Derby problem .... someones gonna write the missing Native class ...

From the screenshot http://www.jnode.org/uploads/derby_errror.jpg can anyone tell me which class and which method is exactly missing ....?

something in the sun.management package?

There are still some work

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.

moving the parent topic ?

Can someone move the parent topic (and all its children) written by hagar to http://www.jnode.org/node/956 because it's related to derby ?

I don't find a way to do such move and wonder if that's even possible with drupal (apparently only book elements seems to be movable).

PS : you can remove that comment when it's done.


my blog : en français, in english or both

Sorry ....

my mistake for bringing that up in this topic ... just innocently proceeded with the flow ....

Not confused anymore :)

It's not possible what you want todo.

And that's why ...

... it is a BAD idea to let forum discussions wander off into unrelated topics. Hint, hint Smiling

So you mean to say ...

... you were able to create the database using ij?

No, but by letting Derby

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.