6/12/2001 1

KaffeOS: Isolation, Resource Management and Sharing in Java

Godmar Back

School of Computing

University of Utah

Dissertation Defense

Dissertation Defense 6/12/2001 2

Motivation

Java is widely used– Examples: applets, servlets, Enterprise Java Beans, mobile

agents, active packets, database procedures

– Untrusted code: possibly malicious or buggy

– Multiple applications on behalf of multiple users

Primary motivation Want to provide robust environment for these applications

Secondary motivation– Make efficient use of resources; increase scalability

– Run on “small” systems (handhelds, embedded systems)

Dissertation Defense 6/12/2001 4

Java Applications

Applet / Agent / Servlet / Database Procedure …

JVM

Base OS

This work is about system structure.

Dissertation Defense 6/12/2001 5

Current Options

- Single JVM with ad-hoc layer

- Efficient sharing

App1 App2 App3

Ad hoc layer

Base OS

JVM

App1 App2 App3

JVM JVM JVM

Base OS

- Multiple JVMs- Strong isolation

- Good resource management

Dissertation Defense 6/12/2001 6

Java Operating System

App1 App2 App3 App4

Java OS

Base OS

+ Good isolation

+ Good resource management

+ Efficient sharing

requires process model

Dissertation Defense 6/12/2001 7

Outline

The Case for KaffeOS KaffeOS’s Design

– Isolation and Safe Termination

– Memory Management

– Interprocess Communication

– Flexible Resource Management

Experimental Evaluation Related Work Future Work and Conclusion

Dissertation Defense 6/12/2001 8

KaffeOS Core Ideas

To provide KaffeOS uses

Isolation and Safe Termination

Red Line

Memory Management Separate Heaps

Interprocess Communication

Shared Heaps

Flexible Resource Management

Hierarchical Resource Framework

Dissertation Defense 6/12/2001 9

The Red Line in Hardware-based OS

MMU prevents access to kernel data structures in user mode

System calls enter kernel mode

Cheriton 1994

Dissertation Defense 6/12/2001 10

The Red Line for Safe Termination

Isolation of applications and system: user/kernel boundary

– Kernel classes must not be corrupted

– Termination is deferred while inside kernel code

– All exceptional situations are handled in kernel code

NB: different from built-in synchronize

Dissertation Defense 6/12/2001 11

class Queue {synchronized Object get();synchronized void put(Object);

}Queue producer, consumer;

void run () {while (!done) {

Object obj = producer.get();consumer.put(obj);

}}

Producer/Consumer Example– Invariant: all produced items are consumed

Guaranteeing Consistency

Kernel.enter();

Kernel.leave();

Dissertation Defense 6/12/2001 12

Red Line in KaffeOS

User/kernel dimension is different from trust dimension:

UserGC

SystemGC

User code (untrusted)

Kernel code (trusted)

Runtime Libs (trusted)

Finalization

User

Kernel

User mode Kernel mode

Trusted Runtime code Kernel code

Untrusted User code

Dissertation Defense 6/12/2001 13

Outline

The Case for KaffeOS KaffeOS’s Design

– Isolation and Safe Termination

– Memory Management

– Interprocess Communication

– Flexible Resource Management

Experimental Evaluation Related Work Future Work and Conclusion

Dissertation Defense 6/12/2001 14

1. Limit memory use of processes

2. Fully reclaim processes’ memory after termination

3. Garbage collect processes individually

Memory Management: Goals

Dissertation Defense 6/12/2001 15

Single Heap (Conventional JVM)

ReferenceObject

Dissertation Defense 6/12/2001 16

Separate Heaps

Kernel Heap

User Heaps

Goal 1: Limit memory use

Dissertation Defense 6/12/2001 17

Reclaiming Memory

References can make objects unreclaimable

Hardware-based OSMMU maps virtual memory

OS manages physical pages

Java runtime systemNo MMU

Garbage Collector frees unreachable objects

Dissertation Defense 6/12/2001 18

Legal and Illegal References

Legal reference

Illegal reference

Goal 2: Full reclamation

Dissertation Defense 6/12/2001 19

Preventing Illegal References

Use GC write barriers– Technique used in incremental and generational collection

Intercept each write, check heaps– Throw SegmentationViolationError if illegal

– Only PUTFIELD, PUTSTATIC, and AASTORE bytecode instructions have to be checked

Small cost on legal write (common case)

Dissertation Defense 6/12/2001 20

Use of Entry and Exit Items

Entry Item

n

n n

x

x

xx

Exit Item

RefCount1

12

Goal 3: Separate Collection

Dissertation Defense 6/12/2001 21

Collecting Cycles

