Processes in KaffeOS: isolation, resource management, and sharing in java

TLDR

Java virtual machines are widely used to run untrusted mobile code and provide OS‑like memory protection and basic services, but they lack application isolation and resource limits. The paper introduces KaffeOS, a Java runtime that adds application isolation and resource management. KaffeOS adopts an OS‑inspired architecture with a user/kernel boundary, per‑process virtual machines, and garbage‑collection write barriers to enable isolated heaps while allowing controlled object sharing. KaffeOS incurs only an 11 % performance overhead compared to the base JVM, is slower than commercial JVMs for trusted code, yet outperforms them when facing denial‑of‑service attacks or misbehaving code.

Abstract

Single-language runtime systems, in the form of Java virtual machines, are widely deployed platforms for executing untrusted mobile code. These runtimes provide some of the features that operating systems provide: inter-application memory protection and basic system services. They do not, however, provide the ability to isolate applications from each other, or limit their resource consumption. This paper describes KaffeOS, a Java runtime system that provides these features. The KaffeOS architecture takes many lessons from operating system design, such as the use of a user/kernel boundary, and employs garbage collection techniques, such as write barriers.The KaffeOS architecture supports the OS abstraction of a process in a Java virtual machine. Each process executes as if it were run in its own virtual machine, including separate garbage collection of its own heap. The difficulty in designing KaffeOS lay in balancing the goals of isolation and resource management against the goal of allowing direct sharing of objects. Overall, KaffeOS is no more than 11% slower than the freely available JVM on which it is based, which is an acceptable penalty for the safety that it provides. Because of its implementation base, KaffeOS is substantially slower than commercial JVMs for trusted code, but it clearly outperforms those JVMs in the presence of denial-of-service attacks or misbehaving code.