Incommunicado

Incommunicado: Efficient Communication for Isolates ` ? Jan Vitek Krzysztof Palacz Grzegorz Czajkowski? Laurent Daynes 3 S Lab, Dept of Computer Sciences, Purdue University ? Sun Microsystems Laboratories, Mountain View, USA

ABSTRACT

Colo ating omputations in a single instan e of safe-language virtual ma hine an improve performan e and overall platform s alability. It also poses various hallenges. One of them is providing a very fast inter-appli ation ommuni ation me hanism. In addition to being eÆ ient, su h a me hanism should not violate any fun tional and non-fun tional properties of its environment, and should also support enfor ement of appli ation-spe i se urity poli ies. This paper explores the design and implementation of a ommuni ation substrate for appli ations exe uting within a single JavaT M virtual ma hine. In parti ular, our goal is to provide a minimal software layer for fast and se ure ommuni ation between isolated omputations in the ontext of the Multitasking Virtual Ma hine. Designing an eÆ ient extension that does not break isolation properties and at the same time pragmati ally oers an API very losely resembling this of the JavaT M Remote Method Invo ation has proven non-trivial. This paper demonstrates a set of te hniques that lead to at least an eight-fold performan e improvement over the in-pro ess inter-appli ation ommuni ation using standard me hanisms oered by the Java platform.

1.

INTRODUCTION

Running multiple omputations in a single instan e of the Java virtual ma hine (JVMT M ), for instan e exe uting many servlets in a Web server, has the potential for improving overall system performan e and s alability by sharing some of the virtual ma hine's internal data stru tures. Colo ation also reates opportunities for better management of resour es and elegant ontrol poli ies at the language level. The main diÆ ulty of delivering olo ation is that the platform must provide strong isolation guarantees to ensure that if one omputation fails or misbehaves, other omputations  Work

performed during a visit at Sun Mi rosystems Laboratories.

won't be disrupted or prevented from performing their assigned tasks. The Java appli ation isolation API urrently under review as JSR-121 [ ℄ de nes the basi fun tionality that an be used to reate and manage mutually disjoint omputations within the JVM. The key abstra tion proposed is that of an 1 isolate . Isolates are instan es of the Isolate lass, whi h provides the means to start a new omputation, suspend or stop a running omputation, and resume a stopped omputation. The isolation API does not de ne a resour e management interfa e, nor does it pres ribe a ommuni ation me hanism to allow appli ations to ommuni ate | it requires only that any ommuni ation me hanism preserve appli ation isolation.

?

The goal of our proje t, ode-named In ommuni ado due to the on i ting needs for keeping appli ations disjoint while allowing them to intera t, is to explore the design spa e of

ommuni ation infrastru tures for isolates. The presented design is by no means de nitive, nor are we in a position to advo ate its in lusion in the isolation API. Rather, we seek to gain experien e with the osts and bene ts of a parti ular s heme as well as to provide a ri h and eÆ ient platform for further experimentation. Designing a ommuni ation substrate for isolates is hallenging for several reasons. New ommuni ation me hanisms

annot interfere with other features oered by the underlying language or by its parti ular implementation. This item is parti ularly important: any new feature may have subtle intera tions with, for instan e, the automati memory manager, whi h in turn may impa t the safety of the language. Any ommuni ation me hanism should be general enough to a

ommodate the many dierent appli ation requirements, su h as dierent se urity poli ies [ ℄, and resour e limits [ ℄. Yet it must remain eÆ ient, so that the bene ts of olo ation are not drowned by the ommuni ation osts. In this respe t, it is essential to use a highperforman e virtual ma hine for experimentation. Using low-quality virtual ma hine implementations, or virtual ma hines without dynami ompilers, may skew the pi ture of the relative osts. Implementing the me hanism in a modern, fast virtual ma hine is mu h more time onsuming, but

?

?

1 This name was hosen in order to avoid further overloading of terms su h as task, pro ess, domain, et .

leads to performan e answers meaningful for pra ti al use. Similarly, byte ode editing approa hes are not only plagued by performan e problems, but typi ally must prohibit the use of ertain languages features [ ℄.

?

Another important guiding prin iple for an implementation is to pay as you go. In other words, appli ations that do not ommuni ate should not suer any slowdown due to the presen e of the new me hanism. This prin iple is key for pra ti al a

eptan e. is a new ommuni ation substrate for isolates that has been designed to provide a minimal interfa e for isolate ommuni ation and was implemented in the Multitasking Virtual Ma hine (or MVM) [ ℄. MVM exhibits many features we believe will be present in future virtual ma hines. In parti ular, it is a single-pro ess, highperforman e, full-featured virtual ma hine hosting multiple tasks in an interferen e-free way, with lean appli ation termination and resour e re lamation fa ilities. MVM has been designed to demonstrate that multitasking in a safe language

an be pra ti al and eÆ ient.

2.1 Application Isolation

The appli ation isolation interfa e urrently under review as JSR-121 provides an API to initiate and ontrol the exe ution of programs written in the Java programming language as isolates. An isolate, onstru ted as an instan e of the Isolate lass, en apsulates an appli ation or appli ation

omponent. Any program an be exe uted as an isolate: Isolate i = new Isolate(mainClassName, arguments); i.start();

In ommuni ado

?

The design of In ommuni ado an be hara terized by: 







Simpli ity

{ In ommuni ado is based on the Java remote method invo ation API, a model that is already familiar to programmers [ ℄. We have tried to minimize departures from the standard. Only two new

lasses were introdu ed to spe ify isolate-spe i features.

?

EÆ ien y { ommuni ation osts in our system are

between 8 and 70 times smaller than when lo ally using RMI. Thus we feel justi ed in advo ating the use of the substrate for performan e riti al appli ations.

Se urity

{ We provide poli y-neutral hooks for implementing powerful appli ation-spe i poli ies. The poli ies an be spe i ed simply and run eÆ iently.

Non-intrusiveness { The fun tional and non-fun tional properties of the underlying virtual ma hine were preserved. In parti ular, we were areful to preserve isolation and termination.

This paper shows how to use the new fa ilities and details the ross-isolate method invo ation pa kage (or XIMI) whi h is the enterpie e of our implementation. The main

ontributions of this work are thus a des ription of an RMI{ based isolate ommuni ation me hanism that addresses the above requirements while simplifying program development as well as an evaluation of its performan e.

2.

BACKGROUND

This se tion gives an overview of the aspe ts of appli ation isolation, MVM, and RMI relevant to In ommuni ado.

the only requirement being that the spe i ed main lass has a main(String[℄) method just like a Java appli ation exe uted from the ommand line. Unlike other exe ution ontainers, su h as servlets or applets, isolates guarantee stri t isolation between programs and guard them against various forms of interferen e. No spe ial oding onventions need to be followed within an isolate, nor is there a need for re ompilation or any other modi ation to the byte ode. Starting an isolate is analogous to starting a new JVM and gives programs the same rights: appli ations exe uted as isolates have full a

ess to all features of the JVM and to all

onstru ts of the Java programming language, ontrolled by standard permissions. The isolate API an be used to start new appli ations as isolates and to manage their life- y le (suspend, resume, terminate). For instan e, a Web server an hoose to start ea h servlet as an isolate, while servlets themselves an be oblivious of the fa t that they run as isolates. No parti ular te hniques are pres ribed to realize isolates, and implementation strategies an range from running the JVM in a separate pro ess for ea h isolate to exe uting all appli ations within a single multi-tasking JVM in a single pro ess. MVM is an example of the latter.

2.2 A Multitasking Virtual Machine

MVM is a general-purpose environment for exe uting disjoint Java appli ations in a single operating system pro ess. Internally, ea h isolate is supported by a logi al instan e of the JVM. The bulk of the runtime as well as the runtime representation of loaded lasses, whi h in ludes byte odes, meta-data des ribing the lass itself (e.g., its elds, methods and onstants) and ode produ ed by a dynami

ompiler, are shared among all JVM instan es. Creating a new JVM instan e only adds a small set of data stru tures that aptures the part of the exe ution ontext of a program that annot be shared (for example, storage for stati variables, lass monitors, and initialization status of

lasses loaded by the program, storage for its threads, and so on). This separation of the JVM runtime omponents into shareable and non-shareable and areful elimination of other possible sour es of interferen e among Java appli ations2 improves s alability as well as strengthens appli ation isolation when ompared to other urrently available approa hes and me hanisms su h as lass loaders, separate pro esses, or middleware ontainers. 2 A detailed atalogue of su h interferen e items an be found in [ ℄.

?

MVM grants ea h isolate a share of the global heap. No programmati means are given to obtain a referen e to an obje t allo ated by one isolate from another one. This guarantees that obje ts allo ated by dierent isolates belong to disjoint graphs of obje ts, and that ea h su h graph has disjoint sets of garbage olle tion roots. Ea h live root is uniquely asso iated with one isolate. Re laiming heap spa e used by an isolate onsists of ignoring the isolate's roots of liveness in subsequent garbage olle tions. When isolate i is terminated, either be ause it exits or be ause another, privileged isolate invokes i.stop(), the resour es allo ated to i must be re laimed. In parti ular, all threads of the isolate must be rolled forward out of any riti al se tions prote ting shared resour es until a termination-safe point where all the threads of that isolate

an be stopped and their resour es re laimed. Re lamation of resour es in ludes exe uting nalizers. Appli ationde ned nalizers are not guaranteed to terminate (e.g., be ause of in nite loops in their ode); resour e ontrol te hniques, beyond the s ope of the paper, address this problem.

2.3 Remote Method Invocation

The abstra tion of remote pro edure all (RPC) has proven to be versatile [ ℄, and has been adopted for a variety of software and hardware platforms. Communi ation me hanisms inspired by RPC but ustomized for a parti ular environment, su h as RMI [ ℄, have emerged. Their existen e provides a onvenient way for programmers to utilize the network apabilities via an API in the spirit of the programming language at hand.

?

?

While remote method invo ation is synta ti ally identi al to lo al method invo ation, there are signi ant semanti al differen es. Remote obje ts an only be manipulated using referen es of the interfa e type java.rmi.Remote or any other interfa e that extends it. Arguments to remote method invo ations as well as their return values are passed by deep opy following the semanti s of Java serialization. The ex eption to this rule is that instan es of java.rmi.Remote are passed by referen e: a stub is reated as repla ement for the remote obje t and its role is to forward invo ations. Beneath this high-level interfa e (the appli ation layer) lie three layers of implementation to whi h the user has programmati a

ess: 

3. AN ISOLATE COMMUNICATION SUBSTRATE

In ommuni ado provides XIMI, a simple interfa e to isolate ommuni ation based on RMI. At the appli ation level the programmer's interfa e has been modi ed (i) to add a new method to the Isolate { in our implementation this is done by extending the Isolate lass to MVMIsolate, and (ii) to in lude the IsolateSe urityManager lass (Figure 1). The semanti s of isolate ommuni ation onforms to the all semanti s and onventions of the appli ation layer of RMI. APIs providing a

ess to the lower layers of RMI are partially supported whenever relevant to in-pro ess ommuni ation. For example, XIMI does not have equivalents of lasses and methods providing programmati a

ess to the transport layer of RMI. This is motivated by the fa t that the fun tionality of these lasses and methods (su h as setting up and managing onne tions or monitoring their "liveness") is either not appli able or performed dierently in XIMI. Isolates are onstru ted by

manager lass. This reates an isolate that is a hild of the

urrent isolate. The l lass has to have a main() method and nm must extend IsolateSe urityManager. The reation of the isolate involves instantiation of the se urity manager whi h will enfor e the se urity poli y asso iated with this isolate. If the se urity manager is null the parent isolate's se urity poli y will be enfor ed. MVMIsolate also de nes the newInstan e(String l) method whi h instantiates an obje t of the lass l within the target isolate and

lass MVMIsolate extends Isolate f

MVMIsolate(String lassname, String[℄ arguments, String managername);

g

String name)

throws Se urityEx eption; void he kNewInstan e(Isolate sour e,

: provides automati ally generated implementations of subinterfa es of java.rmi.Remote, so

alled stubs. These stubs forward invo ations to the a tual, programmer-supplied implementations of these subinterfa es using the transport layer remote referen e layer: responsible for determining the identity of the remote obje ts, e.g., whether the remote obje t is repli ated or not, whether the remote obje t is urrently instantiated or has to be instantiated.



: responsible for onne tion management, en oding and dispat hing invo ations over the wire.

Remote newInstan e(String name);

lass IsolateSe urityManager extends Se urityManager f void he kLoadClass(Isolate sour e,

stub layer



new

MVMIsolate(String l, String[℄ args, String mn) where l is the name of the main isolate lass and mn the name of the isolate se urity

String lassName)

throws Se urityEx eption; void he kInvoke(Isolate sour e,

g

Thread thread, Obje t re eiver, Method method, Obje t[℄ arguments) throws Se urityEx eption; void he kReturn(Isolate sour e, Thread thread, Obje t[℄ result) throws Se urityEx eption;

transport layer

Figure 1: In ommuni ado interfa es.

interfa e Printer implements Remote f void print(Printable obj) throws RemoteEx eption;

...

g

Isolate isl = new MVMIsolate("Appli ation", null, null);

publi lass Appli ation f publi stati void main(String[℄ args) f...g

Printer pr = (Printer)isl.newInstan e("Appli ation.User");

stati publi lass User implements Printer f void print(Printable obj) f ... g

g

g

pr.print(something); ...

Figure 2: A simple example of isolate ommuni ation. The right-hand side ode fragment reates an isolate

ontaining the Appli ation lass, then instantiates the User inner lass and invokes the print method on the remote referen e. then returns a remote referen e to that obje t. The a tual

lass that will be instantiated is determined by requesting the target isolate's lass loader to load l.

3.1 Using XIMI

Figure 2 illustrates isolate ommuni ation. This example

onsists of a remote interfa e Printer with a single print() method and a lass \Appli ation" with a main() method as well as an inner lass User whi h implements Printer. An isolate is reated by instantiating the MVMIsolate lass with the name of the main lass (here Appli ation) and invoking the start() method on the instan e. At this point, the obje t graphs of the new isolate and the urrent appli ation are still disjoint. To initiate ommuni ation, the urrent isolate must request that a new instan e of the User lass be reated within the isolate isl. Then the referen e to that instan e an be used for ommuni ation. Se tion 5 explains how the existen e of su h a referen e does not break MVM's appli ation isolation. As shown above, XIMI remote obje ts are a

essible to lient appli ations as obje ts implementing one or more interfa es that extend java.rmi.Remote. Non-remote obje ts are always opied maintaining the semanti s of serialization, even if the implementation avoids the overhead of a tual serialization. Remote obje ts are passed by referen e as mandated by the RMI spe i ation. The only dieren e with RMI is how referen es to remote obje ts are obtained. RMI uses the java.rmi.Naming lass to a

ess the default registry while XIMI provides ximi.Naming with a similar API3 . In the above example the naming interfa e was not used sin e newInstan e() is suÆ ient for simple ases. More typi ally newInstan e() ould be used to merely bootstrap ommuni ation by providing an initial remote referen e through whi h other remote referen es ould be obtained. RMI provides a default implementation of non-repli ated non-persistent remote referen e semanti s in java.rmi.server.Uni astRemoteObje t. Appli ations need only extend 3 Sin e the methods of java.rmi.Naming are stati ximi.Naming does not extend the former but one ould modify the implementation of java.rmi.Naming to re ognize spe ially formed XIMI URLs and hand o the appropriate queries to the XIMI registry.

this lass to inherit its default implementation. XIMI provides an analogous lass, XIMIUni astRemoteObje t with non-repli ated non-persistent semanti s that an be extended to reate remote obje t implementations a

essible through XIMI. Similarly as in RMI implementations of Remote are not required to extend XIMIUni astRemoteObje t in whi h

ase an API method has to be invoked in order to make the obje t a

essible through XIMI from other isolates. So ketrelated low-level APIs, ontained in RMISo ketFa tory or RMIFailureHandler are not supported sin e XIMI does not use so kets.

3.2 Class Stubs

XIMI simpli es appli ation development by avoiding the intermediate step of stub generation. When RMI it is ne essary to invoke the remote stub ompiler, rmi , in an extra step of the development y le. The remote stub ompiler generates stub lasses given remote lass implementations. For ea h remote method in the remote interfa e implementation lass rmi generates a method in the stub lass with the same signature that marshals its arguments, sends them to the remote obje t and unmarshals the return value it re eives. Whenever an exported remote obje t is passed as a parameter or return value in a remote method all, the stub for that remote obje t is passed instead and the stub lass has to be available for loading in both lient and server. In XIMI stubs are generated dynami ally and on demand, hen e the prepro essing phase is not ne essary, no spe ial tools have to be invoked during development and no spe ial

are has to be taken to ensure that stubs be available for

lass loading.

3.3 Class loading

MVM provides a fast loading me hanism thanks to whi h full lass loading, in luding fet hing the lass le and parsing and verifying it, is required only by the rst isolate that loads a given lass. Subsequent loads of the same lass in other isolates are onsiderably faster [ ℄. The urrent version of MVM restri ts fast loading to the default lass loader. In future releases it is planned to lift this restri tion and allow user-de ned lass loaders to use fast loading. When possible, XIMI takes advantage of this me hanism and loads all

?

ne essary lasses using the same lass loader that was used to load the urrent isolate's main method. In parti ular, fast lass loading is used to load the generated stub lasses. All of our examples and ben hmarks use fast loading.

3.4 Distributed garbage collection

Garbage olle tion is totally transparent in XIMI and does not need interfa ing with user-level ode. The fun tionality of the java.rmi.dg pa kage is not supported, nor is it ne essary for the proper fun tioning of XIMI.

4.

ENFORCING SECURITY POLICIES

The se urity requirements of isolate ommuni ation dier from RMI in at least two respe ts. First, ontrolling network onne tions is a non-issue. Se ond, eÆ ien y is ru ial |not only should appli ations that do not require a se urity manager not pay any pri e, but those requiring se urity should not experien e overheads that would defeat the performan e gains of XIMI. For these reasons, In ommuni ado introdu es a sub lass of Se urityManager alled IsolateSe urityManager whi h provides poli y-neutral hooks that are general enough to implement a variety of se urity poli ies ontrolling ommuni ation between isolates. Instan es of IsolateSe urityManager and its sub lasses are able to interpose on all relevant XIMI operations and throw a Se urityEx eption if a given operation brea hes the appli able poli y. The ex eption is then serialized and rethrown in the aller's thread that issued the oending operation. Figure 1 summarizes the new methods of the lass. The he kLoadClass() method is invoked every time a new

lass is about to be loaded in the isolate, before loading the

lass. The arguments are the name of the lass to load and the isolate whi h aused the load. he kLoadClass() is either triggered as a side ee t of a newInstan e request or during deserialization of a isolate method invo ation if the target isolate is missing some lasses. The sour e isolate is the one that issued the request. he kLoadClass() is not invoked for stub lasses, these are 'safe' sin e they are automati ally generated by the VM. The he kInvoke() method is alled on e for ea h rossisolate method invo ation. Its arguments are the originating isolate, the re e tion obje t des ribing the method about to be invoked, its arguments, and the re eiver obje t on whi h the method will be invoked. he kInvoke() is alled within the target isolate after deserialization of the arguments, when all the argument obje ts have been fully initialized. This allows the se urity manager to inspe t and manipulate the method's arguments. This also opens up a possibility of a denial of servi e atta k (e.g., by reating large obje ts in onstru tors of deserialized obje ts), whi h

an be ontrolled by resour e management te hniques, beyond the s ope of this paper. The he kInvoke() method also re eives a referen e to the Thread belonging to the target isolate and exe uting that parti ular request. The

he kReturn() method allows the se urity manager to inspe t return values (and potentially modify them). Finally, the he kNewInstan e() method is invoked in the target isolate every time newInstan e() is alled. Note that the newInstan e() method is alled with a string argument

while he kNewInstan e() gets the a tual lass that is going to be instantiated. If loading is needed to obtain that

lass, he kLoadClass() is alled rst. Se urity poli ies are hosen by the urrent isolate and dynami ally asso iated with newly reated isolates. In other words the same appli ation an be asso iated with dierent poli ies at dierent times. For instan e the ode isl = new MVMIsolate("Appli ation", null, new RelaxedSe urityManger())

will reate a new isolate running the Appli ation lass with RelaxedSe urityManager. We will now illustrate some appli ations of the proposed API with some examples from the literature.

4.1 The JavaSeal security model

?

The JavaSeal mobile obje t system [ ℄ provides an abstra tion alled a seal, for sealed obje t, whi h plays a similar role to isolates. Just as isolates, seals are disjoint omputations whi h ommuni ate through hannels. The seal se urity model enfor es hierar hi al ommuni ation |a seal

an only ommuni ate with its dire t parent and dire t des endants in the seal hierar hy| and strong restri tions on

lass loading to prote t seals against ode inje tion atta ks |seals an only ex hange instan es of lasses known to both

ommuni ating parties. This poli y an be expressed by

he king for every invo ation that the interlo utor is either the parent isolate or a hild, and by throwing an ex eption if lass loading is triggered as a side ee t of isolate ommuni ation. The following lass demonstrates how to interpose on invo ations and loading requests.

lass SealPoli y extends IsolateSe urityManager f

g

Isolate thisIsolate = Isolate.getCurrentIsolate(); Isolate parentIsolate = thisIsolate.getParent(); void he kLoadClass(Isolate s, String n) throws Se urityEx eption f throw new Se urityEx eption(); g void he kInvoke(Isolate sr , Thread t, Obje t r, Obje t[℄ arguments) throws Se urityEx eption f if (sr .equals(parentIsolate)) return; else if (thisIsolate.equals(sr .getParent())) return; else throw new Se urityEx eption(); g

4.2 The Secure Object Spaces model

Bry e simpli ed the hierar hi al a

ess model of JavaSeal in [ ℄ by allowing any pair of isolates (or to use the terminology of the paper obje t spa es) to ommuni ate provided appropriate a

ess rights ould be obtained. A

ess rights were organized hierar hi ally so that a parent isolate ould grant and revoke the ommuni ation rights of its hildren. The JKernel [ ℄ provides a similar se urity model. To implement this fun tionality, we need to turn the se urity manager into

?

?

Parent Isolate

Child Isolate

Foo f = child.newInstance("FooImpl");

secmgr.checkLoadClass(parent, "FooImpl");

S

Serialization

D

Deserialization

G

Dynamic Generation of class stub

A

Allocation of stub and initialization of Remote reference

_xxxx = new FooImpl();

G

interface Foo extends Remote { Bar m(Bar b) throws RemoteException; }

A Bar b = new Bar(); Bar b2 = f.m(b); S

D

secmgr.checkLoadClass(parent, "Bar"); class FooImpl implements Foo { Bar m(Bar b){ return new Bar2(b); secmgr.checkInvoke(parent, ...); } } _xxxx.m(b_local_copy); secmgr.checkReturn(parent, t, ...);

S

secmgr.checkLoadClass(child, "Bar2");

class Bar2 extends Bar { Bar2(Bar b){...} ... }

D

Figure 3: Overview of the In ommuni ado infrastru ture. The alls to se urity manager and the opies are expli itely indi ated. a referen e monitor that he ks an a

ess matrix for every invo ation (for simpli ity we leave out the details of initializing the matrix):

lass SOSPoli y extends IsolateSe urityManager f

g

Isolate thisIsolate = Isolate.getCurrentIsolate(); void he kInvoke(Isolate sr , Thread t, Obje t r, Obje t[℄ arguments) throws Se urityEx eption f if (matrix(thisIsolate, sr ) == GRANT) return; else throw new Se urityEx eption(); g

4.3 Simple resource accounting

Appli ation servers may need to tra k the resour es expended to servi e a parti ular request, or for long running queries, if the lient isolate dies, the server may need to terminate requests. For this it is ne essary to asso iate threads with the isolates on whose behalf they are exe uting. This

an be done by keeping a thread to isolate mapping for ea h invoke.

lass A

ountingPoli y extends IsolateSe urityManager f ...

void he kInvoke(Isolate sr , Thread tr, Obje t r,

g

g

Obje t[℄ arguments) throws Se urityEx eption f thread2isolate.add(sr , tr);

The A

ountingPoli y has a variable thread2isolate whi h will re ord all threads performing servi es on the behalf of other isolates. The he kReturn() method an be used to deregister threads.

5. XIMI IMPLEMENTATION

The goal of the In ommuni ado implementation in the ontext of MVM was to introdu e the smallest possible number of new VM-level primitives that would provide adequate performan e and implement the remaining fun tionality in user-level libraries while taking advantage of the existing RMI infrastru ture. It was also important to ensure that In ommuni ado ould oexist with standard RMI. Our implementation is ontained in the ximi pa kage. The two new MVM runtime entry points were added:  mtvm instantiate() used to implement Isolate.newInstan e(String lassname)  mtvm invoke() used to implement a tual remote method

invo ations.

We now review the implementation.

5.1 Cross-isolate references

Obje ts residing in one isolate are represented in other isolates using instan es of the ximi.CrossIsolateReferen e

Isolate A

Isolate B

CrossIsolateReference

weak reference

FooImpl

XIMIRemoteStub$42

Foo

foo;

Figure 4: Cross-isolate referen es.

lass. Sin e these obje ts play the same role as remote obje t handles in RMI, they implement the java.rmi.server. RemoteRef interfa e. Furthermore CrossIsolateReferen e sub lasses WeakReferen e from the java.lang.ref pa kage and its instan es an only be reated from within the VM. Its referent eld ontains a regular referen e to an obje t in another isolate. This eld is ina

essible to the programmer, so that the appli ation isolation property of MVM is not violated. Weak referen es and other lasses from the java.lang.ref pa kage allow user ode to intera t with the garbage olle tor. In parti ular, whenever the garbage olle tor determines that an obje t is rea hable only through referent elds of WeakReferen es, it will atomi ally lear all these elds and make the obje t available for nalization. If an instan e of CrossIsolateReferen e, ir, refers to an obje t in isolate A from within isolate B, ir an be strongly rea hable (i.e. rea hable by following regular obje t referen es from a root obje t) only from B, and is allo ated on B's portion of the heap. The referent eld of a ross-isolate referen e that refers to an obje t in isolate A a ts as a garbage olle tion root for A (see Figure 4). Referent elds of strongly rea hable ross-isolate referen es a t as garbage olle tion roots of isolates' obje t graphs. In MVM the heap has generational organization, ea h isolate has its own private, independently- olle table new generation, while the old generation is shared (physi ally, but not logi ally, so as not to violate isolation). The design of XIMI for MVM leverages this fa t. Cross-isolate referen es are always allo ated in the old spa e. Thus, during new generation olle tion of an isolate no referen e pointing to a

ross-isolate referen e is traversed and the referent eld is not traversed. Instead, it is treated as a root, whi h guarantees that the obje t referred to by the ross-isolate referen e will not be olle ted, even though there might be no referen es to it from within the owning isolate. Therefore, new generation olle tions of one isolate never a

ess new spa es of other isolates. This is a desirable feature of XIMI as it maintains the independen e of olle ting new generations on per-isolate basis.

Global olle tions span all isolates and in ee t perform an equivalent of distributed garbage olle tion with no extra

ode involved. Ea h ross-isolate referen e a hes the identity hash ode of the obje t it points to so that its implementation of hashCode() does not require ross-isolate a

esses. The equals() method of ross-isolate referen es is implemented as a native all a

essing the referent elds and performing a pointer equality test (a native all is ne essary be ause referent is a private eld inherited from java.lang.ref. Referen e). Also, syn hronizing on an instan e of CrossIsolateReferen e will serialize a

esses to that obje t but it will not serialize a

esses to the obje t pointed to by the referent eld; this is onsistent with the behavior of RMI and with MVM's properties of appli ation isolation. In order to ensure that the referent eld of ross-isolate referen es are indeed unrea hable to the programmer small

hanges to the JDK libraries were ne essary. The Java programming language allows trusted user ode to ir umvent language prote tion me hanisms using re e tion; hen e it was ne essary to introdu e an extra he k in the setA

essible() method of java.lang.refle t.A

essibleObje t to prevent the programmer from making the referent eld a

essible. This method is rarely used (mainly during serialization), the extra he k is not expensive thus the resulting overhead (and impa t on non-XIMI-related ode) is negligible.

5.2 Remote stubs and invocation

As mentioned earlier, in XIMI the rmi tool is not run reate remote obje t stubs. Instead, stubs are reated on demand by the virtual ma hine. In the implementation the newInstan e(String ) method of Isolate returns an instan e of a dynami ally generated sub lass of XIMIRemoteStub, whi h in turn extends java.rmi.server.RemoteStub. Note that the latter lass maintains a referen e to an instan e of java.rmi.server.RemoteRef. For XIMIRemoteStub this referen e always points to an instan e of CrossIsolateReferen e, a subtype of the RemoteRef interfa e. This is onsistent with the general notion that XIMI is a spe ial ase of RMI. Dynami sub lass generation is performed entirely in the Java programming language by the XIMIStubGenerator lass.

It maintains a a he of stub lasses keyed by lists of remote interfa es they implement. This approa h is very similar to the Proxy API introdu ed in JDK 1.3 [ ℄; in fa t XIMIStubGenerator is a minor modi ation of the lass used internally in JDK 1.3 to generate the byte odes for proxy

lasses. The hanges were introdu ed to make the generated proxies extend the java.rmi.server.RemoteStub lass and thus to better integrate with the RMI infrastru ture.

?

When XIMIStubGenerator builds the stub for a given lass, for ea h method in ea h remote interfa e implemented by the original lass a method is emitted su h that: (i) it has the same signature as the original method, and (ii) it pa kages the arguments as an array of obje ts and passes them, along with an instan e of the java.lang.refle t.Method identifying the remote method to be alled, to the rossisolate referen e embedded in the stub instan e. The rossisolate referen e then alls its invoke() method whi h results in the mtvm invoke() VM all. The virtual ma hine appropriately transmits the arguments over to the target isolate, resolves and alls the method in the target isolate, and transmits ba k the return value. If the arguments or the return value implement the Remote interfa e themselves, XIMIStubGenerator may be alled from within the virtual ma hine to build the ne essary stubs if they have not been

reated yet.

5.3 Serialization

One of the biggest performan e advantages of XIMI ompared to RMI omes from optimizations that an be arried out when performing serialization within the same virtual ma hine. Serialization of most lasses does not require invo ation of library or user ode and thus an be performed entirely in the JVM as a deep opy, as long as only obje ts implementing java.io.Serializable are opied and the semanti s of transient elds is preserved. In ertain ases serialization and de-serialization involves invoking arbitrary ode spe i ed by the author of a given lass or it super- lass(es). This an happen when at least one of the following onditions holds:  the lass implements the Externalizable interfa e,  the lass (or its super- lasses) has any of the spe ial methods readObje t(), readResolve(), writeObje t(), writeRepla e() that are not in luded in any interfa e

but are dis overed by re e tion; there might be many of ea h of those per lass sin e ea h super- lass may de lare its own private spe ial methods, or

 the lass is serializable but one of its super- lasses is

not. In this ase the parameter-less onstru tor of the super- lass has to be invoked on de-serialization.

Classes requiring invo ation of ode written in the Java programming language will be referred to as spe ial, as opposed to \normal" lasses whose serialization an be handled entirely within the virtual ma hine. The methods readObje t() and writeObje t() take java.io.Obje tOutputStream and

java.io.Obje tInputStream instan es as arguments, respe -

tively. A lass implementing these methods an en ode/de ode its elds in any way it sees t using the instan es of these stream lasses passed as arguments. It is therefore ne essary to provide su h instan es during serialization/de-serialization when they are required. Whenever the virtual ma hine dis overs that an instan e of a lass that de nes readResolve() or writeObje t() has to be serialized, a pair of instan es of Obje tOutputStream and Obje tInputStream is allo ated if it does not exist already and the serialization is performed by the ode of Obje tOutputStream. This ode alls writeObje t() of the spe ial lass just en ountered and analogous methods of all the spe ial lasses en ountered later during the urrent serialization/deserialization pro ess. The original serialization ode attempts to serialize all obje ts rea hable from the obje t re eived. Sin e in XIMI there are two obje t graph serialization me hanisms trying to serialize the same graph (one on the virtual ma hine side an one on on the Java programming language side), this poses two problems. First, a normal obje t rea hable from a spe ial obje t ould be opied twi e (by the virtual ma hine deep opy and by serialization). Se ond, when an obje t is pa kage ximi; import java.rmi.server.RemoteStub;

lass CrossIsolateReferen e extends java.lang.ref.WeakReferen e implements java.rmi.server.RemoteRef f

// Obje t referent; // inherited from WeakReferen e

g

native Obje t invoke(Method m, Obje t args) throws RemoteEx eption;

publi lass Isolate f ...

publi Remote newInstan e(String s) f

CrossIsolateReferen e xref = newInstan e0( );

g g

return XIMIStubGenerator.generateStub( , xref);

native CrossReferen eIsolate newInstan e0(String );

interfa e Printer extends java.rmi.Remote f void print(Printable arg) throws RemoteEx eption; g

lass XIMIRemoteStub extends RemoteStub f

// RemoteStub ref; // inherited from RemoteStub XIMIRemoteStub(ximi.CrossIsolateReferen e ref) f this.ref = ref; g

g // dynami ally generated

lass XIMIGeneratedRemoteStub$42 extends XIMIRemoteStub implements Printer f stati Method printM = ...; publi void print(Printable p) f Obje t[℄ args = fpg; ((CrossIsolateReferen e)ref).invoke( allM, args); g g

Figure 5: Summary of XIMI implementation.

de-serialized the virtual ma hine needs to know whi h obje t it is a opy of, so that it an update all the fast- opied obje ts that are supposed to point to it. The problem here is that the information about the obje t's identity is lost during serialization/de-serialization. Therefore, it is ne essary to inform the virtual ma hine whi h obje ts are being written to the stream. For this purpose XIMIObje tOutputStream and XIMIObje tInputStream have been reated as sub lasses of Obje tOutputStream and Obje tInputStream, respe tively. A sub lass of Obje tOutputStream may override the repla eObje t() method that will be alled on ea h obje t written to the stream. The overridden method may return a dierent obje t from the one passed to it and the returned obje t will be serialized instead of the original. However, the XIMIObje tOutputStream implementation of that method returns the original obje t passed to it as argument and invokes a allba k to the virtual ma hine informing it that this obje t is being serialized. Similarly XIMIObje tInputStream overrides resolveObje t() to perform a allba k to the virtual ma hine informing it about what obje t is being deserialized. The overridden methods an be also used to prevent unne essary serializing of normal obje ts. For spe ial obje ts repla eObje t() of XIMIObje tOutputStream works as des ribed above, but for normal obje ts it returns an instan e of ximi.NormalObje tRepla ement instead. This obje t has only one integer eld whose value is a pointer to a variable within the VM address spa e that ontains a pointer to the a tual obje t (so alled global JNI handle). Su h global JNI handles an be safely embedded in obje ts as integers be ause NormalObje tRepla ement instan es are never rea hable from user ode and even though the garbage olle tor may move obje ts to whi h JNI handles point to when serialization/deserialization is being performed, the addresses of the handles themselves remain unae ted. The size of NormalObje tRepla ement is most likely smaller than the size of the obje t it is repla ing and sin e it has no referen e elds, it will not ause the re e tion ode to serialize re ursively all the obje ts the original obje t points to. Thanks to the allba k in repla eObje t() the virtual ma hine is informed that the original obje t has to be opied on the VM side and its referen e elds have to be pro essed. This te hnique ensures that pointers from spe ial obje ts to normal obje ts are updated orre tly. Note that pointers from spe ial obje ts to spe ial obje ts are handled entirely by ode written in the Java programming language by the standard serialization routines and pointers from normal obje ts to normal obje ts are handled entirely by the XIMI implementation inside the virtual ma hine. In order to orre tly handle pointers from normal obje ts to spe ial obje ts, ximi.Spe ialObje tRedire tion are used. When a spe ial obje t "emerges" from deserialization, the VM side does not know whi h spe ial obje t it is a opy of, so it annot update the fast- opies of normal obje ts to point to it. It is not guaranteed that during a given serialization/deserialization the n-th all to resolveObje t()

will be invoked on the obje t returned by the n-th all to

repla eObje t(). Therefore one annot assign serial numbers to spe ial obje ts in the repla eObje t() allba k and

identify them on deserialization.

The following solution has been implemented. Ea h time a repla eObje t() method is invoked on a spe ial obje t, a Spe ialObje tRedire tion is reated. Before the XIMIObje tOutputStream is losed, all the a

umulated Spe ialObje tRedire tion obje ts are saved to it. These obje ts

ontain two elds, one is a referen e to the original spe ial obje t and the other is the same referen e in form of a native pointer (again, an integer eld ontaining a pointer to the global JNI handle of the original obje t). On deserialization, the native pointer retains its value while the Java referen e is updated to point to the deserialized opy of the spe ial obje t. The overridden resolveObje t() method of XIMIObje tInputStream invokes a allba k that informs the virtual ma hine about the address of the opy of the spe ial obje t so that referen es pointing to it an be orre tly updated. Again, the memory overhead of those extra obje ts is relatively small (two elds plus serialization overhead) and proportional to the number of spe ial obje ts. The above solution has the following problem: when ode written in the Java programming language dete ts an obje t that spe i es a writeRepla e() method, it alls the method and passes the repla ement obje t to its repla eObje t() method. Therefore XIMIObje tOutputStream annot see the original obje t and annot register it with the VM. However, there might be normal obje ts with referen es to the original obje t and the VM does not know that these referen es should be updated to point to the repla ement when these obje ts are deserialized. Currently, the solution to this problem is to hange the implementation of Obje tOutputStream to in lude a registerRepla ement(Obje t original, Obje t repla ement) method that is alled whenever a repla ement is instantiated. The default implementation of this method does nothing, but XIMIObje tOutputStream overrides this method and ensures that the Spe ialObje tRedire tion instan e reated for the obje t being serialized ontains the original obje t, not its repla ement(s). This is a small JDK

hange and an be easily maintained.

5.4 Threads

There are several hoi es regarding on whi h sta k and in whi h thread in the target isolate a remote method shall be invoked. XIMI urrently employs an "impersonation" te hnique: whenever an obje t is instantiated in another isolate or a all is performed on an obje t residing in another isolate the urrent thread temporarily hanges its ee tive task ID, thus rossing over to the other isolate for the duration of the

all or instantiation. In order to ensure preservation of isolation properties a new java.lang.Thread obje t is allo ated upon rossing the isolate boundary and asso iated with the VM-side thread obje t. When the remote all ompletes the original java.lang.Thread obje t is restored (following sta k dis ipline). Appropriate try- at h blo ks are inserted to insulate the aller from a failure in the allee's ode. It is likely that the same thread will all a remote method again on the same isolate, therefore for ea h isolate a weak

referen e to the thread most re ently allo ated by XIMI is maintained. Thanks to this a hing me hanism repeated allo ating and throwing away Thread obje ts is avoided in most ases. Overall, the presented approa h results in little overhead for XIMI alls.

5.5 Termination

An isolate an be terminated at any time, and in ee t referent elds of ross-isolate referen es may be ome invalid at any time. However, the referent elds an only be a

essed either by spe ial isolate-aware JVM down alls or through the garbage olle tor. If an isolate is terminated while in JVM ode, the omputation will be aborted and an ex eption will be reported to the alling isolate. From the garbage olle tor's perspe tive all obje ts in the terminated isolate will be either unrea hable or rea hable through referent elds of ross-isolate referen es, i.e., weakly rea hable (sin e CrossIsolateReferen e inherits from WeakReferen e). A

ording to the language spe i ation, on e the garbage olle tor determines that an obje t is weakly rea hable (i.e. rea hable through the referent elds of WeakReferen es but neither through regular Java referen es nor the referent elds of SoftReferen es) it is required to "atomi ally lear all weak referen es to that obje t and all weak referen es to any other weakly-rea hable obje ts from whi h that obje t is rea hable through a hain of strong and soft referen es" [ ℄. In the ontext of MVM this means that no dangling referen es will ever appear upon isolate termination: either the referent eld of CrossIsolateReferen e is null or it points to a valid obje t and the native down all an determine that the isolate has been terminated. On e the referent elds are leared all the obje ts belonging to the terminated isolate be ome available for re lamation. It is important that the new generation of the terminated isolate be a tually s avenged (and not disposed of without examination), otherwise the CrossIsolateReferen es would not have their referent elds leared, thus possibly misleading the global garbage olle tor during its future runs. An alternative not requiring new generation s avenging upon isolate termination would be to maintain a list of all ross-isolate referen es.

?

The urrent implementation limits the possibilities of immediate re lamation of all resour es of an isolate upon its termination: when a remote all is in progress the isolate that initiated the all annot be easily terminated be ause the thread exe uting the all has allo ated various VM-side resour es (e.g., memory) and the VM depends on unwinding the thread sta k to re laim these resour es. The thread

annot be terminated safely in the isolate where the remote

all is being exe uted so the initiating isolate an be safely terminated only whenever the thread returns from the remote all, whi h may happen after an arbitrarily long time. This limitation ould be removed by providing me hanism for releasing VM-side resour es from sele ted parts of the thread.

5.6 Naming

In order to start using remote obje ts RMI lients need to obtain referen es to these obje ts. In order to obtain these

referen es, RMI lients present textual names to registry obje ts. Sin e the ommuni ation with registry obje ts is also performed using RMI, an API is provided to obtain a referen e to the bootstrap registry obje t itself. RMI an have dierent naming on gurations, it provides an interfa e, java.rmi.naming.Registry, and methods to lo ate the registry, while the a tual naming an be implemented in various on gurations (e.g. entral dire tory with ba kup, a star on guration et ). However, a reasonable default is provided. Along the same lines naming an be on gured in various ways in XIMI and a

essed using the same interfa e, however, a default on guration is provided. In this on guration there is a VM-wide registry that is instantiated on demand and lo ated in the primordial isolate (the rst isolate

reated in the VM). Other isolates instantiate spe ial forwarding registries that relay queries to the entral registry. The above mentioned ximi.Naming lass provides stati onvenien e methods that an be used to a

ess the default registry implementation, similar to java.rmi.Naming. It is worth noting that the implementation of registries does not involve spe ialized MVM support (just as naming in RMI is implemented using RMI itself).

6. PERFORMANCE

In order to evaluate the eÆ ien y of XIMI in omparison to RMI we performed a set of mi roben hmarks. The mi roben hmarks are intended to re e t either how RMI is used in real-world appli ations or how XIMI might be used for isolate ommuni ation. In our baseline on guration both the lient and the server were lo ated in the same JVM and and ommuni ated via regular RMI. Therefore effe ts related to full serialization and use of operating system

ommuni ation primitives are observed but not networkrelated overhead. The experimental setup onsisted of a Sun EnterpriseT M 3500 server with four UltraSPARCT M II pro essors, with 4GB of main memory, running the SolarisT M Operating Environment, version 2.8. The baseline on guration was exe uted using the Java HotSpotT M virtual ma hine (referred to from now on as HSVM), version 1.3.1, with the JDK version 1.3.1. This is also the ode basis for the MVM prototype used in our experiments, whi h allows for meaningful omparisons. Ea h remote method implementation in our ben hmarks returns the value it has been passed as an argument. We organized our ben hmarks in the following groups depending on the type of arguments passed to the remote all:  prims: eight ben hmarks in whi h values of various

primitive types are passed and one ben hmark where the remote all does not take arguments and returns void

 primarr: eight ben hmarks in whi h 100 element ar-

rays of various primitive types are passed around

 smallobj: one ben hmark with binary trees of depth

5; ea h node in the tree ontains only links to its left and right des endant as well as its parent

 bigobj: one ben hmark with binary trees of depth 5;

ea h node in the tree ontains the same elds as in

10

12.1 10.5

10.0 8.4

8

6.1

6

4

1.4

2 0

prims

primarr

smallobj

bigobj

objarr

90% 80% 70% copy phase 1 copy phase 2 other stub creation isolate switch time

60% 50% 40% 30% 20% 10%

e ot m re

rr ja ob

bj go bi

al

lo

bj

0%

Figure 7: Remote invo ation stages and their run time ontribution.

percentage of RMI time 14 12

100%

ar r

Figure 6 presents the exe ution time of XIMI-based invo ations expressed as per entage of the exe ution time of the baseline on guration. It shows that XIMI is at least 8 times faster than RMI. The biggest dieren e is observed with smallobj, for whi h XIMI performs more than 70 times better than the baseline. This an be explained by XIMI's more eÆ ient serialization, exe uted entirely within the VM in this ben hmark. Other ben hmarks do not experien e similar improvements either be ause serialization is not as heavily used (e.g., primarr serializes a single obje t per invo ation, prims serializes only one boxed primitive value per invo ation), or be ause other osts are more prominent. In parti ular, the performan e gains obtained from an optimized serialization de rease as the size of transferred obje ts in reases, as indi ated by the dieren e between smallobj and bigobj.

sm

For ea h type of argument we measured the time needed to exe ute 1000 remote method invo ations.

Figure 7 shows the ontributions of various stages in XIMI as the per entage of the total running time. The osts of a XIMI remote invo ation break down into ve omponents: byte- opying, referen e pat hing, stub reation, isolate ontext swit h, and \other" osts.

im

 remote: one ben hmark with 100 element arrays of obje ts implementing the java.rmi.Remote interfa e

s

a root of a binary tree of depth 5

pr

 objarr: one ben hmark with 100 element arrays of the same type as nodes in bigobj; ea h array entry is

primarr sin e arrays are obje ts already. The xed ost of boxing primitives is in urred by both RMI and XIMI and hen e the improvement a hieved by XIMI in prims is lower than in primarr. In fa t while for RMI prims is faster in absolute numbers than primarr, for XIMI it is primarr that is faster than prims.

im

and a String eld

pr

smallobj and also a one eld for every primitive type

remote

Figure 6: XIMI running time as per entage of RMI running time. We believe that most a tual uses of RMI resemble the smallobj ben hmark, hen e its good performan e is most indi ative of the advantages XIMI may have in the ontext of its pra ti al, real-world appli ations. It is interesting to see that XIMI a hieves better improvement on primarr than primobj. However, re all that in order to perform remote method invo ation with a primitive argument, both XIMI and RMI wrap the primitive value with an obje t type during all marshalling and unwrap the result on method return. This is not required in ase of

The opying me hanism for passing arguments and returning a result pro eeds in two phases. Phase 1 opies the obje ts into the target isolate, sets the transient elds in the opies to their default values, and establishes a mapping between original obje ts and their opies. Phase 2 uses this mapping to update all referen e elds in the opies. Whereas performan e of phase 1 depends on the size of the obje ts, phase 2 depends on the number of opied referen es. As result, the duration of phase 2 for both prims and primarr, where the passed obje ts do not in lude any referen es, is only a small fra tion of the overall running time. Dynami stub generation imposes a ost only when referen es to obje ts implementing the Remote interfa e are passed a ross isolates, as it is the ase with remote (the only ben hmark for whi h stub generation o

urs while exe ution time is measured). Ea h su h referen e must be repla ed at the target with a referen e to a stub obje t of the orresponding type. This requires, for ea h Remote referen e,

he king whether the stub lass exists, and if so, onstru ting an instan e of it. The generation of a given stub lass is a one-time event a ross all isolates, and only the rst isolate to use a parti ular stub lass pays the ost of full loading of that lass. Subsequent isolates use fast loading. Thus, the

ost of generating a stub is amortized a ross all isolates. The osts of rossing isolate boundaries are negligible. This is due to the impersonation te hnique used in the implemen-

tation of XIMI as well as Thread obje t a hing des ribed earlier. The results of the above presented ben hmarks do not re e t the osts of handling spe ial obje ts during serialization. These osts are highly dependent on the number of spe ial obje ts en ountered during this pro ess. Our experiments indi ate that in the extreme ase, when all serialized obje ts are spe ial, XIMI performs in fa t slower than RMI. This is understandable sin e syn hronizing two graph serialization me hanisms is ostly (it involves serializing additional obje ts and ommuni ating between the Java libraries and the VM ode) and is worth performing only if the amount of spe ial obje ts among all the obje ts being serialized is small. However, in many ases ustom serialization/deserialization yields exa tly the same results as the deep opy performed by XIMI. For example, when implementing an array-based list the authors of the lass might hoose not to rely on the default serialization that would write the underlying array with possibly many null entries at the end but instead write only the non-null entries dire tly to the stream and re reate the array on deserialization. XIMI annot in general dis over that serialization and deserialization is semanti ally equivalent to a deep opy but ode written in the Java programming language might indi ate that this is the

ase by appropriately annotating lasses with that property, e.g., using a marker interfa e. Standard serialization would ignore this interfa e but XIMI would re ognize it as an indi ation not to treat instan es of lasses implementing this interfa e spe ially.

7.

RELATED WORK

A substantial body of work exists on spe ializing RPC for the lo al ase. Lightweight RPC [ ℄ and doors [ ℄ are representative examples. In the ontext of the Java programming language and the JVM, related eorts revolve around (i) interfa ing the JVM with fast, typi ally non-TPC/IP proto ols, (ii) improving the speed of RMI, by either layering it on top of faster proto ols or by redesigning and re-implementing it, and (iii) designing alternative ommuni ation me hanisms for omputations o-lo ated in the same instan e of the JVM.

?

?

Exposing new ommuni ation primitives to the programmer is typi ally a

omplished either via JNI or through extending the virtual ma hine. An example is Javia [ ℄, where a user-level network interfa e is exposed to programmers as a set of send/re eive methods. A major issue is buer management. Appli ations an allo ate pinned regions of memory and use them as arrays in the Java programming language. These arrays are obje ts and an be a

essed dire tly but are not ae ted by garbage olle tion as long as they need to remain a

essible by the network interfa e. Programmers manage buers expli itly and safely by deta hing their lifetime from the lifetime of their referen es: the allo ation of a buer does not result in reating an array referen e to it (whi h has to be obtained by an expli it all) and the buer is not expli itly freed when there are no more referen es to it. To maintain the safety properties of the language, the garbage olle tor was modi ed to hange the s ope of its olle ted heap dynami ally. Buers are not moved by

?

the olle tor (whi h ee tively pins them to satisfy a requirement of the network interfa e) until their de-allo ation, whi h happens only after the appli ation states there are no more referen es to the buer and after the olle tor veri es this laim. Buer management in Javia is analogous to some issues in XIMI: ross-isolate referen es ee tively maintain

ommuni ation buers. One of the reasons Javia designers rely on programmer's expli it ooperation in identifying unused ommuni ation buers is the la k of weak referen es in their version of the JDK.

?

?

Manta [ ℄ and KaRMI [ ℄ are eÆ ient re-implementations of the RMI for high-performan e parallel omputing. Analyzing these systems reveals that while most of the sour es of diÆ ulties in their designs are the same as in XIMI, the solutions are dierent, as XIMI an make ertain assumptions related to o-lo ation of ommuni atng omputations. These assumptions simplify ertain de isions but also reate optimization opportunities not available in the general

ase of distributed ommuni ation. Manta layers RMI on top of a user-level ommuni ation subsystem. To re on ile the goals of preserving the eÆ ien y of the ommuni ation layer and retaining the exibility and interoperability of RMI, Manta heavily relies on ompile-time analysis. A native ompiler generates spe ialized serialization routines for serializable argument lasses, whi h avoids type inspe tion at run-time and pushes most of the proto ol overhead to ompile time. Polymorphi remote method invo ations that require dynami lass loading are supported at runtime: Manta will invoke its byte ode ompiler to generate the meta- lasses, serialization routines, and the obje t ode for the methods as if they were generated by the Manta sour e level ompiler. An important optimization is avoiding reating a new thread at the allee's site. The Manta

ompiler onservatively determines for ea h remote method whether it is guaranteed to exe ute without blo king. If so, it is exe uted without a thread ontext swit h. The Manta RMI proto ol ooperates with the garbage olle tor to keep tra k of referen es a ross ma hine boundaries, employing referen e ounting to tra k remote referen es. KaRMI is also designed to support non-TCP/IP ommuni ation networks. A major sour e of performan e gains is slim en oding of type information: while obje ts stored to disk must be readable even if byte ode of their lasses is not available in RMI, in the parallel omputing settings it an be safely assumed that the byte ode is always available from a le system. Another serialization improvement is implementing buering on the re eiver side, and not using the RMI approa h of buered streams on top of TCP/IP. KaRMI departs from the RMI standard, as it annot deal with ode that expli itly uses so ket fa tories or port numbers. Obje t a hing at the lient side has been identi ed as a potential sour e of signi ant performan e improvements to RMI [ ℄. Sin e most remote a

esses to obje ts are typi ally read-only this approa h an work well. However, in general maintaining onsisten y among a hed opies an be very

hallenging. Su h an approa h seems not very useful for XIMI, where the ommuni ation is fast.

?

Several proje ts aimed at safe and ontrolled dire t shar-

ing of obje ts among omputations o-lo ated in a single instan e of the JVM. For instan e the J-Kernel [ ℄ adds prote tion domains to the Java programming language and makes a strong distin tion between obje ts that an be shared between domains, and obje ts that are on ned to a single domain. The system provides me hanisms for lean domain termination. Inter-appli ation ommuni ation is performed via deep obje t opies of method arguments and return values, similarly to XIMI. However, ertain obje ts an be shared dire tly. They are wrapped inside apability obje ts, whi h support revo ation. A

essing su h obje ts is more expensive than using plain obje t referen es, sin e revo ation status must be he ked ea h time. In the J-Kernel appli ations that do not ommuni ate do not suer any performan e penalties related to the presen e of ustom ommuni ation me hanisms. A serious pra ti al limitation of J-Kernel is that it is a pure Java library. Depending on the implementation of the JVM on whi h J-Kernel runs, ertain s enarios may make lean termination impossible.

hallenges. In this paper we presented a detailed analysis of the design and implementation of a parti ular realization of this goal: equipping MVM with an eÆ ient isolate ommuni ation me hanism. In ommuni ado demonstrates that the goal of high-performan e do not have to on i t with safety and isolation properties. Several te hniques leveraging of the properties of the Java platform and of o-lo ating

omputations in the same instan e of the virtual ma hine lead to a signi ant performan e improvement { at least eight-fold when ompared to the lo al invo ation of RMI { while preserving the isolation, resour e a

ounting and lean termination properties of MVM.

Bry e and Vitek implemented JavaSeal, a mobile obje t platform in whi h disjoint omputations, alled seals, ould

oexist in the same Java virtual ma hine [ ℄. One of the dieren es with our approa h is that JavaSeal was a purely user-level pa kage whi h relied on user-de ned lass loader to enfor e disjointed-ness. Bry e later worked on se ure obje t spa es in whi h byte ode rewritting was used to ensure appli ation isolation [ ℄.

is a registered trademark in the United States and other ountries,

?

?

?

The interposition approa h take for the isolate se urity manager is not novel, similar ideas have been studied in the se urity ommunity [ , ℄ and, to some extent, it is related to the before and after advi e of Aspe tJ [ ℄.

??

?

Dire t obje t sharing has also been implemented through the modi ations to the virtual ma hine. An example of this approa h is KaeOS [ ℄, whi h supports the OS abstra tion of a pro ess in a Java virtual ma hine: ea h pro ess exe utes as if it were run in its own JVM, and has a separately olle table heap. There is also a single kernel heap, maintained by trusted ode and used to store obje ts related to user pro esses, for example, the obje ts that represent pro esses itself. KaeOS pro esses an dynami ally

reate a shared heap to ommuni ate with other pro esses. Obje ts on the shared heap are not allowed to have pointers to obje ts on any user heap, be ause those pointers would prevent this user heap's full re lamation. Write barriers enfor e this restri tion; attempts to assign su h pointers will result in an ex eption. As a write barrier is exe uted on every pointer write, even appli ations that never ommuni ate in ur performan e overhead related to the ost of obje t sharing. We view this as an important limitation. XIMI's use of weak referen es ee tively a hieves dire t but impli it obje t sharing, with no performan e onsequen es for non ommuni ating programs.

?

8.

CONCLUSIONS

Extending a multitasking-enabled virtual ma hine with a

ommuni ation me hanism that is at the same time eÆ ient, does not break any property of the virtual ma hine, and is exposed to programmers with a familiar API poses various

Trademarks Sun, Sun Mi rosystems, In ., Java, JVM, HotSpot, and Solaris are trademarks or registered trademarks of Sun Mi rosystems, In ., in the United States and other ountries. SPARC and UltraSPARC are a trademarks or registered trademarks of SPARC International, In . in the United States and other ountries. UNIX

ex lusively li ensed through X/Open Company, Ltd.

9. REFERENCES

[1℄ Godmar Ba k, Wilson H. Hsieh, and Jay Lepreau. Pro esses in KaeOS: Isolation, resour e management, and sharing in java. In Pro eedings of the 4th Symposium on Operating Systems Design and

Implementation (OSDI-00), pages 333{346, Berkeley, CA, O tober 23{25 2000. The USENIX Asso iation.

[2℄ B. N. Bershad, T. Anderson, E. Lazowska, and H. Levy. Lightweight remote pro edure all. ACM Transa tions on Computer Systems, 8(1):37{55, February 1990. Me hanism for ommuni ating between address spa es on a shared memory (multi)-pro essor. darrell ypress (Sun Mar 14 14:51:49 1993). [3℄ Walter Binder, Jarle Hulaas, and Alex Villaz`'on. Portable resour e ontrol in java: The j-seal2 approa h. In Pro eedings of the 16th Conferen e on Obje t-Oriented Programming, Systems, Languages,

