How does it work?

Excuse if I am making a stupid question.

I want to know, how exactly is java bytecode executed on JNode. Is the part in assembler an implementation of a Java SE Virtual Machine? Is the bytecode compiled tu run on the processor. I am asking because Java bytecode needs a Virtual Machine that normally runs over the OS, so I assume that maybe a VM for java was implemented, capable of running over the CPU directly without a need of an OS. Is that right?


Pre-assembled by Ant script

Imagine writing a virtual machine using nothing but the Java programming language. How do you run a virtual machine without a pre-existing virtual machine? A method cannot assemble itself, right?

Please be aware that we use two virtual machines: a build-time virtual machine and a runtime virtual mchine. A foreign "build-time" virtual machine is written by someone else. It can be used to pre-assemble the prerequisite parts of a target "runtime" virtual machine. Therefore, an assembler is written using the Java programming language. At build-time, a target virtual machine is assembled using an assembler language. Certain methods have been assembled ahead of time. Ahead of time native code is platform-specific.

A target virtual machine has no runtime dependencies on a foreign virtual machine. Other methods are compiled just in time. A just-in-time compiler is platform-specific.

Apache Ant is part of the build-time process. A custom Ant task is used during the build-time process to assemble a kernel.

Minor nitpicks

(This is my understanding of how things work ...)

Using gchii's terminology, the 'build-time virtual machine' only uses the assembler to translate the tiny JNode assembly language core to machine code. All Java code that that contributes to the boot image for the JNode kernel is first compiled to bytecodes using the Sun Java compiler, then compiled from bytecode directly to native code using the JNode native code compiler. The assembler is not used in the process of compiling the Java code.

The other significant thing that happens in the 'build-time virtual machine' is the creation of the boot image. This image consists of the machine code produced by the native code compiler and assembler, together with images of Java objects, static frames and other stuff that are needed to get the JNode VM going. These are glued together by the 'boot image builder' using a mixture of high level black magic and gaffer tape. The result is the 'boot image' that GRUB eventually loads into memory on the target machine and starts via a jump instruction.

We use the term 'native compiler' rather 'just-in-time compiler' because JNode uses the same compiler in both the 'build-time' and 'runtime' virtual machines. In the 'build-time' vm, the compiler is called ahead of time.

Even in the 'runtime' virtual machine, the JNode native-code compiler is run eagerly when uncompiled classes are classloaded. By contrast, a classic Sun Java runtime will run bytecode methods a bit using the interpreter to try to gather some stats before using the JIT compiler to compile to native code. So, while the JNode native-code compiler is just in time in this context, a Sun JIT compiler is more so ...

And of course, the JNode native-code compiler and the assembler are both Java programs, as is the boot image builder.

This doesn't alter tricle's conclusions though.

Clarification required: just-in-time vs. hot-spot compiling

Sometimes, I use a technical term without properly clarifying what I mean. So, I am asking you for clarification on the term 'native compiler'. Is there a formal method of documenting technical terms for the project? Is there a dictionary for technical terms?

As I understand it, JNode uses a unique approach to the fundamental technical problem of writing an operating system using the Java programming language. (Many so-called experts have said, 'It cannot be done.')

A. Every class loaded by a class loader is compiled into native code. A native compiler is responsible for compiling a class file into native code. In other words, a compiler starts with a pre-compiled class file (or processor-independent code file) and always ends with native (or processor-specific) code. When writing a native compiler, we use the Java programming language. At build-time and runtime, the same compiler is used to compile a class.

In other words, a class is never interpreted; JNode has no runtime interpreter. This strategy reduces the development effort. Two parallel components, interpreter and compiler, do not need to be developed, maintained and tested.

On the other hand, a native compiler does not mean that a compiler is written in a native (processor-specific) language, such as assembler, or a non-Java language, such as C/C++.

At build-time, a relatively small part of JNode is compiled into native code. (1) A Java compiler reads a Java file and writes a stored class file, and then (2) a native compiler reads a class file and writes native code to another stored file. The stored file is platform-specific. Later, the stored file is loaded into memory. This is a classic example of ahead-of-time compiling.

At runtime, a small part of JNode is loaded into memory from a pre-compiled file. The remainder of JNode and applications are compiled into native code. a native compiler reads a class file and writes native code to memory. A native compiler is invoked when a class is loaded by a class loader. So, it is not necessary to store this native code in a file.

Is this an improved definition of terms? We need to clarify the meaning of just-in-time compiler and hot-spot compiler.

just-in-time vs. hot-spot compiler

The just-in-time or JIT compiler operates while the program is executed. This is in contrast with the ahead-of-time compiler which operates before the program is executed.
The JNode JIT compiles a method of a class when the method is invoked for the first time.

Hotspot is the name of a JVM and JIT compiler used in the JDK. The term refers to the special way of its operation where the JVM monitors the interpreter based execution of the code and compiles only the most frequently executed portions (hotspots) of the code.

Issue created ...

See issue 2935.

Very Impressive

Tahnk you for the answer.

That was really well thought. Now does that mean that JNode can be ported by porting the JIT compiler and the build-time virtual machine?


See Porting Guide

You're welcome. For more information on porting, see also Porting Guide.