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? Operating System JVM Java Prg1 JVM Java Prg2 Java Prg3 Java Prg1 Java Prg2 Java Prg3 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 User GC Kernel GC 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 AHeap 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 Shared Buffer

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