MareaAnEfcientApplicationLevelObjectGraphSwapper3isnotpossibletodoitinthesamewayitisdoneinstandardJavabecauseJ2MEdoesnotprovidetheJDBCAPICustomandSpecicRuntimeContrarytothepreviousalternativewh ID: 187321
Download Pdf The PPT/PDF document "2MarianoMartinezPeck,NouryBouraqadi,Mar..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
2MarianoMartinezPeck,NouryBouraqadi,MarcusDenker,StéphaneDucasse,LucFabresseUnusedobjectscansometimesbeasymptomofanevenmoreseriousproblem:memoryleaks[BM08].Inpresenceofmemoryleaks,applicationsusemuchmoreresourcesthantheyactuallyneed.Theymayeventuallyexhausttheavailablememoryandleadtosystemcrashes.Operatingsystemshavebeensupportingvirtualmemorysincealongtime[Den70,Sta82,CH81,WWH87,KLVA93].Virtualmemoryistransparentinthesensethatitautomaticallyswapsoutunusedmemoryorganizedinpagesgovernedbysomestrategiessuchastheleast-recently-used(LRU)[CH81,CO72,Den80,LL82].Asvirtualmemoryistransparent,itdoesnotknowtheapplication'smemorystructure,nordoestheapplicationhaveanywaytoparametrizeorcooperatewiththevirtualmemorymanager.Inthispaper,weproposeMarea,anObjectGraphSwapper(OGS)whosemaingoalistooffertheprogrammerasolutiontohandleapplication-levelmemory.Developerscaninstructoursystemtoreleaseprimarymemorybyswappingoutunusedobjectstosecondarymemory.Mareaisdesignedto:1)saveasmuchmemoryaspossiblei.e.,thememoryusedbyitsinfrastructureisminimalcomparedtotheamountofmemoryreleasedbyswappingoutunusedobjects,2)minimizetheruntimeoverheadi.e.,theswappingprocessisfastenoughtoavoidslowingdownprimarycomputationsofapplications,and3)allowtheprogrammertoinuencetheobjectstoswap.Thecontributionofthispaperistwofold.Ontheonehand,weintroduceaprecisede-scriptionofproblems,challenges,algorithmsanddesignaspectswhilebuildinganOGSforobject-orientedsystems.Ontheotherhand,wepresentMarea,ourefcientsolutionanditsimplementationinthePharoprogramminglanguage[BDN+09].WeshowthatMareacanreducetheprimarymemoryoccupiedbyapplicationsupto36%.Ourimplementationalsodemonstratesthatwecanbuildsuchatoolwithoutmodifyingthevirtualmachine(VM)yetwithacleanobject-orienteddesign.Theremainderofthepaperisstructuredasfollows:Section2startswithabriefanalysisoftheexistingsolutionsandtheirlimitations.Section3liststherequirementstobuildanOGS.Section4presentsMareaandgivesanoverview.Section5explainstheneedandthedifcultyofcorrectlyhandlingsharedobjects.ThealgorithmsofMarea'sobjectswapperarepresentedinSection6togetherwiththesolutiontographintersections.Section7ex-plainshowtouseMareafromthedeveloperpointofview.Section8providesbenchmarksforswappingcodeanddatawhileincludingananalysisofunusedobjects.Marea'simple-mentationandrequirementsaredescribedinSection9.WeevaluateMareaoveralistofrequirementsanddesiderataanddiscussinfrastructure-specicissuesandoptimizationsinSection10.Finally,inSection11,relatedworkispresentedbeforeconcludinginSection12.2LimitsofExistingSolutionsThememorythatisoccupiedbutunusedcanbesplitintwoparts.Onepartisusedbythecodeoftheapplicationandlinkedlibraries.Theotherpartstoresdatageneratedasaresultoftheexecution.Reducingbothpartsisofinterest.ReducedandSpecializedRuntime.Solutionsbelongingtothisfamilydecreasethemem-oryusagebyremovingcodeandbuildingsmallruntimes.Forexample,J2MEisastripped-downversionofJavaforembeddeddevicesthatcontainsastrictsubsetoftheJava-classlibraries.However,decisionsbehindthisreductionaretakenbythedevelopersofJ2ME.Fromdevelopersperspective,J2MEisamonoliththatcannotbeadapted.J2MEdegradestheJavaenvironmentandAPIsrightfromthespecication.Moreover,someJ2MEAPIsarenotcompatiblewithJ2SE,breakingtherule“compileonce,runevery-where.”Forinstance,ifanapplicationneedstodirectlyconnecttoarelationaldatabase,itJournalofObjectTechnology,vol.12,no.1,2013 Marea:AnEfcientApplication-LevelObjectGraphSwapper3isnotpossibletodoitinthesamewayitisdoneinstandardJavabecauseJ2MEdoesnotprovidetheJDBCAPI.CustomandSpecicRuntime.Contrarytothepreviousalternativewheretheruntime'sdevelopersdecidewhattoinclude,anotheralternativeistoletdevelopersdecidewhateachapplicationneedsandcreateaspecicandcustomizedruntimeforit.JITS(JavaInTheSmall)isatoolthatallowsthedevelopertocustomizetheruntimetoavoidtheneedofem-beddingunusedpackagesorfeatures[CGV10].TheideaofJITSistodevelopusingstandardJava.Then,fordeployment,JITScreatesatailoredruntimeaccordingtotheapplication'sneeds.JITSdevelopersoftendevelopapplicationsinasubsetofJavathateasestheidenti-cationofunusedclasses(noinheritanceorpolymorphismandproceduralprogramming).Similarsolutionsareimplementedinotherprogramminglanguages.Forexample,Visual-WorksSmalltalkprovidesaruntimepackager1,whichmakessmallerruntimesbyexplicitlyremovingclassesandpackages.Still,withthisstrategy,developersneedtoknowwithabsolutecertaintywhatisrequiredbytheirapplications.Atdevelopmentstage,itisdifcult,time-consumingandsometimesimpossibletogureoutwhatanapplicationneedsforallpossibleexecutionpathsevenwithstaticanalyzers.Moststaticanalyzersdonottakeintoaccountreectivefeaturesthatareoftenusedtosupportapplicationevolutionanddynamiccodeloading[BSS+11].ApplicationData.Certaintypesofapplications,suchasgraphicseditors,oftenhavetomanipulateimageswithasizethatisbiggerthanprimarymemory.Developersaddressthisissuebyoftenbuildingtheirownadhocinternalmemorymanagementsystem[EGK95].Nevertheless,thetraditionalwaytohandledataistosaveittolesordatabasesandloadthemwhennecessary.Whiledatabaseconnectorscanbereused,developersstillhavetohandledatastorageandloadingexplicitly.OperatingSystemVirtualMemory.Whileoperatingsystems(OS)providevirtualmem-ory,thissolutionisnotsatisfactorytoaddresstheunusedobjectsissuebecauseofthefollow-ingreasons:GarbageCollection:Memorynotusedcan,intheory,beswappedbytheoperatingsystemtodisk.However,theobjectsondiskalsoneedtobegarbagecollected.AsGC'sworkingsetinvolvesallobjects(includingthosethatareondisk),thiscantriggermemorythrashing(trafcbetweenprimaryandsecondarymemory)thatdegradesper-formancebyordersofmagnitude[YBK+06,HFB05].InSection11wediscusssomesolutionstothisproblem.Persistence:Inimage-basedsystemssuchasSmalltalk,wecanpersistthecurrentob-jectmemorystateinadisksnapshot.Asthevirtualmachineisnotawareofthemem-orymanagementoftheOS,itcannotsaveitsmemoryinastatewheresomepartsareswappedoutwhileothersarenot.Thus,savingthesystemmeansswappinginalldataandwritingoutthecompleteheap.TheOSonlyknowsaboutmemorypagesorsimilarstructuresusedbyvirtualmem-oryimplementations.Therefore,theOScannotguesswhichobjectsarethemostap-propriateonestoswap.Theinformationaboutobjectusageisonlyavailableattheapplication-level[EKO95,EGK95]. 1ExplainedinVisualWorksApplicationDeveloper'sGuide.JournalofObjectTechnology,vol.12,no.1,2013 Marea:AnEfcientApplication-LevelObjectGraphSwapper5WhenMareaswapsagraph,itcorrectlyhandlesallthereferencesfromoutsideandinsidethegraph.Whenoneoftheswappedobjectsisneeded,itsgraphisautomaticallybroughtbackintoprimarymemory.Toachievethis,Mareareplacesoriginalobjectswithproxies[GHVJ93].Wheneveraproxyinterceptsamessage,itloadsbacktheswappedgraphfromsecondarymemory.Sincewearechangingthelivingobjectgraphatruntime,thisprocessiscompletelytransparentforthedeveloperandtheapplication.Anyinteractionwithaswappedgraphhasthesameresultsasifitwasneverswapped.Figure1showsthatMareaisbuiltontopoffourmainsubsystems:(1)objectgraphswapper,(2)proxytoolbox,(3)serializerand(4)objectstorage.Wedescribetheminthefollowing. Figure1–Mareasubsystems.ObjectGraphSwapper.Itstaskistoefcientlyswapgraphsbetweenprimaryandsec-ondarymemory.AsweexplainlaterinSection5,detectingandcorrectlyhandlingthesharedobjectsofagraphisachallengingtaskthattheOGSaddresses.TheOGSusesaserializerandaproxytoolboxtosave,loadandreplaceobjects.ProxyToolbox.TheOGSreplacessomeobjectsofthegraph2beingswappedwithproxies.Thereferencestoproxiedobjectsarereplacedwithreferencestoproxies.Werefertothisfunctionallyasobjectreplacement.Todealwiththeuniformityrequirement,Marearequiresthatproxytoolboxsupportsproxifyinganykindofobjectsincludinglanguageruntimeobjects(classes,methods,con-texts)sinceinSmalltalksuchelementsareobjectstoo.ObjectSerializer.WhenanOGSneedstoswapoutagraph,therststepistoserializeit.AnimportantrequirementofMareaistohaveaccesstoafastserializer.Whenaswappedoutobjectisneeded,itisessentialtobeabletoloaditbackasfastaspossibletoavoidapplicationslowdowns.Furthermore,theserializermustbeabletocorrectlyserializeandmaterializeanykindofobjectssuchasclasses,methods,contextsorclosuresinaccordancewiththeimplementationlanguage.ObjectGraphStorage.Itsmainresponsibilityistostoreandloadserializedgraphs(eachserializedgraphisanarrayofbytes).Thegraphstorageresponsibilitiesarereiedinaseparateclassfollowingthestrategydesignpattern.ThisallowsMareatoeasilysupportdifferentbackendsandtheusercanchoosewhichonetouseorevencreateitsown.Currentbackendsarethelocallesystem,Riak3andMongoDB4NoSQLdatabases. 2Section6explainswhichobjectsareactuallyreplacedbyproxies.3http://wiki.basho.com/Riak.html4http://www.mongodb.org/JournalofObjectTechnology,vol.12,no.1,2013 Marea:AnEfcientApplication-LevelObjectGraphSwapper7 Figure3–Theneedtomanagesharedobjects.whenwereloadthegraph,DshouldbeupdatedtoreferthematerializedC,andCshouldrefertothematerializedE.Theproblemisthatprogramminglanguagesdonotprovideaneasyorincrementalwayofdetectingsharedobjects.Objectsdonothaveback-pointerstotheobjectsthatrefertothem.Hence,acostlyfullmemorytraversalisoftenrequiredasImageSegmentdoes[MPBD+10a].Byusingweakcollectionsthatholdreferencestoproxiesandlettingthegarbagecollectordoitsjob,Mareaavoidsafullmemoryscanasweexplaininthenextsection.6Marea'sObjectSwapperAlgorithmsMareaprovidesanefcientapproachtodetectandcorrectlyhandlesharedobjectswhileavoidingafullmemoryscan.Mareacreatesaproxyforeveryobjectofthegraph(whetheritisaroot,aninnerorasharedobject).Theneachobjectisreplacedbyitsassociatedproxy(previousobjectpointersnowpointtotheassociatedproxy).Asaresult,proxiesforinnerobjectsarenotreferencedfromanyotherobject.Indeed,innerobjectswereonlyreferencedfrominsidethegraphandallobjectswerereplacedbyproxies.Hence,assoonastheGCruns,itwillgarbagecollectallinnerobjectsandallproxiesleavingonlythoseproxiesforfacadeobjectsandtherootofthegraph.Duringtheswapin,thegraphismaterializedandallproxiesassociatedwiththegrapharereplacedbytheappropriatematerializedobjects.Thesubsequentsectionsexplainindetailtheswappingoutandinoperations.6.1SwappingOutTheswappingoutphaseistriggeredexplicitly,i.e.,theprogrammerhastoinstructtheOGStoswapoutagraph.Marea'sstrategytoswapoutobjectgraphsdecomposesintothefollowingsteps.1.Initialization:MareaassignsanautomaticallygeneratedanduniqueID(anumber)toeachgraph.IntheexampleofFigure4,Mareaassignsthenumber42tothegraph.2.Serializetheobjectgraph:withthedefaultconguration,Mareaserializesthegraphintoasinglelelocatedinasecondarymemory(e.g.,onharddisk).ThelenameisthegraphID(42.swapinourexample).3.Createproxies:Mareacreatesaproxyforeachobjectofthegraph.WeintroduceproxiesDict,anidentitydictionarythatmapsobjectstoproxies.Intheexample,itmapsA,B,C,andEtotheirrespectiveproxies,namelyPa,Pb,Pc,andPe.TheresultisJournalofObjectTechnology,vol.12,no.1,2013 Marea:AnEfcientApplication-LevelObjectGraphSwapper96.2SwappingInTheswapinofagraphistriggeredwhenoneofitsproxiesisaccessed,forexample,viaamessagesendoraninstancevariableaccess.Thissituation,i.e.,whenthesystemneedsanobjectthatwasswappedout,causeswhatisknownas“objectfaulting”[HMB90].Whenaproxyinterceptsanactionithascertaininformationaboutit.Forexample,iftheactionisamessagesend,theproxyknowswhichmessagewassentanditsarguments.Theproxypassesalltheinterception'sinformationtoahandler.ThehandlerrstmakestheOGStoswapinthegraphassociatedwiththeproxy.Then,thehandlerforwardstheoriginalmessagetotheobjectthatwasinitiallyreplacedbytheproxy.Section9.1givesmoredetailsaboutMarea'sclassesandtheirresponsibilities.WecontinueourexamplefromFigure4(d).WeassumethattheproxyPareceivesamessage.Theresultingswapindecomposesintothefollowingsteps: (a)Objectgraphismaterializedandproxiesareassociated. (b)Proxiesarereplacedbymaterializedob-jects. (c)Finalresult.Figure5–Stepstoswapin:Materialization,associationofproxieswithmaterializedobjects,proxyreplacementandcleaning.1.Materializetheobjectgraph:thisisdonebyrstgettingthelenamedaftertheproxy'sgraphID.Oncewehavethestream,wematerializetheobjectgraph(withalltheobjectsreferences)intoprimarymemory.2.Associateproxieswithmaterializedobjects:ThegraphIDisalsousedtoretrievethelistofproxiesfromtheGraphTable.Thislistincludesonlyaliveproxiesi.e.,proxiesthathavesurvivedGCbecauseofbeingreferenced.Eachproxystoresthepositioninthestreamofthecorrespondingproxiedobject.Withthisinformation,wecanidentifythematerializedobjectassociatedwithagivenproxy.InFigure5(a),Pacorrespondstotheobjectattheposition2intheserializationstreamofgraph42.Thus,PaisassociatedtoA'.TheresultofthisprocessisatemporaryproxiesDictinwhichthekeysareproxiesandthevaluesaretheassociatedmaterializedobjects.3.Replaceproxieswithoriginalobjects:allreferencestoeachproxyintheproxiesDictareupdatedsothattheynowpointtothecorrespondingmaterializedobject.TheproxiesweneedtoreplacearethosethatarestoredaskeysintheproxiesDictandtheirassociatedmaterializedobjectsarethevaluesofthedictionary.Figure5(b)illustratestheresultofthisstep.4.Cleaning:wediscardproxiesDict,thecurrentgraphisremovedfromtheGraphTableandthelefortheserializedgraphisdeleted7.Figure5(c)presentsthenalstateafteraGCrun.Theresultoftheswappinginisagraphequaltotheonethatwasswappedout,asFigure2shows.NoticethatevenifthematerializedobjectsarecalledA',B',C',andE',theyareequaltoA,B,C,andE. 7Marea'scurrentimplementationoffersanAPItotriggeranautomaticcompactionoftheGraphTable.SuchcompactioncanalsobedoneautomaticallyaftereachGC.JournalofObjectTechnology,vol.12,no.1,2013 Marea:AnEfcientApplication-LevelObjectGraphSwapper11Followingourexample,Figure6showstheresultofswappingoutrstthegraph42andthenthegraph43withthehandlingofsharedproxies.Whenswappingoutgraph43,Pcisaddedtoboth,GraphTableandSharedProxiesTable. Figure6–Swappingouttwographswithsharedproxies.First,graph42andthengraph43.Solutionpart2:SwappingInwithSharedProxies.Tohandleswappingingraphswithsharedproxies,theswapinalgorithmperformsasdescribedinSection6.2exceptforproxiesfoundinthematerializedgraph.Thoseproxiesaresharedones.EachmaterializedsharedproxyisreplacedbytheappropriateobjectfromtheSharedProxiesTablewhichislookedupbasedontheproxy'sID.Toillustratethealgorithm,consideragainourexamplewithtwographsofFigure2.Afterswappinggraph42(startingwithobjectA)andgraph43(startingwithobjectD)inthisorder,weobtainastructuredepictedbyFigure6.Now,twoswappinginscenariosmayoccur:graph42isswappedbefore43orvice-versa.Wewillconsiderthosescenariosandshowthatbothgraphsarecorrectlyrebuilt.Intherstscenario,graph42isswappedinrst.Noneofthematerializedobjects(A',B',C',andE')isaproxy.WesimplyreplaceproxiesPaandPcfoundatentry42oftheGraphTablewiththerightobjects,namely:A'andC'.Thereplacement,whichissystem-wide,affectstheSharedProxiesTablesinceC'replacesPc.Whengraph43isthenswappedin,MarearstreplacestheproxyPdfoundinentry43oftheGraphTablebythematerializedobjectD'.Entry43oftheGraphTablealsoincludesC'whichisignoredbecauseitisnotaproxy.Then,Mareadetectsasharedproxyissuesincethereisaproxy(Pc')inthematerializedgraph.Next,weusetheIDofPc'togetC'fromtheSharedProxiesTable.Finally,Pc'isreplacedbyC'.Thus,bothgraphsarereconstructedcorrectlyandsharingispreserved.Inthesecondscenario,graph43isswappedinrst.MarearstreplacestheproxyPdbythematerializedobjectD'.Entry43oftheGraphTablealsoincludesPcwhichisignoredbecauseitsgraphIDis42andnot43.MareadetectsasharedproxyissuesincethereisPc'inthematerializedgraph.WeusetheIDofPc'togetPcfromtheSharedProxiesTable.Next,wereplacePc'byPc.Whengraph42isthenswappedin,MareareplacesproxiesPaandPcfoundatentry42oftheGraphTablewiththerightobjects,namely:A'andC'.ThereplacementmakesD'referenceC'.Again,bothgraphsarereconstructedcorrectlyandsharingispreserved.CleaningSharedProxiesTable.SinceGraphTablecontainsweakreferences,Mareacanlis-tenwhentheGCclearsthoseweakreferencesandthendoanautomaticcleanupandcom-pactionofthetable.However,SharedProxiesTableholdsstrongreferencestoitsvalues(theycanbeproxiesornormalobjects).Toclearthistable,MareaneedstoanalyzeGraphTable.IfaproxyofSharedProxiesTableisnotreferencedfromanyentryinGraphTable,itmeansthatallitsrelatedgraphswereswappedinsoitcanberemoved.WecouldmakeMareatriggerthiscleaningwhenswappinginagraph,orhookintotheGCandtriggeritautomaticallyaftereachGC.However,thisaddsanunnecessaryoverheadJournalofObjectTechnology,vol.12,no.1,2013 Marea:AnEfcientApplication-LevelObjectGraphSwapper133.Weransomescripts(similartotheoneofSection7)toswapoutasmanyobjectsaspossible.Insomeexperimentstherootsofobjectgraphswereclasses,inotherstheywerepackages.4.Werantheapplicationoverseveralreal-casescenariosi.e.,weuseditandweranactionsonit.Whiledoingso,neededgraphswereswappedin.5.Wemeasuredthememoryusedandtheswappingspeed.Then,weperformedthesameexperimentsbutonaPharoCorewithoutobjectswappingandanalyzedthegainedmemory.EnvironmentConguration.OurexperimentswererunwithPharoCore1.3buildnumber13327andCogVirtualMachineversion`CoInterpreterVMMaker-oscog-EstebanLorenzano.139'.TheoperatingsystemwasMacOS10.6.7runningina2.4GHzIntelCorei5processorwith4GBofprimarymemoryDDR31067MHz.TheharddiskwasSATA,500GBandrunningat7200RPM.Theswappingwasdonewiththedefaultobjectgraphstorage,i.e.,lesinthelocallesystemcreatingoneleperswappedgraph.8.1ApplicationsDBXTalkCMSWebsite.ItisthewebapplicationoftheDBXTalkproject10.Itisdevel-opedwithPier11,aCMSbasedontheSeasideWebframework[DRS+10].MooseSuite(version4.7).Moose12isaplatformforsoftwareanddataanalysis[NDG05].Itallowsuserstohandledifferentlargemodelsthatrepresentthepackagesanddatathatarebeinganalyzed.Dr.Geo(version11-12g).Thisisaninteractivegeometrysoftwarethatallowsonetocreategeometricsketches.ThePharoruntimeusedbyDr.Geoisalreadyreduced.ItisbasedonaPharoCoreusingtheproductionconguration.Besides,developerscompacteditevenfurtherbyremovingpartofthecodeincludedinPharoCore.Sincetheruntimeisonly11.2MB,itisaninterestingchallenge.PharoInfrastructure(version1.3).ApartfrombenchmarkingthememoryconsumptionofdifferentapplicationsbuiltontopofPharo,wemeasurethePharoinfrastructure(theIDEandtheruntime)itselfwithoutanythingextraloadedonit.Theideaistocomparetheinfras-tructureversusapplicationsandanalyzeifwecancompactPharo'sruntimeevenmore.Alltheseselectedreal-worldapplicationshavedifferentcharacteristicswiththepurposeofbeingrepresentative.DBXtalkCMSisawebapplication,Mooseisalargestandalonesoftware(around174packages1364classesand121010linesofcode),DrGeoisamobileappandPharoistheinfrastructureitself.8.2SwappingOutCodeMareacanswapdifferentuser-providedobjectgraphs.However,acommonscenarioiswhentheuserwantstoswapout“unusedcode”tomakeitsapplication'sruntimesmallerandlessmemoryconsuming. 10Thewebsiteiscurrentlylocatedinhttp://dbxtalk.smallworks.com.ar/11www.piercms.com12http://www.moosetechnology.org/JournalofObjectTechnology,vol.12,no.1,2013 Marea:AnEfcientApplication-LevelObjectGraphSwapper15InthecaseofDr.Geowereduced24.5%oftheruntime,whichissignicantknowingthatthedevelopersalreadycompactedDr.Geoasmuchastheycould.RegardingPharo'sinfrastructurewewereabletogain32.7%ofmemory.TheactionsperformedonPharoweretostartit,browsesomeclasses,createanewclassandaddsomemethodstoit.ThisanalysisshowsthatPharo'senvironmentcanstillbereduced.MeasuringInternalData.Besidesmeasuringtheamountofmemoryreleasedaspartoftheswapping,itisalsointerestingtoknowhowmuchoftheresultedmemoryisoccupiedbyproxiesandotherinternaldatastructuresofMarea.Toanswerthatquestion,weevaluatedsomeoftheapplications. Application(swapunit)Memoryreleased(MB)afterexperi-mentsProxiesProxiesmemory(bytes)Internaldatastructures(bytes)Totalinternal(bytes)Totalin-ternal/memoryreleasedTotalinternal/sizeafterexperi-ments DBXTalk(class)7.8976191350203773925124126.08%3.55%DrGeo2(class)7.74599646081268521914607.23%2.34% Table2–MeasuringInternalData.ToexplainthecolumnsofTable2,weconsidertherstline.Inthiscase,“Memoryre-leased(MB)afterexperiments”is21.7(sizebeforeswapping)-13.8(sizeafterexperiments)=7.89.Thenextcolumnsareself-explanatory.Thetableshowsthatonaveragetheinter-naldatastructuresofMareaandtheproxiesthemselves,representonlybetween6.08%and7.23%ofthereleasedmemoryandbetweenofthe2.34%and3.55%oftheresultingmemory.Classesvs.PackagesasRoots.Partofourexperimentswastocomparetheimpactofconsideringpackagesastherootsofthegraphratherthanclasses.WereporthereonlytheexperimentswithDBXTalksincetheresultswithothersapplicationsweresimilar.AswecanseeinthersttworowsofTable1,thegainwhenusingclassesasswapunitismuchbiggerthanwithpackages.Themainreasonisthatconsideringapackageasrootinvolveslargerobjectgraphs.Theaveragenumberofobjectspergraphis1340withpackageswhileitis170withclasses.Thenassoonasoneoftheseobjectsisneeded,thewholegraphisswappedin.Oneconclusionfromthisexperimentisthatdecidingwhichgraphsarechosentoswapisimportantanddirectlyimpactsontheresults.Anotherconclusionisthatclassesareagooddefaultcandidate.AnalyzingSharedObjects.Ifweonlyconsiderexperimentswithclassesasroots,sharedobjectsrepresentbetween15%and17%ofeachgraph.ThismeansthatthecompactionofGraphTableisworthysince83%to85%isfullofnils.IntheexampleofDBXTalk,thecompactionresultsinareductionofmemoryfootprintby1MBwhichisalreadysubtractedfromthe13.8MBmentionedinTable1.UnderstandingMemorySavings.Table3describeswithmoredetailstheactualobjectsswappedout.Wedistinguishedbetweenclasses,methodsandplaininstances.Theanalysisshowsthattheresultsonaverageareapproximatelythesame.JournalofObjectTechnology,vol.12,no.1,2013 Marea:AnEfcientApplication-LevelObjectGraphSwapper17 ModelObjectsSwappingouttime(ms)Swappingintime(ms) Morphic21026721702025360Network539127227511476Marea32313812127835 Table4–SwappingdifferentlargeMoosemodels.22secondstoswapoutandapproximately1secondtoswapin.ConsideringthesizeoftheexperimentedgraphsweconcludethatMareacanbeusedbyapplicationstoautomaticallyswapdata.Theswappingoutoflargegraphsisexpensiveregardingexecutiontime.OntheMooseexample,those12to22secondstoswapoutalargemodelhavetobecomparedwithalternativessuchasreconstructingthewholemodeleachtimeorjustwritingitondiskandre-readingit.OurconclusionisthatMarea'soverheadisnotsignicantcomparedtoalternativeswhileitbringsalotofbenetstotheapplicationdevelopers.8.4MeasuringUnusedObjectsWegatheredstatisticsaboutthememoryconsumptionandobjectsusage[MPBD+10b]basedonaPharoVMthatwemodiedtosupporttheidenticationofunusedobjects.Foreachex-periment,westarttheanalysis,weusethesystemforawhile,westoptheanalysisandnallycollecttheresults.Foreachapplicationwegotthefollowinginformation:thepercentageofusedandunusedobjectsandthepercentageofmemorythatusedandunusedobjectsrepre-sent.TheresultsarepresentedinTable5. App.%Usedobjects%Unusedobjects%Usedob-jectsmemory%Unusedob-jectsmemory DBXTalk19%81%29%71%Moose18%82%27%73%DrGeo23%77%46%54%Pharo10%90%37%63% Table5–Measuringusedandunusedobjects.Table5showsthat,afterhavingnavigatedallthepagesoftheDBXTalkwebsiteanddoingourbesttocoverallitsfunctionalities,only19%oftheobjectswereusedrepresenting29%oftheruntimememorysize.ForMoose,wegotthat18%oftheobjectswereusedbyourexperiment.ThismakessensebecauseMooseisareallylargesuiteoftoolsthatprovidesmanyvisualizationsandintegrationwithmultipleprogramminglanguages.Inourcase,wejustimportedSmalltalkprojectsandwerunallthevisualizationsandtools.Dr.Geoexampledemonstratesthatitsruntimeisalreadyreducedandthatisthereasonwhyitspercentageofusedobjectsisbiggerthantheotherexamples.InthePharoinfrastructureexample,only10%oftheobjectswereusedrepresenting37%oftheruntimememorysize.Whydo10%oftheobjectsrepresent37%ofthememory?Thisisbecausetheruntimeincludesallthebitmapstorendertheenvironment.Thereareafewbitmaps(312inourexample)buteachofthemislargeinmemoryconsumption.Those312bitmapsoccupy4.8MBwhichrepresentalmosthalfoftheconsumedmemory.Conclusion.UsingMareawewereabletodecreasetheamountofmemoryused.How-ever,thegainedmemorydoesnotmatchtheexpectedpercentageofunusedobjectpreviouslyanalyzed.Forexample,inDBXTalk,wecouldsave36.4%ofthememoryeventhoughwepreviouslymeasuredinourexperimentsthat71%wasunused.OnereasonisthegranularityJournalofObjectTechnology,vol.12,no.1,2013 20MarianoMartinezPeck,NouryBouraqadi,MarcusDenker,StéphaneDucasse,LucFabresse2000linesofcodeacross35classes.Theaveragenumberofmethodsperclassis9whiletheaveragelinesofcodepermethodis6conformingtoSmalltalkstandards[KST96].The80unitteststhatcoverallMarea'susecasesareimplementedinapproximately1900linesofcode,whichisalmostaslongasMarea'simplementation.Figure7showsasimpliedUMLclassdiagramofMarea'sdesign. Figure7–SimpliedUMLclassdiagramofMarea.Itskeyclassesare:ObjectGraphExporteristheentrypointforthenaluser.ItprovidesmethodstoswapoutgraphofobjectsandreliesonFuelfortheserialization.ThealgorithmistheoneexplainedinSection6.Similarly,ObjectGraphImporterimplementsthealgorithmtoswapinanditsinputisaproxy.ItreliesonFuelforthematerialization.ProxyandClassProxyareconcretesubclassesofGhost'sAbstractProxy.Theironlypur-poseistointerceptmessagestotriggertheswappingin.ClassProxyisneededbecausewewanttoproxyclassesthemselvesandtheVMexpectscertainshapeforclasses.Onceamessageisintercepted,itisforwardedtoitsassociatedhandlerwhichisMarea-Handlerinourcase.Therearealsocertainspecialmessagesthattheproxiesimplementandanswerthemselvesratherthaninterceptinge.g.,isProxyorproxyInstVarAt:.MareaHandlerisaconcretesubclassofGhost'sProxyHandlerwhosemaingoalistoman-ageinterceptions.Aninterceptionisareicationofamessagethatwassenttoaproxyandintercepted.Eachinterceptioncontainseverythingneededtoswapinthereceiveroftheinterceptedinvocationi.e.,theproxythatforwardedtheinterception,thereceiverandthearguments.MareaHandlertriggerstheswapinofthegraphassociatedwiththeproxy(bydelegatingtotheObjectGraphImporterandpassingtheproxyasparameter)thatforwardedtheinterceptionandthenitforwardstothejustswapped-inobjectthemessageinterceptedbytheproxy.9.2RequiredReectiveEntryPointsAlthoughimplementingawholeOGSusuallyrequiresdevelopmentonthevirtualmachinesideorevenattheOSlevel,ourimplementationreliesonthedefaultPharoVM.Nevertheless,MareatakesadvantageofthefollowingreectivefeaturesandhooksprovidedbytheVMandthelanguage.Objectreplacement:theprimitiveObject»become:anotherObjectatomicallyswapsthereferencesofthereceiverandtheargument.AllreferencesintheentiresystemthatJournalofObjectTechnology,vol.12,no.1,2013 22MarianoMartinezPeck,NouryBouraqadi,MarcusDenker,StéphaneDucasse,LucFabresse9.3UsingLowMemoryFootprintProxiesMarea'sgoalistoreducethememoryfootprintofapplications.However,Mareaitselfusesproxies,whichalsooccupymemory.Ghostalreadyreducesthememoryfootprintofproxiesbutwereduceditevenmore.CompactClasses.WetakeadvantageofthePharointernalobjectrepresentation:wede-clareourproxyclassesascompact.InPharo,upto32classescanbedeclaredascompactclasses.Ina32bitssystem,compactclassinstances'objectheadersareonly4byteslonginsteadofthe8bytesthatapplytoinstancesofregularclasses.ReducingInstanceVariablesinProxies.Secondly,weencodetheproxyinstancevari-ablespositionandgraphIDinoneuniqueproxyID.TheproxyIDisaSmallIntegerwhichuses15bitsforthegraphIDand16bitsfortheposition.SinceSmallIntegerareimmediateobjects16,wedonotneedanobjectheaderfortheproxyID.Withtheseoptimizations,aninstanceofProxyisonly8bytes(4fortheheaderand4fortheproxyID).ByusingsmallintegersforproxyIDs,wehavealimitof32767forthegraphIDand65535fortheposition.Still,Mareamayexceedthoselimits.Pharocanrepresentintegerswithanarbitrarylargenumberofdigits.However,insteadofusingSmallIntegerswhichareimmediateobjects,itusesinstancesoftheclassLargePositiveIntegerwhichareplainobjectsandhenceoccupymorememory.Nevertheless,LargePositiveIntegerisacompactclasssoitsinstanceshaveasmallheader.10Discussion10.1MareaEvaluationoverRequirementsandDesiderataThefollowingistheevaluationofMareaoverthelistedrequirements:EfcientObject-BasedSwappingUnit.First,Marea'sswappingunitconsistofob-jects.Second,itdoesnotswapobjectsindividuallybutgraphsofobjects.Thisgener-atesfewobjectfaultsandwhenswappingin,itloadsfewunnecessaryobjects.Uniformity.Mareacanhandleallkindsofobjectswhethertheyrepresentcode,run-timeentities,applicationdata,etc.AutomaticSwappingIn.Assoonasaswappedobjecthappenstobeneeded,itisautomaticallyswappedin.Automaticswappingout.Currently,Mareaonlyprovidesasmallandsimpleproto-type.Section12explainsthatthisisthenaturalfutureworkofthisdissertation.Transparency.Fromthepointofviewofanapplication,MareaistransparentinthesensethattheapplicationwillgetthesameresultswhetheritisusingMareaornot.Fromtheapplication'sdevelopmentpointofview,theapplicationcodeisnotpollutedwithcoderelatedtoswapping.Instead,Marea'scodeistotallydecoupledfromtheapplication.However,thereisthetriggeringoftheswappingoutiftheuserwantstodoitwhenanapplication-leveleventoccurs.Andhereoverthedesiderata: 16InSmalltalk,immediateobjectsareobjectsthatareencodedinamemoryaddressanddonotneedanobjectheader.InPharo,integersareimmediateobjects.JournalofObjectTechnology,vol.12,no.1,2013 24MarianoMartinezPeck,NouryBouraqadi,MarcusDenker,StéphaneDucasse,LucFabresse(anObject==anotherObject)ifTrue:[selfdoSomething]ifFalse:[selfdoSomethingDifferent]ImaginethatanObjectisreplacedbyaproxy,i.e.,allobjectsinthesystemwhichwerereferringtothetarget(anObject),willnowrefertotheproxy.Sinceallreferenceshavebeenupdated,==18continuestoanswercorrectly.Forinstance,ifanotherObjectwasthesameobjectasanObject,==answerstruesincebotharereferencingtheproxynow.Iftheywerenotthesameobject,==answersfalse.SpecialProxies.Someobjectscanbereplacedbutonlybyproxiesthatrespectcertainshape.Forexample,duringmethodlookup,thePharoVMdirectlyaccessessomeinstancevariablesofobjectsrepresentingclasses.GhostproxiessolvethisproblembycreatingspecialproxiesforclassesandmethodsthatrespecttheshapeneededbytheVM.ObjectReplacementinPharo.TheobjectreplacementinPharoisdonebyusingtheprim-itivebecome:whichscansthewholememorytoswapallreferencestothereceiverandtheargument.Additionally,Pharoprovidesa“bulkbecome”thatreplacesmultipleobjectsatthesametime.Mareausesabulkbecometoconvertalltheproxiesofagraph.Thatway,wepaythememorytraversalonlyonce.WhileperformingthebenchmarksdescribedinSection8,wemeasuredthetimeofthebulkbecomeforeachgraphandwecalculatedwhichpercentageofthetotalswappingtimeitrepresents.Wendoutthat,onaverage,thisprimitivetakesabout60%ofthetotalswappingtime.ThisfullmemorytraversalisnotneededbyMareaitselfanditisactuallyacurrentlim-itationofPharo.Infact,otherSmalltalkdialectsprovideafastbecomee.g.,VisualWorksandGemStone.Thismeansthatifthelanguageprovidesafastbecome,alltheoverheadmeasuredinSection8willdecrease%60,i.e.,Mareawillbe%60faster.10.3MessagesThatSwapInLotsofObjectsHavingclassesandmethodsasrst-classobjectsofferssolidreectivecapabilities.However,somesystemqueriesaccessallclassesormethodsinthesystem,thatmaycausetheswapinofmanyoftheswappedoutgraphs.Atypicalexampleiswhenaprogrammerasksforallthesendersofacertainmessage.Thesystemsendsmessagestoallobjectsthatareinthemethoddictionariesofclassescausingtheswapiniftheyhappentobeproxies.Thisscenarioandmostofthesimilaroneshappenduringapplicationdevelopment.AsMareaisintendedtoreducememoryfordeployedapplications,thisisnotusuallyaproblem.Still,weidentiedthefollowingpossiblesolutions.ExplicitVerication.ThissolutionwasintroducedbyImageSegment(anobjectswapperdevelopedbyD.IngallsforSqueak[IKM+97]).Itmodiesalargeamountofqueriesofthebasesystemtoexplicitlycheckwhichobjectsareinmemoryandonlyperformactionsonthem.Theimplementationissimple:onemethodisInMemorydenedinProxyreturnsfalseandonemethodinObjectreturnstrue.Inothercases,ImageSegmentswapsinthegraph,sendsthemessagetotheobjectsthatwerejustswappedinandthenitswapsthemoutagain.Anexampleofthisiswhenaclasschangesitsshapeanditsswappedinstancesneedtobeupdated.ThistypeofsolutionraisesthequestionofthetransparencyofanOGS. 18InPharothemessage==answerswhetherthereceiverandtheargumentarethesame.JournalofObjectTechnology,vol.12,no.1,2013 Marea:AnEfcientApplication-LevelObjectGraphSwapper27afewproxiesthatactastriggerstoautomaticallyswapinneededobjects.Ourproposaldiscussespotentialissuesandhowtohandlethem.Thisincludessituationswheredifferentgraphssharingsomeobjectsareswappedinandoutseparatelyinanarbitraryorder.OurimplementationofMareademonstratesthatwecanbuildafastapplication-levelOGS.ThankstosomefunctionalitiesofthePharovirtualmachinelike“objectreplacement”wewereabletoimplementMareawithoutmodifyingtheVMyetwithacleanobject-orienteddesign.ItalsoallowedustovalidateempiricallyoursolutionbyexperimentingMareawithdifferentreal-worldapplications.Wehavefocusedonmeasuringtheefciencyanduseful-nessofit.Ourbenchmarksdemonstratethatthememoryfootprintofdifferentapplicationscanbereducedfrom23%to36%.AnaturalfollowuptothisworkistoautomatetheprocessofswappingoutgraphsandtobuildanautomaticsystemforfreeingmainmemoryontopofMarea.Rightnowwehaveasimpleprototypethateverycertainamountoftimerandomlyselectsobjectsandchecksifthoseobjectsareunused.Ifanobjectisunused,thenMareacontinuesanalyzingitstransitiveclosure(subgraph).Ifalltheobjectsofthesubgraphareunused,Mareaswapsoutthegraph.Inthisprototypeeachobjecthasaagtomarkitasunusedandwithacustomizedvirtualmachine,weturnontheagwhentheobjectisused.Everycertainperiodoftime,theagsofallobjectsarereset.Thechallengetoimplementabetterautomaticswappingoutstrategyistodetectgraphsofunusedyetreferencedobjectswhicharegoodcandidatestobeswappedout.Firstandforemost,weneedtoanswerthequestion:howtoidentifyunusedobjects?Afterusinganobject(e.g.,messagereception),howlongshouldthesystemwaitbeforeconsideringitasunused?Besides,differentcriteriashouldbeconsideredtoselectgraphstoswapoutsuchas:thegraph'ssize,thepercentageofunusedobjectsorthepercentageofobjectssharedwithothergraphs.Anotherinterestingdirectiontoexploreistherelationshipbetweenobjectgraphswappingandgarbagecollection.Couldtheytakeadvantageoneoftheother?Cantheyreusethesamememorytraversal?Cantheysharetheinformationoragsstoredinobjectheaders?OneofthecurrentlimitationsofMareaiswhenagraphchangeswhilebeingswappedout.Allouralgorithmstoswapandtheserializationdonotworkproperlywhenthegraphchangesinthemiddleoftheoperation.ThisisbecauseMareaisimplementedatthelanguagesideandthereforeitisnotatomic.Weplantostudythisproblemandanalyzepossiblesolutions.AcknowledgmentsWethankIgorStasenkoforhishelpwiththediscussionsanddevelop-mentofMarea,MartinDiasforhisworkonFuelserializerandEstebanLorenzanoforhishelpwiththeexperimentsandbenchmarkswithSeasideandPier.References[AM95]MalcolmAtkinsonandRonaldMorrison.Orthogonallypersistentobjectsystems.VLDBJOURNAL,4:319–401,1995.[BDN+09]AndrewP.Black,StéphaneDucasse,OscarNierstrasz,DamienPollet,DamienCas-sou,andMarcusDenker.PharobyExample.SquareBracketAssociates,Kehrsatz,Switzerland,2009.URL:http://pharobyexample.org/.[BM08]MichaelD.BondandKathrynS.McKinley.Toleratingmemoryleaks.InGailE.Harris,editor,OOPSLA:Proceedingsofthe23rdAnnualACMSIGPLANConferenceonObject-OrientedProgramming,Systems,Languages,andApplications,October19-23,2008,Nashville,TN,USA,pages109–126.ACM,2008.URL:http://doi.acm.org/10.1145/1449764.1449774.JournalofObjectTechnology,vol.12,no.1,2013 Marea:AnEfcientApplication-LevelObjectGraphSwapper29[HFB05]MatthewHertz,YiFeng,andEmeryD.Berger.Garbagecollectionwithoutpaging.InProceedingsofthe2005ACMSIGPLANconferenceonProgramminglanguagedesignandimplementation,PLDI'05,pages143–153,NewYork,NY,USA,2005.ACM.doi:10.1145/1065010.1065028.[HMB90]AntonyL.Hosking,J.EMoss,andCynthiaBliss.Designofanobjectfaultingper-sistentSmalltalk.Technicalreport,UniversityofMassachusetts,Amherst,MA,USA,1990.[IKM+97]DanIngalls,TedKaehler,JohnMaloney,ScottWallace,andAlanKay.Backtothefuture:ThestoryofSqueak,apracticalSmalltalkwritteninitself.InProceedingsofthe12thACMSIGPLANconferenceonObject-orientedprogramming,systems,languages,andapplications(OOPSLA'97),pages318–326.ACMPress,November1997.URL:http://www.cosc.canterbury.ac.nz/~wolfgang/cosc205/squeak.html,doi:10.1145/263700.263754.[Kae86]TedKaehler.Virtualmemoryonanarrowmachineforanobject-orientedlanguage.ProceedingsOOPSLA'86,ACMSIGPLANNotices,21(11):87–106,November1986.doi:10.1145/28697.28707.[KLVA93]KeithKrueger,DavidLoftesness,AminVahdat,andThomasAnderson.Toolsforthedevelopmentofapplication-specicvirtualmemorymanagement.InProceedingsOOPSLA'93,ACMSIGPLANNotices,volume28,pages48–64,October1993.doi:10.1145/165854.165867.[KST96]EdwardJ.Klimas,SuzanneSkublics,andDavidA.Thomas.SmalltalkwithStyle.Prentice-Hall,1996.[LL82]H.LevyandP.H.Lipman.VirtualmemorymanagementintheVAX/VMSoperat-ingsystem.IEEEComputer,16(3):35,March1982.doi:10.1109/MC.1982.1653971.[MBMZ00]AlonsoMarquez,StephenMBlackburn,GavinMercer,andJohnZigman.Imple-mentingorthogonallypersistentJava.InInProceedingsoftheWorkshoponPersistentObjectSystems(POS,pages218–232,2000.[MPBD+10a]MarianoMartinezPeck,NouryBouraqadi,MarcusDenker,StéphaneDucasse,andLucFabresse.Experimentswithafastobjectswapper.InSmalltalks2010,Con-cepcióndelUruguay,Argentina,2010.URL:http://rmod.lille.inria.fr/archives/workshops/Mart10b-Smalltalks2010-Swapper-ImageSegments.pdf.[MPBD+10b]MarianoMartinezPeck,NouryBouraqadi,MarcusDenker,StéphaneDucasse,andLucFabresse.Visualizingobjectsandmemoryusage.InSmalltalks2010,Con-cepcióndelUruguay,Argentina,2010.URL:http://rmod.lille.inria.fr/archives/workshops/Mart10a-Smalltalks2010-VisualizingUnusedObjects.pdf.[MPBD+11]MarianoMartinezPeck,NouryBouraqadi,MarcusDenker,StéphaneDucasse,andLucFabresse.EfcientproxiesinSmalltalk.InProceedingsofESUGInternationalWorkshoponSmalltalkTechnologies(IWST'11),Edinburgh,Scotland,2011.URL:http://rmod.lille.inria.fr/archives/workshops/Mart11a-IWST11-Ghost.pdf,doi:10.1145/2166929.2166937.[MPBD+12]MarianoMartinezPeck,NouryBouraqadi,StéphaneDucasse,LucFabresse,andMar-cusDenker.Ghost:Auniformandgeneral-purposeproxyimplementation(submitted+passedrstreviewround).JournalofScienceofComputerProgramming(SCP),October2012.[NDG05]OscarNierstrasz,StéphaneDucasse,andTudorGîrba.ThestoryofMoose:anagilereengineeringenvironment.InMichelWermelingerandHaraldGall,editors,Proceed-ingsoftheEuropeanSoftwareEngineeringConference,ESEC/FSE'05,pages1–10,NewYorkNY,2005.ACMPress.Invitedpaper.URL:http://scg.unibe.ch/archive/papers/Nier05cStoryOfMoose.pdf,doi:10.1145/1095430.1081707.[Sta82]JamesWilliamStamos.Alargeobject-orientedvirtualmemory:Groupingstrategies,measurements,andperformance.TechnicalReportSCG-82-2,XeroxPaloAltoRe-searchCenter,PaloAlto,California,may1982.JournalofObjectTechnology,vol.12,no.1,2013 30MarianoMartinezPeck,NouryBouraqadi,MarcusDenker,StéphaneDucasse,LucFabresse[Ung84]DaveUngar.Generationscavenging:Anon-disruptivehighperformancestoragereclamationalgorithm.ACMSIGPLANNotices,19(5):157–167,1984.doi:10.1145/390011.808261.[Ung95]DavidUngar.Annotatingobjectsfortransporttootherworlds.InProceedingsofthetenthannualconferenceonObject-orientedprogrammingsystems,languages,andapplications,OOPSLA'95,pages73–87,NewYork,NY,USA,1995.ACM.doi:10.1145/217838.217845.[WWH87]IforWilliams,MarioWolczko,andTrevorHopkins.Dynamicgroupinginanobject-orientedvirtualmemoryhierarchy.InJ.Bézivin,J-M.Hullot,P.Cointe,andH.Lieberman,editors,ProceedingsECOOP'87,volume276ofLNCS,pages79–88,Paris,France,June1987.Springer-Verlag.[YBK+06]TingYang,EmeryD.Berger,ScottF.Kaplan,J.Eliot,andB.Moss.Cramm:Virtualmemorysupportforgarbage-collectedapplications.InInUSENIXSymposiumonOperatingSystemsDesignandImplementation,pages103–116,2006.JournalofObjectTechnology,vol.12,no.1,2013