CHAPTER 11 Related Work This chapter compares the JX architecture to other projects that extend Java with capabilities that are important for operating systems, such as isolation of protection domains, inter-domain communica- tion, sharing between domains, resource accounting and user-defined resource management, reus- ability, scalability, and security. Our evaluation of the related systems is guided by a number of ques- tions: Isolation. How are protection domains implemented? How well can domains be isolated from each other? Can domains be completely confined? Can domains be terminated independently from each other? Can domains use different JDK implementations? Communication. Is fast inter-domain communication possible? Does communication creates inter- dependencies between protection domains? Sharing. Is code and/or data sharing possible? How transparent can code be shared? How are special cases, such as static fields or synchronized methods, treated? Resource accounting. How exact is resource accounting and how well does the system cope with specific problems? When accounting CPU time a specific problem is the considerations of garbage collection time and time spent in interrupt handlers. When accounting memory specific problems are the account for stack and thread control block usage. User-defined resource management. Is it possible to use different garbage collectors in different domains and are the GC runs independent from each other. Does the system provide any support for the implementation of independent garbage collection? Is it possible to use different schedulers for different protection domains? Reusability. How does the addition of protection domains affect reusability? Scalability. How expensive are protection domains. Is it possible to efficiently create small as well as large domains? Security. How secure is the system with respect to the criteria presented in Chapter 10? What secu- rity mechanisms are provided by the system? The following projects either attempt to provide an operating system structure or attempt to improve one of the aspects in our list (the projects are listed in no particular order): Conversant [16] by The Open Group Research Institute was one of the first attempts to enhance Java with separate protection domains and resource accounting. Whenever a new name space is created by using a new class loader a new heap is created and used by the code that is loaded by the class loader. System classes are loaded by the internal class loader and shared between protection domains. Inter- Chapter 11: Related Work 137 heap references can be created by passing references through static variables of shared system class- es. A runtime check (write barrier) is used to detect attempts to create inter-heap references. KaffeOS [10] by the University of Utah is an extension of the Kaffe JVM to support a process ab- straction. The design is similar to Conversant. Heaps are separated and a write barrier is used to detect attempts to create inter-heap references. There is no IPC primitive, but shared heaps are used for com- munication. The system provides a process abstraction that is similar to UNIX, with kernel-mode code and user-mode code. JRes [45] by the Cornell University is a pure Java system that uses bytecode rewriting in class loaders to support resource accounting. Before each object allocation instruction and in each finalizer a call to the resource management system is inserted. J-Kernel [87], [86] by the Cornell University was developed by the same research team that devel- oped JRes. It supports a task structure and capability-like inter-task references on top of an unmodi- fied JVM. The J-Kernel is layered on top of RMI and extends RMI by a capability mechanism. Ca- pabilities are realized by generating proxy classes “on-the-fly” and using a reference to an instance of such a proxy class instead of the original reference. Luna [85], [86] by the Cornell University is a follow-on project to the J-Kernel. It extends the Java type system and introduces a new type for remote pointers. Remote pointers are references to objects of a different task. Remote pointers allow fine-grained sharing between tasks and they can be revoked either explicitly or when the target task terminates. Secure Java [52] by the Vrije Universiteit Amsterdam and IBM T. J. Watson Research Center is a JVM that runs on top of the Paramecium [53] kernel. Aurora [148], [139] by Oracle is the central component of JServer, the Java runtime environment that is embedded in Oracle’s database. The main goal of the Aurora JVM is scalability, i.e. the support of many concurrent database sessions. MVM [44] by Sun Microsystems is an extension of the HotSpot JVM that allows to run multiple JVMs in a single process. When possible, data is shared between the JVMs. Scalable JVM OS/390 [51] by IBM is a port of a JVM to the OS/390 operating system. As this port aimed at using a JVM to run server programs, it focused on reliability, availability, security, and scal- ability. These concerns were addressed by using facilities of the underlying OS/390 system: reliabil- ity and availability by using performance monitoring, security by using the principal-based access control of OS/390, and scalability by using OS/390 processes and shared memory to store the re- solved system classes. JavaSeal [27] by the University of Geneva and its follow-on project J-SEAL2 [22], by the Technische Universität Wien is a pure Java implementation of resource accounting and management. JavaOS [154] by Sun Microsystems is a complete Java operating system. Similar to the Pilot OS [147] (see Section 2.5 of Chapter 2) JavaOS is a single-user system. As JavaOS is the only real Java- based operating system besides JX, it is very related to the work described in this dissertation. All systems besides JavaOS are no real operating systems but extensions of Java runtime en- vironments with functionality that usually is associated with operatings systems, such as task termi- nation and resource control. 138 1 Architectural aspects 1.1 Isolation Systems that provide protection domains on top of an unmodi®ed JVM use the name spaces that are created by class loaders. Inside a JVM a class is uniquely identi®ed by its class name and the class loader that loaded the class. A class contains references to other classes in its constant pool. When these class names are resolved by the JVM internal linker the class loader that loaded the class is re- quested to load the new class. Using a new class loader to load a class creates a new, separate name space because the new class can not use previously loaded classes. An exception are system classes that are loaded by a JVM internal class loader and that are accessible in all name spaces. An unmodi®ed JVM uses a shared heap for all protection domains (name spaces). This leads to an optimal memory utilization but allows for denial-of-service attacks. To make these attacks impossible systems either keep the shared heap model and account object allocations (JRes) or use separate heaps. Fragmentation can be reduced by using heap fragments (as illustrated by the third domain in Figure 11.1). A shared heap model usually is combined with a shared thread model. The thread con- tains frames of different protection domains (see Figure 11.2). Figure 11.1: Shared heap vs. separate heaps The different patterns represent objects of different protection domains. In a shared heap model ob- jects of different domains are mixed which unnecessarily complicates resource accounting and rec- lamation. shared heap: separate heaps: Heap. It is relatively easy to share data between protection domains in a Java system. A multi-tasking system must prevent DoS attacks that simply ®ll the heap or lead to a fragmentation of the heap. Sys- tems that use a single heap and that do not account allocations are subject to simple heap exhaustion attacks. These systems include JavaOS, JKernel, Aurora. Conversant and KaffeOS use separate heaps and write barriers to detect attempts to create inter-heap references. This check slows down the putstatic, put®eld, and aastore bytecode to about 50% of the original speed in the Conversant system. KaffeOS uses a separate heap per process and shared heaps for interprocess communication. Instanc- es of system classes are allocated on a shared heap. System classes must be modi®ed to protect (hide) Chapter 11: Related Work 139 Figure 11.2: Stacks with mixed frames A shared heap model is usually combined with a shared thread model. A single thread executes code that belongs to different protection domains and thus the thread contains frames that belong to differ- ent domains. These frames contain references to objects of their domain. Although an inter-domain invocation has nearly zero overhead, the shared stack makes clean and safe termination nearly im- possible. Stack Heap shared kernel locks (example is the Thread class). They must also be modified to multiplex state be- tween processes (example is the static System.out variable that represents the standard output stream and should be process local). KaffeOS allows sharing between processes and allows access to the fields of shared objects. We think that this kind of sharing is fundamentally flawed because it can be used to violates the contract of the abstract data type (ADT). To circumvent that a malicious process violate the ADT contract by directly modifying the state of the object KaffeOS programs will end up encapsulating this state and allowing access only through methods, which will be equivalent to the JX sharing model. The J-Kernel [86] uses the Java classloading mechanisms to add a task structure (termination, revocation, resource accounting) to an unmodified JVM.