KaffeOS: Controlling Resources In A Multi-Process Java Virtual Machine Godmar Back.
-
Upload
marjory-fox -
Category
Documents
-
view
220 -
download
0
Transcript of 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
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