PHASE III
  Home  | Phase I | Phase II | Phase III | RJQ | Favorite Links | Contact  | What's New | Photo Page | Guest Book  


This phase particularly has been difficult for us with very little information available to support what we promised at the beginning of the project. Hardly any material is available on how the unique design features of JavaOS affect its architecture . We have built from where we left Phase II.



JavaOS, the Java runtime executes not only user-level applications, but also the system-level windows, graphics, networking, and driver code. The lowest layer of code handles the tasks often found in micro- or nano-kernels. The kernel for Java contains the low-level functions required by the Java Virtual Machine. This required functionality falls into the following categories:

  • Booting
  • Exceptions
  • Threads
  • Memory Management
  • Monitors
  • File System
  • Timing
  • Native Code Library Management
  • Interrupts
  • DMA
  • Debugging
  • Miscellaneous Platform Control

Boot systems for network, ROM, RAM, CD-ROM, floppy, and hard disks are all possible. While the bootstrap code is running, it allocates several memory regions, including one for the Java heap, and others for various I/O device registers and DMA regions. The bootstrap also handles mapping hardware devices that it has detected to their corresponding device drivers.

The main purpose of the trap and interrupt handling code is to service traps and interrupts and make the information accessible to the appropriate Java device driver.

JavaOS does not require a Memory Management Unit, but it can use an MMU to make several disjoint ranges of physical memory appear contiguous, which simplifies memory allocation. The Java programming language eliminates the direct manipulation of memory by encapsulating all access into objects, classes, and automatic free memory collection.

JavaOS presents a portable, abstract memory model. The memory model is built upon the notion of addressing. Addressing is the process of identifying a memory location. The most fundamental unit of addressing in JavaOS is the physical address. A physical address identifies a unique memory location. A physical address is not translated by the MMU; rather it is a raw memory location, identifying what may be ROM, RAM, or I/O memory.

The JavaOS virtual address space is created by the JavaOS kernel layer. JavaOS does not assume a one to one correspondence between the physical and virtual address spaces. The use of an MMU to enhance the support of the virtual address space is not assumed either. Rather, MMU usage and page management is seen as a kernel implementation issue. JavaOS operates in a single virtual address space.


Memory management

The memory management facilities of JavaOS is a unique one, since Java implements garbage collection, a feature not seen in other programming language.


JavaOS presents all the memory available on the system as a contiguous block, regardless of whether that memory is physical or virtual. Because Java imposes strict protection on threads with no means to directly manipulate memory (no pointers), JavaOS can safely execute all programs in one memory area. (The only exception is made for device drivers, which sometimes require direct memory access. But that service is not found in the API.)


At the lowest level, free memory is viewed as a singly linked list of up to 256 chunks. A set of nodes keep track of the starting address of each block and points to the next available block, and the list is kept in increasing address order. When an allocation request is received, the linked list is traversed from the beginning to find the chunk with the best fit (the smallest one that meets the requirement) and appears later in the list. When a region is freed, it is added to the neighboring free areas.

When JavaOS is first initialized, it preallocates a chunk of memory equivalent to about 5% of the total system memory to be the heap, and 25% of the heap is devoted to object space. All user allocation requests are made to the object space, which gives out free space using a combination of first fit, best fit, and paging.

Each allocated object is marked by a handle (a long word) to track its size, location, and usage. There is some coalescing of free space during the allocation process, but most of the heap memory is reclaimed through garbage collection.

While the Java API allows the allocation of space to create objects, there is no explicit deallocation function call. Java maintains a strict "hands off" policy toward user manipulation of memory, and its lack of pointers and deallocation are ways to prevent illegal memory references. Garbage collection can be invoked by one of the memory management routines whenever free space has run out, or asynchronously by a thread running in the background. During the garbage collection process, all the object and reference handles are checked, and those no longer in use are returned to the heap.

http://www.engr.csulb.edu/~hliao/526/JavaOS.html

