Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
2Activity
0 of .
Results for:
No results containing your search query
P. 1
Dynamic Memory Allocator Review

Dynamic Memory Allocator Review

Ratings: (0)|Views: 106|Likes:
Published by ipas

More info:

Published by: ipas on Nov 10, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

02/22/2014

pdf

text

original

 
DynamicStorageAllocation: ASurveyandCriticalRevie
??
PaulR.Wilson,MarkS.Johnstone,MichaelNeely,andDavidBole
??
DepartmentofComputerScienceUniversityofTexasatAustiAustin,Texas,78751,USA 
wilson|markj|neely@cs.utexas.edu 
Abstract
Dynamicmemoryallocatiohasbeenafundamentalpartofmostcomputersystemssinceroughly1960,andmemoryallocationiswidelyconsideredtobeeitherasolvedproblemoraninsolubleone.Ithissurvey,wedescribeavarietyofmemorallocatordesignsandpointoutissuesrele- vanttotheirdesignandevaluation.Wethen chronologicallysurveymostofthelitera- tureonallocatorsbetween1961and1995.(Scoresofpapersarediscussed,invarying detail,andover150referencesaregiven.Wearguethatallocatordesignshavebeeundulyrestrictedbyanemphasisonmech- anism,ratherthanpolicy,whilethelatterimoreimportant;higher-level 
strategic 
issues arestillmoreimportant,buthavenotbeegivenmuchattention.Mosttheoreticalanalysesandempiricalallocatorevaluationstodatehavereliedon verystrongassumptionsofrandomnessand independence,butrealprogrambehavior exhibitsimportantregularitiesthatmustbexploitedifallocatorsaretoperformwellipractice.
Aslightlydierentversionofthispaperappeari
Proc.1995Int'l.WorkshoponMemoryManagement 
Kinross,Scotland,UK,September27{29,1995, SpringerVerlagLNC
.Thisversiondiersinseveral veryminorrespects,mainlyinformatting,correctionof severaltypographicalandeditingerrors,claricationof afewsentences,andadditionofafewfootnotesancitations.
?
ThisworkwassupportedbytheNationalScienceFoun- dationundergrantCCR-9410026,andbyagiftfrom Novell,Inc.
??
ConvexComputerCorporation,Dallas,Texas,USA.(dboles@zeppelin.convex.com
1Introduction 
Inthissurvey,wewilldiscussthedesignandevalua- tionofconventionaldynamicmemoryallocators.B\conventional,"wemeanallocatorsusedforgeneral purpose\heap"storage,wheretheaprogramcanrequestablockofmemorytostoreaprogramobject,andfreethatblockatanytime.Aheap,inthissense,isapoolofmemoryavailablefortheallocationand deallocationofarbitrary-sizedblocksofmemoryinarbitraryorder.
Anallocatedblockistypicallyusedtstoreaprogram\object,"whichissomekindofstruc- tureddataitemsuchasaPascalrecord,aCstruct,oraC++object,butnotnecessarilyanobjectinthe senseofobject-orientedprogramming.
Throughoutthispaper,wewillassumethatwhilablockisinusebyaprogram,itscontents(adatobject)cannotberelocatedtocompactmemory(as isdone,forexample,incopyinggarbagecollectorWil95]).Thisistheusualsituationinmostimplementationsofconventionalprogrammingsystem(suchasC,Pascal,Ada,etc.),wherethememormanagercannotndandupdatepointerstoprogram objectswhentheyaremoved.
Theallocatordoesnot 
Thissenseof\heap"isnottobeconfusedwithaquitdierentsenseof\heap,"meaningapartiallyordered treestructure.
Whilethisisthe 
typical 
situation,itisnottheonlone.The\objects"storedbytheallocatorneednocorresponddirectlytolanguage-levelobjects.Anexampleofthisisagrowablearray,representedbyaxesizepartthatholdsapointertoavariable-sizedpart.Theroutinethatgrowsanobjectmightallocateanew,largervariable-sizedpart,copythecontentsoftheolvariable-sizedpartintoit,anddeallocatetheoldpart.Weassumethattheallocatorknowsnothingofthis,and wouldvieweachofthesepartsasseparateandindepen- dentobjects,evenifnormalprogrammerswouldsee\single"object.
Itisalsotrueofmanygarbage-collectedsystems.I
 
examinethedatastoredinablock,ormodifyoraconitinanyway.Thedataareaswithinblocksthatarusedtoholdobjectsarecontiguousandnonoverlap- pingrangesof(realorvirtual)memory.Wegenerallassumethatonlyentireblocksareallocatedorfreed,andthattheallocatorisentirelyunawareofthetype oforvaluesofdatastoredinablock|itonlyknowthesizerequested.
Scopeofthissurvey
Inmostofthissurvey,wewilconcentrateonissuesofoverallmemoryusage,rather thantimecosts.Webelievethatdetailedmeasuresof timecostsareusuallyaredherring,becausetheyob- scureissuesofstrategyandpolicy;webelievethat mostgoodstrategiescanyieldgoodpoliciesthat areamenabletoecientimplementation.(Webelievethatit'seasiertomakeaveryfastallocator thanaverymemory-ecientone,usingfairlystraightforwardtechniques(Section3.12).Beyondacertaipoint,however,theeectivenessofspeedoptimiza- tionswilldependonmanyofthesamesubtleissuethatdeterminememoryusage.Wewillalsodiscusslocalityofreferenceonlybriey.Localityofreferenceisincreasinglyimportant,asthe dierencebetweenCPUspeedandmainmemory(odisk)speedshasgrowndramatically,withnosignof stopping.Localityisverypoorlyunderstood,however;asidefrommakingafewimportantgeneralcomments,weleavemostissuesoflocalitytofutureresearch.Exceptwherelocalityissuesareexplicitlynoted,weassumethatthecostofaunitofmemoryisxeanduniform.Wedonotaddresspossibleinteractions withunusualmemoryhierarchyschemessuchascompressedcaching,whichmaycomplicatelocalityissues andinteractinotherimportantwayswithallocator designWLM91,Wil91,Dou93].Wewillnotdiscussspecializedallocatorsforpartic- ularapplicationswherethedatarepresentationsand allocatordesignsareintertwined.
some,insucientinformationisavailablefromthecompilerand/orprogrammertoallowsaferelocation;thisiespeciallylikelyinsystemswherecodewrittenindierentlanguagesiscombinedinanapplicationBW88].Iothers,real-timeand/orconcurrentsystems,itisdifcultforthegarbagecollectortorelocatedatawith- outincurringundueoverheadand/ordisruptivenesWil95].
Examplesinludespecializedallocatorsforchained- blockmessage-buers(e.g.,Wol65]),\cdr-coded"listprocessingsystemsBC79],specializedstorageforoverlappingstringswithsharedstructure,andallocator
Allocatorsforthesekindsofsystemssharemany propertieswiththe\conventional"allocatorswediscuss,butintroducemanycomplicatingdesignchoices.Inparticular,theyoftenallowlogicallycontiguouitemstobestorednon-contiguously,e.g.,inpiecesof oneorafewxedsizes,andmayallowsharingofpartor(other)formsofdatacompression.Weassumethat ifanyfragmentingorcompressionofhigher-level\ob jects"happens,itisdoneabovethelevelofabstrac- tionoftheallocatorinterface,andtheallocatorisen- tirelyunawareoftherelationshipsbetweenthe\ob-  jects"(e.g.,fragmentsofhigher-levelobjects)thatimanages.Similarly,parallelallocatorsarenotdiscussed,due tothecomplexityofthesubject.
Structureofthepaper
Thissurveyisintendedtservetwopurposes:asageneralreferencefortech- niquesinmemoryallocators,andasareviewofthe literatureintheeld,includingmethodologicalcon- siderations.Muchoftheliteraturereviewhasbeeseparatedintoachronologicalreview,inSection4.Thissectionmaybeskippedorskimmedifmethodologyandhistoryarenotofinteresttothereader,especiallyonarstreading.However,somepoten- tiallysignicantpointsarecoveredonlythere,oronlmadesucientlyclearandconcretethere,sotheseriousstudentofdynamicstorageallocationshouldnd itworthwhile.(Itmayevenbeofinteresttothosinterestedinthehistoryandphilosophyofcomputescience,asdocumentationofthedevelopmentofascienticparadigm.
Theremainderofthecurrentsectiongivesourmo- tivationsandgoalsforthepaper,andthenframethecentralproblemofmemoryallocation| 
fragmen- tatio
|andthegeneraltechniquesfordealingwitit.Section2discussesdeeperissuesinfragmentation,andmethodologicalissues(someofwhichmaybe skipped)instudyingit.Section3presentsafairlytraditionaltaxonomyof 
usedtomanagediskstorageinlesystems.
Weuse\paradigm"inroughlythesenseofKuhKuh70],asa\patternormodel"forresearch.The paradigmswediscussarenotasbroadinscopeasthe onesusuallydiscussedbyKuhn,butonourreading,hiideasareintendedtoapplyatavarietyofscales.WearnotnecessarilyinagreementwithallofKuhn'sideas,orwithsomeoftheextremeandanti-scienticpurposes theyhavebeenputtobysomeothers.
 
knownmemoryallocators,includingseveralnotusu- allycovered.Italsoexplainswhysuchmechanismbasedtaxonomiesareverylimited,andmayobscurmoreimportantpolicyissues.Someofthosepolicissuesaresketched.Section4reviewstheliteratureonmemoryallocation.Amajorpointofthissectionisthatthemaistreamofallocatorresearchoverthelastseveraldecadeshasfocusedonoversimplied(andunrealisticmodelsofprogrambehavior,andthatlittleisactu- allyknownabouthowtodesignallocators,orwhat performancetoexpect.Section5concludesbysummarizingthemajor pointsofthepaper,andsuggestingavenuesforfuturresearch.
TableofContent
1Introduction 
::::::::::::::::
1.1Motivation 
:::::::::::::::
1.2WhatanAllocatorMustD
:::::
1.3Strategies,PlacementPolicies,and SplittingandCoalescing 
:::::
Strategy,policy,andmechanism.
:::
Splittingandcoalescing.
::::::::
2ACloserLookatFragmentation,and HowtoStudyI
::::::::::::::
2.1InternalandExternalFragmentation 
:
2.2TheTraditionalMethodology:Proba- bilisticAnalyses,andSimulation UsingSyntheticTrace
:::::
Randomsimulations.
::::::::::
1Probabilisticanalyses.
:::::::::
1Anoteonexponentially-distributerandomlifetimes.
:::::::::
1AnoteonMarkovmodels.
::::::
12.3WhatFragmentationReallyIs,anWhytheTraditionalApproachiUnsound 
:::::::::::::
1Fragmentationiscausedbyisolatedeaths.
:::::::::::::::
1Fragmentationiscausedbytimevaryingbehavior.
:::::::::
1Implicationsforexperimentalmethod- ology.
::::::::::::::::
12.4SomeRealProgramBehavior
::::
1Ramps,peaks,andplateaus.
:::::
1Fragmentationatpeaksisimportant.17 Exploitingorderingandsizedepen- dencies.
::::::::::::::
1Implicationsforstrategy.
:::::::
1Implicationsforresearch.
:::::::
1Prolesofsomerealprograms.
::::
1Summary.
::::::::::::::::
22.5DeferredCoalescingandDeferredReuse22 Deferredcoalescing.
::::::::::
2Deferredreuse.
:::::::::::::
22.6ASoundMethodology:SimulationUsingRealTrace
::::::::::
2Tracingandsimulation.
::::::::
2Localitystudies.
::::::::::::
2
3ATaxonomyofAllocator
:::::::
23.1AllocatorPolicyIssues 
:::::::::
23.2SomeImportantLow-LevelMechanisms27 Headereldsandalignment.
:::::
2Boundarytags.
:::::::::::::
2Linkeldswithinblocks.
:::::::
2Lookuptables.
:::::::::::::
2Specialtreatmentofsmallobjects.
::
2Specialtreatmentoftheendblockof theheap.
::::::::::::::
23.3BasicMechanism
:::::::::::
33.4SequentialFit
:::::::::::::
33.5DiscussionofSequentialFitsandGen- eralPolicyIssues.
::::::::
33.6SegregatedFreeList
:::::::::
33.7BuddySystem
:::::::::::::
33.8IndexedFit
::::::::::::::
4Discussionofindexedts.
:::::::
43.9BitmappedFit
::::::::::::
43.10DiscussionofBasicAllocatorMecha- nisms.
:::::::::::::::
43.11QuickListsandDeferredCoalescing 
:
4Schedulingofcoalescing.
:::::::
4Whattocoalesce.
:::::::::::
4Discussion.
:::::::::::::::
43.12ANoteonTimeCost
:::::::::
4
4AChronologicalReviewofTheLiterature 
:::::::::::::::::::::
44.1Therstthreedecades:1960to199
:
41960to1969.
::::::::::::::
41970to1979.
::::::::::::::
51980to1990.
::::::::::::::
54.2RecentStudiesUsingRealTrace
::
6Zorn,Grunwald,etal.
:::::::::
6Vo.
:::::::::::::::::::
6Wilson,Johnstone,Neely,andBoles.
:
6

Activity (2)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->