计算机科学与技术Java垃圾收集器中英文对照外文翻译文献.docx

计算机科学与技术Java垃圾收集器中英文对照外文翻译文献.docx

《计算机科学与技术Java垃圾收集器中英文对照外文翻译文献.docx》由会员分享，可在线阅读，更多相关《计算机科学与技术Java垃圾收集器中英文对照外文翻译文献.docx（6页珍藏版）》请在冰豆网上搜索。

计算机科学与技术Java垃圾收集器中英文对照外文翻译文献

中英文资料外文翻译文献

原文：

HowagarbagecollectorworksofJavaLanguage

Ifyoucomefromaprogramminglanguagewhereallocatingobjectsontheheapisexpensive,youmaynaturallyassumethatJava’sschemeofallocatingeverything（exceptprimitives）ontheheapisalsoexpensive.However,itturnsoutthatthegarbagecollectorcanhaveasignificantimpactonincreasingthespeedofobjectcreation.Thismightsoundabitoddatfirst—thatstoragereleaseaffectsstorageallocation—butit’sthewaysomeJVMswork,anditmeansthatallocatingstorageforheapobjectsinJavacanbenearlyasfastascreatingstorageonthestackinotherlanguages.

Forexample,youcanthinkoftheC++heapasayardwhereeachstakesoutitsownpieceofturfobject.Thisrealestatecanbecomeabandonedsometimelaterandmustbereused.InsomeJVMs,theJavaheapisquitedifferent;it’smorelikeaconveyorbeltthatmovesforwardeverytimeyouallocateanewobject.Thismeansthatobjectstorageallocationisremarkablyrapid.The“heappointer”issimplymovedforwardintovirginterritory,soit’seffectivelythesameasC++’sstackallocation.（Ofcourse,there’salittleextraoverheadforbookkeeping,butit’snothinglikesearchingforstorage.）

Youmightobservethattheheapisn’tinfactaconveyorbelt,andifyoutreatitthatway,you’llstartpagingmemory—movingitonandoffdisk,sothatyoucanappeartohavemorememorythanyouactuallydo.Pagingsignificantlyimpactsperformance.Eventually,afteryoucreateenoughobjects,you’llrunoutofmemory.Thetrickisthatthegarbagecollectorstepsin,andwhileitcollectsthegarbageitcompactsalltheobjectsintheheapsothatyou’veeffectivelymovedthe“heappointer”closertothebeginningoftheconveyorbeltandfartherawayfromapagefault.Thegarbagecollectorrearrangesthingsandmakesitpossibleforthehigh-speed,infinite-free-heapmodeltobeusedwhileallocatingstorage.

TounderstandgarbagecollectioninJava,it’shelpfullearnhowgarbage-collectionschemesworkinothersystems.Asimplebutslowgarbage-collectiontechniqueiscalledreferencecounting.Thismeansthateachobjectcontainsareferencecounter,andeverytimeareferenceisattachedtothatobject,thereferencecountisincreased.Everytimeareferencegoesoutofscopeorissettonull,thereferencecountisdecreased.Thus,managingreferencecountsisasmallbutconstantoverheadthathappensthroughoutthelifetimeofyourprogram.Thegarbagecollectormovesthroughtheentirelistofobjects,andwhenitfindsonewithareferencecountofzeroitreleasesthatstorage（however,referencecountingschemesoftenreleaseanobjectassoonasthecountgoestozero）.Theonedrawbackisthatifobjectscircularlyrefertoeachothertheycanhavenonzeroreferencecountswhilestillbeinggarbage.Locatingsuchself-referentialgroupsrequiressignificantextraworkforthegarbagecollector.Referencecountingiscommonlyusedtoexplainonekindofgarbagecollection,butitdoesn’tseemtobeusedinanyJVMimplementations.

Infasterschemes,garbagecollectionisnotbasedonreferencecounting.Instead,itisbasedontheideathatanynon-deadobjectmustultimatelybetraceablebacktoareferencethatliveseitheronthestackorinstaticstorage.Thechainmightgothroughseverallayersofobjects.Thus,ifyoustartinthestackandinthestaticstorageareaandwalkthroughallthereferences,you’llfindalltheliveobjects.Foreachreferencethatyoufind,youmusttraceintotheobjectthatitpointstoandthenfollowallthereferencesinthatobject,tracingintotheobjectstheypointto,etc.,untilyou’vemovedthroughtheentireWebthatoriginatedwiththereferenceonthestackorinstaticstorage.Eachobjectthatyoumovethroughmuststillbealive.Notethatthereisnoproblemwithdetachedself-referentialgroups—thesearesimplynotfound,andarethereforeautomaticallygarbage.

Intheapproachdescribedhere,theJVMusesanadaptivegarbage-collectionscheme,andwhatitdoeswiththeliveobjectsthatitlocatesdependsonthevariantcurrentlybeingused.Oneofthesevariantsisstop-and-copy.Thismeansthat—forreasonsthatwillbecomeapparent—theprogramisfirststopped（thisisnotabackgroundcollectionscheme）.Then,eachliveobjectiscopiedfromoneheaptoanother,leavingbehindallthegarbage.Inaddition,astheobjectsarecopiedintothenewheap,theyarepackedend-to-end,thuscompactingthenewheap（andallowingnewstoragetosimplybereeledofftheendaspreviouslydescribed）.

Ofcourse,whenanobjectismovedfromoneplacetoanother,allreferencesthatpointattheobjectmustbechanged.Thereferencethatgoesfromtheheaporthestaticstorageareatotheobjectcanbechangedrightaway,buttherecanbeotherreferencespointingtothisobjectInitialization&Cleanupthatwillbeencounteredlaterduringthe“walk.”Thesearefixedupastheyarefound（youcouldimagineatablethatmapsoldaddressestonewones）.