, ACM SIGPLAN Noti es, New York, O tober 2001. ACM Press. and Appli ations (OOPSLA-01)

[4℄ Andrew D. Birrell and Bru e Jay Nelson. Implementing remote pro edure alls. ACM Transa tions on Computer Systems, 2(1):39{59, February 1984. [5℄ Ciaran Bry e and Chrislain Raza mahefa. An approa h to safe obje t sharing. In Pro eedings

of the

Conferen e on Obje t-Oriented Programming,

Systems, Languages and Appli ation (OOPSLA-00), volume 35.10 of ACM Sigplan Noti es, pages 367{381, N. Y., O tober 15{19 2000. ACM Press.

[6℄ Chi-Chao Chang and Thorsten von Ei ken. Interfa ing Java with the virtual interfa e ar hite ture. In ACM 1999 Java Grande Conferen e, June 1999. [7℄ Grzegorz Czajkowski and Laurent Dayes. Multitasking without ompromise: a virtual ma hine evolution. In

Pro eedings of the 16th Conferen e on Obje t-Oriented Programming, Systems, Languages, and Appli ations

, ACM SIGPLAN Noti es, New York, O tober 1998. ACM Press.

(OOPSLA-01)

[8℄ Troy Downing. Java

. IDG Books, 1998.

RMI

[9℄ T. Fraser, L. Badger, and M. Feldman. Hardening COTS software with generi software wrappers. In Pro eedings of the 1999 IEEE Symposium on Se urity

, pages 2{16, Washington Brussels - Tokyo, May 1999. IEEE.

and Priva y (SSP '99)

[10℄ Li Gong. Inside Java

2 platform se urity: ar hite ture,

. Addison-Wesley,

API design, and implementation

Reading, MA, USA, 1999.

[11℄ G. Hamilton and P. Kougiouris. The spring nu leus: a mi rokernel for obje ts. In Summer USENIX Conferen e, Cin innati, OH, June 1993. [12℄ Chris Hawblitzel, Chi-Chao Chang, Grzegorz Czajkowski, Deyu Hu, and Thorsten von Ei ken. Implementing multiple prote tion domains in Java. In Pro eedings of the USENIX 1998 Annual Te hni al

, pages 259{270, Berkeley, USA, June 15{19 1998. USENIX Asso iation. Conferen e

[13℄ Java Community Pro ess. Appli ation Isolation API Spe i ation. http://j p.org/jsr/detail/121.jsp, 2002. [14℄ Mi hael B. Jones. Interposition agents: Transparently interposing user ode at the system interfa e. In Barbara Liskov, editor, Pro eedings of the 14th Symposium on Operating Systems Prin iples, pages 80{93, New York, NY, USA, De ember 1993. ACM Press. [15℄ Gregor Ki zales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jerey Palm, and William G. Griswold. An overview of Aspe tJ. In J. Lindskov Knudsen, editor, ECOOP 2001 | Obje t-Oriented Programming 15th

, volume 2072 of Le ture Notes in Computer S ien e, pages 327{353. Springer-Verlag, Berlin Heidelberg, June 2001.

European Conferen e, Budapest Hungary

[16℄ Vijaykumar Krishnaswamy, Dan Walther, Sumeer Bhola, Ethendranath Bommaiah, George Riley, Brad Topol, and Mustaque Ahamad. EÆ ient implementations of Java remote method invo ation (RMI). In Pro eedings of the 4th Conferen e on Obje t-Oriented Te hnologies and Systems

, pages 19{36, Berkeley, April 27{30 1998. USENIX Asso iation. (COOTS-98)

[17℄ J. Massen, R. van Nieuwpoort, R. Veldema, H. Bal, and A Plaat. An eÆ ient implementation of java's remote method invo ation. In ACM PPoPP, Atlanta, GA, May 1999. [18℄ Christian Nester, Mi hael Philippsen, and Bernhard Hauma her. A more eÆ ient rmi for java. In Java Grande Conferen e, San Fran is o, CA, June 1999.

View publication stats

[19℄ Sun Mi rosystems, Ind. JavaTM 2 SDK, Standard Edition Do umentation. http://java.sun. om/j2se/1.3/do s/index.html , 2001. [20℄ J. Vitek and C. Bry e. The JavaSeal mobile agent kernel. Autonomous Agents and Multi-Agent Systems, 4, 2001. [21℄ T. Von Ei ken, C.-C. Chang, G. Czajkowski, and C. Hawblitzel. J-Kernel: A apability-based operating system for Java. Le ture Notes in Computer S ien e, 1603:369{394, 1999.