Multitasking JVMs

Isolates and KaffeOS

Presentation by

James Rose

Multitasking in Java

We want to share the virtual machineShare bytecodeShare JIT-compiled native codeStart JVM onceEfficient IPC

Naïve approach

Create a thread for each task Hope for the best!

Problems with Sharing

No way to enforce separationNo accounting for resourcesNo way to safely terminate

processes

Approaches

Code-to-code translationModified 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 classDefines a simple mechanism for

passing messagesMVM: 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 clientspublic 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 AIsolate 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

serverget print 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

SharedCode

HeapHeap

Isolate 1Isolate 2

XIMI