Therearetwoissuesthatmaketheseso-called“copycollectors”inefficient.Thefirstistheideathatyouhavetwoheapsandyousloshallthememorybackandforthbetweenthesetwoseparateheaps,maintainingtwiceasmuchmemoryasyouactuallyneed.SomeJVMsdealwiththisbyallocatingtheheapinchunksasneededandsimplycopyingfromonechunktoanother.

Thesecondissueisthecopyingprocessitself.Onceyourprogrambecomesstable,itmightbegeneratinglittleornogarbage.Despitethat,acopycollectorwillstillcopyallthememoryfromoneplacetoanother,whichiswasteful.Topreventthis,someJVMsdetectthatnonewgarbageisbeinggeneratedandswitchtoadifferentscheme（thisisthe“adaptive”part）.Thisotherschemeiscalledmark-and-sweep,andit’swhatearlierversionsofSun’sJVMusedallthetime.Forgeneraluse,mark-and-sweepisfairlyslow,butwhenyouknowyou’regeneratinglittleornogarbage,it’sfast.Mark-and-sweepfollowsthesamelogicofstartingfromthestackandstaticstorage,andtracingthroughallthereferencestofindliveobjects.

However,eachtimeitfindsaliveobject,thatobjectismarkedbysettingaflaginit,buttheobjectisn’tcollectedyet.Onlywhenthemarkingprocessisfinisheddoesthesweepoccur.Duringthesweep,thedeadobjectsarereleased.However,nocopyinghappens,soifthecollectorchoosestocompactafragmentedheap,itdoessobyshufflingobjectsaround.“Stop-and-copy”referstotheideathatthistypeofgarbagecollectionisnotdoneinthebackground;Instead,theprogramisstoppedwhilethegarbagecollectionoccurs.IntheSunliteratureyou’llfindmanyreferencestogarbagecollectionasalow-prioritybackgroundprocess,butitturnsoutthatthegarbagecollectionwasnotimplementedthatwayinearlierversionsoftheSunJVM.Instead,theSungarbagecollectorstoppedtheprogramwhenmemorygotlow.Mark-and-sweepalsorequiresthattheprogrambestopped.

Aspreviouslymentioned,intheJVMdescribedherememoryisallocatedinbigblocks.Ifyouallocatealargeobject,itgetsitsownblock.Strictstop-and-copyrequirescopyingeveryliveobjectfromthesourceheaptoanewheapbeforeyoucanfreetheoldone,whichtranslatestolotsofmemory.Withblocks,thegarbagecollectioncantypicallycopyobjectstodeadblocksasitcollects.Eachblockhasagenerationcounttokeeptrackofwhetherit’salive.Inthenormalcase,onlytheblockscreatedsincethelastgarbagecollectionarecompacted;allotherblocksgettheirgenerationcountbumpediftheyhavebeenreferencedfromsomewhere.Thishandlesthenormalcaseoflotsofshort-livedtemporaryobjects.Periodically,afullsweepismade—largeobjectsarestillnotcopied（theyjustgettheirgenerationcountbumped）,andblockscontainingsmallobjectsarecopiedandcompacted.

TheJVMmonitorstheefficiencyofgarbagecollectionandifitbecomesawasteoftimebecauseallobjectsarelong-lived,thenitswitchestomark-andsweep.Similarly,theJVMkeepstrackofhowsuccessfulmark-and-sweepis,andiftheheapstartstobecomefragmented,itswitchesbacktostop-and-copy.Thisiswherethe“adaptive”partcomesin,soyouendupwithamouthful:

“Adaptivegenerationalstop-and-copymark-andsweep.”

ThereareanumberofadditionalspeedupspossibleinaJVM.Anespeciallyimportantoneinvolvestheoperationoftheloaderandwhatiscalledajust-in-time（JIT）compiler.AJITcompilerpartiallyorfullyconvertsaprogramintonativemachinecodesothatitdoesn’tneedtobeinterpretedbytheJVMandthusrunsmuchfaster.Whenaclassmustbeloaded（typically,thefirsttimeyouwanttocreateanobjectofthatclass）,the.classfileislocated,andthebytecodesforthatclassarebroughtintomemory.Atthispoint,oneapproachistosimplyJITcompileallthecode,butthishastwodrawbacks:

Ittakesalittlemoretime,which,compoundedthroughoutthelifeoftheprogram,canaddup;anditincreasesthesizeoftheexecutable（bytecodesaresignificantlymorecompactthanexpandedJITcode）,andthismightcausepaging,whichdefinitelyslowsdownaprogram.Analternativeapproachislazyevaluation,whichmeansthatthecodeisnotJITcompileduntilnecessary.Thus,codethatnevergetsexecutedmightneverbeJITcompiled.TheJavaHotspottechnologiesinrecentJDKstakeasimilarapproachbyincreasinglyoptimizingapieceofcodeeachtimeitisexecuted,sothemorethecodeisexecuted,thefasteritgets.

译文：

Java垃圾收集器的工作方式

如果你学下过一种因为在堆里分配对象所以开销过大的编程语言，很自然你可能会假定Java在堆里为每一样东西（除了primitives）分配内存资源的机制开销也会很大。

不过，事实上垃圾收集器能够深刻影响对象的加速创建。

一开始听起来有些奇怪——存贮空间的释放会影响存贮空间的分配，但是这的确是一些JVMs的工作方式，并且这意味着J