Introduction to Java operating systems, OS on a higher level.

By: Benedict Ching Wei Ming Martin Ericsson Peter Haglund

May 2006 Introduction

The way that programs are engineered has evolved from assembler to object-programming methods. However, the evolution of operating systems has not kept up with these new methods. There are now many different projects that are looking to solve this problem and in particular, how to get a more efficient operating system.

In this report, we will be introducing two projects, the JX Operating System and JNode. Both of these projects aim to implement a Java operating system as their goal. The JX Operating System project is a university development research project at being developed at the University of Erlangen-Nurnberg in Germany while JNode is an open-source project developed by Ewout Prangsma and his team of developers. These two projects differ a lot in terms of their implementation as well as support and funding. But we will be concentrating on a brief technical introduction of these two OS and an illustration of our work when we ran the two operating systems.

The JX Operating system

Golm et al [1] at University of Erlangen-Nurnberg has developed an operating system almost completely written in java. The goal was to achieve good performance and to be able to benefit from the object-oriented and type safe from java. They claimed to reach about 50% performance of Unix in a raw test and about similar speed as Unix when there's a lot of I/O going on. The reason why they did this rather unconventional design is that they believe that an operating system that is dynamically compiled, as java byte codes are, can in the long run outperform traditional operating system. This is due to the many compiler optimizations available only at runtime for example inlining virtual calls and the fact that you know exactly what system that your compiling for, what cache size you have and etc. A large thing for the project seems to be memory management and protection. The JX operating system is as written earlier almost implemented in java to a 100%. There is a small microkernel that implements things that java can't but should do, for example system initialization, saving and restoring CPU state and monitoring. The microkernel runs without any protection and must be trusted. A few more java components are also running without protection by default and these are also needed to be trusted. These are the code verifier, the code translator and some hardware dependent components. This resides in a so called domain, in this case the domain zero which contains all the untrusted code.

Domains The java code is divided up in components that are loaded into domains. The domains are at runtime compiled to native code. Domains are resource managers that are meant to be a protected unit. They are independent unit in that sense that they have their own garbage collectors that runs independently from each other and every domain can implement different garbage collector algorithms. Memory for it own threads and stacks are also allocated inside the domains memory area. Domains are independent but they are allowed to share classes and interfaces with other domains.

Portals To communicate between to domains something called portals are implemented. This work very much like java own Remote Method Invocation(RMI). An object that implements the portal interface is called a service and communicate with another domain. The portal interface includes it's own portal thread. So when a thread invokes a portal it will halt its own execution and continue the execution of the portal thread instead. To keep the isolation between domains all input parameters to a portal is copied at the invocation. The domain zero has several so called fast portals that are executed in the caller thread for performance reasons and might sometimes even be necessary to for example yield the processor.

Memory objects To deal with abstraction of memory JX create memory objects. The natural choice might have been java byte arrays but the authors points out several shortcomings of these. They feel that the lack of methods for accessing these and the fact that you can't make write protected memory with it was reason enough to create this new abstraction. Memory objects are like normal java objects but they are translated into machine code in a different way. They are replaced by memory access instruction and that makes them faster than if it should be compiled the traditional way. Memory objects can be passed to other domains but are not copied, it implements shared memory. An example of a memory object is the ReadOnlyMemory that simply lacks the write method.

Components As said before all java code is divided into components that are then loaded into a domain. Components contains classes, scheduling information, interfaces and so on. A few advantages with using components are compability, the whole system is build up with components. These are meant to be compatible with each other and changing one of them doesn't mean that you have to change them all with this property. A related thing is reusability as with all object oriented design. Even the java development kit(JDK) is implemented as a component. So when the traditional JDK calls a native method the JDK component calls domain zero via a fast portal.

Memory management The whole JX system runs in one physical address space and the protection is based on the type safety of java. JX have two levels of memory management, one global in the kernel that allocates memory for domains and one local in each domain. The global memory allocator automatically joins free areas of memory and has a very low memory foot print and overhead. Both stack overflow and null pointer detection is checked in software. In the current implementation the null pointer is checked by using the Pentium debug system and the stack is checked at the beginning of each method.

