Download KaffeOS - School of Computing

KaffeOS: Isolation, Resource
Management and Sharing in Java
Dissertation Defense
Godmar Back
School of Computing
University of Utah
6/12/2001
1
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
2
Java Applications
Applet / Agent / Servlet / Database Procedure …
JVM
Base OS
This work is about system structure.
Dissertation Defense 6/12/2001
4
Current Options
-
Single JVM with
ad-hoc layer
App1
App2
App3
Ad hoc layer
- Efficient sharing
JVM
Base OS
-
Multiple JVMs
- Strong isolation
- Good resource
management
App1
App2
App3
JVM
JVM
JVM
Base OS
Dissertation Defense 6/12/2001
5
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
6
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
7
KaffeOS Core Ideas
To provide
KaffeOS uses
Isolation and Safe
Termination
Red Line
Memory Management
Separate Heaps
Interprocess
Communication
Flexible Resource
Management
Shared Heaps
Dissertation Defense 6/12/2001
Hierarchical Resource
Framework
8
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
9
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
10
Guaranteeing Consistency

Producer/Consumer Example
– Invariant: all produced items are consumed
class Queue {
synchronized Object get();
synchronized void put(Object);
}
Queue producer, consumer;
void run () {
while (!done) {
Kernel.enter();
Object obj = producer.get();
consumer.put(obj);
}
Kernel.leave();
}
Dissertation Defense 6/12/2001
11
Red Line in KaffeOS
User code (untrusted)
Runtime Libs (trusted)
Finalization
User
GC
User
Kernel
Kernel code (trusted)
System
GC
User/kernel dimension is different from trust dimension:
User mode
Kernel mode
Trusted
Runtime code
Kernel code
Untrusted
User code
Dissertation Defense 6/12/2001
12
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
13
Memory Management: Goals
1. Limit memory use of processes
2. Fully reclaim processes’ memory after termination
3. Garbage collect processes individually
Dissertation Defense 6/12/2001
14
Single Heap (Conventional JVM)
Object
Dissertation Defense 6/12/2001
Reference
15
Separate Heaps
Kernel Heap
User Heaps
Goal 1: Limit memory use
Dissertation Defense 6/12/2001
16
Reclaiming Memory
Hardware-based OS

Java runtime system
MMU maps virtual memory
No MMU
OS manages physical pages
Garbage Collector frees
unreachable objects
References can make
objects unreclaimable
Dissertation Defense 6/12/2001
17
Legal and Illegal References
Legal reference
Illegal reference
Goal 2: Full reclamation
Dissertation Defense 6/12/2001
18
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
19
Use of Entry and Exit Items
Entry Item
x
Exit Item
1
RefCount
n
n
2
x
n
1
x
x
Goal 3: Separate Collection
Dissertation Defense 6/12/2001
20
Collecting Cycles

Dissertation Defense 6/12/2001
Merge heaps upon
termination into kernel heap
21
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
22
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
23
Shared Heaps
Kernel Heap
Legal reference
Illegal reference
Shared
Heap
User Heap
Dissertation Defense 6/12/2001
User Heap
24
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
25
Shared Heaps: Trie Example
package shared;
class Trie {
A
static class TrieNode {
final static int WIDTH = 96;
TrieNode [] children = new TrieNode[WIDTH];
boolean eow = false;
}
private TrieNode
private int
root;
maxlength;
C
A
B
R
A
Trie(Reader r) throws IOException { … }
public void dump(PrintStream s) { … }
O
F
public boolean lookup(String s) { … }
B
}
C
N
T
import shared.Trie;
Shared sh = Shared.registerClass("shared.Trie", 1);
Trie trie = (Trie) sh.getObject(0);
A
A
K
… trie.lookup(“aback”);
Dissertation Defense 6/12/2001
26
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
27
Hierarchical Resource Framework

Resource API to allow for different policies

Hierarchical management

Work-conserving
Dissertation Defense 6/12/2001
28
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
29
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
30
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
31
SpecJVM Performance of KaffeOS
70
Runtime in Seconds
60
50
IBM JDK 1.1.8
Kaffe 2000
KaffeOS (fake heap pointer)
KaffeOS (heap pointer)
KaffeOS (no heap pointer)
KaffeOS (no write barrier)
40
30
20
10
0
compress
Dissertation Defense 6/12/2001
jess
db
javac
mpegaudio
mtrt
jack
32
Write Barrier Counts
Benchmark
Dynamic
Write Barrier
Conservative
Count Overhead (Best-case) upper bound for
(millions)
for No Heap Pointer
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
33
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
34
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
35
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
36
Service Under DoS Attack
25000
IBM/1
Successful requests in 30 second interval
IBM/n
KaffeOS
IBM/1+MemHog
20000
IBM/n+MemHog
KaffeOS+Memhog
15000
10000
5000
0
0
10
20
30
40
50
60
70
80
Number of servlets
Dissertation Defense 6/12/2001
37
MemHog Stresstest
9
Memory Usage in MB
8
7
y = 31.5 x + 7,926,291
6
5
y = 31.5 x + 5,623,933
4
3
Memory Consumption
2
overall bytes allocated
bytes on kernel heap
1
0
0
50
100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950
# of MemHogs killed
Dissertation Defense 6/12/2001
38
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
39
CpuHog Scenario
MD5 Computations per Second
20
CpuHog starts
18
CpuHog's share minimized
Servlet C's shares increased
16
14
12
10
8
6
CpuHog
4
MD5-Servlet A
MD5-Servlet B
2
MD5-Servlet C
0
0
10
20
30
40
50
60
70
80
90
100
110
120
130
Time in Seconds
Dissertation Defense 6/12/2001
40
GarbageHog Scenario
20
GarbageHog starts
MD5 Computations per Second
18
GarbageHog's share minimized
Servlet C's shares increased
16
14
12
10
8
6
GarbageHog
4
MD5-Servlet A
MD5-Servlet B
2
MD5-Servlet C
0
0
10
20
30
40
50
60
70
80
90
100
110
120
130
Time in Seconds
Dissertation Defense 6/12/2001
41
Outline

The Case for KaffeOS

KaffeOS’s Design

Experimental Evaluation

Related Work

Future Work and Conclusion
Dissertation Defense 6/12/2001
42
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
43
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
44
Outline

The Case for KaffeOS

KaffeOS’s Design

Experimental Evaluation

Related Work

Future Work and Conclusion
Dissertation Defense 6/12/2001
45
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
46
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
47
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
48
The End

Time for more Questions
Dissertation Defense 6/12/2001
49