Precise Memory Leak Detection for Java Software Using Container Profiling

Distinguishd Papr Prcis Mmory Lak Dtction for Java Softwar Using Containr Profiling Guoqing Xu Atanas Rountv Dpartmnt of Computr Scinc and Enginring Ohio Stat Univrsity {xug,rountv}@cs.ohio-stat.du ABSTRACT A mmory lak in a Java program occurs whn objct rfrncs that ar no longr ndd ar unncssarily maintaind. Such laks ar difficult to undrstand bcaus static analyss typically cannot prcisly idntify ths rdundant rfrncs, and xisting dynamic analyss for lak dtction track and rport fin-graind information about individual objcts, producing rsults that ar usually hard to intrprt and lack prcision. W introduc a novl containr-basd hap-tracking tchniqu, basd on th obsrvation that many mmory laks in Java programs occur du to containrs that kp rfrncs to unusd data ntris. Th novlty of th dscribd work is two-fold: (1) instad of tracking arbitrary objcts and finding laks by analyzing rfrncs to unusd objcts, th tchniqu tracks only containrs and dirctly idntifis th sourc of th lak, and (2) th approach computs a confidnc valu for ach containr basd on a combination of its mmory consumption and its lmnts stalnss (tim sinc last rtrival), whil prvious approachs do not considr such combind mtrics. Our xprimntal rsults show that th rports gnratd by th proposd tchniqu can b vry prcis: for two bugs rportd by Sun and for a known bug in SPECjbb, th top containrs in th rports includ th containrs that lak mmory. Catgoris and Subjct Dscriptors D.2.4 [Softwar Enginring]: Softwar/Program Vrification Rliability; D.2.5 [Softwar Enginring]: Tsting and Dbugging Dbugging aids Gnral Trms Rliability, Prformanc, Masurmnt, Exprimntation Kywords Mmory laks, containr profiling, laking confidnc This matrial is basd upon work supportd by th National Scinc Foundation undr grant CCF-0546040. Prmission to mak digital or hard copis of all or part of this work for prsonal or classroom us is grantd without f providd that copis ar not mad or distributd for profit or commrcial advantag and that copis bar this notic and th full citation on th first pag. To copy othrwis, to rpublish, to post on srvrs or to rdistribut to lists, rquirs prior spcific prmission and/or a f. ICSE 08, May 10 18, 2008, Lipzig, Grmany. Copyright 2008 ACM 978-1-60558-079-1/08/05...$5.00. 1. INTRODUCTION Whil garbag-collctd languags can rduc mmoryrlatd bugs such as dangling pointrs, programs writtn in ths languags can still suffr from mmory laks causd by kping rfrncs to uslss objcts. Laks dgrad runtim prformanc and significant laks vn caus th program to run out of mmory and crash. In addition, mmory lak bugs ar notoriously difficult to find. Static analyss can b usd to attmpt th dtction of such laks. Howvr, this dtction is limitd by th lack of scalabl and prcis rfrnc/hap modling, as wll as by rflction, multipl thrads, scalability for larg programs, tc. Thus, in practic, idntification of mmory laks is mor oftn attmptd with dynamic analyss. Existing dynamic approachs for hap diagnosis hav srious limitations. Commrcial tools such as JProfilr [13] and JProb [12] wr dvlopd to hlp undrstand typs, instancs, and mmory usag. Howvr, this information is insufficint for programmrs to locat a bug. For xampl, in most cass, th fact that typ java.util.hashmap$entry has th highst numbr of instancs tlls th programmr nothing about th hash maps that hold ths ntris. Rsarch tools for mmory lak dtction typically focus on hap diffrncing [3, 4, 14] and fin-graind objct tracking [1, 8, 7, 20]. Of xisting dynamic tchniqus, LakBot [17], Cork [14], and Sligh [1] rprsnt th stat of th art. Both Lak- Bot and Cork us hap growth as a huristic, which could rsult in fals positivs (growing typs ar not ncssarily tru laks). Sligh, on th othr hand, uss stalnss (tim sinc last us) to find laks. This approach could lad to imprcision as wll. As an xampl, a fram in a Java Swing program cannot b tratd as a lak, although it may nvr b usd aftr it is cratd. In addition, largr objcts that ar lss stal may hav gratr contribution towards th lak. For xampl, mor attntion should b paid to a big containr that is not usd for a whil than to a nvr-usd string. Furthrmor, ths xisting tools follow a traditional from-symptom-to-caus approach that starts from tracking all objcts and finds thos that could potntially b uslss (symptom). It thn tris to find th laking data structur (caus) by analyzing dirct and transitiv rfrncs to ths uslss objcts. Howvr, th complx run-tim rfrnc rlationships among objcts in modrn Java softwar significantly incrass th difficulty of locating th sourc of th lak, which could lad to imprcis lak rports. It bcoms vn hardr to find th caus of a lak if thr ar multipl data structurs that ar contributing to th problm. For xampl, as rportd in [14], it took th authors a 151

B-Tr Transaction-containr HashMap ArrayList HashSt Obj... Obj Obj... Obj Obj... Figur 1: Containr hirarchy in Java. significant amount of tim to find th sourcs of laks aftr thy xamind th rports gnratd by Cork. Our proposal. W propos a novl tchniqu for Java that dtcts mmory laks using containr profiling. Arguably, misus of (usr-dfind or Java built-in) containrs is a major sourc of mmory lak bugs in ral-world Java applications. For xampl, many of th mmory lak bugs rportd in th Sun bug rpository [23] wr causd, dirctly or indirctly, by inappropriat us of containrs. Th ky ida bhind th proposd tchniqu is to track oprations on containrs rathr than on arbitrary objcts, and to rport containrs that ar most likly to lak. Th major diffrnc btwn our tchniqu and th from-symptom-to-caus diagnosis approach is that w start by suspcting that all containrs ar laking, and thn us th symptoms to rul out most of thm. Hnc, w avoid th procss of symptomto-caus sarching that can lad to imprcision and rducd programmr productivity. Figur 1 shows th containr hirarchy typically usd in a Java program: usr-dfind containrs in th top layr us containrs providd by th Java collction framwork (th middl layr), which vntually stor data in arrays (th bottom layr). Th focus of our tchniqu ar containrs in th first and scond layrs, bcaus in most cass ths containrs ar dirctly manipulatd by programmrs and hnc mor likly to b sourcs of laks. Arrays ar not trackd; compltmntary approachs such as [21] can potntially b usd to dtct laks dirctly causd by arrays. Our tchniqu rquirs ahad-of-tim modling of containrs: usrs nd to build a simpl glu layr that maps mthods of ach containr typ to primitiv oprations (.g., ADD, GET, and REMOVE). An automatd tool instrumnts th application cod and uss th usr annotations to connct invocations of containr mthods with our run-tim profiling libraris. To writ this glu cod, usrs hav to b familiar with th containr typs usd in th program. This dos not incras th burdn on th programmrs: whn using xisting lak dtction tools [17, 1, 14], programmrs hav to inspct th cod to gain similar knowldg so that thy can intrprt th tool rports. Using our approach rquirs larning such knowldg in advanc. Of cours, th tool mbds pr-dfind modls for containrs from th Java collction framwork, and thrfor programmrs nd to modl only usr-dfind containrs. Running th tool vn without modling of usr-dfind containrs can still provid usful insights for finding laks: in our rports, top-lvl Java library containrs (i.., th scond layr in Figur 1) can dirct on s attntion to thir dirct or transitiv ownrs, which ar likly to b usr-dfind containrs (i.., th first layr in Figur 1) that ar th actual causs of bugs. Obj W comput a huristic laking confidnc valu for ach containr, basd on a combination of its mmory consumption and th stalnss of its data lmnts; this could yild mor accurat rsults compard to xisting approachs [17, 1, 14]. For ach containr, w also rank call sits in th sourc cod, basd on th avrag stalnss of th lmnts rtrivd or addd at ths sits. This containr ranking and th rlatd call sit ranking can assist a programmr to quickly idntify th sourc of th mmory lak. Th concptual modl usd to comput ths valus and our implmntation of th tchniqu for Java ar prsntd in Sction 2 and Sction 3, rspctivly. Our tool achivd high prcision in rporting causs for two mmory lak bugs from th Sun bug databas [23] and a known mmory lak bug in SPECjbb [22] in fact, th top containrs in th rports includd th ons that lakd mmory. In addition, an valuation of th run-tim prformanc showd accptabl ovrhad for practical us. Contributions. Th main contributions of this work ar: A dynamic analysis that computs a confidnc valu for ach containr, providing a basis for idntification and ranking of likly-laking containrs A mmory lak dtction tchniqu for Java basd on this confidnc analysis A tool that implmnts th proposd tchniqu An xprimntal study of lak idntification and runtim prformanc, showing that our tchniqu can prcisly dtct mmory lak bugs with practical ovrhad 2. LEAK CONFIDENCE ANALYSIS This sction prsnts a confidnc analysis that computs laking confidnc valus for trackd containrs. Th goal of th analysis is to quantify th contribution of a containr to mmory laks. A containr is an abstract data typ (ADT) with a st of data lmnts and thr basic oprations ADD, GET, and REMOVE. W us σ n to dnot a containr σ with n lmnts. Th simplifid ffcts of th oprations ar as follows (o dnots a containr lmnt): ADD(σ n,o):void σpr n σpost, n+1 o/ σpr, n o σ n+1 post GET(σ n ):o σpr n = σpost, n o σpr n REMOVE(σ n,o):void σpr n σpost, n 1 o σpr, n o/ σ n 1 post W trat all (Java library and usr-dfind) containrs as implmntations of th containr ADT. Tracking oprations on a containr rquirs usr-supplid annotations to bridg th gap btwn mthods dfind in th Java implmntations and th thr basic ADT oprations. W hav alrady dfind such annotations for th containr typs from th standard Java libraris. During th xcution of a program, lt th program s mmory consumption at a timstamp τ i b m i. In cass whn τ i is a momnt immdiatly aftr garbag collction (w will rfr to such momnts as gc-vnts), it will b dnotd by τ gc i and its mmory consumption will b dnotd by m gc i. A program writtn in a garbag-collctd languag has a mmory lak symptom within a tim rgion [τ s, τ ] if (1) for vry gc-vnt τ gc i in th rgion, m s m gc i m, and (2) in this rgion, thr xists a subsqunc ss =(τ gc 1,τgc 2,...,τgc n ) of gc-vnts, with n 2, such that τ gc j <τ gc j+1 and mgc j <m gc j+1 for j =1,...,n 1. Th priod [τ s, τ ] will b rfrrd to as a laking rgion. 152

