Transcript presentation source

KaffeOS:
Controlling Resources In A
Multi-Process Java Virtual
Machine
Godmar Back
Summary
A 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?
Java
Prg1
Java
Prg2
Java
Prg3
JVM
JVM
JVM
Java
Prg1
Java
Prg2
Java
Prg3
JVM
KaffeOS
Operating System
Operating System
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
Sharing Attack
Server
Client
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
User code (untrusted)
Runtime Libs (trusted)
Finalization
User
GC
User
Kernel
Kernel code (trusted)
Kernel
GC
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
• Per-process
heaps
• Separately
accounted
and
collected
Heap A
Kernel Heap
Heap B
Separating GC
• Collect heaps independently
• Use distributed garbage collection
technique
– cross-references treated like remote
references
• Monitor writes
• Shared scanning of thread stacks
Sharing
• Shared
objects
• Separately
accounted
• Fully
collected
• Basic
datatypes
Heap B
Heap A
Kernel Heap
Shared
Buffer
Programming Model
• Producer/Consumer
• Agree on buffer type
to share data
• Register shared type
• Create buffer
• Use it transparently
class Buffer {
int length;
int offset;
byte []data;
}
Sharing Example
• Producer
• Consumer
Class bufferClass = Shared.register(“Buffer”);
Buffer b = (Buffer)Shared.create(bufferClass, “ourbuffer”);
synchronized (b) {
produceData(b);
b.signal();
}
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 OSlike 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