Sequence from boot to Jnode prompt in terms of source files

Can anyone give a diagram similar to the one on this page http://www.jnode.org/node/175, to explain the sequence of Jnode from grub boot menu to Jnode prompt in terms of source code files?

This will help us better understand the Jnode at a much much higher level (start level) which actually would be hugely helpful for the first step to delving into source code ...

An overview of the boot sequence

Grub will call the entry address found in the multiboot header (written by the BootImageBuilder).

Then the assembly code generated by org.jnode.build.x86.BootImageBuilder.initImageHeader(...) (see BootImageBuilder.initVm(...) and BootImageBuilder.initCallMain(...)) will be executed to call org.jnode.boot.Main.vmMain().

Finally, the vmMain method is trying to instanciate the main class declared in the plugin list you have choosen in grub :

  • "JNode GUI (all plugins)" : the main class is declared in /all/conf/gui-plugin-list.xml, in the manifest node
  • "JNode (default)" : the main class is declared in /all/conf/default-plugin-list.xml, in the manifest node

I might have missed some details since I had to dig into the code to give you these informations but I believe that's a good overview of the boot sequence.

Fabien

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

can you tell more dtails

Thanks Fabien,
So, the builder will be excuted just on build time and generate the native code type of Main class?
When the grub runs, it will jump to the entry of the assembled vmMain() method? Just like some other os will start an compiled & linked application image from its main function address? After that, how can the vmMain instance all of the plugins? will the plugins all be compiled to .class byte code type in build time and be translated to local machine codes now?

So, the builder will be

So, the builder will be excuted just on build time and generate the native code type of Main class?
Yes

When the grub runs, it will jump to the entry of the assembled vmMain() method? Just like some other os will start an compiled & linked application image from its main function address?
right

After that, how can the vmMain instance all of the plugins?
When you are inside vmMain, it's like for any other java applications.
But in JNode, each plugin has its own ClassLoader (PluginClassLoader).

Let say that the class C1 is in the plugin P1.
When a class C1 need a class C2. C2 is searched in that order :

  1. in the parent classloader of C1
  2. in the classloader of C1
  3. in the classloader of each plugin dependency of P1

Since PluginClassLoader extends ClassLoader, it's more or less the same ClassLoader mechanism that you find in any other VMs.

will the plugins all be compiled to .class byte code type in build time ...
Right. Like any other java application in binary form : it's a set of .class inside a .jar file.
In JNode, each plugin is a .jar file with its own classes.

...and be translated to local machine codes now?
The JNode build is compiling the core classes (mainly the classes from OpenJDK/IcedTea/Classpath) to assembly/machine code.

1) At early boot time, all classes must be in assembly code because JNode is not yet ready/fully initialised to be able to compile .class files to assembly code.

2) A bit later, still at boot time, some other classes (non core classes) are needed and are compiled from .class to assembly code to be executed.

For now, the compilation from .class to assembly code is done as needed and at class level : all the methods of the class are compiled at once, even if one of these methods is never called.

Fabien

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