This dfinition hlps to idntify th appropriat tim rgion to analyz, bcaus most programs do not lak from th start of xcution. End momnt τ can b spcifid by tool usrs as an analysis paramtr, and can b diffrnt for diffrnt kinds of analyss. For post-mortm off-lin diagnosis, τ is ithr th nding tim of th program, or th tim whn an OutOfMmory rror occurrd. For on-lin diagnosis don whil th program is running, τ could b any tim at which th usr dsirs to stop data collction and to start analysis of th collctd data. W us gc-vnts as chckpoints bcaus at ths tims th program s hap mmory consumption dos not includ unrachabl objcts. Th dfinition of a mmory lak symptom dos not rquir th amount of consumd mmory at ach gc-vnt to b largr than it was at th prvious on, bcaus in many cass som gc-vnts rclaim larg amounts of mmory, whil in gnral th mmory footprint still kps incrasing. Th ratio btwn th numbr of lmnts n in th subsqunc ss and th siz of th ntir squnc of gc-vnts within th laking rgion can b dfind by tool usrs as anothr analysis paramtr, in ordr to control th lngth of th laking rgion. Givn a particular valu for this usr-dfind ratio, thr could b multipl valus of τ s corrsponding to this ratio. Our approach chooss th smallst such valu as τ s, which dfins th longst rgion and allows mor prcis analysis. (Additional dtails ar dscribd in Sction 3.) Acontainrσ is mmory-lak-fr if ithr (1) at tim τ, it is in stat σ 0 (i.., mpty), or (2) it is garbag collctd within th laking rgion. That is, σ n dos not lak mmory if at tim τ, its accumulatd numbr of ADD oprations is qual to its accumulatd numbr of REMOVE oprations, assuming w trat th dallocation of σ n as bing quivalnt to n REMOVE oprations. Containrs that ar not mmorylak-fr contribut to th mmory lak symptom and ar subjct to furthr valuations. Howvr, this dos not ncssarily man that all of thm lak mmory. For xampl, if an OutOfMmory rror occurs bfor som REMOVE oprations of a containr, this containr is not mmory-lak-fr according to th abov dfinition, although in rality it may vry wll b lak-fr. For ach containr that is not mmory-lak-fr by this dfinition, w comput a confidnc valu that indicats how larg is its contribution to th mmory lak symptom. Our tchniqu considrs both th mmory consumption and th stalnss whn computing th confidnc for a containr. Mmory contribution. On factor that charactrizs a containr s contribution to th lak is th amount of mmory th containr consums during its liftim. W quantify this factor by dfining a mmory tim graph which capturs a containr s mmory footprint. Th rlativ mmory consumption of a containr σ at tim τ is th ratio btwn th sum of th mmory consumption of all objcts rachabl from σ in its objct graph, and th total amount of mmory consumd by th program at τ. Th mmory tim graph for σ is a curv whr th x-axis rprsnts th rlativ tim of program xcution (i.., τ i/τ for timstamp τ i)andthy-axisrprsnts th rlativ mmory consumption of σ (i.., mm(σ) i/total i corrsponding to x- point τ i/τ ). Th starting point of th x-axis is τ 0/τ whr τ 0 = max(τ s, allocation tim of σ) and th nding point is τ 1/τ whr τ 1 = min(τ, dallocation tim of σ). A sampl graph is shown in Figur 2. Th x-axis starts at 0.4 rlativ tim (0.4 τ absolut tim), which rprsnts 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 0.4 0.5 0.6 0.7 0.8 0.9 1 Figur 2: A sampl mmory tim graph. ithr th starting tim of th lak rgion τ s or σ s allocation tim, whichvr occurs latr. Th graph indicats that σ is not frd within th lak rgion, bcaus th x-axis nds at 1, which rprsnts th nding tim τ of th lak rgion. Using th mmory tim graph, a containr s mmory contribution (MC) is dfind to b th ara covrd by th mmory consumption curv in th graph. In Figur 2 this ara is shown in dark. Bcaus th graph starts from τ s (or latr), th MC considrs only a containr s mmory consumption within th laking rgion. For a containr, both its mmory consumption and its liftim contribut to its MC. Sinc MC should rflct th influnc of both th containr itslf and all objcts (dirctly or transitivly) rfrncd by it, th mmory consumption of th containr is dfind as th amount of mmory consumd by its ntir objct graph. Bcaus rlativ valus (i.., btwn 0 and 1) ar usd to masur th mmory consumption and th xcution tim, th MC of a containr is also a valu btwn 0 and 1. Containrs that hav largr MC contribut mor to th mmory lak symptom. Not that in practic it is likly to b too xpnsiv to comput th xact MC valu for a containr, bcaus th containr s mmory consumption changs frquntly as th program xcuts. Sction 3 prsnts a sampling approach that can b usd to approximat this valu. Stalnss contribution. Th scond factor that charactrizs a containr s contribution is th stalnss of its lmnts. Th stalnss of an objct is dfind in [1] as th tim sinc th objct s last us. W provid a nw dfinition of stalnss in trms of a containr and its lmnts. Th stalnss of an lmnt o in a containr σ is τ 2 τ 1 whr REMOVE(σ, o) occurd at τ 2,anoprationGET(σ):o or ADD(σ, o) occurd at τ 1, and thr dos not xist anothr GET opration that rturns o in th rgion [τ 1, τ 2]. If τ 1 <τ s, τ 1 is rdfind to b τ s. If τ 2 <τ s, th stalnss is undfind. In othr words, th stalnss of o is th distanc btwn th tim whn o is rmovd from σ and th most rcnt tim whn o is rtrivd from σ. Ifo is nvr rtrivd from σ, τ 1 should corrspond to th ADD opration that adds o to σ. If o is nvr rmovd from σ, τ 2 is ithr th dallocation tim of σ, or th nding tim of th laking rgion τ. Th intuition bhind this dfinition is that if th program no longr nds to rtriv an lmnt from a containr, th lmnt bcoms uslss to that containr. Hnc, th stalnss of th lmnt masurs th priod of tim whn th lmnt bcoms uslss but is still bing kpt by th containr. In addition, tracking occurs only within th laking rgion if an lmnt s rmoval tim τ 2 is arlir than th starting tim of th laking rgion, w do not comput th stalnss for th lmnt. Th stalnss contribution (SC) of a containr σ is th ratio of ( P n i=1 stalnss(oi)/n) and(τ τs), whr th sum 153