Merge heaps upon termination into kernel heap

Dissertation Defense 6/12/2001 22

Outline

The Case for KaffeOS KaffeOS’s Design

– Isolation and Safe Termination

– Memory Management

– Interprocess Communication

– Flexible Resource Management

Experimental Evaluation Related Work Future Work and Conclusion

Dissertation Defense 6/12/2001 23

IPC: Direct Sharing

Alternatives:– No sharing (copy between processes)

– Indirect sharing (use proxy objects or surrogates)

Objects contain direct pointers to shared objects– Preserve Java model

Should not compromise accurate accounting or full reclamation!

Dissertation Defense 6/12/2001 24

Shared Heaps

Legal reference

Illegal reference

User Heap

Kernel Heap

Shared Heap

User Heap

Dissertation Defense 6/12/2001 25

Shared Heaps: Model

Accounting of shared objects– Shared heap’s size is fixed after creation

– Sharers are all charged for shared heaps: double charging

Reclamation– As soon as garbage collector detects that nothing on shared heap

is referenced

Restrictions on programming model– Cannot allocate new objects after heap is frozen

– Cannot have references to user heaps

Dissertation Defense 6/12/2001 26

Shared Heaps: Trie Examplepackage shared;

class Trie {

static class TrieNode { final static int WIDTH = 96; TrieNode [] children = new TrieNode[WIDTH]; boolean eow = false; }

private TrieNode root; private int maxlength;

Trie(Reader r) throws IOException { … }

public void dump(PrintStream s) { … }

public boolean lookup(String s) { … }

}

import shared.Trie;

Shared sh = Shared.registerClass("shared.Trie", 1);

Trie trie = (Trie) sh.getObject(0);

… trie.lookup(“aback”);

A

A BC

A

BC

A

R

O

N

K

F

T

A

Dissertation Defense 6/12/2001 27

Outline

The Case for KaffeOS KaffeOS’s Design

– Isolation and Safe Termination

– Memory Management

– Interprocess Communication

– Flexible Resource Management

Experimental Evaluation Related Work Future Work and Conclusion

Dissertation Defense 6/12/2001 28

Hierarchical Resource Framework

Resource API to allow for different policies

Hierarchical management

Work-conserving

Dissertation Defense 6/12/2001 29

CPU and Memory Allocation

Memory– Must not require partitioning

– Soft limits: Limit overall use, allow temporary use of surplus memory

– Hard limits: Provide memory guarantees if desired

CPU– Stride-scheduling for processes as a whole

– Priority-based scheduler for threads in process

Dissertation Defense 6/12/2001 30

Outline

The Case for KaffeOS KaffeOS’s Design Experimental Evaluation

– Performance for well-behaved code

– Performance for adverse loads

Related Work Future Work and Conclusion

Dissertation Defense 6/12/2001 31

Performance for Well-behaved Code

Baseline performance Write barrier overhead

– Microbenchmarks

– SpecJVM98 benchmarks

Compared against– Base JVM: Kaffe (Kaffe00 from June 2000, www.kaffe.org)

– IBM JDK 1.1.8 – fastest industrial 1.1 JVM

Microbenchmarks– Instruction cost:

» 11 cycles minimum with one word overhead per object, 43 cycles minimum with no memory overhead

Dissertation Defense 6/12/2001 32

SpecJVM Performance of KaffeOS

0

10

20

30

40

50

60

70

compress jess db javac mpegaudio mtrt jack

Ru

nti

me

in S

ec

on

ds

IBM JDK 1.1.8Kaffe 2000KaffeOS (fake heap pointer)KaffeOS (heap pointer)KaffeOS (no heap pointer)KaffeOS (no write barrier)

Dissertation Defense 6/12/2001 33

Write Barrier Counts

Benchmark

Dynamic Count

(millions)

Write BarrierOverhead (Best-case)

for No Heap Pointer

Conservative upper bound for

IBM JDK

compress 0.47 -0.5% (0.0%) 0.7%

jess 7.94 -1.1% (1.0%) 10.5%

db 30.09 2.5% (3.8%) 8.1%

javac 20.78 5.6% (2.5%) 7.3%

mpegaudio 5.51 -1.4% (0.8%) -1.7%

mtrt 3.06 0.3% (0.5%) -0.2%

jack 19.90 3.4% (1.9%) 14.1%

Dissertation Defense 6/12/2001 34

Outline

The Case for KaffeOS KaffeOS’s Design Experimental Evaluation

– Performance for well-behaved code

– Performance for adverse loads

Related Work Future Work and Conclusion

Dissertation Defense 6/12/2001 35

Performance for adverse loads

