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

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