Processes in KaffeOS:
Isolation, Resource Management,
and Sharing in Java
Godmar Back
Wilson Hsieh
Jay Lepreau
School of Computing
University of Utah
School of Computing
Janos Project
Motivation

Java Applications
– Untrusted code: possibly malicious or buggy
– Multiple applications on behalf of multiple users

Efficient use of resources
– Resource-constrained environments: “small” systems
(handhelds, embedded systems)
– Increased scalability
School of Computing
2
What is KaffeOS

A Java operating system:
– Enhanced JVM that provides operating system functionality

Features:
– Separation
– Resource management
– Direct sharing

Focus on memory (GC) and CPU management

Architectural concepts taken from OS

Mechanisms taken from garbage collection
School of Computing
3
Current Options
-
Multiple apps in
one JVM
App1
App2
App3
JVM
Base OS
-
One app per
JVM in different
OS processes
App1
App2
App3
JVM
JVM
JVM
Base OS
School of Computing
4
Java Operating System
App1
App2
App3
App4
Java OS
Base OS
+ Good separation
+ Good resource management
+ Allows some direct sharing
School of Computing
5
KaffeOS Design Principles

Process separation

Full reclamation of memory

Precise memory and CPU accounting

Direct sharing

Safe termination of processes

Hierarchical memory management
School of Computing
6
Process Separation

Protecting access to a process’s objects
– Via Java type safety, via Java name spaces

Define a user/kernel boundary
– Protect integrity of kernel
– Guarantee safe termination [HotOS ’99]

Separation of resources
– Memory, CPU, garbage collection
School of Computing
7
Heap Structure (user heaps)
user heap
user heap
user heap
kernel heap
School of Computing
8
Full Reclamation

Assumption: do not have MMU to unmap memory
– Rely on garbage collection to free objects

References can make objects unreclaimable
– Define and enforce set of rules for writes that create references

Define heap structure
School of Computing
9
Heap Structure (user heaps)
X
user heap
user heap
user heap
kernel heap
School of Computing
10
Enforcing Heap Structure

Certain cross-heap pointers are illegal
– User-user pointers are illegal

Use GC “write barrier” to enforce
– Check heaps on every write
– Throw SegmentationViolationError if illegal

Small cost on legal write (common case)
– Microbenchmarks (tight loop, hot cache)
» 41 cycles without memory overhead
» 25 cycles with slight memory overhead
School of Computing
11
Memory and CPU Accounting

Accurate and complete per-process accounting
– Minimize number of objects on kernel heap
– Minimize amount of time spent in kernel code

Separate garbage collection
– Minimize unaccounted resource use
– Avoid priority inversion
– Maintain isolation
School of Computing
12
Heap Structure (separate GC)
user heap
user heap
user heap
xv
e
School of Computing
kernel heap
13
Heap Structure (resolving cycles)
user heap
user heap
user heap
user heap
user heap
kernel heap
School of Computing
14
Direct Sharing

As Interprocess Communication Mechanism

Objects may contain pointers to other objects
– Preserve Java model

Accounting of shared objects
– Sharers are all charged for shared heaps: double charging
– Non-double charging does not work

Reclamation
– As soon as garbage collector detects that nothing on shared heap
is referenced
School of Computing
15
Heap Structure (shared heaps)
user heap
user heap
user heap
X
shared heap
shared heap
kernel heap
School of Computing
16
Performance Results

Overhead for well-behaved applications
– SpecJVM98 benchmarks: 2-8%

Comparing
– IBM JDK 1.1.8
– Base JVM: Kaffe (www.kaffe.org)
» Current version: Kaffe00 (June 2000)
– KaffeOS with unoptimized write barrier
– KaffeOS with optimized write barrier (memory overhead)
School of Computing
17
SpecJVM Performance of KaffeOS
70
KaffeOS
KaffeOS
unoptimized WB optimized WB
GC Time
60
Kaffe00
Run Time
Seconds
50
40
IBM JDK1.1.8
30
20
10
0
compress
School of Computing
jess
db
javac
mpegaudio
mtrt
jack
18
MemHog DoS Scenario

Off-the-shelf Servlet engine
– Linux 2.2.x w/ 256MB, Apache 1.3.12, JServ 1.1, JSDK 2.0

How would we deal with this?
– Run 1 servlet per IBM JVM (IBM/1)
– Run all servlets on one IBM JVM (IBM/n)
– Run each servlet in a KaffeOS process
IBM/1
IBM/N
KaffeOS
IBM/1, MemHog
IBM/N, MemHog
KaffeOS, MemHog
School of Computing
19
Service Under DoS Attack
10000
IBM/1
IBM/n
KaffeOS
IBM/1,MemHog
IBM/n,MemHog
1000
Seconds
KaffeOS,MemHog
100
10
1
0
10
20
30
40
50
60
70
80
Servlets
School of Computing
20
Related Work

Other Java Operating Systems
– J-Kernel/JRes [Hawblitzel ’98, Czajkowski ‘98],
Alta [Tullmann ‘99], Java Nucleus [van Doorn ’00]

Java VM extensions
– Multiprocess JVM [Balfanz ‘98], IBM [Dillenberger ‘00], Oracle 8i

Java language extensions
– Luna [Hawblitzel]
– Java Realtime Extensions [Sun ‘00]

Operating Systems
– Opal [Chase ‘94]
– Pilot [Redell et al. ‘80], Cedar [Swineheart et al. ‘86],
– Spin [Bershad ‘95], Inferno [Dorward et al. ‘97]
School of Computing
21
Ongoing Work & Open Issues

Running other DoS attacks
– GarbageHog: allocate and abandon lots of memory
– CPUHog: execute for too long

Create bigger applications that use direct sharing
model for IPC

Demonstrate safe termination claim experimentally
School of Computing
22
Summary

Java operating systems are necessary to support
untrusted Java applications efficiently

KaffeOS
– Architectural concepts taken from operating systems
– Mechanisms taken from garbage collection
» Distributed GC
» Write barriers

Big issue: dealing with memory/GC

Resource-based denial-of-service attacks can be
stopped
School of Computing
23