• No results found

Application. handle layer. access layer. reference layer. transport layer. ServerImplementation. Stub. Skeleton. ClientReference.

N/A
N/A
Protected

Academic year: 2021

Share "Application. handle layer. access layer. reference layer. transport layer. ServerImplementation. Stub. Skeleton. ClientReference."

Copied!
12
0
0

Loading.... (view fulltext now)

Full text

(1)

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

di erentparameterpassingsemantics.

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

(2)

therelativelocationofitsobjects.Locationtransparencyenablestheseparation

ofapplicationdesignfromobjectallocationanddistributiondecisions.In

partic-ularthisopensupthepossibilitytodecideaboutthelocationofcreatedobjects

automatically with compile time or runtime support. JavaPartyalso supports

migration of already allocated objectsto di erent 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 di erent 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

(3)

1.3 Related work

ToexecuteaprogrameÆcientlyinadistributedenvironment,afastnetworkand

slim protocol layersare necessaryprerequisites. We havealready show how to

achievethisin pureJava[5,3]onaMyrinetnetwork.Thereareothere ortsto

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,itdoesnot tthe

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.Section4provesthee ectivenessofthe

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

(4)

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,becauseofdi erentargumentpassing

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 the gure.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

objectsareidenti edbysocalledobjectnumbersthat areassignedto aremote

objectat the time it is exported. The object numberin combinationwith the

Internetaddressofthemachineandtheporttheobjectwasexportedonidenti es

theobjectin thedistributed environment.

(5)

transporttechnologyalsode nesthewireprotocolthatisusedforthe

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 modi cationsmade

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

identi es 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

implementationwithoutanyadditionalle ort.

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.

(6)

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

onceandthatcannolongerbemodi edarecandidatesforpassingthem

di-rectlyinalocalcalltoaremotemethod.Becausetheremotemethodcannot

modifythestateofthepassedobject,theapplicationisunlikelytoperceive

thedi erenceofacall-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

(7)

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 ful ll thedesign

criterionofafunctional APIbetweenthelayersdescribedabove.

Topreventtheadditionalparameterconversion,thestub objectmust

mar-shalthemethod argumentsdirectly.Toachievethis,wesplitthemethod

invo-cation processin three phases. The rstphaseis responsible forestablishinga

method invocationcontext, in thesecond phasethemethod is invoked, andin

thethirdphasetheresultofthemethodisreturned.Thelasttwophasesare

un-derthecontrolofthestubusingtheinvocationcontext.TheKaRMIlayershave

onlytobecrossedin the rstphasewhiletheobjectaddressingandthecorrect

transport technology is detected. The invocation context that is the result of

the rstphaseispartofthetransportlayerandencapsulatesanetwork

(8)

// --- 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

processis nishedbycallingcloseSendCall().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 twobene tsoverapure 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 bene t 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 not t into theconcept of RMI where the server

implementa-tionobjectand thegeneratedremote proxyobjectmustimplementacommon

interface.Anasynchronousremoteinvocationmustnecessarilyhaveasignature

(9)

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 bene t 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,

theadditionallayerdoesnotdegradeperformancesigni cantly,becausethereis

notmuchcomputation performed inthehandle andthenetwork accessclearly

dominatestheoverheadoftheadditionallayer.

Incaseof alocal callwith theshortcut(l2) inKaRMI, theadditionallayer

slows down theinvocationsigni cantly 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 di erent

(10)

an integer as result. The third and fourth take one and two int-parameters

respectively.The fthmethodtakesaparameterofimmutabletypeasdescribed

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.The rsttwobarsofeachgrouparefor

referenceonly.The rstbar(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 e ect

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

(11)

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

ofthis gureislinearincontrasttoFigure3.The rstbar(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,Geo reyFox, 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.

(12)

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-i cation,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

References

Related documents

happened, and as such was an act of self-definition. Du Fu’s poetics of historical memory refers to these transformations enacted in and through poems on the identities of place

Since 2012, the Fukushima Gender Equality Centre has operated to verify the human resource training business in regards to DRR & Gender Equality, and to consider new programs

Patient cable PK-83-B for single-chamber pacing with two screw terminals for temporary leads on the patient side and Redel plug on the Reocor side (use Redel adapter).

Un elemento que sin duda va a repercutir sobre la posibilidad de que esta nueva planificación comunitaria arraigue y poder lograr así el objetivo de una ciudad más cohesiva

Using a color palette that is similar to that of the master artist you selected, fill the shapes in your drawing.. Use the Paint Bucket or Fill tool to fill the shapes with

Job Description : The Wind Farm Project Manager position is a high level position; this position will oversee all aspects of the technical specialities of wind power

The new embedded systems management solution for Dell servers features hardware and firmware inventory and alerting, data center level power monitoring, faster performance and

Overall, the ROAD traffic light approach promotes transparency and provides the flexibility to adjust the monitoring plan based on data and modelling results becoming available as