SystemArchitecture.Main @ jos.sf.net

JJOSPages

In the beginning, there was the hardware. In this hardware, and on it, and over it, ran JOSBox; and verily, it was a virtual machine, composed of a kernel and a JVM; and there was much rejoicing, for JOSBox ran many bytecode applications simultaneously, whose names were MultipleJavaProcesses. Above JOSBox, there lived the Sun, whose platforms covered the sky in libraries. Between the Sun and the JOSBox were begat many layers, which were named many times and known by many names.

I think the Project agrees that the JOSBox is the native code necessary and sufficient to virtualize the hardware to some standard interface, so that device drivers can be wrtten in Java. That is, all the functionality above the JOSBox could be implemented in Java. Within the JOSBox, several architectures are possible. To borrow a term, we expect that the UltimateJOS, the distribution which one could install on an empty hard drive and run on naked silicon, will have a specific kernel part (hopefully implementing the KernelInterface), and a specific JVM part (hopefully written against the KernelInterface. The JOSBox could be implemented as a process on a host system; we would expect such an implementation, if based on a conventional JVM, to be incomplete, but useful for testing.

[Project overview] The teaseme project (http://teaseme.sourceforge.net) is a JVM which currently runs (to some degree or another) on three platforms: the Linux kernel, as a kernel module; a GNU/Linux system, as a user process; and on RJK, RobertFitzsimmon's kernel. /* In user mode? As the `init' process? */

The JJOS project is composed of two parts: decaf, a C++ JVM, and jJOS, a C++ and assembler kernel. decaf currently runs on jJOS and as a GNU/Linux user process.

At some layer above this, we wish to support the full Java API. Many libraries in the Java platform are Pure Java; a layer below them lies the `core Java API,' a small subset of which must be implemented by any spec-compliant JVM. Above this layer lies those classes required by the Java Language Spec. (This layer may be empty.) Above that layer lies one final layer before the full Java API: the libraries which require native libraries on conventional JVMs. Most of the functions of these libraries will be performed by bytecode in JOS: networking, file i/o, and the like. This is the domain of BCNI, ByteCode Native Interface, as akin to the Java Native Interface. I hope that BCNI could be implemented in the JVM; that methods marked native by, say, java.net.SocketImpl could be redirected to native.net.SocketImpl, or something similar, thereby minimizing the diffs that the Project has to maintain against its chosen class library or libraries. This may not be practical; in any case, GCHII is ready with his implementation of BCNI, which uses the factory paradigm to generate architecture-specific classes implementing with arhitecture-independent interfaces.

Aside from the Java API, we wish to provide the JOS API, which will expose the abilities of the operating system which are abstracted away by conventional JVMs. This would include, as a primary example, process control and inter-process communication. This layer would be notionally parallel to the Java API layer, since it would depend on operations not available through the Java API; it would, however, make use of the Java API as prudent. It would include an abstraction of the system in the same way that the JVM provides an abstraction of a conventional O/S process. (Notionally, the JOS `platform'; I am (will be) working on implementing console and keyboard abstractions in jos.platform.*.)Above this layer would the API used by application programmers, JADE, the JOS Application and Desktop Enviroment.

There are few other names lying around the Wiki which I will attempt to fit into this understanding of the JOS SystemArchitecture. JADE is in not, I think, in the JOSCore, but instead depends on it. The JOSExtensions are a layer below the Java API which provide the `native' side of BCNI. The JOSystem is part of the JOSCore, along with the kernel. The JOSCore marks the boundary above which no native (machine-code) components are required. The JOSystem, then, must be the Java to kernel bridge code.

I'll try an ASCII diagram, with where decaf's packages appear to go in (parentheses).


| `legacy' applications | JOS-specific applications | JOS systems programming |
|-----------------------------------------------------------------------------|
| java API              | JADE                      | JOS API                 |
|                       |___________________________|                         |
|____________________________________|                                        |
| core java API         |              (jos.platform.*, jos.system.*)         |
|_______________________|_____________________________________________________|
| JOS Extensions -- ByteCode Native methods (jos.platform.drivers.*)          |
|_____________________________________________________________________________|
JOSCore{ | JOSSystem { | JVM-spec-required or JVM-specific classes          | |
       { |           { |-------------------------------|--------------------| |
       { |           { | java to machine interface     | the JVM itself     | |
       { |           { | (virtual machine)             |                    | |
       { |             |          |----------------------------------|      | |
       { |             |----------| kernel                           |------| |
       { |_____________|__________|__________________________________|______|_|
|-----------------------------------------------------------------------------|
| the hardware                                                                |
|-----------------------------------------------------------------------------|

Dependencies proceed down the page. JOSCore = JOSystem + kernel, where JOSystem = minimal classes + JVM + java to machine interface. Note that the JOS API may depend on parts of the Java API (possibly distinct from the core java API), and that parts of the core java API may depend on the JOS API. I hope the diagram helps. :)

See DriverArchitecture for my understanding of how JJOS currently handles its drivers.

-- ToddMiller ( 21 June 2001 )

Content of these pages are owned and copyrighted by the poster.
Hosted by: