Workstation Clusters
BernhardHaumacherandMichaelPhilippsen
UniversityofKarlsruhe,Germany
hauma@ira.uka.de andphlipp@ira.uka.de
http://wwwipd.ira.uka.de/JavaPa rty/
Abstract. In a distributed programming environment with location
transparency, fast access to remoteresources is absolutely critical for
eÆcientprogramexecution -butitis notsuÆcient.Locality
optimiza-tionwilltrytogroupobjectsaccordingtotheircommunicationpatterns
andreplaceremoteaccessbylocalaccesswheneverpossible.Locality
op-timizationis basedonthe assumptionthatlocal accessalwaysismuch
fasterthanremoteaccess.
Usingconventional communicationpackageslikeRMI,this assumption
isvoid.Aremoteobjectalwaysneedsanaccesslayeraroundittoallow
accessto theobject bymeansotherthandirectreference.Transparent
accesstoaremoteobjectalsoneedstoovercomethisaccesslayer,even
in a local access. Direct reference access can not be used, because of
dierentparameterpassingsemantics.
Inthispaperwepresenttechniquestoprovidetransparentlocalaccessto
potentiallyremoteobjects inthesamemagnitudeasdirectJavaaccess.
1 Introduction
JavaPartyprovidesadistributedJavavirtualmachineontopofregularJava
vir-tualmachinesthatexecuteonthenodesofaworkstationcluster.Thedistributed
natureoftheenvironmentismostlyhiddenfromtheapplicationbyprovidinga
sharedobjectspace acrossall participatingvirtual machines. Tomake objects
accessiblefromothernodes,Java'sremotemethodinvocation(RMI)isused[7].
Insteadof asking the programmer to insert many verbose RMI commands
manuallyintohismulti-threadedJavaapplicationtoportisfromasingle
work-stationtoacluster,JavaPartyallowshimtodeclareclassestoberemote.
Java-PartythengeneratesallthenecessaryRMIcommandsautomatically[6].
1.1 Locationtransparency
InJavaPartyremoteobjectsare locationtransparentin awaythat theremote
therelativelocationofitsobjects.Locationtransparencyenablestheseparation
ofapplicationdesignfromobjectallocationanddistributiondecisions.In
partic-ularthisopensupthepossibilitytodecideaboutthelocationofcreatedobjects
automatically with compile time or runtime support. JavaPartyalso supports
migration of already allocated objectsto dierent nodes without the need for
applicationinteraction.
Classes notexplicitly declared remote are regular Javaclasses, called local
classesbelow.Local objectsareboundto thevirtualmachine theyare created
in,and can notbeaccessed from outsidethat virtualmachine. If local objects
arepassedinmethodinvocationstoremoteobjects,theRMImethodinvocation
semanticsapply. In anRMI calllocal objectsasargumentsareshippedto the
remoteside andinstantiatedthere ascopies identicaloftheoriginal argument.
Transparentaccesstoaremoteobjectrequiresthatthisduplicationoccurseven
ifthecaller islocal to theinvokedremoteobject,becausetheapplication may
relyonthat behavior.
Transparentaccess toaremote objectthereforerequires someintermediate
layerbetweenthecallerandthetargetobjecttoguarantythesamesemanticsno
matterwheretheobjectislocated.UsingregularRMItransparencyalsocanbe
achievedbyalwaysaccessingthe remoteobjectthroughitsRMI proxyobject.
Butthisincursanhugeoverheadforalocalaccessthatiscomparabletoaremote
accessinperformance,becauseRMIdoesnotexploitobjectlocality.Thispaper
presentstechniquesthatcanbeusedtomakeacommunicationpackagelocation
awarein asense that local accesscanbeperformedtransparentlywith similar
performanceasaregularJavamethodinvocation.
1.2 Frequency of local accesses to remote objects in JavaParty
applications
RemoteobjectsarethebuildingblocksofaparalleldistributedJavaParty
appli-cation.NormallyaJavaPartyapplicationwillcreatemanymoreremoteobjects
thannodesareactuallyavailableforexecution,becausetheapplicationbecomes
more exible when adjusting it to dierent target platforms. Especially when
porting an existing multi-threaded Java application to JavaParty,many more
remoteclassesare likelytobedeclared, becauseobjectsofremote classeshave
moreJava-likesemanticsreferringtothedistributed virtualmachine:Theyare
alwayspassedbyreferenceinmethodinvocationsandarevisiblefromthewhole
application.
Anapplicationthatusesmanymoreremoteobjectsthannodesareactually
availableforexecutionreliesonlocalityoptimizationtoensurethatmostofthe
accessesarelocal.Insuchawelloptimizedapplicationthemajorityofaccessesto
remoteobjectswillbelocal.Thereforetheresultingapplicationisonlyexpected
1.3 Related work
ToexecuteaprogrameÆcientlyinadistributedenvironment,afastnetworkand
slim protocol layersare necessaryprerequisites. We havealready show how to
achievethisin pureJava[5,3]onaMyrinetnetwork.Thereareothereortsto
improvetheperformanceof Javaremotemethod invocation. HenriBal'sgroup
at Amsterdamhas publishedresultson thecompilerprojectManta[8]. Manta
has an eÆcient remote method invocation (35s) ona cluster of workstations
connectedbyMyrinetbycompilingJavatonativecode.Krishnaswamyetal.[4]
improveRMI performance by using object caching and using UDP instead of
TCP.
TheseapproachesconcentrateonfastremoteaccesstoobjectsinJava.While
location transparencyinnot themain issuein this area,noperformance
num-bersfor transparentlocal access to remote objectsare available. Inthis paper
westudy thebehavioroftheKaRMI,ouroptimized implementation ofremote
method invocation[5],and describestrategieshow toadd eÆcient transparent
local accessto asystemthatalreadyis optimizedforfastremoteaccess overa
high-performancenetwork.
ThereareothercommunicationpackagesotherthanRMIavailableforJava.
An alternativeapproach forparallelprogramminginJavaistheusageofMPI.
There existseveralMPI bindingsforJava[1,2].Whilemessagepassingis
well-suitedforstaticallydistributednumericalapplications,itdoesnottthe
object-oriented nature of Java very well. For location transparent environments like
JavaParty the remote method invocation approach is preferable because
con-structing messagesis onlyworthwile when thetarget is knownto be remote.
The work described in this paper aims at fast transparent access to objects
especiallyiftheyarelocal.
1.4 Structure ofthe paper
Section2describesimprovementstoKaRMIforearlylocalitydetectionofmethod
calls.It alsodescribesfurther optimizationsthat canonlybeperformedat the
highestprotocollayerandareessentialforaneÆcientlocalmethodinvocation.
Section3describesoptimizationstoJavaPartyforremovingadditionaloverhead
introducedbytheJavaPartylayer.Section4provestheeectivenessofthe
opti-mizationspresentedin thispaperwithbenchmarkresults.Section5concludes.
2 Optimizations at the remote method invocation level
2.1 Structure ofKaRMI
Figure1showsthestandardaccesspathfromJavaPartyapplicationcodethrough
thethreeKaRMI layersto theremoteserverimplementationobject.Thesteps
arelabeled(c1)...(c4)ontheclientsideand(s1)...(s3),ontheserversidewith
opti-access layer
reference layer
transport layer
Stub
ClientReference
SocketTechnology
ParaStationTechnology
LocalTechnology
Skeleton
ServerReference
SocketServer
ParaStationServer
ServerImplementation
Handle
J
a
v
a
P
a
rt
y
Application
(c1)
(c2)
(c3)
(c4)
(n)
(s1)
(s2)
(s3)
(l1)
(l2)
K
a
R
M
I
(d)
(l3)
handle layer
Fig.1.KaRMI'sStructure
the layers.Directaccess to theserver implementation (d) cannot be used for
transparentremoteobjectaccess,becauseofdierentargumentpassing
seman-tics as described in the introduction. For the moment we look at the system
from the viewof a regularKaRMI application byignoring the section labeled
"JavaParty"in thegure.Both regularRMIandKaRMI sharethesame
high-leveldesign,somostofthedescriptionsinthenextparagraphsarevalidforboth
implementationsofremotemethodinvocation.
Theaccess layerofKaRMI providestheapplication withhighlevelaccess
to a remote object through a generated proxy object that has methods with
thesamesignatureastheserverobject.KaRMIisresponsibleforforwardinga
methodinvocationperformedontheproxyobjectto theserverimplementation
andtransmittingtheresultbackto thecaller.Theproxyobject,called "stub",
isresponsibleforconvertingargumentspassedtoeachofitsmethodsintoa
rep-resentationthatcanbehandledbythedeepergenericlayersofthepackage.On
the server side the skeleton object performs the inverse transformation of the
parameterlistandresultvaluebyrestoringthecorrecttypesoftheparameters,
invoking the requestedmethod on theserverimplementation object,and
con-vertingtheresultback toagenericrepresentationthat isreturnedbackto the
caller.
Thereference layeris responsible foruniquelyaddressingremote objects
and dispatching incoming requests to the correct server side object. Remote
objectsareidentiedbysocalledobjectnumbersthat areassignedto aremote
objectat the time it is exported. The object numberin combinationwith the
Internetaddressofthemachineandtheporttheobjectwasexportedonidenties
theobjectin thedistributed environment.
transporttechnologyalsodenesthewireprotocolthatisusedforthe
commu-nication.Atthemoment thereare twotransporttechnologiesimplementedfor
KaRMI, oneforregularTCP/IPsocketscalled SocketTechnologyandone for
theParaStation[9]networklayeroverMyrinet communicationhardware.
2.2 Detection ofa localcallin the access layer
Figure 1 shows the basic optimization (l1) for local calls. If the target of the
call isdetectedto be localto thecaller,thelocal transporttechnologyis used.
Thetechnologyfor localtransport isresponsible forduplicatingtheparameter
and result values to simulate the behavior that is expected form a standard
remote method invocation. These call-by-copy semantics must be adhered to
even if the call does not leave the local address space and therefore is not a
realremote methodinvocation.Theprogrammayrelyonthefactthat remote
calls havecall-by-copysemanticsand doesnotexpect that modicationsmade
to the argument of aremote method invocationget visible to the caller. Ina
locationtransparentenvironmentbasedonKaRMIitisobviousthatallcallsto
aremote objectmust havethe samecallsemantics,becausedue to automatic
objectdistribution,localityisnotnecessarilyknowntotheprogrammer.
Localitydetectionofaremotecall'stargetinthetransportlayeristoolate:
All layersofthe packagesarecrossedbackandforth unnecessarily. Theaccess
layerconvertstheargumentlisttoagenericrepresentationbutthetyped
argu-ments are requiredfor nally invoking the server method. The reference layer
identies the target of the call by object number, where a direct Java
refer-ence tothelocalserverimplementationobjectexists andwould suÆce.Finally
thelocaltransporttechnologyperformscostlyobjectduplicationonthegeneric
methodargumentrepresentation,wherecustomizedprocessingformostfrequent
parametertypeswouldbefaster.
Thereforetheappropriate layerfordetecting localityof acall isthe access
layer(l2)asfarasaregularKaRMIapplicationisconcerned.Becausethetypes
ofthemethod argumentsareknownattheaccess layer,thereis thepossibility
ofaspeciallyoptimizationof argumentduplication:
Basic types. Arguments of basic Java type need no explicit duplication,
be-causetheyare always passedbycopy evenin a regularJavamethod
invo-cation.These parameterscanbepasseddirectlyin alocalcalltotheserver
implementationwithoutanyadditionalleort.
Remotereferences. Remoteobjectsarerepresentedattheclientsidebyproxy
objects called stubs. Stubs are remote references to server objects in the
KaRMIframework.Suchreferencescanalsobepassedin aremotemethod
invocationasmethodargument.Whilethesestubobjectscannotbe
modi-eddirectlybytheapplication,butonlyforwardmethodinvocationstothe
objecttheyreference,theapplicationdoesnotcarewhethersuchareference
objectiscopiedin alocalinvocationornot.
originalserverobjectduring themarshalingprocessof thecall.Evenifthe
remotemethodinvocationislocal,thisconversionmust beperformed.But
directlyconverting a remoteserverobject to astub referencing it is much
lesstime consumingthandoingthesameoperationduring generalpurpose
objectduplication.
Immutableobjects. Like remote stubs there is another category of objects
thatdon'tneedduplication duringalocalcall.Allobjectsthatare created
onceandthatcannolongerbemodiedarecandidatesforpassingthem
di-rectlyinalocalcalltoaremotemethod.Becausetheremotemethodcannot
modifythestateofthepassedobject,theapplicationisunlikelytoperceive
thedierenceofacall-by-copyoracall-by-reference.Suchimmutableclasses
inthecoreJavalibraryarestringsandallobjectequivalentsforbasictypes
likejava.lang.Integer.
Classes declaredimmutable. Sinceobjectduplicationisexpensive,itmakes
sense to enable the application designer to declare classes immutable and
prevent the duplication of their objects in local calls. For this reason, we
provide an additional interface Immutable that marks a class (and all its
subclasses) to beimmutable. The interfacedoes not declareany methods,
but is only used in the stub generator to decide whether areference type
thatisnototherwiseknownisimmutableanddoesnotneedduplication 1
.
2.3 Redesign of the pure functional interface between KaRMI
layers
The optimization presented in this section is an necessaryprerequisite for the
theonedescribedinthenextsection,butalsoopensupthepossibilityof some
interesting extensions to the whole system.Therefore it is worthdescribing it
separately.
The main advantage of KaRMI over RMI are the simple pure functional
interfacesbetweenthelayers.Such clean layeringallowsto easilyadd
alterna-tivetransporttechnologyimplementationstosupporthighperformancenetwork
hardware.A purefunctionalinterfacemeansthattheonly interactionbetween
twolayersofthepackageduringtheexecutionofaremotemethodinvocationis
exactlyonemethod call.Thismethod callshipsallnecessaryinformation that
isrequiredtoperformtheremoteinvocationtothenextlowerlayer.Thelowest
layerisresponsibleforconstructingthenetworkpacketthatultimatelyshipsthe
call totheserverside.
Firstweshow,that such pure functional interfaceis inappropriate because
itcausesunnecessaryobjectallocationsduringaremoteinvocation.Wepresent
a solution to the problem without violating the extensibility of the system to
alternativetransporttechnologies.
Usingpurefunctional interfacesforthelayersinKaRMI requires thateach
layercollectsallnecessaryinformationandforwardsitinasinglecalltothenext
1
Wedecidedtohavetheprogrammerdeclare aclassimmutableinsteadoftryingto
deeperlayer.Becausethetransportlayerisresponsibleforconstructingthebyte
representationoftheinformationsentoverthenetwork,thehigherlayersmust
forwardtheirinformationasJavaobjectstothenextlayer.Thisapproachdoes
not t the access layerverywell. The stub is responsible for dealingwith the
methodsignatureandconvertingtheargumentstoagenericrepresentation.The
deeperlayersofthesystemdonolongerdealwiththemethodsignaturebutare
onlycapableofforwardingremotecallsrequiringthattheargumentsarepacked
in aformatthat cansimplybeforwardedtotheserverside. Ontheserverside
theskeletonisresponsibleforextractingtheargumentsbyrestoringtheconcrete
methodsignatureandactuallyinvokingtheremoteservermethod.InJavathere
existsnoeÆcientrepresentationforanarbitrarymethodsignature,thatcanbe
used to represent the arguments of a method invocation. The Java 2 version
of RMI usesanarrayof objects fortheargumentsand expectsasingle object
asresult.Thisrepresentationrequirestheallocationofanarrayobjectforeach
methodinvocationandthewrappingofeachargumentwithbasicJavatypeinto
anobject.OntheserversidetheJava2versionofRMIdoesnotuseaskeleton
object,butinvokesthemethodoftheserverimplementationobjectthroughthe
re ectionmechanism.TherepresentationofthemethodargumentsisineÆcient
becauseitrequiresmultipleobjectallocationsforsimplemethodsignatures.
Us-ingdynamictypeinspectiontoinvoketheimplementationofthemethodonthe
serversidecausesadditionaloverheadthat caneasilybeavoidedbygenerating
acustomizedskeletonobject.KaRMIdidpreventthewrappingofbasictypesto
objectsbygenerating aparameterobjectclassfor each method signature that
isusedin aremoteobject.Theparameterobjectisusedascontainerobjectto
tunneltheinvocationparametersthroughthegenericlayers.Thisparameter
ob-jectisequippedwithcustommarshalingandunmarshalingmethodsforeÆcient
transmissionoverthenetwork.
Obviously the approach using a parameterobject is not the most eÆcient
solution, because at least one additional object is allocated for each method
invocation.Nowrapping of basictypes to objects isnecessary,but allmethod
parameters are rst copied to instance variables of the parameter object and
then marshaledto thenetworkstream. This wasnecessaryto fulll thedesign
criterionofafunctional APIbetweenthelayersdescribedabove.
Topreventtheadditionalparameterconversion,thestub objectmust
mar-shalthemethod argumentsdirectly.Toachievethis,wesplitthemethod
invo-cation processin three phases. Therstphaseis responsible forestablishinga
method invocationcontext, in thesecond phasethemethod is invoked, andin
thethirdphasetheresultofthemethodisreturned.Thelasttwophasesare
un-derthecontrolofthestubusingtheinvocationcontext.TheKaRMIlayershave
onlytobecrossedin therstphasewhiletheobjectaddressingandthecorrect
transport technology is detected. The invocation context that is the result of
therstphaseispartofthetransportlayerandencapsulatesanetwork
// --- Phase 1
---Connection c = ref.getContext( ... );
// --- Phase 2
---c.openSendCall();
// marshal the method arguments to c
c.closeSendCall();
// --- Phase 3
---if ( c.openReceiveResult() ) {
// unmarshal the method result from c
} else {
// unmarshal an exception returned from c
}
c.closeReceiveResult();
Fig.2.Phasesofaremotemethodinvocation
Figure2showstheactionsperformedinthethreephases.Afterthecontextis
established,thestubstartsthemethodinvocationwithopenSendCall().After
thatcallthecontextisreadytomarshalthemethodarguments.Themarshaling
processisnishedbycallingcloseSendCall().openReceiveResult()requests
theresultoftheremotemethodinvocation.Themethod invocationmayeither
complete normallyby returningtheexpectedresult orreturnexceptionallyby
returning anexception object.Which caseoccurs is indicated by theresult of
openReceiveResult(). Finally the context is passed back to the system for
reusein thecalltocloseReceiveResult().
Thisapproachhas twobenetsoverapure functional designwhere simply
onemethodofthenextdeeperlayerisinvoked.Firstthestubcandirectly
mar-shal themethod argumentswith marshalingmethods provided bythe context
object,sonoadditionalconversionoftheargumentstakesplace.Thisapproach
makesaremote method invocationwith no additionalobjectallocation
possi-ble, becausethe context object iscached and reusedfor following invocations.
There is no need forwrapping basictypes that are the mostfrequentmethod
parameters.
The second benet is the fact that issuing the method invocation is
sepa-ratedfromthereceiptoftheresultofthemethodinvocation.Thisseparationis
necessaryforageneralpurposeimplementationofasynchronousremotemethod
invocations. RMI does not support asynchronousremote method invocations,
because in Javaall method invocationsare synchronousand anasynchronous
invocationdoes nott into theconcept of RMI where the server
implementa-tionobjectand thegeneratedremote proxyobjectmustimplementacommon
interface.Anasynchronousremoteinvocationmustnecessarilyhaveasignature
into issuing the call and receiving theresult. Theproxyis generated after the
application is compiled, so the only way of accessing the proxyfrom the
pre-compiled application is an interface that is known in advance. If the remote
method invocationpackageis used in thecontextof JavaParty,this limitation
nolongerholds. Whileitis inconvenientand error-proneiftheoptimization of
hidingnetworklatenciesislefttotheprogrammer,asynchronousremotemethod
invocationsmakelatencyhidingpossiblethat maybeperformedautomatically
bythecompiler.
3 Optimizations at the JavaParty layer
So far we have presented optimizations that only involve the remote method
invocationpackageKaRMI.BesidesJavaParty,allapplicationsusingKaRMIas
replacement for RMI benet from the optimization of early locality detection
in the access layer (l2) and the smart argument copying strategy introduced
in section2.2.As shownin Figure1,JavaPartyaddsanadditionallayertothe
systemtoprovidetransparentremoteobjectsandobjectmigrationsupport.This
isaccomplishedthroughaddingahandlelayerthat alsousesaproxyobjectto
accesstheremoteserverimplementation,butalso isawareofmigration.
Ifthe objectthat is the target of themethod call is ona remotemachine,
theadditionallayerdoesnotdegradeperformancesignicantly,becausethereis
notmuchcomputation performed inthehandle andthenetwork accessclearly
dominatestheoverheadoftheadditionallayer.
Incaseof alocal callwith theshortcut(l2) inKaRMI, theadditionallayer
slows down theinvocationsignicantly because insteadoftwomethod
invoca-tions(fromapplicationcodetothestubobjectintheaccesslayerandfromthere
to theserverimplementationobject)that arenecessaryforalocalKaRMIcall
so far, three invocations are necessaryfor a local JavaParty invocation. (that
correspondstoaslowdownof50%).
AsshowninFigure1,thelogicalconsequenceistheshortcutinvocation(l3)
thatinvokestheserverimplementationmethoddirectlyfromtheJavaParty
han-dleobjectincasethecallisdetectedtobelocal.Becausethisrequiresknowledge
oftheinternalKaRMIstructurewithinJavaParty,wedecidedtoinlinethecode
oftheKaRMIstubobjectsdirectlyintotheJavaPartyhandlebyintegratingthe
stub generatorinto the JavaParty compiler. TheJavaPartycompiler nowcan
generatesmarthandleobjectsthatareawareofobjectmigration(theJavaParty
functionality)and candecideaboutlocality of the referenced object byeither
invoking theservermethod directly oraccessing the referencelayerof KaRMI
to performaremoteinvocation(the KaRMIfunctionality).
4 Benchmark results
Figure 3 shows benchmark results for calls to empty methods with dierent
an integer as result. The third and fourth take one and two int-parameters
respectively.Thefthmethodtakesaparameterofimmutabletypeasdescribed
insection2.2,whilethesixthonetakesaparameterthat canbefastmarshaled
usingtheuka.transportpackage.Notethatthetimeconsumedbyonemethod
call isgiveninmicrosecondswithalogarithmicscale.
void foo()
int foo()
void foo(int)
void foo(int,
int)
void
foo(Immu.)
void
foo(Transp.)
0,01 us
0,10 us
1,00 us
10,00 us
100,00 us
1000,00 us
pure RMI
pure KaRMI (l1)
stub shortcut
smart copy (l2)
Fig.3.KaRMIbenchmarkresults
ThebenchmarkillustratedinFigure3studiesbarelocalRMI/KaRMI
com-munication.Thereforethemethodsarecalledonastubobjectthatislocatedin
thesamevirtualmachineastheserver.Thersttwobarsofeachgrouparefor
referenceonly.Therstbar(withhorizontalstripes)describesthetimeduration
ofaregularlocalJava-RMIcall.Thesecondbar(withverticalstripes)showsthe
performanceofaregularlocalKaRMIcallwithouttheimprovementsdescribed
inthispaper.Asyoucansee,KaRMIalreadyperformsmuchbetterthanRMI.
Formethodswithnoparametersandvoidorbasicreturntype,theperformance
isbetterbytwoordersofmagnitude.Evenformethodswitharguments(ofbasic
orobjecttype),KaRMIoutperformsRMIbyalargefactor(7:4upto18:4),but
theKaRMIperformanceisstillfarfromoptimal.
Thelasttwobarsofeachgroup(slantedand doublestriped)showforeach
method benchmark the performance of a local call with the optimizations of
KaRMIdescribedinsection2.Evenforthevoidmethodanadditional
acceler-ationfactorof24isachievedbylocalcalldetectionatstublevel(stubShortcut).
Where KaRMI does onlysavelittle in comparison to RMI, thelocality
detec-tionatstublevel(stubShortcut)andavoidingofargumentcopying(smartCopy)
doestherest.Inallthreecases,where costlyargumentcopyingcanbeavoided
thesamegoodabsoluteperformancecanbeachieved.Wheretheduplicationof
theargumentis necessaryto preservethesemanticsof aremotecall,the eect
of the optimization is notperceivablebecauseof the hugeoverhead for object
duplication.
void foo()
int foo()
void
foo(int)
void
foo(int,
int)
void
foo(Immu.)
0,00 us
0,02 us
0,04 us
0,06 us
0,08 us
0,10 us
KaRMI smartCopy (l2)
JP smartCopy (l2)
JP smartHandle (l3)
pure Java
Fig.4.JavaPartybenchmarkresults
spercall pure pure KaRMI KaRMI JP JP pure
RMI KaRMI stub- smart- smart- smart- Java
Shortcut Copy Copy Handle
voidfoo() 166.103 1.367 0.057 0.057 0.093 0.0600.023
intfoo() 172.970 1.260 0.044 0.044 0.066 0.0470.019
voidfoo(int) 170.606 23.032 0.058 0.059 0.099 0.0690.026
voidfoo(int,int) 172.253 23.265 0.062 0.066 0.105 0.0720.027
voidfoo(Immu.) 409.866 22.221 21.595 0.062 0.099 0.0690.026
voidfoo(Transp.)334.720 22.071 20.958 21.469 22.004 22.1920.024
Table1.CombinedviewofKaRMIandJavaPartyresults
version (JP smartCopy) and JavaParty with the additional optimization
de-scribedinsection3(JPsmartHandle).Forreference,theperformanceofa
regu-larJavamethodcall isdepictedinthelast row(pureJava).Notethatthescale
ofthisgureislinearincontrasttoFigure3.Therstbar(KaRMIsmartCopy)
isidenticalto thelast barin Figure3but rescaled.
Youcan see that inlining the stub functionality into the JavaParty handle
layerand usingtheshortcut (l3)forlocal callsasdescribed insection3isable
toalmost completelyavoidadditionalJavaPartyoverhead.
Comparing the time, a local JavaParty method invocation takes, and the
timeforaregularJavamethodcall,provestheresultingJavaPartysystemtobe
eÆcient:A local JavaPartymethod invocation (JPsmartHandle) takes onlya
factorof2:5...2:7longerthanaregularJavamethodinvocation 2
.Youwould
ex-pectaslowdownfactorwiththatmagnitude,becauseinsteadofasinglemethod
invocationinregularJavatwoinvocationsarenecessaryduetotheproxyobject.
Additionally atest forlocality and atypeconversionof theserverreference is
necessarybeforethetargetmethodcanbeinvoked.Table1presentsacombined
viewofthedetailed benchmarkresultsforKaRMIandJavaParty.
5 Conclusion
In this paper, we presented techniques to realize local access to transparent
remoteJavaPartyobjectswithinthesameorderofmagnitudeasaregularJava
method invocation. The resultsare notrestricted to JavaParty, because most
of the optimizationswere performed in the KaRMI remote method invocation
package.ThelocalityawareKaRMIpackagecanbeusedasreplacementforRMI,
thestandardJavaclasslibraryforremotemethodcalls.Furtheronwepresented
thefundamentalsforextendingKaRMI toasynchronousremotemethod calls.
References
1. Bryan Carpenter,GeoreyFox, SungHoonKo, and Sang Lim. Object
serializa-tion for marshaling data in a java interface to MPI. Concurrency: Practice and
Experience,12(7):539{553, 2000.
2. Vladimir Getov, Paul A. Gray, and Vaidy S. Sunderam. Aspects of portability
anddistributedexecutionforJNI-wrappedmessagepassinglibraries. Concurrency:
Practice andExperience,12(11):1039{1050, 2000.
3. Bernhard Haumacher andMichael Philippsen. More eÆcient object serialization.
InParallelandDistributedProcessing,number1586inLectureNotesinComputer
Science,PuertoRico,April12, 1999.SpringerVerlag.
4. VijaykumarKrishnaswamy,DanWalther,SumeerBhola,EthendranathBommaiah,
George Riley, Brad Topol, and Mustaque Ahamad. EÆcient implementations of
Java RemoteMethod Invocation(RMI). InProc. of the4th USENIXConference
onObject-Oriented Technologies andSystems(COOTS'98),1998.
5. Michael Philippsen, Bernhard Haumacher, and Christian Nester. More eÆcient
serialization andRMIforJava. Concurrency: PracticeandExperience, 12(7):495{
518,May2000.
6. Michael Philippsenand Matthias Zenger. JavaParty: Transparent remoteobjects
inJava. Concurrency:Practice andExperience,9(11):1225{1242, November1997.
7. SunMicrosystemsInc.,MountainView,CA. JavaRemoteMethodInvocation
Spec-ication,October1998. ftp://ftp.javasoft.com/docs/jdk1.2/rmi-spec-JDK1.2.pdf.
8. RonaldVeldema,RobvanNieuwport,JasonMaassen,HenriE.Bal,andAskePlaat.
EÆcient remotemethodinvocation. Technical Report IR-450, Vrije Universiteit,
Amsterdam,TheNetherlands,September1998.
9. Thomas M. Warschko,JoachimM. Blum,and WalterF.Tichy. The ParaStation
project:Using workstations as buildingblocksfor parallel computing. Journal of