Process Management

  • Microkernel exports a set of process management services that encapsulates the life cycle of a process.
  • Same address space is shared by multiple process.
  • Each process is assigned a set of threads and memory space(in this case area).
  • A process is created without any assigned resources, over its lifetime it is dynamically assigned threads and memory areas.
  • Process resources are consumed by the Microkernel on deletion of a process.


    Thread Management

  • Microkernel exports a set of thread management services that let the JVM fulfill the semantics of Java Thread.

  • Every Java thread is layered upon a Microkernel thread.
  • Microkernel thread model supports multiple threads inside a single process.


Resource Protection

JavaOS controls resource access through monitors, which is surprising since one of the drawbacks of monitors is the lack of concurrency. Monitors in Java do not encapsulate the resources they protect, thus allowing some degree of parallelism.


The Java monitor structure consists of a hashed key, some bit flags, and a counter to track the number of threads currently inside the monitor. These threads may either be running, waiting to enter, waiting on condition, or suspended. The monitor implements its own queue control routines, which orders threads by priority. Lot of manipulation goes on between the monitor and the scheduler to prevent a race condition when two threads are entering the same monitor at once, while preventing one thread from locking the scheduler and freezing the system.

All system resources are protected by monitors, from the heap to devices to miscellaneous hash tables. Monitors are an integral part of the operating system and are strongly supported by threads.


I/O Support

Microkernel exports a set of memory management services that let the JDK run time allocate virtual address space for I/O. Device management is performed by JavaOS device Interface(JDI).




Java Virtual Machine

Within Java compatible systems like JavaOS, the Java Virtual Machine is obviously used to interpret Java bytecodes, but it is also used as infrastructure for much of the rest of JavaOS. It executes the bytecodes in all classes within the system, handles exceptions, manages almost all of the RAM in the computer, and handles the simultaneous execution of multiple threads


The implementation of the Java Virtual Machine that we use in JavaOS is very close to the standard one provided with Java Developer Kit, but we have tuned the memory allocation mechanisms, and added the reclamation of storage used by classes that are no longer needed by any objects in the system.


Security issues

JavaOS is designed to protect against "untrusted mobile code" to provide maximum security. The Java class libraries are written such that all security concerns are put in one centralized object called the security manager. An exception is thrown by the security manager if there is breach of security.


To allow secured multi-processing the following are needed:
  • A way to launch applications into a JVM which is already running and to end them without exiting the JVM.
  • Notion of a user running Java code.
  • Notion of logging on to the JVM and launching a shell for other applications.
  • Multiple application aware system code.
  • Multiple application aware event dispatching.
  • Distinction between application state and system state.

The single most important consideration in a network system is the network security and the potential for its abuse. There are many aspects to network security for example address spoofing (e.g.using the addresses of other systems), malicious behavior ,and packet capturing (e.g. capturing of passwords and other sensitive data) etc.

The manner in which applications, protocols, and protocol subsystems coexist in the same address space inside virtual machine is one reason why Java-based protocols exacerbates security problems.

In traditional systems, protocols normally reside within the operating system and are separated from applications by a user/kernel coupled with different privilege levels, prevents applications from improperly configuring protocols and executing malicious protocol code.

In JavaOS, no such user/kernel boundary nor differing levels of privilege exist. Consequently, the execution of arbitrary and potentially malicious protocol code cannot be prevented because the Java virtual machine has no knowledge of the semantic meaning of packets that may emanate from within it.


Traditional protocol specifications assume that certain semantics are enforced by the underlying implementations. The semantics include binding of addresses to unique physical resources and the assumption that only a single instance of a particular protocol can operate simultaneously (e.g. only a single IP, TCP, and UDP can operate inside a given system).

When all protocol implementations execute within the operating system kernel and privilege levels protect the user/kernel boundary, network security need to be provided. Java-based protocols execute within user space and since multiple instances of the same protocol can be executed simultaneously in different subsystems, those semantics cannot be enforced.

Java-based protocol implementations can violate those semantics and the assumption that they are enforceable by their implementations in three ways.


First, because multiple JVM can execute simultaneously in host-based configurations ,multiple, independent copies of the same protocol could therefore execute simultaneously.

