One of four Java operating systems developed at the University of Utah, JanosVM is directly related to the most recent, KaffeOS [2]. The K0 VM [3] was an early prototype for KaffeOS that had a different sharing model. The Alta OS [3, 4, 6] is a Java OS supporting a hierarchical process model; Alta explored a very different sharing and communication model from the other systems. All of these systems were based on the Kaffe Java virtual machine.
JanosVM is a direct descendant of KaffeOS, a fully operational system that can run most Java code "out of the box" with only minor modifications. The JanosVM design differs primarily because of different design priorities and implementer preference. Also, we continued to explore the design space [3] of Java operating systems with JanosVM. Our goal is to provide a JVM that can support customized environments for multiple, simultaneous Java applications. Specifically, we are willing to sacrifice "Pure Java" compatibility to better match the needs of environments that are already constrained [1]. For example, servlet engines, applet hosts, and active network platforms already provide restricted environments for their applications.
The initial work on JanosVM focused on boiling down KaffeOS to its major features: separate garbage collectors for each team and a red line [5] to protect critical system structures. Other parts of the system were discarded because they were only used to support the standard Java runtime which provided functionality beyond the JanosVM requirements and would have been difficult to maintain. The result is a system well-suited to providing the building blocks for Java operating systems, rather than a complete Java OS like KaffeOS.
First, the original KaffeOS garbage collector was modified to eliminate the notion of shared heaps and heap merging. Shared heaps were considered confusing, too limiting to be really useful, and offering features that could be achieved through other means. Heap merging was removed because the native-managed parts of the heap could corrupt the kernel heap if all native C code wasn't completely consistent and free of leaks-- a difficult goal to attain, both theoretically, and in our experience, in practice. Therefore, we took the safer and possibly faster approach of throwing away the team's pages. These changes ended up affecting the basic design of KaffeOS, causing ripples throughout the rest of the system. For example, cross-team pointers now require proxies since their referenced objects could completely disappear when a team was terminated (instead of just being merged into the kernel heap).
The second major design change came in the form of thread migration to generalize the transition from user mode to kernel mode. Thread migration works essentially the same way as the user-kernel transition: a thread is made unkillable while it enters another team to manipulate critical data structures. However, in JanosVM, threads can migrate to any other team in the system, not just between their home team and the kernel. This allows a team to act as a "server" for other teams in the system. Note that thread migration in JanosVM is a trusted operation, as the teams involved are unkillable while the migration is active. A Java OS built on JanosVM can use, but should hide, the migration primitives.
Another design difference between JanosVM and KaffeOS is the introduction of class groups. Class groups implement a flexible class sharing model that does not involve sharing internal class loader data, in contrast to KaffeOS's more traditional use of class loaders for sharing system classes. The need for this model arises from the ability of one team to act as a server for the other, and therefore require a common set of classes with which to communicate. While this sharing might be possible to implement with class loaders, a lower level approach involving modifications to the VM's class management code was chosen. Largely inspired by ideas in Alta, we created the class group mechanism and added it to the system. Notably, JanosVM simplifies the Alta mechanism (by defining a static mapping of classes at team creation time), while losing only a little of the power of Alta's mechanism. The resulting system allows Java code to function correctly when a thread visits another team and also avoids potential namespace clashes.
Finally, unlike the safe KaffeOS API, JanosVM exposes many of the implementation details of cross-team pointers and thread migration in its Java-level APIs. While this exposure makes it easier for the VM to be adapted to support new environments, it does mean that bugs in the Java code can create situations that violate type-safety. Specifically, when creating and de-referencing cross-team pointers, Java code must be correct in its protection of those pointers (accessing them only within synchronized blocks on the Importable or Exportable). While enforcing these constraints in a compiler or at run-time should be feasible, such checks are currently left to the implementer.
Alta is based on the Fluke nested process model [7], a model for hierarchically organizing processes in a system, whereby processes are wholly "contained" (all resources and interfaces are granted to) by their parent process. In Alta, Java processes could share data through an client-server style interprocess communication (IPC) mechanism. The most important aspect of Alta, with respect to JanosVM, was the type and object sharing. The type sharing in Alta was defined at run-time as types were referenced in the child. The dynamic nature created performance and correctness problems that, as noted above, JanosVM was designed to avoid.
The following papers from the University of Utah's Flux Research Group provide further details and background information.