Practical Virtual Method Call Resolution for Java
Vijay Sundaresan, Laurie Hendren, Chrislain Razafimahefa,
Raja Vall ´ee-Rai, Patrick Lam, Etienne Gagnon and Charles Godin
Sable Research Group (
www.sable.m gill. a)
School of Computer Science
McGill University
Montreal, Quebec, CANADA H3A 2A7
[vijay,hendren,razafima,rvalleerai,plam,gagnon,cgodin]@sable.mcgill.ca
ABSTRACT
Thispaperaddressestheproblemofresolvingvirtualmethod andinterfa e allsinJavabyte ode. Themainfo usis on anewpra ti alte hniquethat anbeusedtoanalyzelarge appli ations. Ourfundamental designgoal was to develop ate hniquethat anbesolvedwithonlyoneiteration,and thuss aleslinearlywiththesizeoftheprogram,whileatthe sametimeprovidingmorea urateresultsthantwopopular existinglinearte hniques, lasshierar hyanalysisandrapid type analysis.
We present two variations of our new te hnique, variable-typeanalysisanda oarser-grainversion alledde lared-type analysis. Bothoftheseanalysesareinexpensive,easyto im-plement,andourexperimentalresultsshowthattheys ale linearlyinthesizeoftheprogram.
WehaveimplementedournewanalysesusingtheSoot frame-work, and we reporton empiri al results for seven ben h-marks. Wehaveusedourte hniquestobuilda urate all graphs for omplete appli ations (in luding libraries) and we show that omparedto a onservative allgraph built using lasshierar hyanalysis,ournewvariable-type analy-sis anremoveasigni antnumberofnodes(methods)and alledges. Further,our results show that we animprove uponthe ompressionobtainedusingrapidtypeanalysis.
Wealsoprovidedynami measurementsofmonomorphi all sites, fo usingon the ben hmark ode ex luding libraries. Wedemonstratethatwhen onsideringonlytheben hmark ode, both rapidtype analysis and our newde lared-type analysisdonotaddmu hpre isionover lasshierar hy anal-ysis. However,our ner-grainedvariable-typeanalysisdoes
Allworkreportedinthispaperwasdonewhileallauthors wereatM GillUniversity.CurrentlyVijaySundaresanisat IBMToronto,ChrislainRaza mahefaisattheUniversityof Geneva,andPatri kLamisatMIT.
resolve signi antly more all sites, parti ularly for pro-gramswithmore omplexusesofobje ts.
1.
INTRODUCTION
AstheJava(tm)programminglanguageandJavabyte ode be omesmorepopular,itisbe omingimportanttoprovide optimizing ompilers and more eÆ ient runtime systems. Oneimportant optimizationproblemforJava,as forother obje t-oriented languages, is that ofstati ally determining whatmethods anbeinvokedbyvirtualmethod alls. The results of su h ananalysis anbeused to redu e the ost ofvirtualmethod alls,todete tpotentialsitesformethod inlining, and to provide an a urate all graph. A more a urate allgraph anbeusedto: (1) ompa tappli ations byremovingmethodsthatarenever alled,and(2)improve the eÆ ien y and a ura y of subsequent interpro edural analyses.
Of ourse, virtualmethodresolutionisnotanewproblem. It has been widelystudied for a variety of obje t-oriented languages[7, 8, 9, 10, 12, 14, 18, 16, 21, 24, 28, 29, 30℄. Thefo us ofthis paperis thedevelopmentand evaluation ofanewsimpleandinexpensivete hniqueforresolving vir-tualmethod allsinJava. Amaindesignobje tive was to develop ate hniquethat would produ ea solution inone iterationandthuss aleslinearlyinthesizeoftheprogram. Further,wewanted ate hniquewhi hwas simple,easy to implement, ouldbeappliedtolargeJavaappli ations,but yet ouldalsoyieldmorepre isionthantwoeÆ ient exist-ing te hniques. Inparti ular, we wantedtomeasure stati and dynami improvementsover lasshierar hy analysis[8, 14, 21℄andrapidtypeanalysis[8℄.
Our te hnique is based on an analysis that builds a type propagationgraphwherenodesrepresentvariablesandedges represents ow oftypesdue to assignments, in luding the impli itassignmentsduetomethodinvo ationandmethod returns. The rstvariationis alled de lared-type analysis, wherethenodesrepresentthede laredtypeofvariables. For this analysis the typepropagation graph ontains at most onenodeforea h lassintheappli ation. These ond vari-ationis alled variable-type analysisandit is ner-grained andmorea urate,althoughstilleÆ ient. Inthisvariation the type propagationgraph ontains atmost onenodefor ea hvariablewithanobje t(referen e)type. Bothofthese
the types of all obje ts allo ated, and uses this to prune the allgraph,de lared-typeandvariable-typeanalysis nd whi htypesofobje ts rea hea hvariable(i.e. whi h allo- atedobje tsmightbeassignedtothisvariable).
Inkeeping withourdesirefora simpleandeÆ ient analy-sis,theanalyseswere arefullydesignedsothatoneiteration overthe type propagation graphresults ina safesolution. Further,ouralgorithmissimpletoimplementand ould eas-ilybeaddedto ompilersthatalreadyhave lasshierar hy analysisand/orrapidtypeanalysis.
AlloftheanalyseswereimplementedusingtheSoot frame-workthatprovidesJimple,atypedthree-address ode repre-sentationofJavabyte ode[1℄. Sin eourframeworkoperates onbyte ode,ouranalysisisnotrestri tedtoJava,but an beused for byte odeprodu edfrom awidevariety of lan-guages. Theben hmarksusedinourevaluation aremeant to be representative of real appli ations and theyin lude four SPECjvmben hmarks plusthree otherlarge, obje t-oriented ben hmarks. We use these ben hmarks to show bothstati anddynami resultsthatillustratethea ura y ofour analyses. When onsideringthewhole appli ations, in ludinglibrary ode,wefoundthat theexisting analyses didperformquitewell,butourvariable-typegaveadditional improvements.When onsideringonlytheben hmark ode, fa toring out the library ode, we found that the existing analyses performed poorly, but our variable-type analysis performedsigni antlybetter.
Theremainderofthispaperisstru turedasfollows. In Se -tion2wegiveanoverviewofSootandJimple,andwegive averybriefsummaryof lasshierar hy analysisand rapid typeanalysisasimplementedinoursystem. InSe tion3we outlinevariable-typeanalysisandthe oarser-grainversion, de lared-typeanalysis. Wepresentourexperimental frame-workand empiri almeasurementsinSe tion4. Finally,in Se tion5wedis ussrelated work, on entratingmostlyon othereÆ ientte hniques,andinSe tion6wegiveour on- lusionsandfuturework.
2.
FOUNDATIONS
2.1
The Soot Framework
OuranalysesarebuiltontopoftheJimpleintermediate rep-resentation,whi hispartoftheSootframework. TheSoot frameworkisasetofJavaAppli ationProgramming Inter-fa es(APIs)formanipulatingJava odeinvariousforms[1℄. We analyze omplete appli ations, so our implementation worksby rstreading all lass lesthatarerequiredbyan appli ation,startingwiththemainroot lassandre ursively loadingall lassesusedinea hnewlyloaded lass. Asea h lass is read, it is onverted into the Jimple intermediate representation. After onversion, ea h lassis storedinan instan eofaSootClass,whi hinturn ontainsinformation su hasitsname,itssuper lass,alistofinterfa esthatit im-plements,anda olle tionofSootFieldsandSootMethods. Ea hSootMethod ontains information in ludingitsname, modi er,parameters,lo als,returntypeandalistofJimple three-address odeinstru tions. All parametersand lo als havede laredtypes[22℄. Figure1(a)showsaJavamethod, andFigure1(b)showsatextualrepresentationoftheJimple
byte odein lass les,andnotfromthehigh-levelJava pro-grams. Thismeansthatwe ananalyzeJavabyte odethat hasbeenprodu edbyany ompiler,optimizer,orothertool.
Afteranalysisandtransformationwe onverttheJimple rep-resentationba ktoJavabyte ode,makingourentiresystem abyte odetobyte odeoptimizer[37℄.
Intermsofouranalysis,thereareseveralimportantpoints to note. Firstly, there are relatively few kinds of Jimple statements,andea hstatementhasasimpleformat. Thus, our analyses an be spe i edby giving the rules for ea h kind of Jimple statement. Further, all operands in Jim-ple are either variable referen es or onstants. Sin e we have a de lared type for ea h variable, and ea h onstant hasatype,ouranalyses anuse thistypeinformation ina straightforward manner. Another important point is that Jimplesplitsvariablesa ording toD/UandU/Dwebs,so that twounrelatedvariablesof thesame namewill not be onfusedinouranalyses.
Figure1(b)showsexamplesofassignmentstatements, on-ditional statements, method alls, and return statements. Also notethat at the beginningof ea hmethodthereare spe ialidentitystatementsthatprovideexpli itassignments from parameters(in ludingthe impli it\this"parameter), andlo als.
2.2
Class Hierarchy Analysis and the
Conser-vative Call Graph
Theobje tiveofallofouranalysesistodetermine,at ompile-time,a allgraphwithasfewnodesandedgesas possible. Allofouranalysesstartwitha onservative allgraphthat isbuiltusing lasshierar hyanalysis.
2.2.1
Class Hierarchy Analysis
Class hierar hy analysis is a standard method for onser-vatively estimating the run-timetypes of re eivers [8, 14, 21℄. Given a re eiver oof witha de lared type d, hierar- hytypes(d)forJavaisde nedasfollows:
If re eiver o has a de lared lass type C, the possi-blerun-timetypesofo,hierar hytypes(C),in ludesC plusallsub lassesofC.
Ifre eiverohasade laredinterfa etypeI,thepossible run-timetypesof o, hierar hytypes(I), in ludes: (1) thesetofall lasses thatimplementIorimplementa subinterfa eofI,whi hwe allimplements(I),plus(2) allsub lassesofimplements(I).
Toimplementthisanalysis,wesimplybuildaninternal rep-resentationoftheinheritan ehierar hy,andthenweusethis hierar hyto omputetheappropriatehierar hytypessets.
2.2.2
Call Graphs
Forourpurposesa allgraph onsistsofnodesanddire ted edges. Forasingle-threadedappli ation,the allgraphmust in ludeonenodeforea hmethodthat anberea hedbya
publi int stepPoly(int x) { if(x < 0) { System.out.println("err or") ; return -1; } else if(x <= 5) return x * x; else return x * 5 + 16; } { java.io.PrintStream r1; Example r0;
int i0, i1, i2, i3;
r0 := this; i0 := parameter0; if i0 >= 0 goto label0; r1 = java.lang.System.out; r1.println("error"); return -1; label0: if i0 > 5 goto label1; i1 = i0 * i0; return i1; label1: i3 = i0 * 5; i2 = i3 + 16; return i2; }
(a)Javasour e (b)Jimplerepresentation
Figure1: Example ofJimple
is anappletor has threads, then the all graphmustalso in ludeallmethodsthat anberea hedstartingatanyentry point. Anexample allgraphisgiveninFigure2(b).
Ea hnodeinthe allgraph ontainsa olle tionof allsites. ConsideramethodMfrom lassCwithnmethod allsinits body. MethodM isrepresentedinthe allgraphbyanode labeledC :M,andthisnodewill ontainentriesforea h all site,whi hwedenoteC :M[1℄toC :M[n℄. Inourexample,the allgraphnodefor methodC.main ontainstwo allsites, C :main[1℄whi hisa.m(),andC :main[2℄whi hisb.m().
Edgesinthe allgraphgofrom allsiteswithina allgraph node, to all graph nodes. The all graph must ontain anedge for ea h possible alling relationship between all sitesand nodes. Ifit is possible that allsite C :M[i℄ alls methodC
0 :M
0
,thentheremustbeanedgebetweenC :M[i℄ andC
0 :M
0
inthe allgraph. Intheexample allgraphthere arethreeedgesfromthe allsitea.m() orrespondingtothe fa tthatthevirtual alla.m()mightresolveto allstoA.m, B.morC.m.
Spe ialattentionisrequiredwhenadding allingedgesfrom avirtualmethodorinterfa e all,andthisisdoneusingan approximationoftherun-timetypesofthere eiver. Given avirtual allsiteC :M[i℄ ofthe form o:m(a1;:::;an), and asetof possibleruntimetypesforre eivero, allthis run-timetypes(o),we ndallpossibletargetsofthe allas fol-lows. Forea htypeCiinruntimetypes(o),lookupthe lass hierar hy starting atCi untila lassCtargetis found that in ludesamethodC
target
:mthatmat hes thesignatureof m. TheedgefromC :M[i℄to Ctarget:misaddedto the all graph.
Considerthethe alla.m()inthe exampleinFigure2. If thepossibleruntimetypesforre eiverain ludesfA;B;Cg, theninea h aseamat hingmethodmisfoundinthe lass
itself (withoutlooking furtherup the hierar hy),and thus the all edges to A.m, B.m, and C.m are added. However, sometimes thetarget methodisfound furtherup the hier-ar hy. Consider the all this.toString(). If thepossible runtimetypesforthere eiverthisarefA;B;Cg,then look-ing up the hierar hy in ea h ase will result in the target Obje t.toString().
Note that a all graph may ontain spurious nodes and edges. Spurious edges maybe in ludedforvirtual method alls. Whenadding alledgesfromavirtualmethod allsite C :M[i℄oftheformo:m(a
1 ;:::;a
n
),anedgemustbepla ed betweenthis allsiteandeverymethodC
0
:m orresponding to the possible run-timetypesof there eivero. If we use a onservative approximation of the run-time types for o, thenwemayin ludespurious typesinourapproximation, andthismayleadtospuriousedges. Inourexample,ifthe typeofthere eiverainthe alla.m() anonlyhavea run-timetypeofA,thentheedgestoB.mandC.marespurious. Spuriousnodesarein ludedwhenallin omingedgestothe nodeare spurious. Intheexample, iftheedgefroma.m() to C.m is spurious, then the node C.m would also be ome spurious. Notethatentiresubpie esofthe allgraph ould be omespuriousifthesubgraphbe omesdis onne tedfrom the roots of the graph. In the example, if the edge from a.m()toA.mwasspurious,thenboththenodesforA.mand Obje t.toString be omespurious.
Theanalysespresentedinthispaperaredesignedtoredu e thenumberofspuriousedgesandnodesbyprovidingbetter approximationsoftheruntimetypesofre eivers.
2.2.3
Building the Conservative Call Graph
Inourimplementation, allgraphsarebuiltiterativelyusing a worklist strategy. The worklist starts withnodes for all possible entry points(for example, main, start, run). As
String m() { return(this.toString()); } } lass B extends A { String m() { ... } } lass C extends A { String m() { ... }
publi stati void main(...) { A a = new A(); B b = new B(); String s; ... s = a.m(); s = b.m(); } }
m()
B
m()
A
C
m()
main()
Object
toString()
Class Hierarchy
Call Graph
this.toString()
a.m()
b.m()
C.main
A.m
B.m
C.m
Object.toString
(a)ExampleProgram (b)ClassHierar hyandCallGraph
Figure2: Example ofa onservative all graph
the allsitesinthenodearealsoadded. Ifthetargetofan edgeisnotalreadyinthe allgraph,thenitisaddedtothe allgraphandtotheworklist. Conservative allgraphsare builtusinghierar hy typesastheestimateforruntime types fordeterminingtheedgesfromvirtualmethod allsites.
Consider the example in Figure 2. The onservative all graphstartswith theentry methodC.main whi hin ludes two allsitesa.m()andb.m(). Next,edgesareaddedfrom a.m(). The type of re eiver a is estimated using hierar- hyanalysisonthede laredtypeofa,hierar hy types(A)= fA,B,Cg. For ea h element of this set, the appropriate methodmislo ated,leadingtothree alledges toA.m,B.m andC.m. Forthe allsiteb.m(),thede laredtypeofbisB, hierar hy types(B)=fBg, andso thereisonlyoneoneedge toB.m. There isoneremaining allsite, this.toString() whi his inside methodA.m. The de laredtypeof this is A,andhierar hytypes(A)=fA,B,Cg. However,inthis ase all three types lead to the same all edge to the method Obje t.toString(). Thisillustratesthepointthatatighter estimateofrun-timetypesmaynotne essarilyleadtofewer edges.
Inourworkweusethenumberof alledgesfroma allsite (andnotthe numberofrun-timetypesof there eiver)to determineifthe allsiteismonomorphi orpolymorphi . If thereisonlyoneedgefroma allsite,we ategorizethe all siteasmonomorphi ,whereasiftherearetwoormoreedges we ategorizethe allsiteaspolymorphi . Inthe allgraph inFigure2,the alla.m()ispolymorphi ,whereasthe alls b.m()andthis.toString() aremonomorphi .
2.3
Rapid Type Analysis
Rapid type analysis [8℄ is averysimpleway of improving the estimate of the types of re eivers. The observation is thata re eiver anonly havea typeof anobje t thathas beeninstantiatedviaanew. Thus,one an olle tthesetof obje ttypesinstantiatedintheprogramP, allthis instan-tiatedtypes(P).Givenare eiverowithde laredtypeCwith
ar hy types(C)\instantiated types(P) asabetterestimate oftheruntimetypesforo.
Asanexample, onsidertheprogramPgiveninFigure2(a), andassumethattheprogram ontainsinstantiationsof ob-je ts of type A and B. Now onsider the all site a.m(), where a has de lared type A. In this ase we would use rapid types(P,A) =fA,Bgto ndtheruntimetypesfor re- eiver a. Thisleads to onlytwo all edges, to A.m and to B.m. So,usingrapidtypeanalysisthe allgraphwouldnot in ludethe alledgeto C.m,norwould itin ludethenode forC.m.
Thisparti ularversionofrapidtypeanalysisshouldbe alled pessimisti rapid type analysissin eitstartswiththe om-plete onservative all graph built by CHA and looks for all instantiations inmethodin that all graph. This may, therefore, nd aninstantiation whi h is ina method that should really be removed from the all graph. The origi-nal approa h suggestedbyBa on andSweeney [8℄ is opti-misti rapid type analysis. Inthe optimisti approa h the allgraphis iteratively reated,and onlyinstantiations in methods alreadyin the allgraphare onsidered as possi-blesetfor omputinginstantiated types(P).Wehave imple-mentedbothvariationsand giveexperimentalresults om-paringtheminSe tion4.
3.
VARIABLE-TYPE AND DECLARED-TYPE
ANALYSES
Rapidtypeanalysis anbe onsideredtobeavery oarse-grainme hanismforapproximatingwhi htypesrea ha re- eiverofamethodinvo ation. Ine e t,rapidtypeanalysis says that a type A rea hes a re eiver o if there is an in-stantiation of anobje tof type A (i.e. an expression new A()) anywhere inthe program, and A is a plausible type for ousing lasshierar hyanalysis. Inthisse tion we pro-pose twoanalysesthatresultin ner-grainapproximations bytakinginto onsideration hainsofassignmentsbetween
putationsarebrokendownintosimpleassignments,and as-sumingnoaliasing betweenvariables,we anstatethe fol-lowing property.
1
ForatypeA torea h are eiverothere mustbe some exe ution path through the programwhi h startswitha allofa onstru tor oftheform v=newA() followed by some hain of assignments of the form x1 = v;x2 =x1;:::;xn =xn 1;o=xn. Theindividual assign-mentsmayberegularassignmentstatements,ortheimpli it assignmentsperformed atmethodinvo ationsand method returns.
Weproposetwo ow-insensitiveapproximationsofthis rea h-ing-typesproperty. Bothanalysespro eedby: (1)building a type propagation graph where nodes represent variables, andea hedgea!brepresentsanassignmentoftheformb = a,(2)initializing rea hingtypeinformationgeneratedby assignmentsoftheformb = new A()(i.e. thenode asso i-atedwith b is initializedwith the type A) and, (3) propa-gatingtypeinformationalongdire tededges orresponding to hainsofassignments.
ForaprogramP,ea hvariableawithanobje t(referen e) typeis asso iatedwithsomenodeinthe typepropagation graph, alledrepresentative(a). Afterpropagatingthetypes, ea hnodeninthetypepropagationgraphisasso iatedwith asetoftypes, alled rea hingtypes(n). Thus,after propa-gating typeswe an ndout theset oftypesrea hing any variable. Forbuilding allgraphsweare parti ularly inter-estedintypesrea hingvariablesusedasre eivers. Givena re eivero, withde lared typeC, we approximate the run-timetypesofousingrea hingtypes(representative(o))\ hi-erar hy types(C).Notethatwe lteroutimpossiblerea hing typesbyinterse tingwithpossibletypesasindi atedby hi-erar hytypes.
Inthefollowingsubse tionswedes ribetheanalysisinmore detail. We rst present the morea urate analysis, alled variable-typeanalysis,wheretherepresentativeforavariable aisthenameofa,andthenexplaina oarser-grainvariant alled de lared-type analysis where therepresentativefor a isthede laredtypeofa.
3.1
Variable-type analysis
Variable type analysisusesthe \name"ofa variableas its representative. InJimplewe anhave threekindsof vari-ablereferen es(more omplexreferen esaresimpli edinto a ombinationof these simpleones), and we assign repre-sentativenamesasfollows:
Ordinaryreferen es: areoftheforma,andreferto lo- als or parameters. The name C.m.a is used as our representative, whereCistheen losing lassandmis theen losingmethod.
Fieldreferen es: areoftheforma.fwherea ouldbea lo al, aparameter,or thespe ialidenti erthis. We useastherepresentativethenameC.fwhereCisthe name of the lass de ning eld f. Note that we ig-nore a, so this means that we are approximating all 1
Wedis usswhywedonothaveto onsideraliasingin
Se -tivenodeinthetypepropagationgraph.
Arrayreferen es: areoftheforma[x℄,whereaisalo al orparameter,andxisalo al,parameter,or onstant. We treat arraysas onelarge aggregate, so the name C.m.aisused,similartotheordinaryreferen e ase.
3.1.1
Constructing the type propagation graph
GivenaprogramP,whereP onsistsofall lassesthatare referredtointhe onservative allgraph,nodesare reated asfollows:
forevery lassCthatisin ludedinP forevery eldf inC,wheref hasan
obje t(referen e)type
reateanodelabeledwithC :f
foreverymethodC :mthat isin ludedinthe onservative allgraphofP
foreveryformalparameterp i
ofC :m, wherep
i
hasanobje ttype reateanodelabeledC :m:pi foreverylo alvariablel
i
ofC :m, wherel
i
hasanobje ttype reateanodelabeledC :m:li reateanodelabeledC :m:thisto
representtheimpli it rstparameter reateanodelabeledC :m:returnto
representthereturnvalueC :m
Notethatthe lasttworules anbeoptimizedto add the C :m:this node only when the method refers to this,and to addC :m:return onlywhenthemethod returns anobje ttype. Thisdoes not a e tthe a - ura yoftheresult,itjustleavesoutnodesthatwill havenoedgestothem.
On eall of thenodes havebeen reated,weadd edgesfor all assignments that involve assigning to a variable with an obje t type. These may beeither expli it assignments viaassignmentstatements,andimpli itassignmentsdueto methodinvo ationandreturns.Edgesareaddedasfollows:
AssignmentStatements: are allintheformlhs=rhs; or lhs =(C) rhs;, where thelhs and rhs mustbean ordinary, eldor array referen e. For ea hstatement of this form,we add adire ted edge from the repre-sentative node for rhs to the representative node of lhs.
MethodCalls: areintheformofl hs=o:m(a1;a2;:::;an); or o:m(a1;a2;:::;an);. There eiveromustbe a lo- al,aparameter, orthe spe ialidenti er this. Ea h argument mustbe a onstant, a lo al, or parameter name.
The method all orresponds to some all site, all itC.m[i℄, inthe onservative allgraph. Assignment edgesareaddedasfollows:
forea hC 0
:m 0
toC 0
:m 0
:this
ifthereturntypeisnotvoid addanedgefromC
0 :m
0
:returnto therepresentativeforl hs
forea hargumentai thathasobje ttype addanedgefromtherepresentativeofaito
therep. ofthemat hingparameterofC 0
:m 0
.
Notethat wehandle native methodsby summarizing their e e tonour analyses. Noneoftheben hmarks forwhi hwepresentresultshaveanynativemethods; buttherearesomenativemethodsintheJavalibrary that are alled bytheseben hmarks. We have exam-inedthe odefortheseJavalibrarynativemethodsin theopensour eKa eOpenVM[2℄inorderto ndthe appropriatesummary.
InFigure 3(a) wegive the important parts of anexample program. Note that sin e our analysis is ow-insensitive, the order of assignments is not important, nor is ontrol ow. Thus, this list of assignments representsa program that ontains those assignments. This program has only ordinary variables of the form a1, a2, a3, b1, b2, b3, .
2 Figure3(b)showstheinitial graph. There isonenodeper variable, and one edge per assignment. For example, the assignment a3 = b3; orresponds to the edge from b3 to a3.
3.1.2
Aliases
All of the assignment rules assume that a variable refer-en e, and all of itsaliases, are represented by exa tly one node in the type propagation graph. That is, if a and b are aliases, thentheyshould orrespond tothe same node inthegraph. Infa t, thisisoneofthekeypropertiesthat makes our analysis simple. This property is true for or-dinaryreferen esbe ause lo als andparameters annotbe aliased inJava.
3
It isalso truefor eld referen esbe ause we representall instan esof obje ts withthat eld as one nodeinthe graph. So, if two eldreferen es a.fand b.f arealiased(a andb referto thesameobje t) itis ne be- ausewearerepresentingthembothwitha eld alledC.f. However, itis nottruefor array referen esbe ause several di erent variablenamesmay referto thesame array. Fur-ther, referen es to arrays an be stored in variables with typejava.lang.Obje t. Forexample, onsiderthe follow-ingsmallexample: A[℄ a = new A[10℄; Obje t o1 = a; Obje t o2 = o1; A[℄ b = (A[℄) o2; .
Inthis asea,o,o1,o2and bareall referringtothesame array. So,anassignment toa[i℄isalsoassigningtob[i℄.
Thus, whenadding edges for assignments of the form lhs =rhs, wherebothsides are oftype java.lang.Obje t, or whenatleastonesidehasanarraytype,edgesareaddedin bothdire tionsbetweentherepresentativesofrhsandlhs. Thisen odes thealiasing relationship, and bothnodes are 2
Inthea tualanalysisthenamesarequali edbytheir sur-rounding lassnameandmethodname,weusethe unqual-i edvariablenametokeepourexamplesimple.
3
Thatis, twolo als a andb mustrepresentdi erent lo a-tions, and there is nome hanism for getting a pointer to
thissituationo urringveryfrequentlyinourben hmarks.
3.1.3
Size of the propagation graph
Thetypepropagationgraphin ludesatmost2M+P+L+F nodes, where M is thenumberofmethods,P is thetotal numberof parameters with anobje t type, L is the total numberlo alswithanobje ttype,andF isthenumberof eldswithanobje ttype. Thus,thenumberofnodesgrows linearlywiththesizeoftheprogram.
The numberofedges is slightlymore diÆ ultto estimate. Thereisatmostoneedgeforea hassignmentstatementin theprogram. However,thenumberofedgesduetomethod allsdependsonthenumberoftargetsfor allsites. Inthe worst ase a method all may have C targets, where C is thenumberof lassesintheprogramunderanalysis. Thus, ea hmethod all ouldresultinC(2+numparams)edges beingaddedtothetypepropagationgraph. So,itispossible tohaveO(CM )edges,whereCisthenumberof lasses andM
isthenumberofmethod allsintheprogramunder analysis. In pra ti ewedo not ndthis behavior, and in fa t thegraphsarequitesparse(seeTable4in Se tion4).
3.1.4
Initializing and propagating types
In the initialization phase, we visit ea h statement of the form lhs = new A(); or lhs = new A[n℄;. For ea h su h statement we add the typeA to the Rea hingTypes set of therepresentativenodefor lhs. Figure3( )showsthetype initializationfortheexampleprogram.
After initialization, we propagate types. This is a om-plishedintwophases. The rstphase ndsstrongly- onne ted omponentsinthetypepropagationgraph. Ea h strongly- onne ted omponentisthen ollapsedintoonesupernode, withRea hingTypesofthis ollapsednodeinitializedtothe unionofallRea hingTypesofits onstituent nodes. Figure 3(d) shows two nodes ollapsed. Inthis ase neither node hadaninitialtypeassignment,sothe ollapsednodehasno typeassignmenteither.
After ollapsingthestrongly- onne ted omponents,the re-maining graph is a DAG, and types are propagated in a single pass starting from the roots in a topologi al man-ner, where a node is pro essed only after all of its prede- essors have already been pro essed. Note that both the strongly- onne ted omponent dete tion and propagation on the DAG has omplexity of O(max(N;E))operations, wherethemostexpensiveoperationisaunionoftwo Rea h-ingTypesets.
Figure3(e)shows the nalsolutionfor oursmallexample. From this solution we an infer that variables a1, a2, a3 and b3 havea rea hingtypeA (i.e. they anonlyrefer to obje tsoftypeA).Variableb2hasarea hingtypeB, has area hingtypeofC,andb3hasarea hingtypeofA,B.
3.2
Declared-Type Analysis
De lared-typeanalysispro eedsexa tlyasvariable-type anal-ysis,ex eptforthewayinwhi hweallo ate representative nodesforvariables.Inde lared-typeanalysisweusethe
de-a1
b1
b2
a2
a3
b3
c
{B}
{C}
{A}
{A}
{B}
a1
b1
b2
a2
a3
b3
c
{B}
{C}
{A}
{A}
{B}
a1
b1
b2
a2
a3
b3
c
A a1, a2, a3;
B b1, b2, b3;
C c;
b1 = new B();
b2 = new B();
c = new C();
a1 = a2;
a3 = a1;
a1 = new A();
a2 = new A();
b1 = b2;
a3 = b3;
b3 = (B) a3;
(b) Nodes and Edges
(c) Initial Types
(d) Strongly-connected components
(e) final solution
b1 = c;
(a) Program
{C}
{A}
{A}
{B}
a1
b1
b2
a2
a3
b3
c
{A}
{B,C}
Figure3: Example ofavariable-type analysis
thevariablename. Basi ally,thisisjustputtingallvariables withthesamede laredtypeintothesameequivalen e lass. Figure4showsthede lared-typeanalysisforsameprogram forwhi hwepreviously omputedthe variable-type analy-sis. Notethatthesize ofthegraphis onsiderablysmaller, butalsothe nalanswerisnotaspre ise. Thede lared-type analysis on ludedthat all variableswith de laredtypeof Cmustpoint toC obje ts. However, it onservatively on- ludesthat variableswith ade lared type ofA or Bmight point to A,Bor C obje ts. InSe tion 4we present empir-i alresults to evaluate these two analyses with respe tto a ura yandthesizeofthegraphproblemtobesolved.
3.3
Tradeoffs
Wehavedesignedourapproa htoworkwellwithJava, par-ti ularlyforlarge,obje t-oriented ben hmarks. Inorderto keep our algorithm simple and eÆ ient, yet e e tive, we havemadeseveraldesignde isions:
Avoidingsolving the aliasing problem: Weavoid hav-ingtosolvethegeneralaliasingproblemby represent-ing all instan esof eld f of lassC as onevariable name (as des ribed inse tion 3.1.2). This keeps the analysis simple. Arrays do introdu e one restri ted sort of aliasing, and we handle this by introdu ing
arrays.
No killing basedon astsor de lared type: Forea h as-signment statement l hs = rhs or l hs = (C)rhs, we alwayspropagate all typesfromthe node for rhs to thenodeforl hs. One ouldimagineanalgorithmthat removedimpossibletypesbasedonthede laredtype of rhs or the type given in the ast expression (C). However, this would lead to information being killed alongsomeedges,anditwouldrequireeitheran itera-tiveworklistsolveroramore omplex onstraintsolver (i.e. itwouldnolongerbepossibleto ollapsestrongly onne ted omponents and solve simply in one pass overthegraph).
It should be noted that we do lter out impossible types after we have the nal solution. That is, for ea hvariableweusethede laredtypeofthevariable and lasshierar hyanalysistoeliminateanyrea hing typesthatare notpossible.
Apessimisti algorithm: Ouralgorithmispessimisti in thesensethat itaddsedges forall method alls that are indi ated by the onservative all graph. This meansthatwemayin ludespuriousedges,andtypes may propagate along those edges. The opposite ap-proa hwouldbetooptimisti allyassumethatmethod
A
B
C
A
B
C
{A}
{B}
{C}
{C}
A
B
C
{A,B}
(b) Nodes and Edges
(c) Initial Types
(d) Strongly-connected components
(e) final solution
{C}
A
B
C
{A,B,C}
A a1, a2, a3;
B b1, b2, b3;
C c;
b1 = new B();
b2 = new B();
c = new C();
a1 = a2;
a3 = a1;
a1 = new A();
a2 = new A();
b1 = b2;
a3 = b3;
b3 = (B) a3;
b1 = c;
(a) Program
Figure 4: Example ofade lared-type analysis
that orrespond to the types urrentlyrea hing oat ea hstepof the analysis. Thisset would in reaseas theanalysis pro eeds,andon eagainiteration would berequired.
We animprove our pessimisti algorithm by giving it abetter onservative all graphtostart with. We experimented with twovariations: (1)using the all graph generated using optimisti rapid type analysis as input to variable-type analysis; and (2) usingthe outputofvariable-typeanalysisastheinputfora se -onditerationofvariable-typeanalysis.
Aninterpro edural, wholeprogram, approa h: Ano-theralternativetoourapproa histopropagate rea h-ing type information intrapro edurally, and perform onservative approximationsfor the e e t of method alls. By studying the more obje t-oriented ben h-marks,wefoundthatmanyoftherea hingtypeswere really being propagatedinterpro edurally,and so we designed our analysis to workon atypepropagation graphthaten odesthewholeprogram,withalledges for method allsandreturns.
Basedon atyped 3-addressrepresentation: Our ap-proa hwas implemented using Jimple,an intermedi-ate representation that provides expli it names and typesfor all lo alvariables. This allows our analysis to beverysimple. Sin eallassignmentsare between expli it, named lo ations, we an represent the type propagation graph in an obvious fashion. The fa t that lo alvariableshave atype isalso usefulfor two reasons[22℄. First,itmakesthede nitionof de lared-typeanalysis trivial. Se ond, ithelpsto improvethe pre ision ofthe onservative allgraph, sin e the de- laredtypeofare eivermaybetighterthanthetype inthesignatureen odedinthe orresponding invoke-virtualorinvokeinterfa ebyte odeinstru tion.
4.
EXPERIMENTAL RESULTS
Wehaveexperimentedwithsevenben hmarks,as outlined inTable1. ThefourSPECjvmben hmarksin luderaytra e whi hisagraphi sraytra er, ompresswhi hisa ompres-sionprogrambasedonamodi edLempel-Zivmethod,ja k whi hisaJavaparsergeneratorbasedonthePurdue Com-piler Constru tionToolSet (PCCTS), andjava whi h is the Java ompiler fromSun's JDK 1.0.2. Theotherthree ben hmarksin ludesable whi hisa ompiler frontend generator written inJava[3℄, soot is an earlier version of our ompilerframework[1℄,andpizzaisthePizza ompiler [4℄. Forallben hmarks,theJavalibraryusedwasfromthe Bla kdownlinuxport,JDK1.1.7.
Thestatisti sinTable1provideaninsightintothenatureof the ben hmarksfor whi hwe have ondu tedexperiments. In the olumn labeled # Stmts, we show the number of Jimplestatementsinthewholeappli ation(ben hmarkplus Java libraries a essed by the appli ation), and the num-ber of Jimple statements in onlythe ben hmark (without libraries). Inthe olumnlabeledHierar hywegivethe av-erage andmaximumdepthofthe inheritan ehierar hyfor thewholeappli ationandben hmarkonly. Thesenumbers not only measure the extent of obje t orientedness of the wholeappli ation,butarealsousefulindis overingwhether itistheben hmarkitselfthathasbeenwritteninanobje t oriented manner, or if the Javalibraries are the sour e of obje torientedness. Forexample,we anseethatraytra e and ompressarenotveryobje t-oriented. The olumn la-beledClassesand Interfa esgivesthenumberof lasses and interfa esthat ome from the library, the ben hmark odeonly,andtheoveralltotal.
Table2givesasummaryofthe onservative allgraphbuilt forea hben hmarkusingClassHierar hyAnalysis(CHA). We havemeasured the onservative allgraph hara teris-ti sforthewholeappli ation(in ludingthelibrary)aswell as theportions ofthe allgraphrelatedto theben hmark alone. A ordingly,Table2isdividedinto2distin tparts.
avg. depth max. depth library ben h. whole whole ben h. whole ben h. whole ben h. only app. lang. name app. only app. only app. only lass int. lass int. (total) java 205raytra e 49239 5347 3.0 1.3 6 3 274 41 34 1 350 java 201 ompress 46619 2727 3.0 1.1 6 2 274 41 21 1 337 java 228ja k 55107 11215 3.0 1.6 6 3 274 41 62 5 382 java 213java 69585 25304 3.5 3.2 8 7 277 41 177 5 500 java sable -w 68575 24621 3.2 2.3 6 5 276 41 298 13 628 java soot- 63506 33396 3.3 2.1 6 4 185 11 497 34 727 pizza pizza ompiler 73130 42805 3.0 1.7 6 5 187 11 207 11 416
Table1: Ben hmarkChara teristi s
Name WholeAppli ation Ben hmarkOnly
CallSites Edges CallSites Edges
jNj pot. pot. jNj pot. pot.
mono. poly. total mono. poly. total mono. poly. total mono. poly. total raytra e 1729 6582 377 6959 6576 2591 9167 207 2037 12 2049 2037 46 2083 ompress 1583 5450 369 5819 5444 2556 8000 76 927 6 933 927 30 957 ja k 1857 7191 779 7970 7185 3619 10804 337 2672 396 3068 2672 992 3664 java 2821 10570 1276 11846 10564 13707 24271 1188 5933 848 6781 5933 10306 16239 sable 3737 11151 1332 12483 11140 24553 35693 1955 5920 889 6809 5920 20736 26656 soot 2828 11653 1738 13391 11653 25331 36984 2001 9070 1545 10615 9070 22620 31690 pizza 2660 13729 799 14528 13729 6024 19753 1756 11115 577 11692 11115 4069 15184
Table2: Conservative CallGraph Chara teristi s
First onsider the hara teristi s of thewhole appli ation, in ludinglibraries. Column1showsthenumberofmethods that are in the all graph. Note that this number mea-suresthenumberofmethodsthat might be alledstarting at all possible entry points, basedon CHA, and doesnot in ludemethodsthat annotberea hedfromarootinthe onservative all graph. Column 2 shows the number of monomorphi all sitesinmethodsinthe allgraph. The monomorphi sites in lude allsitesfor invokestati and invokespe ialinstru tionsaswellas allsitesfor invoke-virtualandinvokeinterfa e instru tionsthathavebeen resolved toexa tly onemethodby CHA.Column3shows the number of potentially-polymorphi sites i.e. invoke-virtualandinvokeinterfa einstru tionsthathavemore than1 targetafter performing CHA.Column4shows the totalnumberof allsitesinthewholeappli ation. Column5 showsthenumberofmonomorphi edges(edgesfrom mono-morphi all sites), while olumn 6 shows the number of potentially-polymorphi edges(edgesfrom potentially-poly-morphi all sites). Column7 shows the total numberof edgesinthewholeappli ation.
Now onsiderthe se ondpart ofTable 2,whi hshows the hara teristi softheben hmarkonly,notin ludingany li-brarymethods. Thispartofthetablein ludesallmethods fromthe allgraphthat donotbelong totheJavalibrary, allsites insidethese methods, and the edges atta hedto these allsites. These guresgivea learideaaboutthe per-forman eofCHAonthe ben hmark lasses. For example, itis learthatthereishardlyanys opeforimprovementof theben hmarkportionofthe allgraphinben hmarkslike raytra e or ompress, whereas inben hmarks likejava , soot,orsable therearemanyunresolved allsites.
Table3summarizesthee e tofapplyingavarietyof te h-niques onthe onservative allgraph. In thistable pRTA ispessimisti rapidtypeanalysis,oRTAisoptimisti rapid type analysis, DTA is de lared-type analysis, and VTA is variable-typeanalysis. Wealsogavetwo ombinations: oRTA+VTAisthe ombinationof rstusingoRTAtobuild apruned allgraph,andthenapplyingVTA;andVTA+VTA is theresult of rstusingoneappli ationof VTA toget a pruned allgraph,and thenapplyingVTAonthat pruned graph.
4.1
Reducing the size of the Conservative Call
Graph
Oneuseofouranalysesistoredu ethesizeofthe allgraph. Eliminatingmethodsfromthe allgraphmeansthatthese methodsdonotneedtobein ludedintheappli ation. This leads to smaller, ompa ted lass les for appli ations, or smaller exe utables for ompilers that translate lass les for ompleteappli ationstonative ode. Further,redu ing methodsand alledgesresultsinsmaller allgraphswhi h anmakesubsequentinterpro eduralanalysesmoreeÆ ient andmorea urate. InTable3,the olumnslabeledNodes Removed andEdges Removedsummarizes thenumber andper entageofnodes/edgesremovedforea hanalysis.
Rapid type analysis has been shown to be quite e e tive for C++ ben hmarks [8℄,parti ularly for removingunused methods and all edges from the all graph for omplete appli ations (in luding libraries). Inthis ase the library odeoften ontainsmanymethodsthatarenever alledby aparti ularappli ation. Ourresults on rmthatrapidtype
Nodes Edges Callsites Nodes Edges Callsites Removed Removed Resolved Removed Removed Resolved
(%tot.) (%tot.) (%poly) (%tot.) (%tot.) (%tot.) (%poly) (%tot.) raytra e pRTA 808 (46%) 3585 (39%) 292 (77%) (4.2%) 15 (7%) 46 (2%) 5 (41%) (0.2%) oRTA 884 (51%) 4128 (45%) 300 (79%) (4.3%) 15 (7%) 46 (2%) 5 (41%) (0.2%) DTA 925 (53%) 4375 (47%) 304 (80%) (4.4%) 18 (8%) 55 (2%) 5 (41%) (0.2%) VTA 1026 (59%) 5200 (56%) 342 (90%) (4.9%) 18 (8%) 68 (3%) 5 (41%) (0.2%) oRTA+VTA 1031 (59%) 5242 (57%) 342 (90%) (4.9%) 18 (8%) 68 (3%) 5 (41%) (0.2%) VTA+VTA 1026 (59%) 5200 (56%) 342 (90%) (4.9%) 18 (8%) 68 (3%) 5 (41%) (0.2%) ompress pRTA 814 (51%) 3664 (45%) 293 (79%) (5.0%) 11 (14%) 40 (4%) 3 (50%) (0.3%) oRTA 890 (56%) 4207 (52%) 301 (81%) (5.2%) 11 (14%) 40 (4%) 3 (50%) (0.3%) DTA 926 (58%) 4418 (55%) 303 (82%) (5.2%) 16 (21%) 62 (6%) 4 (66%) (0.4%) VTA 1033 (65%) 5214 (65%) 344 (93%) (5.9%) 16 (21%) 70 (7%) 4 (66%) (0.4%) oRTA+VTA 1039 (65%) 5256 (65%) 346 (93%) (5.9%) 16 (21%) 70 (7%) 4 (66%) (0.4%) VTA+VTA 1033 (65%) 5214 (65%) 344 (93%) (5.9%) 16 (21%) 70 (7%) 4 (66%) (0.4%) ja k pRTA 820 (44%) 3763 (34%) 313 (40%) (3.9%) 17 (5%) 121 (3%) 21 (5%) (0.7%) oRTA 896 (48%) 4306 (39%) 321 (41%) (4.0%) 17 (5%) 121 (3%) 21 (5%) (0.7%) DTA 924 (50%) 4475 (41%) 323 (41%) (4.1%) 20 (5%) 184 (5%) 21 (5%) (0.7%) VTA 1027 (55%) 5719 (52%) 734 (94%) (9.2%) 21 (6%) 565 (15%) 382 (96%) (12.5%) oRTA+VTA 1033 (55%) 5769 (53%) 735 (94%) (9.2%) 21 (6%) 565 (15%) 382 (96%) (12.5%) VTA+VTA 1027 (55%) 5719 (52%) 734 (94%) (9.2%) 21 (6%) 565 (15%) 382 (96%) (12.5%) java pRTA 823 (29%) 4516 (18%) 319 (25%) (2.7%) 30 (2%) 713 (4%) 30 (3%) (0.4%) oRTA 886 (31%) 5056 (20%) 327 (25%) (2.8%) 30 (2%) 738 (4%) 30 (3%) (0.4%) DTA 931 (33%) 5460 (22%) 337 (26%) (2.8%) 33 (2%) 855 (5%) 30 (3%) (0.4%) VTA 1001 (35%) 6639 (27%) 489 (38%) (4.1%) 35 (2%) 1136 (6%) 135 (15%) (2.0%) oRTA+VTA 1005 (35%) 6682 (27%) 489 (38%) (4.1%) 35 (2%) 1144 (7%) 135 (15%) (2.0%) VTA+VTA 1001 (35%) 6639 (27%) 489 (38%) (4.1%) 35 (2%) 1136 (6%) 135 (15%) (2.0%) sable pRTA 657 (17%) 4145 (11%) 407 (30%) (3.3%) 42 (2%) 1077 (4%) 164 (18%) (2.4%) oRTA 708 (18%) 4720 (13%) 421 (31%) (3.4%) 49 (2%) 1220 (4%) 168 (18%) (2.5%) DTA 773 (20%) 5670 (15%) 456 (34%) (3.7%) 75 (3%) 1854 (6%) 192 (21%) (2.8%) VTA 867 (23%) 10723 (30%) 635 (47%) (5.1%) 91 (4%) 5943 (22%) 311 (34%) (4.6%) oRTA+VTA 918 (24%) 11092 (31%) 663 (49%) (5.3%) 91 (4%) 5951 (22%) 311 (34%) (4.6%) VTA+VTA 1016 (27%) 11141 (31%) 680 (51%) (5.4%) 92 (4%) 6005 (22%) 317 (35%) (4.7%) soot pRTA 212 (7%) 2635 (7%) 137 (7%) (1.0%) 60 (2%) 1362 (4%) 38 (2%) (0.4%) oRTA 224 (7%) 2814 (7%) 143 (8%) (1.1%) 60 (2%) 1362 (4%) 38 (2%) (0.4%) DTA 282 (9%) 4061 (10%) 172 (9%) (1.3%) 68 (3%) 2168 (6%) 60 (3%) (0.6%) VTA 328 (11%) 7447 (20%) 657 (37%) (4.9%) 89 (4%) 5027 (15%) 510 (33%) (4.8%) oRTA+VTA 335 (11%) 7669 (20%) 662 (38%) (4.9%) 90 (4%) 5076 (16%) 510 (33%) (4.8%) VTA+VTA 348 (12%) 8380 (22%) 829 (47%) (6.2%) 109 (5%) 5960 (18%) 682 (44%) (6.4%) pizza pRTA 213 (8%) 2097 (10%) 123 (15%) (0.8%) 17 (1%) 643 (4%) 3 (0.3%) (0.0%) oRTA 213 (8%) 2097 (10%) 123 (15%) (0.8%) 17 (1%) 643 (4%) 3 (0.3%) (0.0%) DTA 233 (9%) 2566 (12%) 155 (19%) (1.1%) 20 (1%) 830 (5%) 23 (3%) (0.2%) VTA 270 (10%) 3462 (17%) 270 (32%) (1.9%) 32 (1%) 1418 (9%) 109 (17%) (0.9%) oRTA+VTA 270 (10%) 3462 (17%) 270 (32%) (1.9%) 32 (1%) 1418 (9%) 109 (17%) (0.9%) VTA+VTA 270 (10%) 3462 (17%) 270 (32%) (1.9%) 32 (1%) 1418 (9%) 109 (17%) (0.9%)
Table3: ImprovementofCallGraph overConservativeCall Graph
byte odeben hmarks.
When onsideringthewholeappli ation,thenumberofdead methodnodesremovedbypRTAvariesbetween7% ofthe totalnumberofmethodsinthe onservative allgraph(soot) toabout51%( ompress),andthenumberofedgesremoved bypRTAvariesfrom7%(soot- )to45%( ompress). The optimisti version, oRTA, doesperformbetter thanpRTA onseveralben hmarks,givingahighof56%nodesand52% edgesredu ed( ompress). However,whenyou onsiderthe ben hmark odeonly, weseethat thereismu hlesss ope for improvement, andwe seeverylittle di eren e between oRTAandpRTA.
Bothofournewanalysesshowadditionalbene toveroRTA, withVTAperformingthebest.When onsideringthewhole appli ation,VTAremoves10%(pizza)to65%( ompress) ofthemethodsand17%(pizza)to65%( ompress)ofthe
for thelargeobje t-oriented ben hmarks. Forexample,for sable oRTA removed 13% of the edges, whereas VTA removed30%,andforsootoRTAremoved7%whereasVTA removed20%.
Our ombinedanalyses,oRTA+VTAandVTA+VTA,show smallimprovementsoverVTA,withthe largestimpa tfor theveryobje t-orientedben hmarks,sable andsoot.
These resultsshowthatVTA isquiteusefulfor further re-du ingthesizeofthe allgraph,and ingettingmore om-pa tion by removing additional methods. Note that for large ben hmarks, where a greater proportionof the ode is from the ben hmark itself and not from the library, a mu hsmallerper entageofmethods anberemovedbyall analyses,althoughVTAdoesperformslightlybetter.
fa toring out the library ode. For methods, oRTA elim-inates 1% to 14% and VTA eliminates 1% to 21%. For edges,oRTAeliminates2% to4% andVTAeliminates3% to 22%. VTA works parti ularly well for ja k, sable , sootandpizza. Overall,whenwe onsideronlythe ben h-mark ode,asmallerper entageofmethodsandedges an beeliminated,butthe gapbetweenRTA andVTA anbe moresigni ant, and thegap betweenpRTA and oRTA is lesssigni ant.
4.2
Resolving Virtual Calls
The se ond major measurement is how many potentially polymorphi allsites anberesolvedtoexa tlyonemethod. Belowwepresentbothstati anddynami results.
4.2.1
Static Results
Given the onservative all graphbuilt by CHA,we have measuredhowmanyoftheremainingpotentially polymor-phi sites anberesolvedor eliminatedbyRTA,DTAand VTA. These results are found in Table 3, in the olumns labelledCallsites Resolved. Wesaythata allsiteis re-solvedifitwaspotentiallypolymorphi afterCHAanalysis, butresolvestoexa tlyonemethodafterRTA/DTA/VTA.
4 Wehavepresentedthenumberof allsitesresolved,aswell as two per entages. The olumn labelled %poly gives the per entagewithrespe ttothe numberofpotentially poly-morphi allsitesinthe onservative allgraph,whereasthe olumnlabelled%tot. givestheper entage withrespe tto all allsites. A allsiteiseliminatedifthemethod ontain-ingthe allsiteiseliminatedduetoRTA/DTA/VTA.
First onsider results of the whole ben hmark. VTA per-forms signi antly better than pRTA and oRTA, in some asesresolvingmorethantwi easmany allsites(i.e. ja k, sootand pizza). Next, onsiderthe behavior ofmethods thatarepartoftheben hmarkonly(i.e. notpartoftheJava library). Here we see that the ben hmarks raytra e and ompressdonothaveanyinterestingbehavior. Eventhough the analyses resolves a high per entage of the potentially polymorphi allsites(high%poly),these allsiteswerenot veryimportant inthe overallpi ture (low%tot.). For the remaining veben hmarks we notethat pRTA, oRTAand DTAdonotperformverywell, givinglessthan5%(%poly) on four of the ben hmarks. However, VTA anresolve a signi antnumberof allsiteswithahighof96%(%poly)or 12%(%tot.) forja k. Also,notethatthegapbetweenRTA andVTAisquite largeonall veben hmarks. Thisseems to indi ate that RTA and DTA are notgood at resolving allsites inthe ben hmarkpartof the ode,whereasVTA anresolveasigni antnumber.
4.2.2
Dynamic Results
We have used pro ling to estimate the possible run time-impa toftheanalyses. Weinstrumentedthebyte ode pro-du edbyour ompilertoprodu easummaryofwhi h meth-odswerea tually alledatea hinvokevirtualand invokein-terfa e all,andto olle t theexe utionfrequen yfor ea h allsite. We have on entrated onthe run time behavior of all sites in the ben hmark lasses (ex luding the Java
4
Wehaveshownthenumberofpotentiallypolymorphi all
libraries). Figure5summarizestheper entageofdynami alls that orrespond to invokevirtual/invokeinterfa e all sites that an be resolved to one method (monomorphi all sites). For ea h ben hmark, the rst four bars or-respond to all sites that ould be resolved using CHA, RTA, DTA and VTA. The rightmost bar for ea h ben h-mark shows the result of our dynami pro le (i.e. how many allsitesonly resolved toonemethodduring an a -tual exe ution). For example, inja k,almost 100% ofall invokevirtual/invokeinterfa e allsaremonomorphi at run-time, whereas injava only about 90% are monomorphi atruntime. Ingeneral,we anseesomeinterestingtrends. First,forben hmarksthatarenotveryobje t-oriented,like raytra e and ompress, a simplemethod like CHA nds all monomorphi all sites. Se ond, it appears that RTA and DTA giveverylittle or noimprovementonall ben h-marks, on rming our stati measurements. However, our VTAanalysisdoesgivesomeimprovement,withsigni ant improvementonseveral ofthem. Insome ases (ja k and pizza), we observe that the numberof all sites resolved byVTAisalmostthesameasthenumberofmonomorphi allsobtainedwiththepro le,andinthese asesthereisno needfor anymoresophisti atedanalyses.
Fortwoben hmarks,sootandjava ,weobservethatwhile VTAdidresolvesubstantiallymore allsitesthananyofthe otheranalyses,itisnotabletoperformwellenoughto ap-proa hthe results obtainedinthe pro le. Westudied the reasonsfor thisgaponsootasthe di eren eisgreaterfor this ben hmark, and as it is ananalysis framework devel-oped by us, we had the sour e ode with whi h we were familiar. WeillustratethereasonforVTA'sinabilityto nd all monomorphi alls with a typi al example. The soot frameworkhasanabstra t lassAbstra tValueBox that is a ontainer lassthat de laresa eld holding anobje t of lassValue. Valueisalsoanabstra t lassthatisoverridden byspe i lasseslikeLo al,Instan eField, InvokeExpr. Abstra tValueBox isextendedbyspe i ontainer lasses likeLo alBox,Instan eFieldBoxandInvokeExprBox. These spe i ontainer lasses donot de lare any eldsand the valuesthatare heldintheseboxesare storedintheValue eldofAbstra tValueBox. Thusobje tsbelongingtomany lassesthatoverrideValuerea htheValue eldde laredin Abstra tValueBox. Thea essormethodto gettheValue storedinabox isde nedonlyinAbstra tValueBox andit returns the Value eld. Thus whenevera spe i kind of Valueobje tisputintoaboxandretrieved,all the lasses thatrea hedtheValue eldareinthesetofpossibletypes ( omputed by VTA) for the obje t retrieved. We believe that this would be a problem for evenmore sophisti ated analysesbe ausethestatementsthatputvaluesintheboxes areoftenveryfarfromstatementstakingthevaluesout,and
5
One ommons enario isthat onewouldwant toperform ompiler optimizations onthe ben hmark odealone, and leavetheJavalibrary lassesun hanged(forexample,when performing lass leto lass leoptimizationonuser ode). Thiswasthemainreasoningbehindourde isiontopro le the ben hmark lasses only, as this would give us a good indi ationofthepossibleperforman eimpa tofoptimizing the ben hmark. Also we felt that it would be interesting to measure the di eren e in performan e of the analyses ontheben hmark lassesdynami ally,giventhatthestati results indi ate that our VTA analysis does substantially
itwouldbediÆ ulttopairthede nitionsandusesup or-re tly.
Anotherexplanation for the gap is thepresen e of several runtime agsinthis ben hmark. Fora parti ularoption, thereisusuallyanabstra t lassperformingthebasi fun -tionality asso iatedwith theoption, and itis extended by di erent lassesthatperformaspe i fun tion. Depending ontheparti ular hoi efortheruntime agoneofthe pos-sible lassesisinstantiated. Thus,thisisanexamplewhere the allsiteismonomorphi foraparti ularrunofthe pro-gram,butpolymorphi overmanydi erentruns. Thissort ofmonomorphism annotbedeterminedbyastati analysis, butwouldbeagood andidatefor runtimeoptimizations.
Theben hmarksjava andsootareexampleswhere there exists a substantial numberof polymorphi alls, even af-ter ananalysis like VTA has been usedto devirtualize as many allsaspossible. ThegapbetweentheresultofVTA andthe pro le orrespondsto allsthat are monomorphi atruntime,butwerenotdeterminedtobemonomorphi by thestati analysis. FromFigure5we anseethatforjava thisgapisabout18%(90-72),andforsootthisgapisabout 28%(67-39).One antryto losethisgapbyapplyingmore expensive stati analyses, or one anuse dynami all op-timizationte hniques,likebran htargetpredi tion[11℄,or inline a hing[17℄. For example, ahardware-basedbran h targetbu er (BTB),likethe 512-entry BTB ofaPentium III,redu estheoverheadof alls thatseldomlyswit h tar-getsby storing the last targetof every allsite. The pre-di tion hit rateof a large BTB is equal to the numberof timesthatatargetatanexe uted allsitedoesnot hange, andtherefore it gives anupperboundto the dynami fre-quen yofmonomorphi alls. InDriesenandHolzle'sstudy onthe dire t ostof virtual fun tion alls inC++[19℄, a BTBpredi ts75%ofthe allsonasuiteofC++programs. Whenallmemberfun tionsarede laredvirtual(asinJava), the predi tionrate limbs to 90%, whi his similar to the
Javapro lesobtainedinthe urrent study. Astati analy-siste hniquelikeVTA anbeused toremoveall provably monomorphi allsites, after whi ha BTB optimizes dy-nami allymonomorphi alls. ABTB anhandleprovably monomorphi alls, butsin e it is a limitedresour e lose tothepro essor ore,itislikelytoremainlimitedin apa -ity, and therefore monomorphi allsite removalby stati analysis anin reasetheprogramworkloadthataparti ular pro essor anhandleeÆ iently.
Figure 5 also demonstrates how many truly polymorphi allsexistintheben hmark,these orrespondto100minus theheightofthepro lebar. Forjava thereareabout10% (100-90), andfor soot thereare about33% (100-67). Dy-nami te hniques analsooptimizetrulypolymorphi alls byusingmoresophisti ated bran htarget predi tion, that exploits orrelationsbetweenthe urrent allsiteanda pre-viously exe uted allsite, bothpolymorphi . Forexample, as adedtwo-levelpredi tionhasbeenshowntoredu ethe numberof unpredi table polymorphi alls from 25% (for a 256-entryBTB) to 6% (3-stages of 512-entry two-level), therebyoptimizing75%oftheremainingtrulypolymorphi alls[20℄.
4.2.3
Performance Improvements
Onemightwonderifthein reasedpre isionofVTAis use-fulinfurtheroptimizations. Certainlyredu ingthesizeand omplexityofthe allgraphwillimprovesubsequent inter-pro eduralanalysesandhelpsto ompa tappli ations,but isitalsousefulforperforman eimprovementofthe ben h-mark? We don't expe t it to make a large di eren e on anyoneoptimization,butwedoexpe tittogivesmall im-provements ondi erent optimizations. Currentlywe have implementedmethodinlining,whereweuseourframework to read lass les, inline methods basedon the allgraph produ ed by CHA or the all graph after pruning using VTA, andthengeneratetheinlined lass les[34℄. We
ex-oftheben hmarksshowbetterperforman ewhenthe inlin-ingisbasedonthe allgraphusingVTAratherthanCHA. Forsootweobserve1%speedupwheninlining isdone us-ingtheCHA allgraphbut3%speedupwhentheVTA all graphisused. Forjava weseenoimprovementforinlining whenbasedontheCHA allgraph, but2%speedupwhen using the VTA all graph. This leads us to believe that someoftheextra allsitesfoundbyVTA ouldbe impor-tantonesforinlining. Wehopetoseeotherbene tsasmore optimizationsareaddedtoourframework.
4.3
Measuring the Analysis
Ourimplementationis notyettunedfor speed,soinorder togiveanestimateofthetimerequiredforea hanalysis,we gatheredinformation aboutthe size ofthe datastru tures built for ea halgorithm, plussome exe ution numbers for ouruntunedimplementation. InTable4,weshowour mea-surements.
6
NotethatforDTAandVTA,thetimerequired toobtainthesolutionisproportionaltothenumberofedges inthe onstraintgraphafterthegraphhasbeentransformed su hthatea hstrongly onne ted omponentinthe origi-nal onstraintgraphisrepla edbyspe ialSCCnodes. The numberofedgesinthe onstraintgraphisobservedtogrow linearlywiththesize of theappli ationfor bothDTAand VTA. In omparingDTAand VTA, we observe that VTA hasabout4timesthe numberofnodes,andabout8times thenumberof edges as inDTA. Thisgivesagood indi a-tionaboutthe relative ostsof these2 analyses. The last olumnofTable4givesthetime,inse onds,forsolvingthe onstraintgraph. Theinterestingpointisnotso mu hthe absolutetime
7
, butthe fa tthat the analysis s aleswell, andbehaveslinearlyinpra ti e. ThisalsoshowsthatVTA isindeeda onstantfa tor(around10)moreexpensivethan DTA,andsothein reasedpre isionofVTAoverDTAdoes omeatapri e.
5.
RELATED WORK
There has been onsiderable work inthe area of applying moreexpensiveanalysesofvarying omplexityfor allgraph onstru tion,espe iallyforlanguages likeC++, Modula-3, and Ce il. One of the lassi algorithms is 0-CFA whi h hasO(n
3
) omplexity. Other ontext-insensitiveapproa hes in lude Palsberg and S hwartzba h's algorithm [28℄, Hall and Kennedy's all graph onstru tion algorithm for F or-tran [23℄, andLakhotia's algorithm [26℄ for buildinga all graphinlanguages withhigherorderfun tions. Other re-latedworkin ludesShiver'sk-CFAfamilyofalgorithms[32, 33℄forsele tingthetarget ontourbasedonken losing all-ing ontours at ea h all site, Agesen's Cartesian Produ t Algorithm[6℄, and Ryder's[31℄ allgraph onstru tion al-gorithmforFortran77. PlevyakandChien'siterative algo-6
Note that the numberof Jimple statements reported in Table 4is less thanthe numbers reportedearlier inTable 1where we summarizedthe ben hmark hara teristi s. In Table 1wein ludedallmethodsin lassesthatarereferred to by the ben hmark,whereas inTable 4we in lude only thosemethodsthatappearinthe onservative allgraph. 7
ThisimplementationisbuiltinJavausingveryhigh-level datastru turesbasedon olle tions,anditwasrunusinga relativelyslowJavainterpreter(linuxjdk1.1.7)ona333Mhz pentium. Thus one ansafelyassume that atuned
imple-and triesto re neitto thedesired extent by reating new ontours. Chatterjeeet. al. giveamethodfor nding rele-vant ontextsforasubsetofC++/Java[12℄. Agesen[5℄ de-s ribes onstraint-graph-basedinstantiationsofk-CFA,and Plevyak'salgorithm.
Ourworkhasfo used onate hniquethat an nda solu-tionthat doesnotrequireany iterationand s aleslinearly in the size of the program. Thus, previous work that fo- uses on the e e tiveness of inexpensive analyses is more dire tly related to this paper. Inthis eld, the goal is to ndsimple,inexpensive,yete e tiveanalyses. Theresults ofDean et. al. [14℄suggestthat lasshierar hyanalysis is agoodte hniqueforresolvingmanymethodinvo ationsfor theCe illanguage. Fernandez[21℄implementedvirtual all elimination andusedanidea thatisessentiallyClass Hier-ar hyAnalysis(CHA).AignerandHolzle[7℄ ndthattype feedba k and lasshierar hy analysis are both e e tive at resolving methodinvo ationsinC++. Ourwork on rms that CHA does work well for Java byte ode, and we use CHAto getouroriginal onservative allgraph. However, our VTA methods ansubstantiallyimprovethe onserva-tive allgraph,removing10%to63%ofthenodes,and17% to64%oftheedges.
Ba on and Sweeney's workon faststati analysis ofC++ virtual fun tion alls [8℄ onsiders three relatively simple analysis te hniques alled: Unique Name, Class Hierar hy Analysis,and Rapid TypeAnalysis(RTA).They have dy-nami allymeasuredtheresultsforresolutionofuservirtual alls,andhavegivenanestimateforthenumberofdead all sites. They on ludedthatrapidtypeanalysisisextremely e e tiveinresolving fun tion alls,redu ing odesize, and isfast.Ourresultsseemto on rmthatrapidtypeanalysis doesalso workwellwith Javawhen omplete appli ations in ludinglibrary odeareanalyzed. However,weshowthat rapidtypeanalysisdoesnotperformwellwhen onsidering theben hmark odeonly.Further,ourresultsindi atethat variable-typeanalysisgivesbetterresultsforboth ases,the ompleteappli ation,andtheben hmarkonly.
Diwan[18℄des ribesresultsforsimpleande e tiveanalysis of stati ally-typedobje t-oriented languages, and provides experimental resultsfor ModulaIIIprograms. Their anal-ysisissimilartooursinthesensethattheyalsopropagate typesfromallo ationsitestouses. However,thereare signif-i ant di eren esbetweentheir approa hand our rea hing-typeanalyses. First,weanalyzeJavabyte ode,andso we have tailoredourapproa hto thespe i s ofJava, in lud-ing how toproperlyhandleJava arrays. Further,we have experimentedwithawidevarietyofben hmarks,in luding somelarge ben hmarks thatare veryobje toriented. Se -ond,webelievethatourapproa hismoreeÆ ientsin ewe builda omplete onstraintgraph,andsolveiton e. Their approa hrequires iteratinga ow-sensitiveintrapro edural phasesin etheirinterpro eduralstrategyre-analyzes meth-ods when information about parameters or return values hangeduetotheintrapro eduralphase.Third,their inter-pro eduralapproa husesthede laredtypeofobje t elds whi h anintrodu eimpre ision,whereasweusethe rea h-ingtypesfor elds.
Name Jimple beforeSCC afterSCC beforeSCC afterSCC (se onds) Stmts jNj jEj jNj jEj jNj jEj jNj jEj jNj jEj DTA VTA raytra e 27570 1729 9167 3540 3139 2989 1931 12496 18125 10700 13329 8 54 ompress 24833 1583 8000 3235 2832 2741 1745 11010 15734 9471 11461 8 44 ja k 33186 1857 10804 3828 3474 3284 2274 14293 21361 12320 16131 11 68 java 47172 2821 24271 5872 6061 4741 3374 22220 54930 17019 26417 12 113 sable 49421 3737 35693 7722 8273 6104 3927 25482 75280 20298 43618 13 128 soot 43530 2828 36984 6333 6699 5178 3784 24190 68289 19620 43416 15 207 pizza 55468 2660 19753 7177 7445 6023 3856 28007 50242 17216 23390 11 102
Table4: SizeofDataStru tures
Morere ently,DeFouwet. al. havepresentedaframework for expressingandexperimentingwithavarietyof fast in-terpro edural lassanalyses for Ce il and Java[15, 16℄. A keypartoftheirframeworkistheabilitytomergenodesin the onstraint graphaftertheyhave beenvisitedP times. Thisapproa hofmerging afterathresholdallows themto tunethe omplexity of the algorithm. They present eight instantiationsoftheframework,threeofwhi harelinearor nearlinear. OurDTAandVTAalgorithmsarenot instan-tiationsoftheirframeworkbe ausethevarioustradeo swe made(seese tion3.3)tomakeouralgorithmeÆ ientarenot parametersof their approa h. First, ouralgorithm is pes-simisti sin eitusesaninitial onservative allgraph(orthe allgraphgeneratedbyoptimisti RTA)toinsertedgesinto the onstraintgraph,whereastheirs hemesareoptimisti , inserting edges into the all graphas obje tinstantiations arefound. Se ond,theiralgorithmmergesanodewithallof itssu essornodeswhenitisvisitedP times(thekeydesign pointintheirframework). Inouralgorithmwede idewhi h nodeswillbemergedby omputingthestrongly onne ted omponents, and merging those together. Afterthis om-pressionstep, ouralgorithmwillonlyvisitea hnodeon e. Intheirstudytheyanalyzea variety ofCe il ben hmarks, butonlythreeJavaben hmarks. Wehavedemonstratedour analysisononlyJavaben hmarks,butonawidervarietyof those.
Tip and Palsberg have also been working to nd s alable analysesthatworkwellwithJava[36℄. Theirmotivationis very similarto ours, to nd an analysis that makessome tradeo s, gives better results than RTA, buts ales better thantraditional0-CFA analysis. They presenta spe trum of onstraint-basedte hniquesthat fo us onmaking anal-yses s alable by limiting the numberof sets that mustbe approximated. In0-CFAonesetisasso iatedwithea h ex-pression, and inRTA onesetis asso iated withthe entire program. Their newanalyses suggestintermediatepoints. Forexample,CTAusesadistin tsetforea h lass,andXTA usesadistin tsetforea hmethodandea h eld. Although theiranalysesredu ethenumberofsetsapproximated,the underlyingsolvermaystillrequireiteration.
The di eren e between their approa h and ours is in the way inwhi h we enfor e s alability. For VTA we use one setfor ea hlo al variable, and onesetfor ea h eld,thus givingusa ner-grainabstra tion. Insteadof oarseningthe abstra tionlevel,ourdesigngoalwastoeliminateiteration intheanalysis,andwemadevarioustradeo stoenfor ethis (assummarizedinSe tion3.3). For example: ouranalyses are onservative; we start witheitherthe onservative all
graphortheRTA allgraph;andwedonotkillbasedon ast information. Wealsotrieda oarserversion ofVTA alled DTA,whereweapproximatedonesetforea hde laredtype, butwefoundthatDTAwasnotnearlyase e tiveasVTA. So,atleastinourapproa h,thegranularityofVTAappears tobene essaryforgoodresults.
CurrentlytheexperimentalresultsofboththeTip/Palsberg approa handourapproa hbothdemonstratethatwea hieve improvementsoverRTA.Ahead-to-headexperimental om-parisonwillonlybepossiblewhenbothapproa hesare im-plemented inthe sameframework, with thesame assump-tions, and run on the same set of ben hmarks. It would beveryinterestingtoperformthisexperiment. Thiswould also allowus todetermineif theapproa hes ndthe same sour esofimprovements,orifbothte hniques ombined to-gethergivesevenbetter results. If so,itwouldbepossible torunbothanalyses, andthenusetheinterse tion oftheir results.
Anotherinterestingareaoffutureworkisthe ombinationof stati anddynami te hniques. Ishizakiet. al. havestudied awidevarietyofdevirtualizationte hniquesforaJavaJIT ompiler [25℄. Theirstudyshowsthepromiseof ombining stati te hniquesliketypeanalysisanddynami te hniques.
OurworkbuildsontheSootframeworkunderdevelopment atM Gill. Harissa[27℄,Vortex[13℄andJAX[35℄ are alter-nativeimplementationframeworks.
6.
CONCLUSIONS AND FUTURE WORK
Inthispaperwehavepresentedanewte hniquethat anbe used to estimatethe possible typesof re eiversfor virtual method and interfa e alls inJava. Twovariations of the te hnique were presented, variable-type analysis that uses the name of are eiveras itsrepresentative, and de lared-typeanalysis whi husesthede lared typeof are eiveras itsrepresentative. These twoanalyses, plus lasshierar hy analysis andrapidtypeanalysis, two previouslydeveloped typeestimationte hniques,wereimplementedwithSoot,an environmentthattranslatesJavabyte odetoatyped three-address ode. AllfouranalyseswereappliedtosevenJava byte odeben hmarks.
Our methods work on omplete appli ations, and so they requirehavingallofthebyte odefortheben hmark avail-able. Althoughthisisnotusefulforsituationswhere lasses an be dynami ally loaded, we feel that ompilation and optimizationof ompleteappli ationsisreasonableinmany
as ompilers,optimizers,editorsandserver-sideappli ations that anbe ompiledinthisfashion.
For ea h ben hmark, lasshierar hy analysis was used to build aninitial onservative all graph. Measurements of thesegraphs on rmwhatothershavenoted,namelythat lass hierar hy analysis leads to a onservative all graph thatis fairly sparse, withamajorityof allsites resolving toasinglemethod. However,thereiss opefor further im-provementofthese onservativegraphs.
Weapplied rapidtype analysis,variable-typeanalysis and de lared-typeanalysisusingtheinitial onservative allgraph, andfoundthatasigni antnumberofedgesandnodes ould beremoved.Variable-typeanalysisgavethebestresults re-moving10% to 65% of the nodes and 17% to 65% of the edges from the onservative all graph. Further, variable-typeanalysis resolved32%to 94% ofthepotentially poly-morphi all sites (after CHA) to 1 method. All of these results are better than what was a hieved by rapid type analysis. Ourde lared-typeanalysisdid givesomebene t, butnotassigni antasvariable-typeanalysis.
Inorder to studythe e e tof theanalyses onthe ben h-marks,westudiedthedynami behavior oftheben hmark ode only. In this ase we found that neither rapid type analysis norde lared-typeanalysis had signi ant impa t. However, variable-type analysis did show substantial im-provement,insome asesapproa hingthebestpossible re-sult. Thus,itseemsthattheaddedgranularity of variable-type analysis over de lared-type analysis is quite impor-tant,parti ularlywhenoptimizingtheben hmark ode. In other asesvariable-typeanalysisdid ndsigni antlymore monomorphi allsites,buttherewasasubstantialgap be-tweenthestati resultoftheanalysisandthedynami pro- le. We presented several reasons for this gap, and we do notbelievethatasimpleanalysiswillbeableto losemu h oftheremaininggap.
Weobservedthat the extra all sitesresolvedby variable-type analysis a ount for a signi ant numberof alls in thedynami tra e,andwedemonstratedthatinlining ould make use of these extra allsites, giving performan e im-provementfortwoben hmarks.
Ourte hniquesweremeanttobesimple,andwedes ribed the various tradeo s we made to keep the algorithm sim-pleandeÆ ient. Wehavedes ribedourapproa hindetail, andit shouldbe easyfor othersto addto their ompilers, parti ularly iftheyalready have CHAand/or RTA analy-sis. Based onour experimentalresults, we believe that a good overall strategy would be to use an optimisti RT A-style analysisto get the originalpruned allgraph. Then, if there are a signi ant numberof polymorphi all sites remaining,ourVTAanalysis ouldfurtherprunethegraph, givingadditional odesizeredu tion,andbettervirtual all resolution.
Weare urrentlyworkingontoolsfortreeshaking,pointer analysis, and side-e e t analysis based on the all graph produ edbyvariable-typeanalysis.
7.
ACKNOWLEDGEMENTS
This work was supportedby NSERCand FCAR. The au-thorswouldliketothankKarelDriesenforhisinputonthe onne tions between stati and dynami te hniques. We alsowishtoexpressourthankstheOOPSLAreviewersand manyotherswhohavegivenpositivesuggestionsonthisand manypreviousdraftsofourpaper.
8.
REFERENCES
[1℄ URL:http://www.sable.m gill. a/soot/.
[2℄ URL:http://www.transvirtual. om/ka e.html.
[3℄ URL:http://www.sable.m gill. a/sable /.
[4℄ URL:http://wwwipd.ira.uka.de/~pizza/.
[5℄ O.Agesen.Constraint-basedtypeinferen eand parametri polymorphism.InB.L. Charlier,editor, SAS'94|Pro eedingsof theFirstInternationalStati AnalysisSymposium,volume864ofLe ture Notesin Computer S ien e,pages78{100.Springer,28{30Sep. 1994.
[6℄ O.Agesen.TheCartesian produ talgorithm: Simple andpre isetypeinferen eofparametri
polymorphism.InW.G.Oltho ,editor, ECOOP'95|Obje t-OrientedProgramming, 9th EuropeanConferen e,volume952ofLe ture Notesin Computer S ien e,pages2{26,
Aarhus,Denmark, 7{11 Aug.1995.Springer.
[7℄ G.AignerandU.Holzle.Eliminatingvirtualfun tion allsinC++programs.InP.Cointe,editor,
ECOOP'96|Obje t-OrientedProgramming, 10th EuropeanConferen e,volume1098ofLe ture Notesin Computer S ien e,pages142{166,Linz,Austria, 8{12 Jul.1996.Springer.
[8℄ D. F.Ba onandP.F.Sweeney.Faststati analysisof C++virtualfun tion alls.InPro eedingsofthe Conferen e onObje t-OrientedProgramming Systems, Languages, andAppli ations,volume31,10ofACM SIGPLAN Noti es,pages324{341,New York, O t.6{101996.ACMPress.
[9℄ B. CalderandD.Grunwald.Redu ingindire t fun tion alloverheadinC++programs.In21st SymposiumonPrin iplesofProgramming Languages, pages397{408,Jan.1994.
[10℄ C.Chambers,D.Grove,G.DeFouw,andJ.Dean. Call graph onstru tioninobje t-orientedlanguages. InPro eedings oftheACMSIGPLANConferen eon Obje t-OrientedProgrammingSystems,Languagesand Appli ations(OOPSLA-97), volume32,10ofACM SIGPLAN Noti es,pages108{124,New York, O t.5{91997. ACMPress.
[11℄ P.Chang,E.Hao,andY.Patt.Targetpredi tionfor indire tjumps.InPro eedingsof theInternational SymposiumonComputerAr hite ture,pages274{283,