DOS Scenarios against– Memory

– CPU

– Garbage collector

KaffeOS – is more robust

– delivers more effective service

– improves performance under adverse loads

Dissertation Defense 6/12/2001 36

DoS Scenario

Servlet Engine: Apache 1.3.12, JServ 1.1, JSDK 2.0

Some number of “good” servlets Plus one MemoryHog servlet

– Allocate lots of memory

– Try to crash/tie up JVM

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

Dissertation Defense 6/12/2001 37

Service Under DoS Attack

0

5000

10000

15000

20000

25000

0 10 20 30 40 50 60 70 80

Number of servlets

Su

cces

sfu

l req

ues

ts in

30

seco

nd

inte

rval

IBM/1

IBM/n

KaffeOS

IBM/1+MemHog

IBM/n+MemHog

KaffeOS+Memhog

Dissertation Defense 6/12/2001 38

MemHog Stresstest

Memory Consumption

0

1

2

3

4

5

6

7

8

9

0 50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950

# of MemHogs killed

Me

mo

ry U

sa

ge

in M

B

overall bytes allocated

bytes on kernel heap

y = 31.5 x + 7,926,291

y = 31.5 x + 5,623,933

Dissertation Defense 6/12/2001 39

CPU Denial of Service Scenario

Problem: cannot tell a CPU denial-of-service attack from a process doing useful work

Instead: ensure that processes obtain their share when runnable

Allow for manipulation of shares to reflect user priorities

MD5 Servlet computes MD5 hash sum over /usr/dict/word for each request

– Requests/sec is measure of service

Dissertation Defense 6/12/2001 40

CpuHog Scenario

0

2

4

6

8

10

12

14

16

18

20

0 10 20 30 40 50 60 70 80 90 100 110 120 130Time in Seconds

MD

5 C

om

pu

tati

ons

per

Sec

ond

CpuHog

MD5-Servlet A

MD5-Servlet B

MD5-Servlet C

CpuHog starts

CpuHog's share minimized Servlet C's shares increased

Dissertation Defense 6/12/2001 41

GarbageHog Scenario

0

2

4

6

8

10

12

14

16

18

20

0 10 20 30 40 50 60 70 80 90 100 110 120 130Time in Seconds

MD

5 C

om

pu

tati

on

s p

er

Se

co

nd

GarbageHog

MD5-Servlet A

MD5-Servlet B

MD5-Servlet C

GarbageHog starts

GarbageHog's share minimizedServlet C's shares increased

Dissertation Defense 6/12/2001 42

Outline

The Case for KaffeOS KaffeOS’s Design Experimental Evaluation Related Work Future Work and Conclusion

Dissertation Defense 6/12/2001 43

Related Java Work

Java VMs– Multi-processing JVM [Balfanz 98]

– J-Kernel [Hawblitzel et al. 98]

– Alta [Tullmann 99]

– IBM OS/390 JVM [Dillenberger 00]

– MVM [Czajkowski 01]

– JSR 121

Java Language Extensions– Luna [Hawblitzel 99]

Java Realtime Extensions– Realtime Working Group [Sun et al. 00]

Dissertation Defense 6/12/2001 44

Related OS Work

Single-address-space OS– Opal [Chase et al. 94]

Single-language OS– Pilot [Redell et al. 80]

– Cedar [Swineheart et al. 86]

– Inferno [Dorward et al. 97]

Extensible OS– SPIN [Bershad et al. 95]

Dissertation Defense 6/12/2001 45

Outline

The Case for KaffeOS KaffeOS’s Design Experimental Evaluation Related Work Future Work and Conclusion

Dissertation Defense 6/12/2001 46

Future Work

JanosVM (ongoing)– Java operating system for active network node

Integration in higher-performing JVM– More accurate evaluation of costs and benefits

Static analysis using meta-level compilation– Ensure properties about user/kernel mode, shared and reloaded

classes etc. statically

Automatic user-level sharing

Dissertation Defense 6/12/2001 47

Contributions

Operating system principles apply to language runtime systems

– Architectural concept: user/kernel boundary

Software mechanisms can be used to implement full isolation of processes in a Java virtual machine

– GC mechanisms: write barriers, distributed GC techniques

KaffeOS demonstrates how to reconcile isolation, resource management and sharing

– Can stop resource-based denial-of-service attacks with small penalty for well-behaved code

Dissertation Defense 6/12/2001 48

Acknowledgments

Wilson Hsieh

Patrick Tullmann Jason Baker Tim Stack

Jay Lepreau and rest of Flux group for support and feedback on earlier papers

Dissertation Defense 6/12/2001 49

The End

Time for more Questions