Second, multiple copies of a given protocol could potentially assign the same address to different physical resources thus creating confusion with peer protocols.

Third, current address assignment algorithms are typically unable to map between different instantiations of a given protocol.


Performance and Speed

There is not much material available on this matter whatever material we went through all were contradicting each other. Performance basically depends on the applications that are run on the system and these determine how good or bad a system is. Also if the benchmark used is optimized for the particular purpose then it will definitely show good performance for the required purpose and may or may not for others.

Currently JavaOS has minimal performance tuning, "Just-In-Time" compiler has not been used to translate byte-codes into machine code, and makes minimal use of native methods. Therefore, JavaOS performance is poor, but run on certain benchmarks JAVAOS performance it seems is better than systems written in C/C++. But we did not get to know more about these benchmarks as no information we available on this.

Run on Pendragon Software's CaffeineMark benchmark on several systems to compare their performance when executing Java applets, positive results were obtained. The main reason for these positive results were JavaOS's many layers of software architecture that other systems have built up to make programming in languages like C safer and less platform-dependent. While those layers do not affect performance as such,they do not come close to providing the safety and platform independence of Java.


A user interface is very important for the user so that he does not find the system a slower one. Hence all the AWT widgets, window management, region clipping and event processing code are implemented in JAVA. It was seen from the benchmarks on which JAVAOS was run was faster than Solaris/Motif all of which were written in C.



Reason for good performance

Not to implement unnecessary functionality. Java has less of backward compatibility or excessive features that do not make the system unnecessary large hence affecting performance.
The cohesion between the Java class libraries and the underlying implementation. Most platforms require certain amount of code to interface Java AWT, networking and file system libraries to the native operating system's libraries. This code in most cases mismatch in the respective layers leading to decreased performance and complexity.

When the underlying service(for e.g. the networking stack) in Java matching the two layers become easy. The code that sticks the window system and I/O systems in JavaOS is a simple method call layer. When an applet performs a TCP write, the same thread that calls the write goes down through the protocol stack to the level of the Ethernet driver and writes the packet data out the device itself. This doesn't require context switching and all the code is executed in the same address space.

JavaOS allows all subsystem and user applications to remain within the same address space. Many operating systems use memory protection scheme to isolate user applications from system level activities for security and robustness. JavaOS implemented in Java does not require such a structure but the security and robustness is not breached at the same time overhead and complexity of maintaining the address space management is not there. User applications and applets are prevented from accessing any systems-level primitives, except for the ones permitted by the prescribed APIs.


Advantages

  • JavaOS eliminates the overhead of a host operating system. Because JavaOS contains no extraneous features found in other operating systems, it allows smaller and simpler devices to be built that execute Java programs more efficiently than other systems.

  • JavaOS may be stored on ROM, enabling simple, low-cost systems thus reducing boot time.

  • JavaOS is written in Java, thus new components can be quickly developed also it is dynamically extensible.

  • JavaOS enables systems that are as easy to install and maintain as terminals but which are as powerful as traditional desktop machines.



Summary

JavaOS enables Java applications to run directly on hardware without requiring a host operating system.

JavaOS includes the Java Virtual Machine, the standard packages of classes, and the minimum OS code required to support them. The OS code includes low-level code written in C or assembly language, plus device driver, networking, windowing, and graphics-rendering code written largely in the Java programming language.

The main advantage of JavaOS is that by eliminating the overhead and complexity of host operating systems, it enables new classes of simple, intelligent, and dynamic network devices that will be lower cost. JavaOS is targeted at intranet terminals for enterprise desktops, Internet computers, and embedded devices where hardware resources are constrained.






Architectural Study by

- Indranil Sanyal and Dr Sripathy Bhat

(Instructed by Prof. Ralph E.Johnson)




Advanced Software Engineering,
Department of Computer Science,
Univeristy of Illinois Urbana Champaign (UIUC), USA.



Site built and maintained by Dr Sripathy Bhat and Indranil Sanyal