IBMJava如何做到高性能GC的实现内幕
2008-01-05 08:44:10 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚悢鍏尖拻閻庨潧澹婂Σ顔剧磼閻愵剙鍔ょ紓宥咃躬瀵鎮㈤崗灏栨嫽闁诲酣娼ф竟濠偽i鍓х<闁绘劦鍓欓崝銈囩磽瀹ュ拑韬€殿喖顭烽幃銏ゅ礂鐏忔牗瀚介梺璇查叄濞佳勭珶婵犲伣锝夘敊閸撗咃紲闂佺粯鍔﹂崜娆撳礉閵堝洨纾界€广儱鎷戦煬顒傗偓娈垮枛椤兘骞冮姀銈呯閻忓繑鐗楃€氫粙姊虹拠鏌ュ弰婵炰匠鍕彾濠电姴浼i敐澶樻晩闁告挆鍜冪床闂備胶绮崝锕傚礈濞嗘挸绀夐柕鍫濇川绾剧晫鈧箍鍎遍幏鎴︾叕椤掑倵鍋撳▓鍨灈妞ゎ厾鍏橀獮鍐閵堝懐顦ч柣蹇撶箲閻楁鈧矮绮欏铏规嫚閺屻儱寮板┑鐐板尃閸曨厾褰炬繝鐢靛Т娴硷綁鏁愭径妯绘櫓闂佸憡鎸嗛崪鍐簥闂傚倷鑳剁划顖炲礉閿曞倸绀堟繛鍡樻尭缁€澶愭煏閸繃宸濈痪鍓ф櫕閳ь剙绠嶉崕閬嶅箯閹达妇鍙曟い鎺戝€甸崑鎾斥枔閸喗鐏堝銈庡幘閸忔﹢鐛崘顔碱潊闁靛牆鎳愰ˇ褔鏌h箛鎾剁闁绘顨堥埀顒佺煯缁瑥顫忛搹瑙勫珰闁哄被鍎卞鏉库攽閻愭澘灏冮柛鏇ㄥ幘瑜扮偓绻濋悽闈浶㈠ù纭风秮閺佹劖寰勫Ο缁樻珦闂備礁鎲¢幐鍡涘椽閸愵亜绨ラ梻鍌氬€烽懗鍓佸垝椤栫偛绀夐柨鏇炲€哥粈鍫熺箾閸℃ɑ灏紒鈧径鎰厪闁割偅绻冨婵堢棯閸撗勬珪闁逞屽墮缁犲秹宕曢柆宥呯闁硅揪濡囬崣鏇熴亜閹烘垵鈧敻宕戦幘鏂ユ灁闁割煈鍠楅悘鍫濐渻閵堝骸骞橀柛蹇旓耿閻涱噣宕橀纰辨綂闂侀潧鐗嗛幊鎰八囪閺岋綀绠涢幘鍓侇唹闂佺粯顨嗛〃鍫ュ焵椤掍胶鐓紒顔界懃椤繘鎼圭憴鍕彴闂佸搫琚崕鍗烆嚕閺夊簱鏀介柣鎰緲鐏忓啴鏌涢弴銊ュ箻鐟滄壆鍋撶换婵嬫偨闂堟刀銏犆圭涵椋庣М闁轰焦鍔栧鍕熺紒妯荤彟闂傚倷绀侀幉锟犲箰閸℃稑妞介柛鎰典簻缁ㄣ儵姊婚崒姘偓宄懊归崶顒夋晪闁哄稁鍘奸崹鍌炲箹濞n剙濡肩紒鈧崘顔界叆婵犻潧妫欓ˉ婊堟煟閿曞倷鎲炬慨濠傤煼瀹曟帒鈻庨幒鎴濆腐婵$偑鍊戦崹褰掓晝閵堝鐓濈€广儱顦崡鎶芥煏韫囨洖啸妞ゆ柨顦靛娲箹閻愭彃濮堕梺鍛婃尰閻熲晠骞冨鈧獮搴ㄦ嚍閵壯冨箰闂備礁鎲¢崝鎴﹀礉鎼淬垺娅犻柡鍥╁Х绾惧ジ鏌嶈閸撶喎鐣峰鈧崺鐐村緞閸濄儳娉块梻鍌氣看閸嬪嫬煤閵堝悿褰掓倻閸撳灝娲弫鍐焵椤掑嫭绠掓繝鐢靛Т閿曘倝鎮ц箛娑欏仼婵炲樊浜濋悡娑㈡倶閻愰鍤欏┑鈥炽偢閺屽秶鎲撮崟顐や紝閻庤娲栧畷顒勫煝鎼淬倗鐤€闁规儳顕Σ妤冪磽閸屾艾鈧悂宕愰悜鑺モ挃鐎广儱顦粈澶愬箹鏉堝墽鍒伴柛銊︾箖閵囧嫰寮介顫捕婵℃鎳樺娲川婵犲啫顦╅梺鎼炲妽婢瑰棛鍒掓繝姘闁兼亽鍎遍埀顒傛暬閺屻劌鈹戦崱娆忓毈缂備降鍔忓Λ鍕箒闂佺粯枪瀹曠敻鎮鹃悜妯诲弿濠电姴鍟妵婵囦繆椤愩垹鏆欓柍钘夘槸閳诲酣骞囬鐐╁亾閻戣姤鈷戦悹鍥ㄥ絻椤掋垽鏌i褍娅嶇€规洩绻濋獮搴ㄦ嚍閵夈儰绮ф俊鐐€栧ú宥夊磻閹惧灈鍋撶憴鍕闁绘牕銈搁妴浣肝旀担鍝ョ獮闁诲函缍嗛崑鍛存偟椤愨懇鏀介柣妯诲墯閸熷繘鏌涢敐搴$仯鐎垫澘锕畷婊嗩槷闁稿鎸剧划顓炩槈濡粯鎮欑紓浣哄У閻擄繝寮诲☉銏犖ㄦい鏃傚帶椤晠姊洪挊澶婃殶闁哥姵鐗犲濠氭晲婢跺﹥顥濋梺鍦圭€涒晠宕伴幇鐗堚拺闁煎鍊曢弸搴g磽瀹ュ拑韬€殿喛顕ч埥澶愬煑閳规儳浜鹃柨鏇炲€哥粻锝嗙節闂堟稒宸濆ù婊庝簼娣囧﹪鎮欓鍕ㄥ亾閵堝绀堟繛鍡樻尰閸嬪鏌涢埄鍐枔闁逞屽墯濡啫鐣峰鈧、娆撳床婢诡垰娲ょ粻鍦磼椤旂厧甯ㄩ柛瀣崌閹崇娀顢楅埀顒勫吹椤掑倻纾介柛灞捐壘閳ь剟顥撳▎銏ゆ晸閻樿尙鐛ュ┑掳鍊曢幊搴g不娴煎瓨鐓欓梻鍌氼嚟閸斿秹鏌涚€Q勬珚闁哄矉缍侀獮瀣晲閸♀晜顥夌紓浣鸿檸閸樻悂宕戦幘缁樷拻濞达綀娅g敮娑㈡煕閺冣偓濞叉粎鍒掗弮鍫燁棃婵炵娅曢惄顖氱暦濮椻偓椤㈡瑩宕楅崗澶规岸姊绘笟鈧埀顒傚仜閼活垱鏅堕鐐寸厪闁搞儜鍐句純濡ょ姷鍋炵敮锟犵嵁鐎n亖鏀介柟閭︿簽绾惧姊虹拠鍙夊攭妞ゎ偄顦甸獮鎰槹鎼达絿鐒兼繛鎾村焹閸嬫捇鏌涢埡鍐ㄤ槐妤犵偛顑夐弫鍌炴寠婢跺鐫忛梻鍌欑濠€杈╁垝椤栨粍鏆滈柍鍝勫€搁閬嶆煃瑜滈崜娑氭閹惧瓨濯撮柣鐔告緲婵垽鎮峰⿰鍕棆闁稿鍠栧畷姘跺箳閹存梹鐎婚梺瑙勫劤閻ゅ洭骞楅弴鐐╂斀闁绘劖娼欓悘锕傛煟椤撗冩灈闁宠绮欓、鏃堝醇閻斿搫骞嶉梺鑽ゅ枑閻熴儳鈧凹鍓氶幈銊╁炊閵婏絼绨婚梺闈涱檧婵″洨绮婚悙瀛樺弿濠电姴鍟妵婵嬫煛鐏炶姤鍤囬柟顔界懇閹崇姷鎹勬笟顖欑磾婵犵數濮幏鍐磼濮橆剛銈梻浣告惈閻ジ宕伴弽顓炵鐟滅増甯╅弫鍐煥濠靛棙鍣介柨娑欐崌濮婄粯鎷呴悷閭﹀殝缂備浇顕х€氭澘鐣烽幋婵冩闁靛繒濮烽崢鎾⒑閻熼偊鍤熷┑顕呭弮瀹曟垿骞樼紒妯绘珳闁圭厧鐡ㄩ敋濞存粎鍋撻妵鍕箻鐎电硶濮囧┑鐐叉噹閿曨亪寮婚敍鍕勃闁伙絽鐫楅敐鍡欑缁炬澘褰夐柇顖涱殽閻愯尙绠冲ù鐙呯畵閹稿﹥寰勬繝鍛缚闂傚倸鍊搁崐鐑芥倿閿曞倹鍎戠憸鐗堝笒绾惧綊鏌¢崶銉ョ仼缂佺姷濞€閺岀喖鏌囬敃鈧弸鐔搞亜椤愶絾绀嬮柡宀€鍠栭獮鍡氼槾闁圭晫濮撮埞鎴︻敍濞戞瑥鍞夐梺鍝勬湰閻╊垶鐛鈧鍫曞箣閻樼偣鍋¢梻鍌欑閹诧繝骞愮粙璺ㄦ殾妞ゆ帒瀚ч埀顒佹瀹曟﹢顢欓崲澹洦鐓曢柍鈺佸枤濞堟ê霉閻樿櫕鍊愭慨濠冩そ閹筹繝濡堕崨顔界槪闂備礁鎼幊蹇涙儎椤栫偛绠栧Δ锝呭暞閸婂鏌﹀Ο鐚寸礆闁靛ě鍕瀾婵犮垼鍩栭崝鏇犲婵犳碍鐓欓柛鎾楀懎绗¢梺鍝勬噺閻擄繝鐛弽顐㈠灊闁荤喐婢橀埛澶愭⒑鐠囪尙绠扮紒澶屾嚀椤繘鎼归崷顓狅紲濠碘槅鍨甸褔妫勫鍛斀闁绘劖褰冪痪褔鏌ㄩ弴妯虹仾濞e洤锕幃鐣岀矙鐠侯煈妲规俊鐐€栭悧妤€顫濋妸鈺傚仾闁逞屽墴濮婂宕掑顑藉亾閹间焦鍋嬪┑鐘插閻瑩鏌熼柇锕€鏋﹀┑顔藉▕閺屻倕霉鐎n偅鐝栫紒鐐礃濡嫰婀侀梺鎸庣箓閻楀﹪藟婢舵劖鐓熼柟鐐綑婵牓鏌熸笟鍨閾伙絿绱掔€n亞浠㈡い顒€顑呴埞鎴﹀灳閸愯尙楠囬梺鍛婃⒐閻熲晠鎮伴鍢夌喖宕楅悡搴e酱闂備浇鍋愰埛鍫ュ礈閿曗偓鍗卞ù鐓庣摠閳锋帒霉閿濆毥褰掑汲闁秵鐓欑痪鏉垮船娴滄壆鈧娲橀崝鏍崲濠靛柊鎺旂矙閹稿骸鏋犻悗娈垮枦閸╂牠骞嗛弮鍫濈閻庢稒蓱濠㈡垵鈹戦敍鍕杭闁稿﹥鐗曢~蹇旂節濮橆儵銉╂倵閿濆簼鎲鹃柛鐔锋嚇閺屾洘寰勫☉婊咁槹婵炲瓨绮嶇划宥夊Φ閸曨垰绠婚悹楦挎〃缁泛鈹戦埄鍐ㄧ祷妞ゎ厾鍏樺濠氭晲婢跺娅滈梺鎼炲劀閸愩劎顓哄┑掳鍊楁慨鐑藉磻閻愬灚鏆滈柨鐔哄Х瀹撲線鎮楅敐搴℃灈缂侇偄绉归弻宥堫檨闁告挾鍠栭獮鍐ㄎ旀担铏圭槇濠殿喗锕╅崢鎼佸箯濞差亝鐓熼柣鏂挎憸閹冲啴鎮楀鐓庡籍鐎规洘娲栬灃闁告侗鍠氶崢鍗炩攽閳藉棗鐏ラ柕鍡忓亾闂佺ǹ顑嗛幑鍥箖閵忋倕绠甸柟鐑樺灩闂冣偓濠电姷鏁告慨鐑藉极閸涘﹥鍙忛柣鎴f閺嬩線鏌涘☉姗堟敾闁告瑥绻橀弻锝夊箣閿濆棭妫勯梺鍝勵儎缁舵岸寮诲☉妯锋婵鐗婇弫楣冩⒑閸涘﹦鎳冪紒缁樺灴婵$敻宕熼姘鳖啋闂佸憡顨堥崑鐔哥閼测晝纾奸柣鎰靛墮閸斻倖銇勯鐘插幋鐎殿喖顭烽幃銏ゆ偂鎼达綆妲堕柣鐔哥矊缁绘帡寮灏栨闁靛骏绱曢崢鎾绘⒒娴e摜浠㈡い鎴濇嚇閹﹢鏁冮崒娑氬帾闂佹悶鍎滈崘鍙ョ磾婵°倗濮烽崑鐐垫暜閳ュ磭鏆﹂柛妤冨剱濞撳鏌熼鍡楁湰椤ワ紕绱撻崒姘偓鎼佸磹閹间礁纾瑰瀣捣閻棗銆掑锝呬壕闁芥ɑ绻堝娲敆閳ь剛绮旈幘顔煎嚑濞达絿纭堕弨浠嬫煟濡寧鐝柣銊﹀灩閳ь剝顫夐幐椋庢濮樿泛钃熸繛鎴欏灩閻掓椽鏌涢幇鍏哥按濠殿喖娲铏圭矙閸栤€冲闂佺ǹ绻戦敃銏狀嚕鐠囨祴妲堟俊顖炴敱閺傗偓闂備胶纭堕崜婵嬨€冭箛鏂款嚤闁逞屽墯娣囧﹪鎮欓鍕ㄥ亾閺嵮屾綎鐟滅増甯掔粈澶愭煛閸ャ儱鐏╅柣鎾达耿閺岀喐娼忔ィ鍐╊€嶉梺绋匡工椤兘寮诲☉銏犖ㄩ柕蹇婂墲閻濇牠鏌″蹇曠瘈婵﹦绮幏鍛村川婵犲倹娈橀梻浣告贡鏋い顓犲厴楠炲啴鎮滈懞銉︽珕闂佷紮绲芥径鍥绩閾忣偆绡€闁汇垽娼у瓭濠电偠顕滅粻鎾崇暦閻㈢ǹ绀冩い鏃傛櫕閸樻捇姊洪崨濠勭畵閻庢凹鍓熷鎶芥偄閸忚偐鍙嗗┑鐐村灦閻熝囨儗閹烘挻鍙忓┑鐘叉川缁变即鏌曢崶銊ュ妤犵偞甯¢獮瀣堪閸愨晝鈧娊姊婚崒娆戭槮闁硅绻濋幃鐑藉Ψ閿旂粯顔旈梺褰掓?缁€渚€鎮″┑瀣厵闁绘劦鍓氶悘閬嶆煕椤愵偂閭柡灞剧洴椤㈡洟濡堕崨顔句簴闂備礁鎲¤摫闁诡喖鍊垮濠氭晲閸垻鏉搁梺鍝勬川閸嬫﹢骞嬫搴g<缂備降鍨归獮鏍煟閺嶎偄甯堕柣锝囧厴楠炲鏁冮埀顒傜不婵犳碍鍋i柛銉簻閻ㄦ椽鏌i妶鍌氫壕濠电姷鏁搁崑鐘诲箵椤忓棗绶ゅù鐘差儏缁犵喖鏌ㄩ悢鍝勑㈢痪鎹愵潐閵囧嫰寮介顫勃闂佹娊鏀遍崹褰掓儉椤忓牜鏁囬柣鎰綑濞咃絾绻涚€涙ḿ鐭婄紓宥咃躬楠炲啰鎹勭悰鈩冾潔闂佸搫璇為崘銊愭洟姊绘担铏广€婇柡鍌欑窔瀹曟垿骞橀幇浣瑰瘜闂侀潧鐗嗗Λ妤冪箔閹烘鐓曢柣鏇氱娴滀即鏌熼姘殭閻撱倖銇勮箛鎾村櫧闁告ê鎲$换娑欐綇閸撗冨煂濠电姭鍋撻弶鍫涘妽濞呯姵銇勮箛鎾跺闁绘挸鍟撮幃宄扳枎韫囨搩浠奸梺璇茬箲閹告娊寮婚悢纰辨晩闁伙絽鏈崳浼存倵濞堝灝鏋涢柣鏍с偢閻涱喚鈧綆鍠楅崑鎰板级閸偆鍘涢柡浣告喘濮婂宕掑顑藉亾妞嬪海鐭嗗ù锝夋交閼板潡寮堕崼娑樺濞寸姵宀稿缁樻媴娓氼垱鏁繝娈垮枔閸婃宕氶幒鎾村劅闁靛ǹ鍎抽ˇ顐︽⒑閸︻厼鍔嬫い銊ユ噽閻氭儳顓兼径瀣幈濡炪倖鍔戦崐鏇㈠几鎼粹埗褰掓偐閻戞﹩浠╃紓浣介哺閹稿骞忛崨鏉戠闁圭粯甯掓竟宥嗕繆閻愵亜鈧牕煤濡崵绠惧┑鐘叉搐閺嬩線鏌涢幇闈涙灈缁炬儳鍚嬬换娑㈠箣閻愯泛顥濆Δ鐘靛仜閻楁挸顫忕紒妯诲闁告稑锕ラ崕鎾斥攽閻愯尙婀撮柛銊ㄦ閻e嘲鈹戦崱娆愭畷闂佸憡娲﹂崜娆撳焵椤掆偓閻栧ジ寮婚敐鍛傜喖鎳栭埡浣侯偧闂備胶绮幐璇裁洪悢鐓庤摕闁绘柨鍚嬮崵瀣亜閹哄棗浜炬繝纰夌磿閸樠囨箒濠电姴锕ょ€氼剟宕濋妶澶嬬厓閻熸瑥瀚悘鎾煛娴e摜效鐎规洜鍠栭、鏇㈠焺閸愨晝绐旈梻鍌氬€烽懗鑸电仚闂佹寧娲忛崕鐢稿箖瑜旈幃鈺呮嚑椤掍焦顔曟繝鐢靛█濞佳囶敄閸℃稑鐤炬繝闈涱儐閻撳啰鎲稿⿰鍫濈闁绘梻鍘ч悘鎶芥煥閺囩偛鈧悂鏌ㄩ妶鍡曠箚闁靛牆鍊告禍楣冩⒑缂佹ê绗掗柣蹇斿哺婵$敻宕熼姘鳖唺閻庡箍鍎遍悧鍡涘储閿涘嫮纾藉ù锝呮惈瀛濇繝鈷€鍌滅煓闁糕斁鍋撳銈嗗坊閸嬫捇鏌涘Ο鑽ょ煉鐎规洘鍨块獮姗€寮妷锔芥澑闂備胶绮灙濞存粠鍓涚划锝夊籍閸喓鍘遍柣搴秵閸嬫帒鈻撻弮鍫熺厓閻熸瑥瀚悘瀛樸亜閵忥紕鎳呮繛鎴犳暬閹粓鎮剧仦钘夊唨婵犵數濮烽弫鎼佸磻濞戙垹绠柟瀵稿Т缁躲倝鏌涢…鎴濇殠闁挎繂顦粻娑㈡煛婢跺孩纭舵い鏂匡躬濮婃椽鎮烽弶鎸庢瘣缂佸墽铏庨崣鍐ㄧ暦娴兼潙绠婚悹鍥皺椤斿棝姊虹紒妯剁細缂侇噮鍨跺畷鐢稿箣閿旂晫鍘剧紓浣割儓濞夋洘绂掑☉娆愬弿闁挎繂妫楁慨宥嗘叏婵犲偆鐓肩€规洘甯掗~婵嬵敄閽樺澹曢梺缁樺灱婵倝宕甸崟顖涚厾闁告縿鍎查弳鈺伱归悩宕囶暡缂佺粯绻堥幃浠嬫濞戞鎹曟俊鐐€栧ú锕傚矗閸愩劎鏆︽俊銈傚亾閾伙絽銆掑鐓庣仩婵炲牄鍔岄—鍐Χ閸℃顫囬梺绋匡攻閻楁粓鍩€椤掍胶顣叉慨妯稿姂閸┾偓妞ゆ帒鍊归崵鈧繝銏㈡嚀閿曨亜鐣锋导鏉戝唨鐟滃寮搁弮鍫熺厪濠电姴绻愰々顒傜磼閳锯偓閸嬫捇姊绘担鍦菇闁搞劏妫勫玻鑳槼闁绘娴风槐鎾存媴閸濆嫪澹曞┑鐘灪宀h法鍒掗弮鍫熷仭闂侇叏绠戝▓銊╂⒑閸濆嫯顫﹂柛搴や含缁鎮介崨濠勫幍闂佺粯鍨跺玻璺ㄧ不濮椻偓閺屾盯鎮欓崹顐f瘓闂佸搫鐭夌紞渚€骞冮埡鍛€绘慨妤€妫旈崫妤呮⒑鐠囪尙绠扮紒璇茬墦瀹曟繂鐣濋崟鍨櫓闂婎偄娲︾粙鎴濇暜闁荤喐绮岄ˇ闈涚暦閹达箑绠婚柤鎼佹涧閺嬪倿姊洪崨濠冨闁告挻鐟ч崰濠傤吋閸涱亝鏂€闂佸疇妫勫Λ妤佺濠靛牏纾奸悹鍥ㄥ絻閳ь剙娼¢弫鎰版倷閸撲胶鏉稿┑鐐村灦閻燂箓宕曢鍫熲拺闂傚牃鏅涢惁婊堟煕濮椻偓缁犳牠寮鍛牚闁告劧绲鹃弬鈧梻浣哥枃濡嫬螞濡ゅ懏鍊堕柣妯肩帛閻撴瑧鐥弶鍨埞濞存粈鍗抽弻銊モ攽閸繀绮跺銈嗘尭閵堢ǹ鐣烽崼鏇炵厸闁告劘娉曢梻顖涚節閻㈤潧浠╅柟娲讳簽缁辩偞绗熼埀顒冩"闂佽宕橀褏绮堟径灞稿亾楠炲灝鍔氭い锔垮嵆閹€斥枎閹寸姷锛滈柣搴秵娴滅偞绂掗姀銈嗙厸闁糕剝绋愰幉楣冩煛瀹€瀣М闁轰焦鍔欏畷鎯邦槻妤犵偛顑呰灃闁绘﹢娼ф禒婊勩亜閹存繍妯€鐎殿噮鍋婂畷姗€顢欓懖鈺佸Е婵$偑鍊栫敮鎺楀磹缂佹ḿ鈻旂€广儱鎳夐弨浠嬫煟濡櫣锛嶆い锝嗙叀閺屾稓鈧絽澧庣粔顕€鏌$仦鍓ф创濠碉紕鍏橀獮瀣攽閸℃ɑ顔嶅┑掳鍊楁慨鏉懨洪銏犵畺婵°倕鍟崰鍡涙煕閺囥劌澧痪鏉跨Ф缁辨挻鎷呴崜鍙壭ч梺鐟版啞婵炲﹪宕规ィ鍐ㄧ睄闁割偅绻勯ˇ銊ヮ渻閵堝棙鐓ユ俊鎻掔墣椤﹀綊鏌$仦鍓ф创闁糕晛瀚板畷妤呮偑閳ь剚绂嶉鍕庢盯宕熼顐㈡倯闂佹悶鍎弲婵嬫晬濠靛洨绠鹃弶鍫濆⒔閸掓澘顭块悷甯含鐎规洘娲熼獮鍥偋閸垹骞堥梻渚€娼ф灙闁稿酣浜堕妴鍌氱暦閸モ晝锛滃銈嗘⒒閳峰牓宕曡箛鏂讳簻闁规儳鍟块幃鎴犫偓鍨緲鐎氼噣鍩€椤掑﹦绉靛ù婊勭墵瀹曟垿骞樼紒妯煎弳闁诲函绲婚崝瀣姳婵犳碍鈷戦柣鐔哄閹牏绱掓径濠勫煟閽樻繈鏌ㄩ弮鍫熸殰闁稿鎸搁埢鎾诲垂椤旂晫浜梻浣筋嚙缁绘垹鎹㈤崼銉ユ槬闁绘劕鎼粻锝夋煥閺囨浜鹃梺缁樻惈缁绘繈寮诲☉銏犵労闁告劗鍋撻悾鍏肩箾鐎电ǹ顎岄柛銊ㄦ硾椤繐煤椤忓嫬绐涙繝鐢靛Т濞寸兘宕濋崼鏇熲拺闁告稑锕ユ径鍕煕濞嗗繘顎楅悡銈夋煕濞戞﹫姊楃紒璇叉閺屾洟宕煎┑鍫㈩唺闂佸憡甯婇崡鎶藉蓟濞戙垺鍋嗗ù锝呮憸娴犳悂鎮楃憴鍕闁告梹鐟ラ悾鐤亹閹烘繃鏅濋梺鎸庣箓閹冲孩瀵兼惔銏㈢瘈缁剧増蓱椤﹪鏌涢妸锕€鈻曠€规洏鍨奸ˇ宕囩磼閸屾氨校闁靛牞缍佸畷姗€鍩℃担鎻掍壕闁割煈鍋呴崣蹇斾繆椤栨粌甯跺ù婊堢畺閹顫濋悙顒€顏�

