KaffeOS:Controlling Resources In A Multi-Process Java Virtual

Machine

Godmar Back

SummaryA model for a Java run-time system

that• isolates and controls the resource

consumption of processes• allows safe termination of processes• allows processes to directly share

objects

What is Java used for?

• Applets in Netscape’s Mozilla Browser

• Customized Queries in Oracle’s Database Server

• Servlets running in Apache’s Web Server

These systems run multiple programs simultaneously

One-in-one or Many-in-one?

Operating System Operating System

JVM JVM

JavaPrg1

JVM JVM

JavaPrg2

JavaPrg3

JavaPrg1

JavaPrg2

JavaPrg3

KaffeOS

What does an OS provide?• Hardware Abstraction Layer• Security & Protection• Resource Management

• Isolation• Reclamation• Termination

• Communication• Sharing

What does an OS provide?• Hardware Abstraction Layer• Security & Protection• Resource Management

• Isolation• Reclamation• Termination

• Communication• Sharing

Is Type Safety enough?

• Language properties guarantee protection only!

• They do not– support safe termination– control & manage resources– enable communication & sharing

Assumptions & Goals

• Comprehensive accounting with focus on memory & CPU cycles

• Full accounting for resources spent in garbage collection

• Allow direct sharing of structured data for inter-process communication

• Guarantee safe termination

Problems with existing JVMs

• Do not support processes• Do not support safe termination• Existing approaches either

– do not fully isolate resource consumption

or– do not allow direct sharing

Terminating Threads in Java

• First-generation Java systems do not support safe termination of uncooperative threads

• Safe termination requires atomicity• Stopping threads in Sun’s Java:

– no atomicity– hence Thread.stop() is deprecated

Client

Sharing Attack

Server

KaffeOS Model

• Kernel structure– user/kernel mode, red line

• Resource classification– define resource consumption contexts

• Separate heaps, separate GC• IPC through structured sharing

– programming model

KaffeOS Kernel

• Multiple functions– trusted– accounts for resources– manages and accounts for sharing – guarantees safe termination

• Monolithic– implements system services

Safe Termination

• Termination requests postponed in kernel mode– kernel is still preemptible– kernel can safely back out of any

error condition

• User mode is fully stoppable• Does not solve general problem of

asynchronous termination

Drawing The Red Line

UserGC

KernelGC

User code (untrusted)

Kernel code (trusted)

Runtime Libs (trusted)

Finalization

User

Kernel

Classifying Resources

• Transient resources:– scheduled for short time quanta– access can be preempted– e.g.: CPU time, network bandwidth

• Permanent resources:– scheduled for longer time quanta– revocation leads to termination– e.g.: memory

Consumption Contexts

• Process: context for the consumption of permanent resources– memory, file descriptors

• Thread: context for the consumption of transient resources– cycles, network device

• Problem: scheduling excess resources

Resource API

• Specify how to– denote and manipulate resources– create resource hierarchies– assign resources to processes and

threads– provide feedback on their

consumption– associate resources with users

Memory Separation

Kernel Heap

Heap A Heap B

• Per-process heaps

• Separately accounted and collected

Separating GC

• Collect heaps independently• Use distributed garbage collection

technique– cross-references treated like remote

references

• Monitor writes • Shared scanning of thread stacks

Sharing

Kernel Heap

Heap A

Heap B• Shared objects

• Separately accounted

• Fully collected

• Basic datatypes

SharedBuffer

Programming Model

class Buffer {int length;int offset;byte []data;

}

• Producer/Consumer• Agree on buffer type

to share data• Register shared

type• Create buffer• Use it transparently

Sharing Example

• Producer Class bufferClass = Shared.register(“Buffer”);Buffer b = (Buffer)Shared.create(bufferClass, “ourbuffer”);synchronized (b) {

produceData(b);b.signal();

}

• Consumer Class bufferClass = Shared.register(“Buffer”);Buffer b = (Buffer)Shared.lookup(bufferClass, “ourbuffer”);synchronized (b) {

b.wait();consumeData(b);

}

Experimental Setup

• Proof of concept and evaluation• Reuse and extend existing Kaffe

libraries– Will run the same applications as

base Kaffe

• Use OSKit components where needed– CPUI scheduling

Evaluation

• Resource control mechanism– simulate denial-of-service attacks– full reclamation

• Safe termination– check integrity

• Sharing– is it a viable communication

mechanism?

Efficiency

• Microbenchmarks– base VM performance– write barrier overhead

• Memory overhead– GC overhead

Experimental Comparison

• Macrobenchmarks– JVMSpec 98 industry benchmark

• Compare with– serialization-based RPC in JKernel– traditional OS communication based

on underlying OS (one-in-one approach)

– unrestricted sharing

Related Work

• OS research– SPIN

• Resource management in OS– Resource Containers, Escort

• Java research– JKernel, JRes, Alta

OS Research

• SPIN [Bershad ‘95]• Provides extensibility, safety, and

speed– type-safe kernel extensions in

Modula-3– directly linked with kernel– no process abstraction– hard to control & unload

Resource Management Research

• Resource containers [Banga ‘99]– consumption contexts for traditional

monolithic OS– account resources for activities

• Escort [Spatscheck ‘99]– consumption contexts: paths &

protection domains

100% Pure Java Approaches

• JKernel [Hawblitzel ‘98]– sharing only through capabilities– serialization-based RPC

• JRes [Czajkowski ‘98]– instrument bytecode– use callbacks when resource limits

have been exceeded

Extensions to Java

• Alta [Tullmann ‘98]– derived from Fluke microkernel– nesting model for name spaces and

all resources– clear user/kernel separation– GC not per-process– requires extensions to type system

for sharing

Open Issues

• Sharing of more complex structures– copying overhead

• Interaction between modern collectors and heap separation– possibility of heap fragmentation

• Unresolved issues in CPU inheritance scheduling

Conclusion• Java runtime systems require an

OS-like structure– independent of whether they will

replace traditional HW-based operating systems

• KaffeOS is a model that allows– safe termination– resource control– structured data sharing