ID Typ LC MC SC 11324773 util.hashmap 0.449 0.824 0.495 18429817 util.linkdlist 0.165 0.820 0.194 8984226 util.linkdlist 0.050 0.809 0.062 2263554 util.wakhashmap 0.028 0.820 0.034 15378471 util.linkdlist 0.018 0.029 0.256 5192610 swing.jlayrdpan 0.011 0.824 0.013 30675736 swing.jpanl 0.011 0.824 0.013 19526581 swing.jrootpan 0.011 0.824 0.013 17933228 util.hashtabl 0.000023 0.0007 0.026 Tabl 1: Partial rport of LC, MC, and SC valus. is ovr all lmnts o 1,...,o n that hav bn addd to σ and whos stalnss is wll-dfind. Thus, SC is th avrag stalnss of lmnts that hav vr bn addd to σ,rlativ to th lngth of th laking rgion. In addition, th rmoval tim of ths lmnts must b within th laking rgion. Bcaus th stalnss of ach individual lmnt is th lngth of th laking rgion, SC is a valu btwn 0 and 1. Containrs that hav largr SC valus contribut mor to th mmory lak symptom. Putting it all togthr: laking confidnc. Basd on th mmory contribution and th stalnss contribution, w dfin a containr s laking confidnc (LC) to b computd as SC MC 1 SC. Clarly, LC is a valu btwn 0 and 1; also, incrasing ithr SC or MC whil kping th othr factor unchangd incrass LC. W dfin LC as an xponntial function of SC to show that stalnss is mor important than mmory consumption in dtrmining a mmory lak. This dfinition of LC has svral dsirabl proprtis: MC=0 and SC [0, 1] LC=0. If th mmory contribution of a containr is small nough (i.., clos to 0), th confidnc of this containr is clos to 0, no mattr how stal its lmnts ar. This proprty hlps filtr out containrs that hold small objcts, such as strings. SC=0 and MC [0, 1] LC=0. If vry lmnt in a containr gts rmovd immdiatly aftr it is no longr usd (i.., th tim btwn th GET and RE- MOVE oprations is clos to 0), th confidnc of this containr is 0, no mattr how larg th containr is. SC=1 and MC [0, 1] LC=1. If all lmnts of a containr nvr gt rmovd aftr thy ar addd (i.., vry lmnt crosss th ntir laking rgion), th confidnc of th containr is 1, no mattr how larg th containr is. MC=1 and SC [0, 1] LC=SC. If th mmory contribution of a containr is xtrmly high (clos to 1), th confidnc of this containr is dcidd by its stalnss contribution. Our study shows that this dfinition of confidnc ffctivly sparats containrs that ar th sourcs of laks from thos that do not lak. A sampl rport that includs LC, MC, and SC valus for svral containrs is shown in Tabl 1. This tabl is a part of th rport gnratd by our tool whn analyzing Sun s bug #6209673. Th first containr in th tabl is th on that actually laks mmory. Not that th LC valu of this containr is much largr than th LC valus for th rmaining containrs. Using this rport, it is straightforward to find and fix this bug. class HashMap { Objct put(objct ky, Objct valu) {...} Objct gt(objct ky) {...} Objct rmov(objct ky) {...}... } (a) Containr class HashMap class Java_util_HashMap { static void put_aftr(int csid, Map rcivr, Objct ky, Objct valu, Objct rsult) { /* if ky dos not xist in th map */ if (rsult == null) { /* us usr-dfind hash cod as ID */ Rcordr.v().usUsrDfHashCod(); /* rcord opration ADD(rcivr,ky) */ Rcordr.v().rcord(csID, rcivr, ky, rcivr.siz()-1, Rcordr.EFFECT_ADD); }} static void gt_aftr(int csid, Map rcivr, Objct ky, Objct rsult) { /* if an ntry is found */ if (rsult!= null) { Rcordr.v().usUsrDfHashCod(); /* rcord opration GET(rcivr):ky */ Rcordr.v().rcord(csID, rcivr, ky, rcivr.siz(), Rcordr.EFFECT_GET); }} static void rmov_aftr(int csid, Map rcivr, Objct ky, Objct rsult) { if (rsult!= null) { Rcordr.v().usUsrDfHashCod(); /* rcord opration REMOVE(rcivr,ky) */ Rcordr.v().rcord(csID, rcivr, ky, rcivr.siz()+1, Rcordr.EFFECT_REMOVE); }}} (b) Glu class for HashMap Figur 3: Modling of containr java.util.hashmap. 3. MEMORY LEAK DETECTION FOR JAVA Basd on th lak confidnc analysis, this sction prsnts a mmory lak dtction tchniqu for Java. Containr modling. W hav built th glu cod for all typs in th Java collctions framwork. For ach containr typ thr is a corrsponding glu class. For ach mthod in th containr typ that is rlatd to ADD, GET, and REMOVE oprations, thr is a static mthod in th glu class whos nam is th nam of th containr mthod plus th suffix bfor or aftr. Th suffix indicats whthr calls to th glu mthod should b insrtd bfor or aftr call sits invoking th original mthod. Th paramtr list of th glu mthod includs a call sit ID, th rcivr objct, and th formal paramtrs of th containr mthod. For th suffix aftr, th rturn valu of th containr mthod is also addd. Figur 3 shows th modling of containr class java.util.hashmap. It is important to not that most of this glu cod can b gnratd automatically using prdfind cod tmplats. Th glu mthods call our profiling library to pass th following data: th call sit ID (csid), th containr objct, th lmnt objct, th numbr of lmnts in th containr bfor th opration is prformd, and th opration typ. Th call sit ID is gnratd by our tool during instrumntation. Th containr objct, th lmnt objct, and th opration typ ar usd to comput th SC for th containr. Rcording th numbr of lmnts in a containr is ndd for th algorithm in Figur 5, as discussd latr. W us an intgr ID to track ach objct (i.., containr and lmnt). Th first tim a containr objct is obsrvd by th profiling library, w tag this objct with th ID using JVMTI. Th ID for a containr objct (.g., th objct rfrrd to by 154