核心提示:IBM JVM的GC分为三个步骤,Mark phase(标记),Sweep phase(清扫),Compaction phase(内存紧缩). 在了解这些过程之前,IBMJava如何做到高性能GC的实现内幕,我们先看一下IBMjava中的对象的Layout和Heap lay out 一个Java对象在IBM vm中的结
IBM JVM的GC分为三个步骤,Mark phase(标记),Sweep phase(清扫),Compaction phase(内存紧缩). 在了解这些过程之前,我们先看一下IBMjava中的对象的Layout和Heap lay out 一个Java对象在IBM vm中的结构如下
1.size+flags
2.mptr
3.locknflags
4.objectdata
size+flags
这是一个4byte的slot(32 平台)。这个slot的主要功能就是描述对象的尺寸。由于IBMJava中的对象都是以8byte的倍数分配的,因此对象的尺寸其实就是真实尺寸/8存放在4byte的slot中。另外在这个slot的低三位是保留字段起到标记对象的作用。他们分别为 bit1:swapped bit,这个交换位被用于Compaction phase即内存紧缩阶段使用。同时 这一位在标记堆栈溢出的时候(mark stack overflow)也被用于标记NotYetScanned状态. bit2:dosed bit.这个位用于标示这个对象是否被某个堆栈或者寄存器reference到了。
假如这个标志被至位则这个对象就不能在当前的GC cycle中被删除。而且假如某个reference指向的内存不是一个真实的reference比如是一个简单的float 或者integer变量但是它的值恰巧就是Heap中某个Object的地址的时候,我们就不能修改这个refernece。这种对象的bit2也被置为1。bit3:pinned bit。标记一个对象是否是一个一个钉扣对象(PINNED object)。一个Pinned Object也不能被GC删除,因为他们可能在Heap之外被reference到了。典型的一个例子就是Thread,还记得我上面说的僵死县城么?它不能被删除的道理就是这个。另外一种PinnedObject就是 JNI Object,即被本地代码使用的对象。
Mptr:
在32平台上也是4byte的slot。Mptr有两个功能,
1。假如mptr不是一个数组,则Mptr指向一个方法块(method block),你可以通过这个method block来得到一个类块(class block)。这个类块,告诉你这个Object是属于哪个class的实例。method block和class block由Class Loader分配,而不是heap在heap中进行分配
2。假如mptr是一个数组(Array),mptr包含了这个对象中,数组的元素个数。 lockflags
在32平台上也是4byte的slot,但是这个slot只有低4位被用到。
bit2:是array flag.假如这个位被置位,那么这个对象就是一个数组同时mptr字段就包含了数组的元素个数。
bit4是hashed和moved bit.假如这个位被置位,那么他就告诉我们这个对象在被hashed以后被删除了。
Object Data:
就是这个对象本身的数据
Heap layout:
heap top
heap limit
heap base
heap base是heap的起始地址,heap top是heap的结束地址。heaplimit 是当前程序使用的那段heap可以进行扩展和收缩的极限。你可以用-Xmx参数在java运行的时候对heap top和heap base进行控制。
Alloc bits 和 mark bits
heap top allocmax markemax
heap limit alloc size marksize
heap base
上面这个结构描述了heap和alloc bits 以及,markbits之间的关系。allocbits和markbits都是元素为1个bit的vector。他们与heap有同样的长度,下面是两个对象被分配以后在heap和两个vector中的表现
heaptop allocmax markmax
heaplimit allocsize marksize
object2top
.
.
object2base object2allocbit object2markbit
object1top
.
object1base object1allocbit
如上面的结构,假如一个对象在heap被alloc出来,那么在allocbits中就标示出这个对象的起始地址所在的地址。allocbits中只标记起始地址。但是这个过程告诉我们这个对象在那里被创建,但是不告诉我们这个对象是否存活。当在mark phase中假如某一个对象比如object2仍然存活,那么就在markbits中对应的地址上标记一下The free list
IBM jvm中的空闲块用用一个free list链标示。如图
freechunck1 freechunck2 freechunckn
size size size
next------------->next--->.........next--->NULL
freeStorage freeStorage freestorge
有了这些基本概念我们来看看Mark phase的工作情况
MarkPhase
GC的Mark phase将标记所有还活着的对象。这个标记所有可达对象的过程称为tracing。Jvm的活动状态(active state)是由下面几个部分组成的。1.每个线程的保存寄存器(saved registers)2.描述线程的堆栈3.Java类中的静态元素3.以及局部和全局的JNI(Java Native Interface)引用。在Jvm中的方法调用都在C Stack上引发一个Frame。这个Frame包含了,对象实例,为局部变量的assignment结果或者传入方法的参数。所有这些引用在Tracing过程中都被同等对待。实际上,我们可以把一个线程的堆栈看城一系列4-bytes slot的集合,然后对每一个堆栈都从顶向下对这些slot进行扫描。在扫描的过程中都必须校验每个slot是否指向heap当中的一个真实的对象。因为在前面我就说过,很有可能这些slot值仅仅是一个int或float但是他们的值恰巧就等于heap中的一个对象地址。因此在扫描的时候必须相当的保守,扫描的时候必须保证所有的指针都是一个对象,而且这个对象没有在GC中被删除。只有符合下面条件的slot才是一个指向对象的指针。1.必须以8-byte的倍数分配的内存2.必须在heap的范围之内(即大于heapbase小于heaptop)3.对应的allocbit必须置为1。满足这些条件的对象引用我们称为roots,并且把他们的dosed bit置为1表示不能被GC删除。我想大家已经知道C#中为何连Int和Float都是OBject的原因了吧。在C#中因为都是OBject因此,在tracing的过程中就减少了一次校验。这个减少对性能起到很大的影响。 假如扫描完成,那么Tracing过程便能安全精确的执行。也就是说我们可以在roots中通过reference找到他对应的objects,由于他们是真实的reference,那么我们就能够在compactionphase中移动对应的对象并且修改这些reference。
Trace过程使用了一个可以容纳4k的slots的stack。所有的引用逐个push进入这个堆栈并且同时在markbits中进行标记。当push和mark的工作完成之后,我们开始pop出这些slot并且进行trace。
常规的对象(非数组对象)将通过mptr去访问classblock,classblock将会告诉我们从这个对象中找到的其他对象的reference在那里?当我们在classblock找到一个refernce以后,假如发现他没有被mark,那么我们就在markallocbits中mark他然后把他再压入堆栈。
数组对象利用mptr去访问每个数组元素,假如他们没有mark则mark然后压入堆栈。
Trace过程一直持续进行,直到堆栈为空。
MarkStack OverFlow
由于markStack限制了尺寸,因此它可能会溢出。假如溢出发生,那么我们就设定一个全局的标志来表明发生了MarkStack OverFlow,然后我们将那些不能push入stack的OBject的bit1设定为NotYetScanned。然后当tracing过程完成以后,检验全局标志假如发现有overflow则把NotYetScanned的对象再次压入堆栈开始新的tracing过程。
并行Mark(Parallel Mark)
由于使用逐位清扫(bitwise sweep)和内存紧缩规避功能,GC将化大部分的时间是用于Mark而非前面两项。这就导致了IBM JVM需要开发一个GC的并行版本。并行GC的目的不是以牺牲单CPU系统上的效能来换取在4,8路对称CPU系统上的高效率。
并行Mark的基本思想就是通过多个辅助线程(helper thread)和一个共享工作的工具来减少Marking的时间。在单CPU系统中,执行GC工作的只有一个主线程。Parallel mark仍然需要这个主线程的参与,他充当了治理协调的角色。这个Thread所要执行的工作和单CPU上的一样多,包括他必须扫描C-Stack来鉴别需要收集的roots指针。一个有N路对称CPU的系统自动含有n-1个helper thread并且平均分布在每个CPU上,master thread将scan完的reference集合进行分块,然后交给helper thread独立完成mark工作。
每个Helper thread都被分配了一个独立的本地mark stack,以及一个shareable queue。sharqueue将存放help thread在mark overflow的时候的NotyetScanned对象。然后由master thread将sharequeue中的对象balance到其他已经空闲的thread上去。
并发Mark(Concurrent mark)
Concurrent mark的主要目的在于当heap增长的时候减少GC的pause time。只要heap到达heap limit的时候,Concurrent mark就会被执行。在Concurrent phase中,GC要求应用中的每个线程(不是指helper thread而是应用程序自己开启的线程以便充分利用系统资源)扫描他们自己的堆栈来得到roots。然后使用这些roots来同步的trace 可达对象。Tracing工作是由一个后台的低优先级的线程执行,同时程序自己开启的线程在分配内存的时候必须执行heap lock allocation。
由于使用程序自己开启的线程并发的执行mark live objects,我们必须纪录那些已经trace过的object的变化。这个功能是采用一个叫写闸(write barrier) 来实现的。这个写闸在每次改变引用的时候被激活。它告诉我们什么时候一个对象被跟新过了,以便我们从新扫描那部分heap。写闸的具体实现是Heap会分配出512byte的内存段每个段都分配了一个byte在卡表中(card table)。无论何时一个对象的reference被更新cardtable将同步纪录这个对象的起始地址。使用Byte而不用bit的原因是写byte要比写bit快2倍,而且我们可能希望空余的bit会在未来被用到。
当Concurrent mark执行完毕以后,STW collection(stop total world)将会被执行。stw的意思是指suspend所有程序自己开启的线程。因此我们可以看到假如使用Concurrent mark那
更多精彩
赞助商链接