Scheduling As the authors point out, there is no perfect scheduler that fits all applications. This is solved in JX by using several schedulers. There is one global scheduler and then one scheduler in each of the domains. All these can be replaced by the user even at runtime. The idea is that the global scheduler schedules the domains and the domain that is active schedules which of its application threads should be executed.

A Brief Introduction to JNode

JNode is the abbreviation for Java New Operating system Design Effort. It is an open source project to create a Java platform OS where all software in this OS is created in the Java programming language, with the exception of some assembly language to boot and load the system. The goal of JNode is to get a simple to use and install Java operating system for personal use. Any java application should run on it, fast & secure.

The project is led by Ewout Prangsma and supported by his development team consisting of a handful of core developers. They started their first attempt in 1995 with the Java Bootable System (JBS). However, they did not like the amount of C and assembler required and moved on to a new attempt called JBS2. JNode is the third attempt, first introduced in May 2003. JNode uses only two languages - Java and Assembler.

Implementations JNode currently understands ext2, FAT, NTFS and ISO9660 file systems, TCP/IP network protocol and has the working graphic user interface, including USB peripherals. It can be booted from a CD or run in any popular emulator. JNode uses the GNU Classpath Java library and (when completed) should run any Java programs.

Currently, the latest version of Jnode is version 0.2.3 (as at 16 May 2006) that features some GUI and font rendering improvements from the previous version 0.2.2. Please refer to Appendix A for full details of draft versions for version 0.2 and Appendix B for full details of draft version for version 0.3. Change logs for details on enhancements made to all the versions of JNode can be found at http://www.jnode.org/node/52.

File System Framework The file system support in JNode is split up into a generic part and a file system specific part. The role of the generic part is: • Keep track of all mounted file systems. • Map between path names are file system entries. • Share file system entries between various threads/processes.

The role of the file system specific part is: • Store and retrieve files. • Store and retrieve directories.

JNode distinguishes between a File System Type and a File System. A File System Type has a name, can detect file systems of its own type on a device and can create File System instances for a specific device (usually a disk).

On the other hand, a File System implements storing/retrieving files and directories. A File System Type must be known to JNode before it can be used. Therefore, a File System Type must be registered in the File System Service. This can be done via the File System Service API or by adding a line to filesystemtypes.dat in the org.jnode.fs. service package. To access files in JNode, use the regular classes in the java.io package. They are connected to the JNode file system implementation. A direct connection to the file system implementation is not allowed.

Running the implementation

We ran both JX OS and JNode on a VM. The JX project had a demo-disk that ran easily with minimum resources while JNode, which seemed to have a more advanced, implemented version, required more resources and was more complex to run.

Not many operating systems require a Pentium III 1Ghz or better and 512Mb RAM just to run as JNode does.

Both operating systems have a non java implemented bootcode/bootstraper, in JX it is a C version and in JNode it is an assembly version.

Currently, the graphic interface for both the JX OS and JNode are in their early stages of development and simplistic in their design. Thus, we believe that the OS has not only to function efficiently but also have a good graphic interface that appeals to the masses for it to succeed. We have provided some screenshots of the user interfaces of both OS to give a visual appreciation of their usage.

JX Operating system JNode

Conclusions

A java operating system is mostly built by components where the bootcode/bootstraper and Java VM is in a low level language but the main part of the system is done in a high level using the java feature to compile in runtime and thereby getting compile optimisation for the hardware it is running on.

Based on the current stage of development, we think it will take some more years before a reasonably well working operating system in java is available. The JNode project will probably be the first to have a working system but not the smallest and efficient one. From what we can see, the JX OS is more advanced compared to the JNode in its construction and implementation but JNode presently has more implemented features.

References [1] Michael Golm, Meik Felser, Christian Waversich, Jurgen Kleinoder. The JX Operating System

[2] JNode homepage – www.jnode.org

[3] JX Operating system projectpage - www4.informatik.uni-erlangen.de/Projects/JX/ Appendix A: Draft 0.2 plan

