NRMI: Natural and Efficient Middleware

Transcription

1 NRMI: Naural and Efficien Middleware Eli Tilevich and Yannis Smaragdakis Cener for Experimenal Research in Compuer Sysems (CERCS), College of Compuing, Georgia Tech {ilevich, Absrac We presen NRMI: a drop-in replacemen for Java RMI ha suppors call-by-copy-resore semanics for arbirary linked daa srucures, in addiion o regular call-by-copy semanics. Call-by-copy-resore middleware is more naural o use han radiional call-by-copy RPC mechanisms, enabling disribued calls o behave much like local calls. We discuss in deph he effec of calling semanics for middleware, describe how call-by-copy-resore middleware can be implemened efficienly, and show examples of Java programs where NRMI is more convenien han regular Java RMI. 1. Inroducion Remoe Procedure Call (RPC) is one of he mos widespread paradigms for disribued middleware. The goal of RPC middleware is o provide an inerface for remoe services ha is as convenien o use as local calls. RPC middleware wih call-by-copy-resore semanics has been ofen advocaed in he lieraure, as i offers a good approximaion of local execuion (call-by-reference) semanics, wihou sacrificing performance. Neverheless, call-by-copy-resore middleware is no ofen used o handle arbirary linked daa srucures, like liss, graphs, rees, hash ables, or even non-recursive srucures like a cusomer objec wih poiners o separae address and company objecs. This is a serious resricion and one ha has been ofen idenified. The recen (00) Tanenbaum and van Seen Disribued Sysems exbook [17] summarizes he problem and (mos) pas approaches:... Alhough [call-by-copy-resore] is no always idenical [o call-by-reference], i frequenly is good enough.... [I] is worh noing ha alhough we can now handle poiners o simple arrays and srucures, we sill canno handle he mos general case of a poiner o an arbirary daa srucure such as a complex graph. Some sysems aemp o deal wih his case by acually passing he poiner o he server sub and generaing special code in he server procedure for using poiners. For example, a reques may be sen back o he clien o provide he referenced daa. This paper addresses exacly he problem oulined in he above passage. We describe an algorihm for implemening call-by-copy-resore middleware so ha arbirary linked srucures are fully suppored. The echnique is very efficien (comparable o regular call-by-copy middleware) none of he overheads suggesed by Tanenbaum and van Seen are incurred. A poiner dereference by he server does no generae requess o he clien. (This would be dramaically less efficien han our approach, as our measuremens show.) We do no generae special code in he server for using poiners: he server code can proceed a full speed no even he overhead of a local read or wrie barrier is necessary. We implemened our ideas in he form of NRMI (Naural Remoe Mehod Invocaion). NRMI is a modified version of he Java RMI, such ha he user can selec call-bycopy-resore semanics for objec ypes in remoe calls, in addiion o he sandard call-by-copy semanics of Java RMI. (For primiive Java ypes he defaul Java call-bycopy semanics is used.) The implemenaion of call-bycopy-resore in NRMI is fully general, wih respec o linked daa srucures, bu also wih respec o argumens ha share srucure. NRMI is much friendlier o he user han sandard Java RMI: in mos cases, programming wih NRMI is idenical o non-disribued Java programming. In fac, he call-by-copy-resore implemenaion in NRMI is guaraneed o offer idenical semanics o call-by-reference in he imporan case when single-hreaded cliens and saeless servers are used (i.e., when he server canno mainain sae reachable from he argumens of a call afer he end of he call). Since saelessness is a desirable propery for disribued sysems, anyway, NRMI offers behavior pracically indisinguishable from local calls. We would be amiss no o menion up fron ha oher middleware services (mos noably he DCE RPC sandard) have aemped o approximae call-by-copy-resore semanics, wih implemenaion echniques similar o ours. Neverheless, DCE RPC sops shor of full call-bycopy-resore semanics, as we discuss in Secion.. 1

2 This paper makes he following conribuions: A clear exposiion of differen calling semanics, as hese perain o RPC middleware. There is confusion in he lieraure regarding calling semanics wih respec o poiners. This confusion is apparen in he specificaion and popular implemenaions of exising middleware (especially DCE RPC, due o is semanic complexiy). A case for he use of call-by-copy-resore semanics in acual middleware. We argue ha such a semanics is convenien o use, easy o implemen, and efficien in erms of he amoun of ransferred daa. An applied resul in he form of NRMI. NRMI is a maure and efficien middleware implemenaion ha Java programmers can adop on a per-case basis as a ransparen enhancemen of Java RMI. The resuls of NRMI (call-by-copy-resore even for arbirary linked srucures) can be simulaed wih RMI (call-by-copy) bu his ask is complicaed, inefficien, and applicaionspecific. In simple benchmark programs, NRMI saves up o 100 lines of code per remoe call. More imporanly, his code canno be wrien wihou complee undersanding of he applicaion s ing behavior (i.e., wha poiner poins where on he heap). NRMI eliminaes all such complexiy, allowing remoe calls o be used almos as convenienly as local calls.. Background and Moivaion Remoe calls in RPC middleware canno efficienly suppor he same semanics as local calls for daa accessed hrough memory poiners (references in Java we will use he wo erms inerchangeably). The reason is ha efficienly sharing daa hrough poiners (call-by-reference) relies on he exisence of a shared address space. The problem is significan because mos common daa srucures in exisence (rees, graphs, linked liss, hash ables, ec.) are heap-based and use poiners o refer o he sored daa. A simple example demonsraes he issues. This will be our main running example hroughou he paper. We will use Java as our demonsraion language and Java RMI as he main poin of reference in he middleware space. Neverheless, boh Java and Java RMI are highly ypical of languages ha suppor poiners and RPC middleware mechanisms, respecively. Consider a simple linked daa srucure: a binary ree,, soring ineger numbers. Every ree node will have hree fields, daa, lef, and righ. Consider also ha some of he subrees are also poined o by non-ree poiners (aka es). An insance of such a ree is shown in Figure 1. 1 Figure 1: A ree daa srucure and wo ing references o is inernal nodes. When he ree is passed o a local funcion ha modifies some of is nodes, he modificaions affec he daa reachable from, 1, and. For insance, consider he funcion: void foo(tree ree) { ree.lef.daa = 0; ree.righ.daa = ; ree.righ.righ.daa = 8; ree.lef = null; Tree emp = new Tree(, ree.righ.righ,null); ree.righ.righ = null; ree.righ = emp; } If a call foo() is performed locally, he resuls on he daa srucure will be hose shown in Figure. 1 0 Figure : A local call can affec all reachable daa (New number values shown in bold and ialic, new nodes and references are dashed. Null references are no shown.) In oher words, a local call can change all daa reachable from a memory reference. All changes will be visible o ing references. The reason is ha Java has call-byvalue semanics for all values, including references, resuling ino call-by-reference semanics for he daa poined o by hese references. (From a programming languages sandpoin, he Java calling semanics is more accuraely called call-by-reference-value. In his paper, we follow he convenion of he Disribued Sysems communiy and alk abou call-by-reference semanics, alhough references hemselves are passed by value.) The call foo() proceeds ree

3 by creaing a copy, ree, of he reference value. Then every modificaion of daa reachable from ree will also modify daa reachable from,asree and operae on he same memory space. This behavior is sandard in he vas majoriy of programming languages ha allow poiners. Consider now wha happens when foo is a remoe mehod, implemened by a server on a differen machine. The obvious soluion would be o mainain exac call-byreference semanics by inroducing remoe references ha can poin o daa in a differen address space. This is shown in Figure 3. 1 Nework Remoe references can indeed ensure call-by-reference semanics. Neverheless, his soluion is exremely inefficien. I means ha every poiner dereference has o generae nework raffic. Mos objec-oriened middleware (e.g., RMI, CORBA, ec. and no jus radiional RPC) allow he use of remoe references, as remoely-accessible objecs have unique idenifiers and references o hem can be passed around like regular local references. For insance, Java RMI allows he use of remoe references for subclasses of he UnicasRemoeObjec class. All insances of he subclass are remoely accessible hroughou he nework hrough a Java inerface. Neverheless, he usual semanics for reference daa in RMI calls (and he vas majoriy of oher middleware) is call-by-copy. ( Call-by-copy is really he name used in he Disribued Sysems communiy for call-by-value, when he values are complex daa srucures.) When a reference parameer is passed as an argumen o a remoe rouine, all daa reachable from he reference are deep-copied o he server side. The server hen operaes on he copy. Any changes made o he deep copy of he argumenreachable daa are no propagaed back o he clien, unless he user explicily arranges o do so (e.g., by passing he daa back as par of he reurn value). A well-sudied alernaive of call-by-copy in middleware is call-by-copy-resore. Call-by-copy-resore is a parameer passing semanics ha is usually defined informally as having he variable copied o he sack by he ree Figure 3: Call-by-reference semanics can be mainained wih remoe references. caller... and hen copied back afer he call, overwriing he caller s original value [17]. A more sric (ye sill informal) definiion of call-by-copy-resore is: Making accessible o he callee a copy of all daa reachable by he caller-supplied argumens. Afer he call, all modificaions o he copied daa are reproduced on he original daa, overwriing he original daa values inplace. Ofen, exising middleware (noably CORBA implemenaions hrough inou parameers) suppor call-bycopy-resore bu no for poiner daa. Here we discuss wha is needed for a fully-general implemenaion of callby-copy-resore, per he above definiion. Under call-bycopy-resore, he resuls of execuing a remoe call o he previously described funcion foo will be hose of Figure. Tha is, as far as he clien is concerned, he call-bycopy-resore semanics is indisinguishable from a call-byreference semanics for his example. (As we discuss in Secion, he wo semanics have differences only when he server mainains sae ha oulives he remoe call.) There are several complicaions in supporing he callby-copy-resore semanics for poiner-based daa. Our example funcion foo illusraes hem: call-by-copy-resore has o overwrie he original daa (e.g.,.righ.daa in our example), no jus link new daa in he srucure reachable from he reference argumen of he remoe call ( in our example). The reason is ha, a he clien sie, he daa may be reachable hrough oher references ( in our example) and he changes should be visible o hem as well. some daa (e.g., node.lef before he call) may become unreachable from he reference argumen ( in our example) because of he remoe call. Neverheless, he new values of such daa should be visible o he clien, because a he clien sie he daa may be reachable hrough oher references (1 in our example). as a resul of he remoe call, new daa may be creaed (.righ afer he call in our example) and hey may be he only way o reach some of he originally reachable daa (.righ.lef afer he call in our example). Mos of he above complicaions have o do wih ing references, i.e., muliple pahs for reaching he same heap daa. Common reasons o have such es include muliple indexing (e.g., he daa may be indexed in one way using he ree and in anoher way using a linked lis), caching (soring some recen resuls for fas rerieval), ec. Aliasing is very common in heap-based daa and supporing i correcly for remoe calls is imporan. 3

4 3. Supporing Copy-Resore Having seen he complicaions of copy-resore middleware, we now discuss an algorihm ha addresses hem. The algorihm appears below in pseudo-code and is illusraed on our running example in Figures Creae a linear map of all objecs reachable from he reference parameer. Keep a reference o i.. Send a deep copy of he linear map o he server sie (his will also copy all he daa reachable from he reference argumen, as he reference is reachable from he map). Execue he remoe procedure on he server. 3. Send a deep copy of he linear map (or a dela srucure see Secion 5) back o he clien sie. This will copy back all he ineresing objecs, even if hey have become unreachable from he reference parameer.. Mach up he wo linear maps so ha new objecs (i.e., objecs allocaed by he remoe rouine) can be disinguished from old objecs (i.e., objecs ha did exis before he remoe call even if heir daa have changed as a resul). Old objecs have wo versions: original and modified. 5. For each old objec, overwrie is original version daa wih is modified version daa. Poiners o modified old objecs should be convered o poiners o he corresponding original old objecs. 6. For each new objec, conver is poiners o modified old objecs o poiners o he corresponding original old objecs. The above algorihm reproduces he modificaions inroduced by he server rouine on he clien daa srucures. The ineresing par of he algorihm is he auomaically keeping rack (on he server) of all objecs iniially reachable by he argumens of a remoe mehod, as well as heir mapping back o objecs in clien memory. The advanage of he algorihm is ha i does no impose overhead on he execuion of he remoe rouine. In paricular, here is no need o rap eiher he read or he wrie operaions performed by he remoe rouine by inroducing a read or wrie barrier. Similarly, no daa are ransmied over he nework during execuion of he remoe rouine. Furhermore, noe ha supporing call-by-copyresore only requires ransmiing all daa reachable from parameers during he remoe call (jus like call-by-copy) and sending i back afer he call ends. This is already quie efficien and will only become more so in he fuure, when nework bandwidh will be much less of a concern han nework laency.. Discussion.1. Copy-Resore vs Call-by-Reference Call-by-copy-resore is a desirable semanics for RPC middleware. Because all muaions performed on he server are resored on he clien sie, call-by-copy-resore approximaes local execuion very closely. In fac, one can simply observe ha (for a single-hreaded clien) call-bycopy-resore semanics is idenical o call-by-reference if he remoe rouine is saeless i.e., keeps no es (o he inpu daa) ha oulive he remoe call. Ineresingly, saelessness is a very desirable (for many even indispensable) propery for disribued services due o faul olerance consideraions. Thus, a call-by-copy-resore semanics guaranees nework ransparency: a saeless rouine can be execued eiher locally or remoely wih indisinguishable resuls. The above discussion only considers single-hreaded programs. In he case of a muli-hreaded clien (i.e., caller) nework ransparency is no preserved. The remoe rouine acs as a poenial muaor of all daa reachable by he parameers of he remoe call. All updaes are performed in an order deermined by he middleware implemenaion. The programmer needs o be aware ha he call is remoe and ha a call-by-copy-resore semanics is used. In he common case, remoe calls need o a leas execue in muual exclusion wih calls ha read/wrie he same daa. If he order of updaing maers, call-by-copyresore can probably no be used a all. (Of course, he consideraion is for he case of muli-hreaded cliens servers can always be muli-hreaded and accep requess from muliple clien machines wihou sacrificing nework ransparency.) Anoher issue regarding call-by-copy-resore concerns he use of parameers ha share srucure. For insance, consider passing he same parameer wice o a remoe procedure. Should wo disinc copies be creaed on he remoe sie or should he sharing of srucure be deeced and only one copy be creaed? This issue is no specific o call-by-copy-resore, however. Regular call-bycopy middleware has o answer he same quesion. Creaing muliple copies can be avoided using exacly he same echniques as in call-by-copy middleware (e.g., Java RMI) he middleware implemenaion can noice he sharing of srucure and replicae he sharing in he copy. Unforunaely, here has been confusion on he issue. Based on exising implemenaions of call-by-copy-resore for primiive (non-poiner) ypes, an ofen repeaed (misaken) asserion is ha call-by-copy-resore semanics implies ha shared srucure resuls ino muliple copies [16][17][1].

5 Clien sie 7 Nework ree 0 Server sie 1 3 Figure : Sae afer seps 1 and of he algorihm. Remoe procedure foo has performed modificaions o he server version of he daa. Clien sie 7 0 Nework 1 3 Figure 5: Sae afer seps 3 and of he algorihm. The modified objecs (even he ones no longer reachable hrough ree) are copied back o he clien. The wo linear represenaions are mached i.e., used o creae a map from modified o original versions of old objecs. Clien sie 0 0 Nework Figure 6: Sae afer sep 5 of he algorihm. All original versions of old objecs are updaed o reflec he modified versions. Clien sie 0 Nework Figure 7: Sae afer sep 6 of he algorihm. All new objecs are updaed o poin o he original versions of old objecs insead of heir modified versions. All modified old objecs and heir linear represenaion can now be deallocaed. The resul is idenical o Figure 3. 5

6 .. DCE RPC The DCE RPC specificaion [10] is he foremos example of a middleware design ha ries o enable disribued programming in a way ha is as naural as local programming. The mos widespread DCE RPC implemenaion nowadays is ha of Microsof RPC, forming he base of middleware for he Microsof operaing sysems. Readers familiar wih DCE RPC may have already wondered if he specificaion for poiner passing in DCE RPC is no idenical o call-by-copy-resore. The DCE RPC specificaion sops one sep shor of call-by-copy-resore semanics, however. DCE RPC suppors hree differen kinds of poiners, only one of which (full poiners) suppors ing. DCE RPC full poiners, declared wih he pr aribue, can be safely ed and changed by he callee of a remoe call. The changes will be visible o he caller, even hrough es o exising srucure. Neverheless, DCE RPC only guaranees correc updaes of ed daa for es ha are declared in he parameer liss of a remoe call. 1 In oher words, for poiners ha are no reachable from he parameers of a remoe call, here is no guaranee of correc updae. In pracical erms, he lack of full suppor in he DCE RPC specificaion means ha DCE RPC implemenaions do no suppor call-by-copy-resore semanics for linked daa srucures. In Microsof RPC, for insance, he calling semanics differs from call-by-copy-resore when daa become unreachable from parameers afer he execuion of a remoe call. Consider again our example from Secion. Figure is reproduced here as Figure 8 for easy reference. 1 0 ree The remoe call ha operaes on argumen, changes he daa so ha he former objecs.lef and.righ are 1. The specificaion reads For boh ou and in, ou parameers, when full poiners are es, according o he rules specified in Aliasing in Parameer Liss [hese rules read: If wo poiner parameers in a parameer lis poin a he same daa iem], he subs mainain he poined-o objecs such ha any changes made by he server are refleced o he clien for all es. Figure 8: Changes afer execuion of mehod. no longer reachable from. Under call-by-copy-resore semanics, he changes o hese objecs should sill be resored on he caller sie (and hus made visible o 1 and ). This does no occur under DCE RPC, however. The effecs of saemens ree.lef.daa = 0; ree.righ.daa = ; ree.righ.righ = null; would be disregarded on he caller sie. The acual resuls for DCE RPC are shown in Figure. 1 ree.3. Usabiliy: Copy-Resore vs Call-by-Copy Compared o call-by-copy, he main benefis of callby-copy-resore semanics are in usabiliy. Call-by-copyresore simulaes very closely he local execuion semanics, as discussed in Secion.1. Clearly, he behavior of call-by-copy-resore can be achieved by using call-bycopy and adding applicaion-specific code o regiser and re-perform any updaes necessary. Neverheless, his has several disadvanages: The programmer has o be aware of all es, in order be able o updae he values changed during he remoe call, even if he changes are o daa ha became unreachable from he original parameers. The programmer needs o wrie exra code o perform he updae. This code can be long for complex updaes (e.g., up o 100 lines per remoe call for he microbenchmarks we discuss in Secion 5.3). The programmer canno perform he updaes wihou full knowledge of wha he server code changed. Tha is, he changes o he daa have o be par of he proocol beween he server programmer and he clien programmer. This complicaes he remoe inerfaces and specificaions. As we discuss in Secion, a call-by-copy-resore semanics is mos valuable in he presence of ed daa. There are several common implemenaion echniques in mainsream programming languages ha resul ino - 7 Figure : Under DCE RPC, he changes o daa ha became unreachable from will no be resored on he clien sie. 6

7 ing. All of hese echniques produce code ha is more convenien o wrie using call-by-copy-resore middleware han by call-by-copy middleware. Specific examples include: Common GUI paerns like model-view-conroller. Mos GUI oolkis regiser muliple views, all of which correspond o a single model objec. Tha is, all views he same model objec. An updae o he model should resul in an updae o all of he views. Such an updae could be he resul of a remoe call. A varian of his paern occurs when GUI elemens (menus, oolbars, ec.) hold es o program daa ha can be modified. The reason for muliple ing is ha he same daa may be visible in muliple oolbars, menus, ec. or ha he daa may need o be modified programmaically wih he changes refleced in he menu or oolbar. For example, we disribue wih NRMI a modified version of one of he Swing API example applicaions. We changed he applicaion o be able o display is ex srings in muliple languages. The change of language is performed by calling a remoe ranslaion server when he user chooses a differen language from a drop-down box. (Tha is, he remoe call is made in he even dispaching hread, conforming o Swing hread programming convenions.) The remoe server acceps a vecor of words (srings) used hroughou he graphical inerface of he applicaion and ranslaes hem beween English, German and French. The updaed lis is resored on he clien sie ransparenly and he GUI is updaed o show he ranslaed words in is menus, labels, ec. The disribued version code only has wo iny changes compared o local code: a single class needs o implemen java.rmi.resorable and a mehod has o be looked up using a remoe lookup mechanism before geing called. In conras, he version of he applicaion ha uses regular Java RMI, has o use a more complex remoe inerface for geing back he changed daa and he programmer has o wrie code in order o perform he updae. Muliple indexing. Mos applicaions in imperaive programming languages creae some muliple indexing scheme for heir daa. For example, a business applicaion may keep a lis of he mos recen ransacions performed. Each ransacion, however, is likely o also be rerievable hrough a reference sored in a cusomer s record, hrough a reference from he daily ax record objec, ec. Similarly, every cusomer may be rerievable from a daa srucure ordered by zip code, and from a second daa srucure ordered by name. All of hese references are es o he same daa (cusomers, business ransacions). NRMI allows such references o be updaed correcly as a resul of a remoe call (e.g., an updae of purchase records from a differen locaion, or a rerieval of a cusomer s address from a cenral daabase), in much he same way as hey would be updaed if he call were local. 5. NRMI We now describe he pariculars of NRMI design and implemenaion. Despie he fac ha our implemenaion is Java specific, he insighs are largely language independen. Our call-by-copy- resore algorihm can be applied o any oher disribuion middleware ha suppors poiners NRMI Programming Inerface NRMI is a drop-in replacemen for Java RMI ha suppors a sric superse of he RMI funcionaliy by providing call-by-copy-resore as an addiional parameer passing semanics o he programmer. NRMI follows he design principles of RMI in having he programmer decide he calling semanics for objec parameers on a per-ype basis. In brief, indisinguishably from RMI, NRMI passes subclasses of java.rmi.server.unicasremoeobjec by-reference and ypes ha implemen java.io.serializable by-copy. Primiive ypes are passed by-copy ( byvalue in programming languages erminology). Tha is, jus like in regular RMI, he following definiion makes insances of class A be passed by-copy o remoe mehods. //Insances will be passed by-copy by NRMI class A implemens java.io.serializable {...} NRMI inroduces a marker inerface java.rmi.resorable o allow he programmer o choose he by-copy-resore semanics: parameers whose class implemens java.rmi.resorable are passed by copyresore. For example: //Insances passed by-copy-resore by NRMI class A implemens java.rmi.resorable {...} java.rmi.resorable exends java.io.serializable, reflecing he fac ha call-by-copy-resore is basically an exension of call-by-copy. In paricular, resorable classes have o adhere o he same se of requiremens as if hey were o be passed by-copy i.e., hey have o be serializeable by Java Serializaion [1]. In he case of JDK classes, java.rmi.resorable can be implemened by heir direc subclasses. //Insances passed by-copy-resore by NRMI class ResorableHashMap exends java.uil.hashmap implemens java.rmi.resorable {...} In hose cases when subclassing is no possible, a delegaion-based approach can be used. 7

8 //Insances passed by-copy-resore by NRMI class SeDelegaor implemens java.rmi.resorable { java.uil.se _delegaee; //expose he necessary funcionaliy void add (Objec o) { _delegaee.add (o); }... } Declaring a class o implemen java.rmi.resorable is all ha is required from he programmer: NRMI will pass all insances of such classes by-copy-resore whenever hey are used in remoe mehod calls. The resore phase of he algorihm is hidden from he programmer, being handled compleely by he NRMI runime. This saves lines of edious and error-prone code as we illusrae in Secion.3. In order o make NRMI easily applicable o exising ypes (e.g., arrays) ha canno be changed o implemen java.rmi.resorable, we adoped he policy ha a reachable, serializable sub-objec is passed by-copyresore, if is paren objec implemens java.rmi.resorable. Thus, if a parameer is of a resorable ype, everyhing reachable from i will be passed by-copy-resore (assuming i is serializable, i.e., i would oherwise be passed by call-by-copy). I is worh noing ha Java is a good language for demonsraing he benefis of call-by-copy-resore middleware because of he local Java mehod call semanics. In local Java mehod calls, all primiive parameers are passed by-copy ( by-value using programming languages erminology). This is idenical behavior wih remoe calls in Java using Java RMI or NRMI. Wih NRMI we also add call-by-copy-resore semanics for reference ypes, hus making he behavior of remoe calls be (almos) idenical o local calls even for non-primiive ypes. Thus, wih NRMI, disribued Java programming is remarkably similar o local Java programming. 5.. Implemenaion Insighs (High-Level) Having inroduced he programming inerface offered by NRMI, we now describe our implemenaion in greaer deail. We analyze one-by-one each of he major seps of he algorihm presened in Secion Creaing a linear map. Creaing a linear map of all objecs reachable from he reference parameer is obained by apping ino he Java Serializaion mechanism. The advanage of his approach is ha we ge a linear map almos for free. The parameers passed by-copy-resore have o be serialized anyway and all objecs reachable from a remoe call s parameers need o be raversed for ha. The linear map ha we need is jus a daa srucure soring references o all such objecs in he order ha hey were raversed. We ge his daa srucure wih a iny change o he serializaion code. The overhead is minuscule and only exiss when call-by-copy-resore semanics have been chosen. 5.. Performing remoe calls. On he remoe sie, a remoe mehod invocaion proceeds exacly as in regular RMI. Afer he mehod complees, we marshall back linear map represenaions of all hose parameers whose ypes implemen java.rmi.resorable along wih he reurn value if here is any Updaing original objecs. Correcly updaing original reference parameers on he clien sie includes maching up he new and old linear maps and performing a raversal of he new linear map. Boh sep 5 and sep 6 of he algorihm are performed in a single deph-firs raversal by jus performing he righ updae acions when an objec is firs visied and las visied (i.e., afer all is descendans have been raversed). 5.. Opimizaions. There are wo opimizaions ha can be applied o an implemenaion like NRMI in order o rade processing ime for reduced bandwidh consumpion. Firs, insead of sending he linear map over he nework, we can reconsruc i during he un-serializaion phase on he sie of he remoe call. Second, insead of reurning he new values for all objecs o he caller sie, we can send jus a dela srucure, encoding he difference beween he original daa and he daa afer he execuion of he remoe rouine. In his way, he cos of passing an objec by-copy-resore and no making any changes o i is almos idenical o he cos of passing i by-copy. NRMI applies he firs opimizaion, while he second will be par of fuure work Implemenaion (Low-Level) and Performance Experimens Alhough NRMI emphasizes usabiliy, i also aemps o offer an efficien implemenaion. The main poin of our experimens is o demonsrae ha NRMI is efficien enough for real-world use. The implemenaion of NRMI is opimized and suffers only small overheads. The opimized NRMI for JDK 1. is abou 0% slower han regular RMI for JDK 1.. To pu his number in perspecive, his also means ha NRMI for JDK 1. is abou 0-30% faser han regular RMI for he previous version, JDK NRMI Low-Level Opimizaions. In principle, he only significan overhead of call-by-copy-resore middleware over call-by-copy middleware is he cos of ransferring he daa back o he clien afer he remoe rouine 8

9 execuion. In pracice, middleware implemenaions suffer several overheads relaed o processing he daa, so ha processing ime ofen becomes as significan as nework ransfer ime. Java RMI has been paricularly criicized for inefficiencies, as i is implemened as a high level layer on op of several general purpose (and hus slow) faciliies RMI ofen has o suffer he overheads of securiy checks, Java serializaion, indirec access hrough mechanisms offered by he Java Virual Machine, ec. NRMI has o suffer he same overheads o an even greaer exen, since i has o perform an exra raversal and copying over objec srucures. Currenly, NRMI has wo implemenaions: a porable, high-level one and an opimized one. The porable implemenaion makes use of high-level feaures like Java reflecion for raversing and copying objec srucures. Alhough NRMI is currenly ied o Sun s JDK, he porable implemenaion works wih boh JDK 1.3 and JDK 1. on all suppored plaforms. The porabiliy means some loss of performance: Java reflecion is a very slow way o examine and updae unknown objecs. The NRMI implemenaion minimizes he overhead by caching reflecion informaion aggressively. Addiionally, he porable NRMI implemenaion uses naive code for reading and updaing objec fields wihou suffering he penaly of a securiy check for every field. These wo opimizaions are sufficien for significanly reducing he NRMI overheads, even for he porable version. Our original implemenaion of NRMI was more han wo imes slower han he curren porable one. The opimized implemenaion of NRMI only works wih JDK 1. and akes advanage of special feaures expored by he JVM in order o achieve beer performance. The performance of regular Java RMI improved significanly beween versions 1.3 and 1. of he JDK (as we show in our measuremens). The main reason was he flaening of he layers of absracion in he implemenaion. Specifically, objec serializaion was opimized hrough non-porable direc access o objecs in memory hrough an Unsafe class expored by he Java Virual Machine. The opimized version of NRMI also uses his faciliy o quickly inspec and change objecs Descripion of Experimens. In order o see how our implemenaion of call-by-copy-resore measures up agains he sandard implemenaion of RMI, we creaed hree micro-benchmarks. Each benchmark consiss of a single randomly-generaed binary ree parameer passed o a remoe mehod. The remoe mehod performs random changes o is inpu ree. The invarian mainained is ha all he changes are visible o he caller. In oher words, he resuling execuion semanics is as if boh he caller and he callee were execuing wihin he same address space. Wih NRMI or disribued call-by-reference (hrough remoe poiners, as in Figure 3) his is done auomaically. For call-by-copy, he programmer needs o simulae i by hand. We have considered hree differen scenarios of parameer use, lised in he order of difficuly of achieving he call-by-copy-resore semanics by-hand using he means provided by RMI. In he firs benchmark scenario, we assume ha none of he objecs reachable from he parameer is ed by he clien. ree Nework ree 0 1 no es, daa and srucure may change In he second benchmark scenario, we allow es bu assume ha he srucure of he ree says he same (alhough he ree daa may be modified by he remoe mehod). ree Nework ree 0 1 srucure does no change bu daa may 3 5 In he hird benchmark scenario, ing and modificaions can be arbirarily complex: ree nodes can be ed on he clien sie and he ree srucure can be changed by he remoe call. ree Nework ree 0 1 srucure changes es presen

10 Consider how a programmer can replay he server changes on he clien using regular Java RMI in each of he hree cases. We assume ha he programmer is fully aware of he server s behavior, as well as wheher es exis on he clien sie. In he firs case, he parameer jus has o be reurned as he reurn value of he remoe mehod. Once he remoe call complees, he reference poining o he original daa srucure ges reassigned o poin o he reurn value. This will work for any changes o boh he daa and srucure of he ree. The only complicaion here is ha he mehod migh already have a reurn value. Resolving his problem would require defining a special reurn class ype ha would conain boh he original reurn ype and he parameer. Besides he code for his new reurn class ype iself, some addiional code has o be wrien o call is consrucor, populae i wih is consiuen members on he callee sie, and rerieve hem when he call complees. In he second case, he clien needs o reassign he es poining o some nodes in he original ree o poin o he corresponding nodes in he new ree. Afer his sep is performed, he reference reassignmen described in he previous benchmark can be used. If he programmer knows all he es, as well as where in he ree hey poin o (i.e., how o ge o he ed node from he ree roo) hen he es can be reassigned direcly. If, however, he programmer only knows he es bu no how o ge o he ed nodes, hen a search needs o be performed before he updae akes place. Boh he original and he modified rees (ha are now isomorphic) can be raversed simulaneously. Upon encounering each node, all es should be reassigned from poining from he original ree o he modified one. In he hird case, reurning he changed srucure alone is no very useful since he original and he modified rees are no longer isomorphic. To complicae maers furher, he remoe mehod invocaion migh make some changes o some of he ree nodes daa ha were ed by he caller and hen disconnec hem from he ree srucure. This way he modified daa nodes migh no longer be par of he ree srucure. Obviously jus reurning he new ree is no enough. Emulaing he callby-copy-resore or call-by-reference semanics is paricularly cumbersome in his case. The simples way o do i is by having he remoe mehod creae a shadow ree of is ree parameer prior o making any changes o i. The shadow ree poins o he original ree s daa and serves as a reminder of he srucure of he original ree. Then boh he parameer ree and he shadow ree are reurned o he caller. The shadow ree is isomorphic o he original parameer and can be used for simulaneous raversal and copying of es. Afer ha he new ree is used for he reference reassignmen operaion as in he previous cases. Noe ha correc updae is no possible wihou modifying boh he server and he clien. For all benchmarks, he NRMI version of he disribued code is quie similar o he local version, wih he excepion of remoe mehod lookup and declaring a class o be Resorable. Analogous changes have o be made in order o go from he local version o he disribued one ha updaes clien daa correcly using regular Java RMI. Several exra lines of code have o be added/modified in he laer case, however. For all hree benchmarks, abou 5 lines of code were needed in order o define reurn ypes. For he second and hird benchmark scenario, an exra 16 lines of code were needed o perform he updaing raversal. For he hird benchmark scenario, abou 35 more lines of code were needed for he shadow ree Experimenal Resuls. For each of hese benchmarks, we measure he performance of call-by-copy (RMI), call-by-copy-resore (NRMI), and call-by-reference implemened using remoe poiners (RMI). (Of course, NRMI can also be used jus like regular RMI wih idenical performance. In his secion when we alk of NRMI we mean under call-by-copy-resore semanics.) For reference, we also provide hree base line numbers by showing how long i akes o execue he same mehods wihin he same JVM locally, on differen JVMs hrough RMI bu on he same physical machine, and on differen machines bu wihou caring o resore he changes o he clien (i.e., only sending he ree o he server bu no sending he changed ree back o he clien). We show measuremens for boh implemenaions of NRMI and boh JDK 1.3 and JDK 1.. The environmen consiss of a SunBlade 1000 (wo UlraSparc III 750MHz processors and GB of RAM) and a Sun Ulra 10 (UlraSparc II 0MHz) machines conneced wih a 100Mbps effecive bandwidh nework. This environmen cerainly does no unfairly benefi NRMI measuremens he nework speed is on he high end of ypical neworks where high-level middleware is used and he machines have realisic speeds for his kind of processing. For faser machines and slower neworks, he performance of NRMI would sricly improve relaive o he baselines. The resuls of our experimens are shown in Table 1- Table 6. All numbers are in milliseconds per remoe call, rounded o he neares millisecond. We ensured ha all measured programs had been dynamically compiled by he JVM before he measuremens. The local measuremens of Table 1 are given for boh he fas and he slow machines. The local measuremens of Table 3 are from he dual processor SunBlade machine. (This allowed us o 10

11 Table 1: Baseline 1 Local Execuion (processing overhead) on boh he fas (750MHz) and he slow (0MHz) machine Benchmark/ Tree Size JDK 1.3 JDK I <1 / <1 <1 / 1 1 / 6 / 8 <1 / <1 <1 / 1 1 / 1 / 6 II <1 / 1 1 / 1 / 5 15 / 0 <1 / 1 1 / 1 3 / 1 / 16 III <1 / 1 1 / 5 / 6 1 / <1 / 1 1 / 1 / 5 15 / 1 Benchmark/ Tree Size Table : Baseline RMl Execuion, wihou Resore (one-way raffic) JDK 1.3 JDK I II III Benchmark/ Tree Size Table 3: Baseline 3 RMI Execuion wih Resore on local machine (no nework overhead) JDK 1.3 JDK I II III Benchmark/ Tree Size Table : RMI Execuion wih Resore (wo-way raffic) JDK 1.3 JDK I II III Table 5: NRMI (Call-by-copy-resore). Boh he porable and opimized implemenaion shown for JDK 1. Benchmark/ Tree Size JDK 1.3 JDK I / 8 / 8 5 / 3 / 8 II / / 8 7 / 103 / 5 III / / 8 8 / / 7 Benchmark/ Tree Size Table 6: Call-by-Reference wih Remoe References (RMI) JDK 1.3 JDK I II III

12 avoid conex swiching and ge a fair measuremen. The numbers were significanly ained on a uniprocessor machine.) The main observaions from hese measuremens are as follows: The benchmarks have very low compuaion imes heir execuion consiss mosly of middleware processing and daa ransmission. Java RMI in JDK 1. is significanly faser han RMI in JDK 1.3. The speedup is in he order of 50-60% for his experimenal seing. The speedup will be lower for a nework ha is slower relaive o he processor speeds. The resuls of Table minus he corresponding resuls of Table 3 will only yield an upper bound for he raw daa ransmission ime, because he Table 3 resuls were compued exclusively on he fas (750MHz) machine while he Table resuls include compuaion on boh he fas and he slow (0MHz) node. The difference beween he raw daa ransmission ime and he Table -minus-table 3 value can be as high as he difference beween he compuaion imes on he fas and slow machines, shown in Table 1. Even hen, however, JDK 1.3 seems o perform much beer when no nework is involved han he corresponding difference in JDK 1.. This leads us o conclude ha probably RMI in JDK 1. uses he underlying OS/neworking faciliies much more efficienly han JDK 1.3 and his difference disappears when he wo hoss are sharing memory. We independenly corroboraed he raw daa ransmission ime shown in he ables by profiling he benchmarks and noing he amoun of ime hey spen blocked for I/O. We found ha he real ransmission ime for JDK 1.3 is much higher even for ransmiing he exac same amoun of daa as 1.. For benchmarks I and II, NRMI is quie efficien. Even he porable version is rarely more han 30% slower han he corresponding RMI version. The opimized implemenaion of NRMI is abou 0% slower han RMI in JDK 1.. This is cerainly fas enough for use in real applicaions. For insance, he opimized implemenaion of NRMI for JDK 1. is 0-30% faser han regular RMI in JDK 1.3. For benchmark III, which is hard o simulae by hand wih call-by-copy alone, he porable implemenaion of NRMI ges similar performance o regular RMI in all cases, while he opimized implemenaion is faser. The cause is no he processing ime for resoring he values changed by he header. (In fac, we performed he same experimens ignoring he manual resoring of changes and go almos idenical imings.) Insead, he reason is ha he regular RMI version ransfers more daa: he shadow ree is a simple way o emulae he local semanics by hand, bu sores more informaion han ha of he NRMI linear map. (Specifically, i sores all he original srucure of he ree insead of jus poiners o all he reachable nodes.) The only alernaive would be o compue a linear mapping o all reachable nodes on boh sides, effecively imiaing NRMI in user space. Call-by-reference implemened by remoe poiners is exremely inefficien (as expeced). Every access o parameer daa by he remoe mehod resuls in nework raffic. Java RMI does no seem fi for his kind of communicaion a all he memory consumpion of he benchmarks grew unconrollably. For he 1,0 node rees, he benchmarks ook more han 600ms per case (repeaed over 1,000 imes) and in fac failed o complee as hey exceeded he 1GB heap limi ha we had se for our Java virual machines. The reason for he memory leak is ha he references back from he server o he clien creae disribued circular garbage. Since RMI only suppors reference couning garbage collecion, i canno reclaim he garbage daa. The conclusion from our experimens is ha NRMI is opimized enough for real use. NRMI (copy-resore) for JDK 1. is close o he opimized RMI in JDK 1. and faser han regular RMI (call-by-copy wih resuls passed back) in JDK 1.3. Of course, wih NRMI he programmer mainains he abiliy o use call-by-copy semanics when deemed necessary. When, however, a more naural programming model is desired, NRMI is wihou compeiion he only alernaive is he very slow call-byreference hrough RMI remoe poiners. 6. Relaed Work Disribued compuing has been he main focus of sysems research in he pas wo decades. A large porion of he research communiy s effors is aimed a improving he performance and usabiliy aspecs of disribued compuing. Since he objecive of NRMI lies mosly in usabiliy bu wihou sacrificing performance, here is a wealh of work ha exhibis similar goals or mehodologies o ours. Hence, we will be selecive in our presenaion and we will separae performance and usabiliy relaed work Performance Improvemen Work There have been several effors argeed a providing a more efficien implemenaion of he faciliies offered by sandard RMI [1]. Krishnaswamy e al. [6] achieve RMI performance improvemens by replacing TCP wih UDP and by uilizing objec caching. Upon receiving a remoe call, a remoe objec is ransferred o and cached on he caller sie. In order for he runime o implemen a consis- 1

13 ency proocol, he programmer mus idenify wheher a remoe mehod is read-only (e.g., will only read he objec sae) or no, by including he hrowing of read or wrie excepions. Tha is, insead of ransferring he daa o a read-only remoe mehod, he server objec is moved o he daa insead, which resuls in beer performance in some cases. There are several sysems ha improve he performance of RMI by using a more efficien serializaion mechanism. KaRMI [8] uses a serializaion implemenaion based on explici rouines for wriing and reading insance variables along wih more efficien buffer managemen. Maassen e al. s work [7] akes an alernaive approach by using naive code compilaion o suppor compile and run ime generaion of marshalling code. I is ineresing o observe ha mos of he opimizaions aimed a improving he performance of he sandard RMI and call-by-copy can be successfully applied o NRMI and call-by-copy-resore. Furhermore, such opimizaions would be even more beneficial o NRMI due o is heavier use of serializaion and neworking. 6.. Usabiliy Improvemen Work Thiruvahukal e al. [0] propose an alernaive approach o implemening a remoe procedure call mechanism call for Java based on reflecion. The proposed approach employs he reflecive capabiliies of he Java languages o invoke mehods remoely. This simplifies he programming model since a class does no have o be declared remoe for is insances o receive remoe calls. While CORBA does no currenly suppor objec serializaion, he OMG is reviewing he possibiliies of making such suppor available in some fuure version of IIOP [7]. Once objec serializaion becomes available, boh callby-copy and call-by-copy-resore can be implemened enabling [in] and [in ou] parameers passing semanics for objecs. Disribued Shared Memory (DSM) sysems are he main way employed in he research lieraure o making disribued compuing easier. Tradiional DSM approaches creae he illusion of a shared address space, when he daa are really disribued across differen machines. Example DSM sysems include Munin [3], Orca [], and, in he Java world, CJVM [1], and Java/DSM [3]. DSM sysems can be viewed as sophisicaed implemenaions of call-by-reference semanics, o be conrased wih he naive remoe poiner approach shown in Figure 3. Neverheless, he focus of DSM sysems is very differen han ha of middleware. DSMs are used when disribued compuing is a means o achieve parallelism. Thus, hey have concenraed on providing correc and efficien semanics for muli-hreaded execuion. To achieve performance, DSM sysems creae complex memory consisency models and require he programmer o implicily specify he sharing properies of daa. In pracice, he applicabiliy of DSMs has been resriced o high-performance parallel applicaions, mainly in a research seing. In conras, NRMI aemps o suppor naural semanics o sraighforward middleware, which is always under he conrol of he programmer. NRMI (and all oher middleware) do no ry o suppor disribuion for parallelism bu insead faciliae disribued compuing in he case where an applicaion s daa and inpu are naurally far away from he compuaion ha needs hem. A special kind of ools ha aemp o bridge he gap beween DSMs and middleware are auomaic pariioning ools. Such ools spli cenralized programs ino several disinc pars ha can run on differen nework sies. Thus, auomaic pariioning sysems ry o offer DSM-like behavior bu wih more ease of use and compaibiliy: Auomaically pariioned applicaions run on exising infrasrucure (e.g., DCOM or regular unmodified JVMs) bu relieve he programmer from he burden of dealing wih he idiosyncrasies of various middleware mechanisms. A he same ime, his reduces he field of applicaion o programs where localiy paerns are very clear cu oherwise performance can suffer grealy. In he Java world, he J-Orchesra [1], Addisan [18] and Pangaea [1][13] sysems can be classified as auomaic pariioning ools. The JavaPary sysem [5][11] works much like an auomaic pariioning ool, bu gives a lile more programmaic conrol o he user. JavaPary is designed o ease disribued cluser programming in Java. I exends he Java language wih he keyword remoe o mark hose classes he can be called remoely. The JavaPary compiler hen generaes he required RMI code o enable remoe access. Compared o NRMI, JavaPary is much closer o a DSM sysem, as i incurs similar overheads and employs similar mechanisms for exploiing localiy. Doorasha [] represens anoher piece of work on making disribued programming more naural. Doorasha allows he user o annoae a cenralized program o urn i ino a disribued applicaion. Alhough Doorasha allows fine-grained conrol wihou needing o wrie complex serializaion rouines, he choice of remoe calling semanics is limied o call-by-copy and call-by-reference implemened hrough RMI remoe poiners or objec mobiliy. Call-by-copy-resore can be inroduced orhogonally in a framework like Doorasha. In pracice, we expec ha callby-copy-resore will ofen be sufficien insead of he coslier, DSM-like call-by-reference semanics. Finally, we should menion ha approaches ha hide he fac ha a nework is presen have ofen been criicized (e.g., see he well-known Waldo e al. manifeso on he 13