Multitasking JVMs Isolates and KaffeOS Presentation by James Rose

Multitasking in Java We want to share the virtual machine Share bytecode Share JIT-compiled native code Start JVM once Efficient IPC

Naïve approach Create a thread for each task Hope for the best!

Problems with Sharing No way to enforce separation No accounting for resources No way to safely terminate processes

Approaches Code-to-code translation Modified JVM Approach taken by Kaffe, MVM

Sharing in KaffeOS Per-process heap and namespace Shared heaps for communication between processes Common shared.* namespace for all shared objects

KaffeOS Memory Structure  No pointers to user heaps except from kernel

Separation in KaffeOS Write barrier prevents illegal references Shared code can’t keep user objects alive All heaps have independent GC Cross-heap references tracked by reference counting

Termination in KaffeOS User/kernel separation allows safe termination Termination deferred inside kernel code Shared objects are always on top of call stack: malicious code can be terminated without harm to system

Accounting in KaffeOS Memory accounting includes allocations within the VM for a process Independent GC improves accuracy Shared heaps charged to all sharers Precise resource accounting prevents denial-of-service attacks

JSR-121: Isolates and MVM Defines Isolate class Defines a simple mechanism for passing messages MVM: HotSpot + JSR-121

MVM is not an OS No resource accounting

Cross-Isolate Method Invocation Or XIMI, for short Stripped-down version of RMI Isolates can call methods on stubs of objects in other Isolates Stubs are generated by the VM dynamically (no rmic )

Portals XIMI equivalent of RMI’s RemoteObject Objects are wrapped in Portals and passed to clients public abstract class Portal { static public Portal newPortal( Class interface, Object target, boolean copyable); //... }

Invoking Methods on Portals A method call spawns a new thread in the server… Or blocks until the server calls accept() Arguments to the method are “serialized” Not really, that’s slow Method calls may fail if server dies What happens then?

Heap Structure Generational GC: Shared old generation, per-isolate new generation XIReference : weak reference held only by stubs

Heap Structure XIReference XIMIStub$Map Portal HashMap Isolate A Isolate B old space Map nameserv new spaces

KaffeOS MVM Write barriers enforce isolation on shared objects Methods invoked directly Write barriers slow down all programs Objects or stubs are copied between isolates Methods execute in the owning isolate Resource accounting tricky

Applications Java shell Java daemon Dynamic web server Web browser Which model fits these applications better?

Web Server Natural way to code it: interface WebRequest { String getPath(); String getHostname(); String getHTTPVersion(); void println (String out); } interface Servlet { void run (WebRequest w); }

WebServer in KaffeOS WebRequest must be in shared.* But now WebRequest can’t do anything with WebServer ! The paper does not define a communication mechanism, only a sharing mechanism

WebServer in MVM/XIMI class WebServer { public void answerQuery(Socket s) { //..make WebRequest object.. port = Portal.newPortal( WebRequest, curRequest, false); new Isolate(appletName).start (port); }

XIMI WebServer Execution applet server getprint get print

This is stupid… Switching contexts like this is silly and slow But a coarse-grained interface is inconvenient for many applications RMI makes more sense between machines than within machines

MVM Structure Shared Code Heap Isolate 1 Isolate 2 XIMI