We want this release to be the first usable version of JNode where we can run real world Java programs on. This means that we need a working filesystem, a stable virtual machine, a class library mostly compatible with JDK 1.1, a working TCP/IP implementation and a way to install it on a PC. It is not expected to have a fully working GUI yet.

Additional features

To achieve the target outlined above, each team will have to add/complement a number of features. These features are listed below. The percentages specify finised work, so 100% means completed.

JNode-Core 100% - Dynamically (re)loadable plugins 10% - Plugin install, upgrade & uninstall framework 50% - Second level native code compiler target as good (native) code quality 100% - Security system 0% - Setup utility 80% - Implementation of java.lang package 80% - Implementation of java.math package 60% - Implementation of java.security package 90% - Implementation of java.util package 80% - Implementation of java.util.jar package 80% - Implementation of java.util.zip package

JNode-FS 80% - Virtual filesystem (in progress) 60% - Implementation of java.io package 90% - R/w ext2 implementation 20% - R/w fdisk services ? - Format services for ext2 95% - ATAPI driver 95% - CDROM (ISO9660) filesystem

JNode-GUI 0% - Textmode userinterface for use in installer

JNode-Net 25% - TCP/IP stack, client & server 75% - Implementation of java.net package

JNode-Shell 100% - Commands to modify the classpath 100% - Commands to run java code, both .class and .jar files from any location. Appendix B: Draft 0.3 plan

Global enhancements

A major goal of this release is to reduce the memory footprint required by JNode. The VM will be enhanced to support this, and all parts of JNode will have to be more concerned about their memory usage. JNode will become localizable and translations for some locales will be added. Every new part of JNode will have to be localizable according to a set of rules that will be determined. The one and only language for the source code of JNode is and will remain to be English. The remainder of this page will describe the targets and enhancements of the various subprojects of JNode. The names between brackets in the enhancements sections are the names of the lead developer for that enhancement.

Core: Virtual Machine & Operating system The virtual machine will become more stable, reduce memory usage and will add support for Isolates (JSR 121). Furthermore it will enhance the J2SDK compatibility level. The operating system will add support for power management and make enhancements for that in the driver framework. An installer will be developed that is used to install JNode onto a PC system. This installer will put the essential structures/files on the harddisk of the PC. A persistent storage mechanism for plugin preferences will be added.

Enhancements: • Isolate support • Annotation support • Multi CPU support • Integrate MMTK garbage collector • Smart field alignment, to reduce the size of objects • Overall memory reduction • Power management support • API for halt, sleep & reboot of JNode • Installer • Persistent storage for plugin preferences • Access to detailed information about system information such as classes & their usage • Fragmented plugin support

Networking The network layer will be enhanced to fully support wireless networks. Furthermore, the existing TCP/IP stack will be improved in terms of reliability, safety and speed.

Enhancements: • Wireless network support • Wireless netcard drivers • TCP server side fixes • EEPRO100 driver

File system The file system layer will become more stable and will be refactored to make use to the NIO classes. Support will be added for a virtual filesystem that allows links between filesystems. A new "system" filesystem will be added that gives access to a distributed filesystem that contains the JNode system information. This system information is about plugins, kernels & preferences.

Enhancements: • Change file system api's to use ByteBuffers • Update java.io to latest classpath version based on NIO classes • System filesystem • USB storage driver • Extend support for EXT2 to EXT3 • Add write & format support to NTFS • Generic block cache for block devices

GUI The existing GUI will be improved in terms of stability, Java2D support and speed. The video driver interface may be adjusted to make better use of hardware acceleration. A user friendly desktop environment will be developed or integrated.

Enhancements: • Enhance java2D support • Improve use of hardware acceleration • Improve font rendering • Improve Swing awt peers • User friendly desktop environment

Shell The shell will be extended with a graphical console, in order to display not ASCII characters.

Enhancements: • Graphical console • Add Isolate command invoker • Developer support

We want to make life of the JNode developer much easier. This will mean adding good documentation and also provide ways to develop JNode in JNode.

Enhancements: • VM support for debugging • Implement JDWP debugging protocol • Support for a java compiler in JNode