Nam Dscription Purpos GC T GC timstamps To idntify th laking rgion GC M Total liv mmory aftr GCs To idntify th laking rgion CON M Mmory takn up by containrs To comput MC for containrs CON T Timstamps whn masuring CON M To comput MC for containrs CON A Allocation tims of containrs To comput MC and SC for containrs CON D Dallocation tims of containrs To comput MC and SC for containrs OPR Oprations (csid, containr, lmnt, #lmnts, typ) To comput SC for containrs Tabl 2: Data collctd by th profilr. rcivr in Figur 3) is its idntity hash cod dtrmind by its intrnal addrss in th JVM. For an lmnt objct, th idntity hash cod is usd as lmnt ID if th containr dos not hav hash-basd functions; othrwis, th lmnt ID is th usr-dfind hash cod. For xampl, in Figur 3, calls to ususrdfhashcod inform our library that th ID for ky should b its usr-dfind hashcod. For HashMap, w only track ky as a containr lmnt, bcaus ky is rprsntativ of a map ntry. Mthods that rtriv th ntir st of lmnts, such as toarray and itrator, ar tratd as a st of GET oprations prformd on all containr lmnts. Of cours, this approximat tratmnt of itrators may affct th prcision of th computd SC valus. Instrumntation. Th Soot analysis framwork [24] is usd to prform cod instrumntation. For ach call sit in an application class at which th rcivr is a containr, calls to th corrsponding glu mthod ar insrtd bfor and/or aftr th sit. For a containr objct, cod is also insrtd aftr its allocation sit in ordr to track its allocation tim. Naivly instrumnting a Java program can caus tracking of many containrs, which may introduc significant runtim ovrhad. Bcaus thrad-local and mthod-local containrs 1 ar lss likly to b sourcs of laks, w mploy an scap analysis to idntify a st S of thrad-local and mthod-local objcts. W do not instrumnt a call sit if th points-to sts of its rcivr variabl is a subst of S. Profiling. Tabl 2 lists th typs of data that nd to b obtaind by our profilr. In ordr to idntify th laking rgion, w nd to collct GC finishing tims (GC T ) and liv mmory at ths tims (GC M ), using JVMTI. For MC valus of containrs, it is ncssary to collct th amounts of mmory for th ntir objct graphs of containrs (CON M) and th corrsponding collction tims (CON T ). W masur th mmory usag of a containr by travrsing th objct graph starting from th containr, using rflction. Sinc it is impractical to comput th xact valu of MC, sampling is usd to approximat th mmory tim graph. Frqunt sampling rsults in prcis approximation, but incrass run-tim ovrhad. W launch priodic objct graph travrsals (for a st of trackd containrs) vry tim aftr a crtain numbr of gcvnts is sn. Th numbr of gc-vnts btwn two travrsals (i.., th sampling rat) can b givn as a paramtr to dtrmin prcision and ovrhad. Our study indicats that choosing 50 as th numbr of gc-vnts btwn travrsals can kp th ovrhad low whil achiving high prcision. Objct graph travrsal is prformd by a sparat thrad. Onc a containr opration occurs (i.., rcord in Figur 3 is invokd), rcord adds th ID of th containr to a global quu, if that ID is not alrady thr. Whn th givn num- 1 Containrs that ar not rachabl from multipl thrads, and whos liftim is limitd within thir allocating mthods. containrid containr typ 2345765... java.util.hashmap... 2042 lmntid, #lmnts, timstamp root... CSID*10+OPR_TYPE 122365, 125, 1145 Figur 4: Comprssd rcording of OPR vnts. br of gc-vnts complt, th JVMTI agnt activats this thrad, which in turn suspnds all othr thrads, rads IDs from th quu, rtrivs th corrsponding objcts, and prforms graph travrsals. Th allocation tim of a containr (CON A) can b collctd by th instrumntation at th allocation sit, and th JVMTI agnt can provid th dallocation tim of a taggd containr (CON D). To comput SC valus for containrs, w hav to rcord vry opration that a trackd containr prforms (OPR). Bcaus OPR vnts can rsult in larg amounts of data, w us a data comprssion stratgy to rduc spac ovrhad. Th OPR data is stord in a tr structur. Data at a highr lvl of th tr is likly to b mor frquntly rpatd. For xampl, typ java.util.hashmap, which is at th highst lvl of th tr, appars in th vnt squnc for many containr IDs. Similarly, for a singl containr ID, many call sits and oprations nd to b rcordd. Th tr rprsntation is illustratd in Figur 4. Th typ of containr is a parnt of th containr ID. A child of th containr ID is a combination of th call sit ID and th opration typ (ncodd as a singl intgr csid*10+opr_typ). Th laf nods contain tupls of lmnt ID, numbr of lmnts in th containr bfor this opration, and a timstamp. Kping too much profiling data in mmory dgrads program prformanc. W priodically dump th data to disk to rduc its influnc on th run-tim xcution. Th frquncy of dumping is th sam as that of objct graph travrsal: th JVMTI agnt crats a dumping thrad that is activatd at th sam tim th graph travrsal thrad is activatd. Both of ths thrads must complt bfor th xcution of th application thrads is rsumd. Data analysis. Our implmntation prforms an offlin analysis aftr th program finishs or runs out of mmory. Thus, th nd of th laking rgion τ is th nding tim of th program. Th implmntation can asily b adaptd to run th analysis onlin (in anothr procss) and gnrat th rport whil th original program is still running. Th first stp of th analysis is to scan GC T and GC M information to dtrmin th laking rgion. Th currnt 155

1: FIND SC (Doubl τ, Doubl τ s,mapsiz map, Mapopr map) 2: /* opration list for ach containr */ 3: List opr list 4: /* Th rsult map contains ach containr ID and its SC */ 5: Map rsult = 6: for ach containr ID c in opr map do 7: Map tmp = /* a tmporary hlpr map */ 8: opr list = opr map.gt(c) 9: Intgr total = 0 /* total numbr of lmnts */ 10: Doubl sum =0/* P stalnss */ 11: /* Numbr of lmnts in c at tim τ s */ 12: Intgr n = siz map.gt(c) 13: for ach opration opr in opr list do 14: if opr.typ == ADD thn 15: tmp.add(opr.lmntid, opr.timstamp) 16: nd if 17: if opr.typ == GET thn 18: updat tmp with (opr.lmntid, opr.timstamp) 19: nd if 20: if opr.typ == REMOVE thn 21: if tmp.contains(opr.lmntid) thn 22: Intgr lastgt = tmp.gt(opr.lmntid) 23: sum += opr.timstamp lastgt 24: total += 1 25: tmp.rmov(opr.lmntid) 26: ls 27: /* Th lmnt is addd bfor τ s */ 28: sum += opr.timstamp τ s 29: total += 1 30: n = 1 31: nd if 32: nd if 33: nd for 34: if tmp.siz > 0 thn 35: /* Ths lmnts ar nvr rmovd */ 36: for ach lmntid in tmp do 37: Intgr lastgt = tmp.gt(lmntid) 38: sum += τ lastgt 39: total +=1 40: nd for 41: nd if 42: if n > 0 thn 43: /* Elmnts ar addd bfor τ s and nvr rmovd */ 44: sum += (τ τ s) n; 45: total += n 46: nd if 47: c.sc = (sum/total)/(τ τ s) 48: rsult.add(c, c.sc) 49: nd for 50: rturn rsult Figur 5: Computing SC for containrs. implmntation mploys 0.5 as th ratio usd to dfin this rgion, which mans that at last half of th gc-vnts form a subsqunc with incrasing mmory consumption (rcall th lak rgion dfinition from Sction 2). Aftr th smallst τ s that satisfis this constraint is found, ach containr s OPR data is uncomprssd into individual oprations and thy ar sortd by timstamp. Th containr ID and its opration list ar stord in map opr map. Forachcon- tainr, th analysis also dtrmins th first opration that is prformd aftr τ s; th containr ID and th numbr of containr lmnts at this first opration ar stord in map siz map. Oprations that occurd bfor τ s ar discardd. For ach containr, CON M and CON T data is usd to approximat th mmory tim graph and th MC valu. Th approximation assums that th mmory usd by th containr dos not chang btwn two sampls. Thus, MC is P n 1 i=0 (CONT,i+1 CONT,i) CONM,i whr i rprsnts th i-th sampl. Figur 5 shows th computation of SC for containrs. Th algorithm scans a containr s opration list, and for ach lmnt ID, finds its last GET opration, its REMOVE opration, and th distanc btwn thm. (Rcall that th dallocation of th containr is tratd as a st of REMOVE oprations on all lmnts.) For an lmnt that is addd bfor τ s (lins 27 30), stalnss is th distanc btwn th REMOVE opration and τ s. For an lmnt that is nvr rmovd (lins 34 39), stalnss is th distanc btwn τ and th last GET opration. For lmnts that ar addd bfor τ s and nvr rmovd (lins 42 45), stalnss is τ τ s. Laking call sits. For ach lmnt in a containr, th analysis finds th call sit ID corrsponding to its last GET or ADD opration. Thn, it computs th avrag stalnss of lmnts whos last GET or ADD oprations corrspond to that sam call sit ID. Th call sit IDs ar thn sortd in dcrasing ordr of this avrag valu. Thus, th tool rports not only th potntially laking containrs (sortd by th LC valu), but also, for ach containr, th potntially laking call sits (with thir sourc cod location) sortd in dscnding ordr by thir avrag stalnss. Our xprinc indicats that this information can b vry hlpful to a programmr trying to idntify th sourc of a mmory lak bug. 4. EMPIRICAL EVALUATION To valuat th proposd tchniqu for containr-basd mmory lak dtction for Java, w prformd a varity of xprimntal studis focusing on lak idntification and xcution ovrhad. Sction 4.1 illustrats th ability of th tchniqu to hlp a programmr find and fix ral-world bugs. Sction 4.2 prsnts a study of th incurrd ovrhad. 4.1 Dtction of Ral-World Mmory Laks Th xprimnts wr prformd on a 2.4GHz dual-cor PC with 2GB RAM. Thr diffrnt sampling/dumping rats wr usd: 1/15gc, 1/50gc, and 1/85gc (i.., onc vry 15, 50, or 85 gc-vnts). Th xprimntal subjcts wr two mmory lak bugs rportd in th Sun bug databas [23], as wll as a known lak in SPECjbb [22]. Java AWT/Swing bugs. About half of th mmory lak bugs in th JDK com from AWT and Swing. This is th rason w chos two AWT/Swing rlatd lak bugs #6209673 and #6559589 for valuation. Th first bug has alrady bn fixd in Java 6, whil th scond on was still opn and unrsolvd. Bug rport #6209673 dscribs a bug that manifsts itslf whn switching btwn a running Swing application that shows a JFram and anothr procss that uss a diffrnt display mod (.g., a scrn savr) th Swing application vntually runs out of mmory. According to a dvlopr s xprinc [18], th bug was vry difficult to track down bfor it was fixd. W instrumntd th ntir awt and swing packags, and th tst cas providd in th bug rport. W thn ran th instrumntd program and rproducd th bug. Figur 6 shows th tool rports with thr sampling rats. Each rport contains th top thr containrs, for ach containr th top thr potntially laking call sits (---cs), and th tim usd to analyz th data. Sampling rats 1/15gc and 1/50gc produc th sam containrs, in th sam ordr. Th first containr in th rports is a HashMap in class javax.swing.rpaintmanagr. Win- spctd th cod of RpaintManagr and found that th containr was an instanc fild volatilmap. Th call sit in th rport (with avrag stalnss 0.507) dirctd us to lin 591 in th cod of th class, which corrsponds to a GET opration imag = (VolatilImag)volatilMap.gt(config). Th tool rport indicats that th imag obtaind at this call 156

Containr:11324773 typ: java.util.hashmap (LC: 0.449, SC: 0.495, MC: 0.825) ---cs: javax.swing.rpaintmanagr:591 (Avrag stalnss: 0.507) Containr:18429817 typ: java.util.linkdlist (LC: 0.165, SC: 0.194, MC: 0.820) ---cs: java.awt.dfaultkyboardfocusmanagr:738 (0.246) Containr:8984226 typ: java.util.linkdlist (LC: 0.051, SC: 0.062, MC: 0.809) ---cs: java.awt.dfaultkyboardfocusmanagr:851 (0.063) ---cs: java.awt.dfaultkyboardfocusmanagr:740 (0.025) Data analyzd in 149203ms (a) 1/15gc sampling rat Containr:29781703 typ: java.util.hashmap (LC: 0.443, SC: 0.480, MC: 0.855) ---cs: javax.swing.rpaintmanagr:591 (Avrag stalnss: 0.480) Containr:2263554 typ: class java.util.linkdlist (LC: 0.145, SC:0.172, MC: 0.814) ---cs: java.awt.dfaultkyboardfocusmanagr:738 (0.017) Containr:399262 typ: class javax.swing.jpanl (LC: 0.038, SC:0.044, MC: 0.860) ---cs: javax.swing.jcomponnt:796 (0.044) Data analyzd in 21593ms (b) 1/50gc sampling rat Containr:15255515 typ: java.util.hashmap (LC: 0.384, SC:0.426, MC: 0.835) ---cs: javax.swing.rpaintmanagr:591 (0.426) Containr:19275647 typ: java.util.linkdlist (LC: 0.064, SC:0.199, MC: 0.244) ---cs: java.awt.squncdevnt:176 (0.204) ---cs: java.awt.squncdevnt:179 (0.010) ---cs: java.awt.squncdevnt:128 (1.660E-4) Containr:28774302 typ: javax.swing.jpanl (LC: 0.036, SC:0.042, MC: 0.839) ---cs: javax.swing.jcomponnt:796 (0.042) Data analyzd in 10547ms (c) 1/85gc sampling rat Figur 6: Rports for JDK bug #6209673. Containr:5678233 typ: java.util.vctor (LC: 0.890, SC: 0.938, MC: 0.427) ---cs: java.awt.window:1825 (0.938) Containr:3841106 typ: java.bans.proprtychangsupport (LC: 0.645, SC:0.779, MC: 0.427) ---cs: java.awt.componnt:7007 (0.779) Containr:24333128 typ: javax.swing.uidfaults (LC: 0.644, SC:0.875, MC: 0.087) ---cs: javax.swing.uidfaults:334 (0.868) ---cs: javax.swing.uidfaults:308 (0.660) Data analyzd in 454ms (a) 1/15gc sampling rat Containr:5678233 typ: java.util.vctor (LC: 0.890, SC:0.938, MC: 0.427) ---cs: java.awt.window:1825 (0.938) Containr:30318493 typ: java.bans.proprtychangsupport (LC: 0.668, SC:0.828, MC: 0.288) ---cs: java.awt.componnt:7007 (0.828) Containr:9814147 typ: javax.swing.uidfaults (LC: 0.101, SC: 0.327, MC: 0.175) ---cs: javax.swing.uidfaults:334 (0.984) ---cs: javax.swing.uidfaults:308 (0.903) Data analyzd in 282ms (b) 1/50gc sampling rat Containr:5678233 typ: java.util.vctor (LC: 0.293, SC:0.425, MC: 0.525) ---cs: java.awt.window:1825 (0.425) Containr:30502607 typ: javax.swing.jlayrdpan (LC: 0.117, SC:0.221, MC: 0.441) ---cs: javax.swing.jcomponnt:796 (0.162) Containr:2665317 typ: javax.swing.uidfaults (LC: 0.096, SC:0.363, MC: 0.124) ---cs: javax.swing.uidfaults:334 (0.359) ---cs: javax.swing.uidfaults:308 (0.340) Data analyzd in 297ms (c) 1/85gc sampling rat Figur 7: Rports for JDK bug #6559589. sit may not b proprly rmovd from th containr. For a programmr that is familiar with th cod, this information may b nough to idntify th bug quickly. Sinc th cod was nw to us, w had to larn mor about this class and th ovrall display handling stratgy of Swing to undrstand th bug. Bcaus th bug was alrady rsolvd, w xamind th bug valuation, which confirmd that volatilmap is th root of th lak. Th caus of th bug is caching by RpaintManagr of all VolatilImag objcts, rgardlss of whthr or not thy ar currntly valid. Upon a display mod switch, th old GraphicsConfiguration objcts undr th prvious display mod gt invalidatd and will not b usd again. Howvr, th VolatilImag for an obsolt GraphicsConfiguration is nvr rmovd from volatilmap, and hnc all rsourcs allocatd by th imag continu taking up mmory. Not that th rport with sampling rat 1/85gc loss th LinkdList in DfaultKyboardFocusManagr, whichap- pars as th scond containr in th othr two rports. Although this containr is not th sourc of th bug, it dmonstrats that sampling at 1/85gc may not b frqunt nough to maintain high prcision for LC computation. Also not that analysis tim dcrass with th dcras in sampling rat, bcaus th tool procsss lss data. Compard to our rports, xisting approachs that kp track of arbitrary objcts (i.., do not hav our containrcntric viw) would rport allocation sits of som typs of objcts that ithr (1) continuously grow in numbrs or (2) ar not usd for a whil. For bug #6209673, for xampl, thr ar growing numbrs of objcts of numrous typs that ar rachabl by VolatilImag and GraphicsConfiguration objcts. Tools such as Cork [14] hav to backward- travrs th objct graph from th growing objcts to find th typ of objcts that do not grow in numbrs. Howvr, th uslss objcts ar intr-rfrncd, and morovr, travrsing back from ths growing objcts can potntially find multipl typs whos instancs rmain unchangd. In this cas, th containr that holds GraphicsConfigurations, th JFram window, th GraphicsDvic objct, th map that holds VolatilImags, tc. can all b data structurs that ar backward-rachabl from th growing objcts and whos numbrs of instancs do not grow. Tools such as Sligh [1] rport rrors basd solly on th stalnss of objcts. In this cas, th JFram objct would b th most stal objct bcaus it is nvr usd aftr it is cratd. In addition, thr ar numrous typs of objcts that ar mor stal than VolatilImags, such as all componnts in th fram. Hnc, Sligh could rport all ths objcts as th sourcs of th lak, including many fals positivs. Finally, both of ths xisting approachs rquir non-standard JVM modifications and support, whil our tchniqu uss only cod instrumntation and th standard JVMTI intrfac. Rport #6559589 dscribs a bug in Java 6 build 1.6.0 01: calling JScrollPan.updatUI() in a Swing program that uss JScrollPan causs th numbr of listnrs to grow. Bcaus it is common knowldg that ProprtyChangListnrs ar managd by java.ban.proprtychangsupport, w modld this class as a containr and wrot a glu class for it. Th rports ar shown in Figur 7. Th first containr in all thr rports is a vctor in java.awt.window, corrsponding to an instanc fild owndwindowlist; this fild is usd to hold all childrn windows of th currnt window. Lin 1825 of class Window contains an ADD opration addelmnt(wakwindow) for this fild. Th rporting 157

Bfor fixing th bug ) s t y b ( d s U y r o m M 2500000 2000000 1500000 1000000 500000 0 1 5 9 13 17 21 25 29 33 37 41 45 49 53 GC Runs ) s t y b ( d s U y r o m M 2500000 2000000 1500000 1000000 500000 0 Aftr fixing th bug 1 4 7 10 13 16 19 22 25 28 31 34 37 40 GC Runs Figur 8: Mmory footprint bfor and aftr fixing JDK bug #6559589. of this call sit by th tool indicats that whn a Window objct is addd to th vctor, it may not b proprly rmovd latr. W quickly concludd that this cannot b th sourc of th bug, bcaus windows in a Swing program usually hold rfrncs to ach othr until th program finishs. This forcd us to look at th scond containr in rports (a) and (b), which is a ProprtyChangSupport objct in java.awt.componnt. Th rportd call sit at lin 7007 of Componnt is changsupport.addproprtychanglistnr(listnr) Th containr is an instanc fild changsupport, which stors all ProprtyChangListnrs rgistrd in this componnt. Th call sit indicats that th bug may b causd by som problm in JScrollPan that dos not appropriatly rmov listnrs. Rgistring and unrgistring of listnrs for JScrollPan is don in a st of ScrollPanUI classs. Th tst cas uss a mtal look and fl, which is rprsntd by class MtalScrollPanUI, a subclass of Basic- ScrollPanUI. WchckdmthoduninstallListnrs in MtalScrollPanUI, which is supposd to rlas listnrs from th componnt, and found that this mthod calls th mthod with th sam nam in its supr class, but dos not rmov thscrollbarswaplistnr objct hld by a privat fild in th subclass. Furthr invstigation rvald an vn mor srious problm: mthod uninstalllistnrs in th subclass was not xcutd at all, bcaus its signatur was diffrnt from th signatur of th mthod with th sam nam in suprclass BasicScrollPanUI: /* BasicScrollPanUI */ void uninstalllistnrs(jcomponnt c) /* MtalScrollPanUI */ void uninstalllistnrs(jscrollpan scrollpan) Hnc, th causs of th bug ar (1) uninstalllistnrs in MtalScrollPanUI fails to ovrrid th appropriat mthod in suprclass BasicScrollPanUI, and (2) th listnr dfind in subclass MtalScrollPanUI is not rmovd by its own uninstalllistnrs. Wmodifidthcodaccord- ingly, and th mmory lak disappard. Th mmory footprints bfor and aftr fixing th bug ar shown in Figur 8. W hav submittd our modification as a commnt in th bug databas. Again, th rport that usd 1/85gc sampling rat faild to includ th ProprtyChangSupport objct, which is th sourc of th lak. SPECjbb bug. Bnchmark SPECjbb2000 simulats an ordr procssing systm and is intndd for valuating srvrsid Java prformanc [22]. Th program contains a known mmory lak bug that manifsts itslf whn running for a long tim without changing warhouss. Th rport gnratd by our tool for rat 1/50gc is shown in Figur 9. Du to th imprcision of using sampling rat 1/85gc, th rport for it is not shown. W also do not show th rport for sampling rat 1/15gc, bcaus th containrs and thir ordr ar th sam as in th rport for 1/50gc. Containr:4451472 typ: java.util.hashtabl (LC: 0.135, SC: 0.190, MC: 0.659) ---cs: spc.jbb.stocklvltransaction:225 (0.214) ---cs: spc.jbb.stocklvltransaction:211 (0.190) Containr:7776424 typ: java.util.hashtabl (LC: 0.110, SC:0.157, MC: 0.659) ---cs: spc.jbb.stocklvltransaction:211 (0.157) ---cs: spc.jbb.stocklvltransaction:225 (0.114) Containr:28739781 typ: java.util.hashtabl (LC: 0.102, SC:0.146, MC: 0.654) ---cs: spc.jbb.stocklvltransaction:211 (0.146) ---cs: spc.jbb.stocklvltransaction:225 (0.122) Data analyzd in 4078ms (a) bfor modling of longbtr, using 1/50gc Containr:27419736 typ: spc.jbb.infra.collctions.longbtr (LC: 0.687, SC: 0.758, MC: 0.666) ---cs: spc.jbb.district:264 (0.826) ---cs: spc.jbb.stocklvltransaction:225 (0.624) ---cs: spc.jbb.stocklvltransaction:211 (0.519) Containr:21689791 typ: spc.jbb.infra.collctions.longbtr (LC: 0.685, SC: 0.757, MC: 0.662) ---cs: spc.jbb.district:264 (0.783) ---cs: spc.jbb.stocklvltransaction:211 (0.370) ---cs: spc.jbb.district:406 (2.944E-4) Containr:27521273 typ: spc.jbb.infra.collctions.longbtr (LC: 0.667, SC: 0.727, MC: 0.727) ---cs: spc.jbb.warhous:456 (0.798) ---cs: spc.jbb.district:264 (0.784) ---cs: spc.jbb.stocklvltransaction:211 (0.484) Data analyzd in 7579ms (b) aftr modling of longbtr, using 1/50gc Figur 9: Rport for SPECjbb2000 bug. antlr 4.1E-5 chart 2.7E-6 fop 1.3E-5 hsqldb 4.4E-7 jython 5.0E-8 luindx 9.1E-5 lusarch 2.3E-2 pmd 4.3E-6 xalan 5.2E-5 jflx 1.8E-7 Tabl 3: Confidncs for lak-fr programs. Th program was first instrumntd without modling any usr-dfind containrs. Th rsult is shown in Figur 9(a). Non of th containrs in th rport ar likly to lak mmory, bcaus thir confidncs ar vry small. Th first containr rfrs to a hashtabl that holds stocks of an ordr lin. W did not find any problm with th us of this containr. Howvr, w obsrvd that th ordr lins ar actually obtaind from an ordr tabl, which has a typ of longbtr. W found that longbtr is a containr class that implmnts a BTr data structur and is usd to hold ordrs. It took svral minuts to writ a glu class for longbtr. Th program was thn r-instrumntd and r-xcutd. Th rsulting rport is shown in Figur 9(b). Th top thr containrs in th rport ar now instancs of longbtr. Lin 264 of spc.jbb.district is an ADD opration ordrtabl.put(anordr.gtid(), anordr) which indicats that ordrtabl maylakmmory. Mthods rmovoldstordr, rmovoldordrs, anddstroy contain REMOVE oprations for ordrtabl. Wfocusdon th first two mthods, bcaus dstroy could not b calld whn a district is still usful. Using a standard IDE, w found th callrs of ths mthods: rmovoldstordr is calld only onc within DlivryTransaction, andrmov- OldOrdrs is nvr calld. Thrfor, whn a transaction complts, it rmovs only th oldst ordr from th tabl, which causs th hap growth. Insrting cod to rmov ordrs from th tabl fixd th bug. W usd lss tim (a fw hours) than th authors of [14] did (a day) to locat th bug in this program, which w had nvr studid bfor. 158

Program (a) (b) (c) 1/15gc (d) 1/50gc () #IS #IS IT (s) RT o(s) #GC d RT d (s) #GC l RT l (s) #GC d RT s(s) #GC l RT l (s) %OH antlr 176 123 87 17.9 387 18.4 10 18.1 387 18.4 10 18.1 0.7% chart 894 867 202 8.5 5368 38.0 185 35.4 4109 36.5 185 35.1 313.2% fop 1378 1375 125 4.5 693 8.6 24 7.8 545 8.9 24 6.4 44.6% hsqldb 684 674 116 4.3 54 4.7 8 4.4 54 4.7 8 4.4 1.6% jython 443 416 135 7.3 1653 31.8 126 28.2 1440 31.4 126 28.5 298.3% luindx 442 409 65 19.5 1446 24.4 40 23.7 1390 23.9 40 23.7 21.2% lusarch 442 388 81 2.9 418 9.1 21 3.9 326 8.2 23 3.2 11.7% pmd 814 690 111 5.9 2938 26.9 716 18.4 2766 25.2 37 6.6 10.8% xalan 755 752 114 1.4 655 7.7 30 4.0 605 6.2 18 3.7 165.9% jflx 522 438 92 45.1 4171 170.7 1493 130.3 2126 165.8 665 88.05 95.2% bug 1 3109 2768 487 18630 600 7420 600 11457 600 1983 600 bug 2 3105 2770 502 38.1 512 53.0 243 42.3 413 52.2 37 42 10.5% spcjbb 74 73 142 18605 3600 15080 3600 16789 3600 10810 3600 Tabl 4: Ovrhad: (a) cod instrumntation; (b) original running tim; (c) running with 1/15gc rat; (d) running with 1/50gc rat; () run-tim ovrhad. Lak-fr programs. Th tool was also usd to analyz svral programs that hav bn usd widly and tstd xtnsivly for yars, and do not hav any known mmory laks. Tabl 3 shows th confidnc valus computd for ths programs. Th goal of this xprimnt was to dtrmin whthr th proposd tchniqu producd any fals positivs for ths (almost crtainly) lak-fr programs. Th low confidnc valus rportd by th tool ar th xpctd and dsirabl outcom for this xprimnt. 4.2 Static and Dynamic Ovrhad This sction dscribs a study of th ovrhad introducd by th tchniqu. This study utilizs th thr bugs dscribd arlir, as wll as th 10 programs from Tabl 3. Th instrumntd programs wr analyzd with rats 1/15gc and 1/50gc. Th maximum JVM hap siz for ach run was st to 512MB (JVM option Xmx512m). For ach sampling rat, w ran th programs onc with th dfault initial hap siz and onc with a larg initial hap siz (JVM option Xms512m), in ordr to obsrv diffrnt numbrs of gc-vnts. Th tool rports shown arlir wr obtaind with th dfault initial hap siz; with th larg initial siz, th top containrs and call sits and thir ordring wr th sam. Tabl 4 dscribs th static and dynamic ovrhad of th tool. Columns IS and IS show th numbrs of call sits instrumntd without and with mploying scap analysis, rspctivly. Column IT ( instrumntation tim ) rprsnts th static ovrhad of th tool that is, th tim (in sconds) it taks to produc th scap-analysis-basd instrumntd vrsion of th original cod. Column RT o ( running tim ) contains th original running tims of th programs. Th dynamic ovrhad of th approach is dscribd in th rmaindr of th tabl. Columns GC d and GC l show th numbrs of gc-vnts with th dfault and with th larg initial hap siz, rspctivly. Similarly, RT d and RT l show th program running tims with ths two choics of initial hap siz. Column OH rprsnts run-tim ovrhad introducd by our tool whn xcutd with th most optimal configuration, which corrsponds to RT l in columns (d). For bug 1 and spcjbb, w ran th tst cas for 10 minuts and an hour, rspctivly, bcaus th xcution of ths two programs dos not trminat. Applying scap analysis rducs th numbr of call sits that nd to b trackd (th rduction varis from 3 to 124 call sits), whil still maintaining rasonabl instrumntation tim. Using th sam sampling rat, running a program with a larg initial hap siz taks lss tim, bcaus this configuration rducs th numbr of gc-vnts, which in turn rducs th numbrs of thrad synchronizations, disk accsss, and objct graph travrsals prformd by th dynamic analysis. For th sam rasons, dcrasing th sampling rat rducs th run-tim ovrhad. On avrag, th tool introducd 88.5% run-tim ovrhad for th subjct programs (without mploying scap analysis, th ovrhad was vry slightly highr). Such ovrhad is accptabl for dbugging, but it may b too high for production runs. On possibl approach for rducing th ovrhad is to slctivly instrumnt a program. Basd on th manifstation of th bug, dvloprs may hav prfrncs and hints as to whr to focus th ffort of th tool. Th continuous optimization of th tool is part of our futur work. For xampl, th optimization may focus on xcuting th objct graph travrsal thrad and th data dumping thrad in paralll with th application thrads. In addition, th rtrival of a containr objct from its tag though JVMTI also contributs to th xcution ovrhad. Hnc, anothr dirction for futur work is to r-implmnt th tool within an xisting opn-sourc JVM, such as th Jiks RMV [11], in ordr to avoid th ovrhad causd by JVMTI. 5. RELATED WORK Thr is a larg body of work dvotd to th problm of mmory lak dtction. Th discussion blow is rstrictd to approachs that ar most closly rlatd to our tchniqu. Static analysis can find mmory rrors such as doubl frs and missing frs for programs writtn in non-garbagcollctd languags. For xampl, [2] rducs th mmory lak analysis to a rachability problm on th program s guardd valu flow graph. Saturn [25], taking anothr prspctiv, stats mmory lak dtction as a boolan satisfiability problm. Dor t al. [5] propos a shap analysis to prov th absnc of mmory laks in svral list manipulation functions. Hacktt and Rugina [6] us a shap analysis that tracks singl hap clls to idntify mmory laks. Orlovich and Rugina [19] propos an approach that starts by assuming th prsnc of rrors, and prforms a dataflow analysis to disprov thir fasibility. Clousau [9] is a lak dtction tool that uss pointr ownrship to dscrib variabls rsponsibl for fring hap clls, and formulats th analysis as an ownrship constraint systm. Follow-up work [10] proposs a typ systm to dscrib th objct ownrship for containrs, and uss typ infrnc to dtct constraint violations. Although both this work and our tchniqu fo- 159

cus on containrs, th targt of this prvious ffort ar C and C++ program whras w ar intrstd in a garbagcollctd languag. Th analysis from [10] dos not hlp dtct unncssary rfrncs in a Java program. Mor gnrally, all static approachs ar limitd by th lack of gnral, scalabl, and prcis rfrnc/hap modling. Dspit a larg body of work on such modling, it rmains an opn problm for larg ral-world systms, with many challngs du to analysis scalability, modling of multi-thradd bhavior, dynamic class loading, rflction, tc. Dynamic analysis [1, 8, 7, 14, 4, 3, 12, 13, 15] has typically bn th wapon of choic for dtcting mmory laks in ral-world softwar. Howvr, as dscribd in Sction 1 and Sction 4, xisting tchniqus hav a numbr of dficincis. Th work in [4, 3, 12, 13] nabls visualization of hap objcts of diffrnt typs, but dos not provid th ability to dirctly idntify th caus of th mmory lak. Existing tchniqus us growing typs [14, 17] (i.., typs whos numbr of instancs continus to grow), objct stalnss [1], or growing containrs [15] to idntify suspicious data structurs that may contribut to a mmory lak. Howvr, in gnral, a mmory lak causd by rdundant rfrncs is du to a complx intrplay of mmory growing and stalnss and possibly othr factors. By considring a singl mtric which combins both factors, our tchniqu could potntially improv th prcision of lak idntification. In addition, all xisting dynamic-analysis-basd lak dtction approachs xcpt [15] start by considring th lak symptoms (.g., growing typs or stal objcts), and thn attmpt to trac back to th root caus of th lak. As discussd in th dscription of th JDK bugs from Sction 4, th complxity of such bottom-up tracking maks it hard to gnrat prcis analysis rports, and ultimatly puts a significant burdn on th programmr. In contrast, our approach is dsignd from a containr-cntric point of viw it automatically tracks th suspicious bhavior in a top-down mannr, by monitoring (1) th objct graph rachabl from a containr, and (2) th containr-lvl oprations. This highr lvl of abstraction, compard to traditional low-lvl tracking of arbitrary objcts, simplifis th difficult task of idntifying th sourcs of mmory laks. 6. CONCLUSIONS This papr prsnts a novl tchniqu for dtcting mmory laks in Java softwar. Unlik xisting dynamic analyss for lak dtction, th proposd approach mploys a highrlvl abstraction, focusing on containr objcts and thir oprations, and uss both mmory contribution and stalnss contribution to dcid how significant is a containr s laking bhavior. W prsnt an implmntation of this tchniqu and xprimntal studis dmonstrating that th proposd tool can produc prcis bug rports at a practical cost. Ths promising initial rsults indicat that th tchniqu and any futur gnralizations ar worth furthr invstigation. Futur work will focus on optimizations to rduc th run-tim ovrhad. Anothr possibl dirction may b ways to idntify data structurs that act as containrs (.g., using th approach from [16]) instad of rlying on th programmr, and to automat th mapping of containr mthods to th ADT oprations. Altrnativ dfinitions for LC could also b invstigatd, and mor prcis handling of itrators may b dsirabl. Mor contxt information about containrs and call sits could mak th rports mor usful. Acknowldgmnts. W would lik to thank th ICSE rviwrs for thir valuabl commnts and suggstions. 7. REFERENCES [1] M. D. Bond and K. S. McKinly. Bll: Bit-ncoding onlin mmory lak dtction. In ASPLOS, pags 61 72, 2006. [2] S. Chrm, L. Princhous, and R. Rugina. Practical mmory lak dtction using guardd valu-flow analysis. In PLDI, pags 480 491, 2007. [3] W.DPauw,D.Lornz,J.Vlissids,andM.Wgman. Excution pattrns in objct-orintd visualization. In USENIX COOTS, pags 219 234, 1998. [4] W. DPauw and G. Svitsky. Visualizing rfrnc pattrns for solving mmory laks in Java. Concurrncy: Practic and Exprinc, 12(14):1431 1454, 2000. [5] N. Dor, M. Rodh, and S. Sagiv. Chcking clannss in linkd lists. In SAS, pags 115 134, 2000. [6] B. Hacktt and R. Rugina. Rgion-basd shap analysis with trackd locations. In POPL, pags 310 323, 2005. [7] R. Hastings and B. Joyc. Purify: A tool for dtcting mmory laks and accss rrors in C and C++ programs. In Wintr 1992 USENIX Confrnc, pags 125 138, 1992. [8] M. Hauswirth and T. M. Chilimbi. Low-ovrhad mmory lak dtction using adaptiv statistical profiling. In ASPLOS, pags 156 164, 2004. [9] D. L. Hin and M. S. Lam. A practical flow-snsitiv and contxt-snsitiv C and C++ mmory lak dtctor. In PLDI, pags 168 181, 2003. [10] D. L. Hin and M. S. Lam. Static dtction of laks in polymorphic containrs. In ICSE, pags 252 261, 2006. [11] Jiks Rsarch Virtual Machin. jiksrvm.org. [12] JProb. www.qust.com/jprob. [13] JProfilr. www.j-tchnologis.com. [14] M. Jump and K. S. McKinly. Cork: Dynamic mmory lak dtction for garbag-collctd languags. In POPL, pags 31 38, 2007. [15] LakHuntr. www.wilytch.com/solutions/products. [16] N. Mitchll. Th runtim structur of objct ownrship. In ECOOP, pags 74 98, 2006. [17] N. Mitchll and G. Svitsky. Lakbot: An automatd and lightwight tool for diagnosing mmory laks in larg Java applications. In ECOOP, pags 351 377, 2003. [18] E. Nicholas. wblogs.java.nt/blog/ nicholas/archiv/2006/04/laking_vil.html. [19] M. Orlovich and R. Rugina. Mmory lak analysis by contradiction. In SAS, pags 405 424, 2006. [20] F. Qin, S. Lu, and Y. Zhou. Safmm: Exploiting ECC-mmory for dtcting mmory laks and mmory corruption during production runs. In HPCA, pags 291 302, 2005. [21] R. Shaham, E. K. Kolodnr, and M. Sagiv. Automatic rmoval of array mmory laks in Java. In CC, pags 50 66, 2000. [22] SPECjbb2000 Documntation. www.spc.org. [23] Sun Bug Databas. bugs.sun.com/bugdatabas. [24] R. Vallé-Rai, E. Gagnon, L. Hndrn, P. Lam, P. Pominvill, and V. Sundarsan. Optimizing Java bytcod using th Soot framwork: Is it fasibl? In CC, pags 18 34, 2000. [25] Y. Xi and A. Aikn. Contxt- and path-snsitiv mmory lak dtction. In FSE, pags 115 125, 2005. 160