Processes in KaffeOS:
Isolation, Resource Management, and Sharing in Java

Godmar Back

Wilson Hsieh Jay Lepreau

School of Computing

University of Utah

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

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

Current Options

Multiple apps in one JVM

One app per JVM in different OS processes

Java Operating System

+ Good separation

+ Good resource management

+ Allows some direct sharing

KaffeOS Design Principles

Process separation

Full reclamation of memory

Precise memory and CPU accounting

Direct sharing

Safe termination of processes

Hierarchical memory management

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

Heap Structure (user heaps)

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

Heap Structure (user heaps)

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

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

Heap Structure (separate GC)

Heap Structure (resolving cycles)

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

Heap Structure (shared heaps)

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)

SpecJVM Performance of KaffeOS

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

Service Under DoS Attack

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]

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

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


	Godmar Back
	Wilson Hsieh Jay Lepreau
	School of Computing
	University of Utah


	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


	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



	Multiple apps in one JVM



	One app per JVM in different OS processes


	+ Good separation
	+ Good resource management
	+ Allows some direct sharing


	Process separation
	Full reclamation of memory
	Precise memory and CPU accounting
	Direct sharing
	Safe termination of processes
	Hierarchical memory management


	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


	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


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


	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


	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


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)


	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


	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]


	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


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