Intra-procedural Inference of Static Types for Java Bytecode 1

Transcription

1 McGll Unversty School of Computer Scence Sable Research Group Intra-procedural Inference of Statc Types for Java Bytecode 1 Sable Techncal Report No. 5 Etenne Gagnon Laure Hendren October 14, 1998 w w w. s a b l e. m c g l l. c a 1 Ths work has been supported n part by FCAR and NSERC.

2 Abstract In ths paper, we present practcal algorthms for nferrng statc types for local varables and stack locatons of Java bytecode. By decouplng the type nference problem from the low level bytecode representaton, and abstractng t nto a constrant system, we are able to construct a sound and ecent algorthm for nferrng the type of most bytecode found n practce. Usng ths same constrant system, we then prove that ths type nference problem s NP-complete n general. However, our expermental results show that all of the 16,500 methods used n our tests were successfully typed by the ecent polynomal algorthm. 1 Introducton Whle Java bytecode [7] retans type nformaton for method calls and eld accesses, t operates on untyped local varables and stack locatons. In order to decomple bytecode back to Java source code [5], or to mprove subsequent analyzes on Java bytecode, t s mportant to nd a statc type for these locatons. In ths paper, we address the problem of nferrng a sngle statc type for each stack locaton and local varable used n the bytecode. Ths contrasts wth prevous work [8, 6, 1, 2], where the man focus was to statcally nfer the set of dynamc (or concrete) types of all values stored n the locaton at runtme. Whle the type nference problem would seem easy at rst glance, snce Java has sngle nhertance of classes, multple nhertance of nterfaces complcates the problem. In fact, we wll buld the necessary framework needed to show that the type nference problem s NP-complete. But, as our expermental results wll show, n practce, a smple algorthm s able to solve most problems n polynomal tme. More precsely, all of the 16,492 methods extracted from 2,787 JDK 1.1 and SPEC Jvm98 classes were typed by our polynomal algorthm. To smplfy our work, we assume a 3-address-code-based representaton of Java bytecode called Jmple, whch completely abstracts the stack locatons nto local varables. From ths representaton, we extract the set of statc constrants mposed by the program on each untyped varable. The resultng constrant system s at the heart of our work. It allows us to develop fast and ntutve algorthms for solvng smple constrants. It also allows us to prove the hardness of the problem n general. Our paper s structured as follows. In secton 2, we present the bascs of bytecode and the Jmple 3-address-code representaton. In secton 3, we dene the general statc type nference problem, then we state the restrctons assumed n sectons 4 and 5, and 6. These restrctons are lfted n secton 7. In secton 4, we buld a constrant system. We then present solutons for smple constrants n secton 5. Once we have empted our bag of smple trcks, we take a look back at the general constrant system n secton 6 and prove that solvng t s an NP-complete problem. In secton 7 we present extensons to our constrant systems for handlng arrays and nteger types. Secton 8 contans our expermental results. Fnally, we brey revew related work n secton 9 and present our conclusons n secton 10. 1

3 2 Java Bytecode and Jmple We assume that the reader s already famlar wth Java bytecode. A complete descrpton of the class le format can be found n [7]. Furthermore, we assume that all analyzed bytecode would be successfully vered by the Java bytecode verer. Whle the bytecode format seems of great nterest for mplementng an nterpreter, t s not well suted for reasonng about bytecode, snce many operands are on the stack and thus do not have explct names. So, n order to allevate ths dculty, the Sable Research Group developed Jmple [9], a 3-address-code representaton of bytecode, where all stack-based operatons are transformed nto local varable based operatons. Ths s made possble by the restrctons met by vered bytecode, most notably: the constant stack depth at each program pont, and the explct maxmum depth of stack and number of local varables used n the body of a method. The bytecode to Jmple transformaton s done by computng the stack depth at each program pont, ntroducng a new local varable for each stack depth, and then rewrtng the nstructon usng the new local varables 2. For example: load_1 (stack depth before 0 after 1) load_2 (stack depth before 1 after 2) add (stack depth before 2 after 1) store_1 (stack depth before 1 after 0) s transformed nto: stack_1 = local_1 stack_2 = local_2 stack_1 = stack_1 + stack_2 local_1 = stack_1 The Jmple representaton retans all type nformaton contaned n bytecode nstructons. So, for nstance, every vrtual method contans the complete sgnature of the called method, as well as the name of the class declarng the method. However, as there are no explct types for locals or stack locatons, the untyped verson of Jmple does not have types for local varables. In nal preparaton, pror to applyng the typng algorthms outlned n ths paper, a data ow analyss s appled on the Jmple representaton, computng denton-use and use-denton (du-ud) chans. Then, all local varables are splt nto multple varables, one for each web of du-ud chans. Our example would change to: stack_1_0 = local_1_0 stack_2_0 = local_2_0 stack_1_1 = stack_1_0 + stack_2_0 local_1_1 = stack_1_1 Note that stack 1 has been splt nto stack 1 0 and stack 1 1, and smlarly local 1 has been splt nto local 1 0 and local 1 1. Ths splttng s qute mportant, because a sngle local or stack locaton n the bytecode can refer to derent types at derent program ponts. A complete example of a Java program wth t's untyped and typed Jmple code s shown n Fgure 1. The typed verson was computed usng the algorthms presented n ths paper. 2 In realty, the stack analyss, the ntroducton of new local varables, and the transformaton are not as straghtforward as t looks here. Ths s due to the presence of subroutnes (the jsr bytecode nstructon) and double-word values (long, double). A complete descrpton of the bytecode to Jmple transformaton can be found n [9]. 2

4 mport java.awt.*; class Test { statc Component method(boolean b) { Component c = new Button(); f(b) { c = new Choce(); } Object o = c; o.notfy(); return c; } } (a) Orgnal Java Program class Test extends java.lang.object { statc java.awt.component method(boolean param0) { unknown_type v0; unknown_type v1; unknown_type v2; unknown_type v3; v0 := param0; v1 = new java.awt.button; specalnvoke v1.[vod java.awt.button.<nt>()](); v2 = v1; f v0 == 0 goto label0; v3 = new java.awt.choce; specalnvoke v3.[vod java.awt.choce.<nt>()](); v2 = v3; } label0: vrtualnvoke v2.[vod java.lang.object.notfy()](); return v2; } (b) Untyped Jmple class Test extends java.lang.object { statc java.awt.component method(boolean param0) { nt v0; java.awt.button v1; java.awt.component v2; java.awt.choce v3; v0 := param0; v1 = new java.awt.button; specalnvoke v1.[vod java.awt.button.<nt>()](); v2 = v1; f v0 == 0 goto label0; v3 = new java.awt.choce; specalnvoke v3.[vod java.awt.choce.<nt>()](); v2 = v3; } label0: vrtualnvoke v2.[vod java.lang.object.notfy()](); return v2; } (c) Typed Jmple Fgure 1: Example of Typng Jmple 3

5 3 Problem Statement The type nference problem we want to solve s a yes/no problem. We want to know f there exsts a statc type assgnment for all local varables such that all type restrctons mposed by Jmple nstructons on ther arguments are met. If the answer s yes, we want a certcate; a proof n the form of a vald type assgnment for the varables. In the case where there exst more than one soluton, we only requre one of these solutons. If there are no solutons, we want to get a no answer. The restrctons of Jmple nstructons on the type of ther arguments are the same as the statc restrctons mposed by the bytecode nstructons on ther arguments. For example, an nteger addton operator s not allowed to perform addtons on varables of reference type, an assgnment to a eld of type Strng cannot be made from a varable of type Object wthout a type cast, etc. As the statc type of arguments and return values of a method called s explctly ncluded n a method nvocaton nstructon 3, the scope of our problem s reduced to a sngle method at a tme. In other words, our analyss s ntra-procedural. On the other hand, t requres some knowledge about the type herarchy of the program. Ths knowledge s restrcted to classes and nterfaces explctly referenced n the method body, and all ther ancestor classes and nterfaces. Ths s a relatvely small set of classes n practce. Furthermore, the class herarchy nformaton can be cached between successve nvocatons of the type nference algorthm. 3.1 A restrcted problem In the followng sectons (4 to 6), we wll assume that the analyzed Jmple code contans no array nstructons and no reference to array types. Furthermore, we wll assume that there s a sngle nteger type 4 : nt. All references to boolean, byte, short, char (n eld types and method sgnatures) are treated as nt. Ths s smlar to the semantcs of Java bytecode. In secton 7 we wll lft the array type restrcton, and dscuss ways of handlng nteger types. 4 A Constrant System In ths secton, we transform the type nference problem stated n secton 3.1 nto a graph problem. The graph represents the constrants mposed on local varables by Jmple nstructons n the body of an analyzed method. The constrant graph s a drected graph contanng the followng components: 1. hard nodes: each hard node has an explct assocated type. 2. soft nodes: each soft nodes represents a type varable. 3. drected edges: each edge represent a constrant between two nodes. 3 and because Java reles on statc resoluton of overloadng, 4 long s not an nteger type, n our denton. 4

6 A drected edge from node a to node b, represented n the text as ab, means that a should be assgnable to b. The rules of assgnment compatblty are explaned n [7]. Smply stated, a should be of the same type as b, or b should be a superclass (or supernterface) of a. The graph s constructed va a sngle pass over the Jmple code, addng nodes and edges to the graph, as mpled by each nstructon. The collecton of constrants s best explaned by lookng at a few representatve Jmple statements. We wll look at the smple assgnment statement, the assgnment of a bnary expresson to a local varable, and a vrtual method nvocaton. All other constructons are smlar. A smple assgnment s an assgnment between two local varables [b = a]. If varable a s assgned to varable b, the constrants of assgnment compatblty mply that T (a) T (b), where T (a) and T (b) represent the yet unknown respectve types of a and b. So, n ths case, we need to add two soft nodes T (a) and T (b), unless they are already present n the graph. We also need to add an edge from T (a) to T (b) (f not already present). The assgnment of the followng bnary expresson to local varable a, [a = b + 3], generates the followng constrants: T (a) T (b), T (a) nt, and T (b) nt. So we need to add at most one hard node, two soft nodes and three drected edges to the graph, as necessary. Our last and most complcated case s a method nvocaton, [a = b:equals(c)], or n full: a = vrtualnvoke b.[boolean java.lang.object.equals(java.lang.object)] (c) A method nvocaton carres much type nformaton. So we get all the followng constrants, each nvolvng a hard node: T (a) nt, because the return type of equals s boolean, and we have a sngle nteger type. T (b) java:lang:object, from the declarng class of equals. T (c) java:lang:object, from the argument type n the method sgnature. As usual, we must add all necessary edges and nodes to the constrant graph. Fgure 2 shows the constrant graph of the example presented n Fgure 1. Our type nference problem now conssts of transformng soft nodes nto hard nodes, such that all assgnment compatblty constrants, represented by edges, are satsed. If no such soluton exsts, or f a node needs more than one assocated type, the type nference algorthm should report a no answer. We mplement the graph usng two adjacency lsts on each node; a lst of parents and a lst of chldren. So, each drected edge s represented by two references, one parent and one chld reference. 4.1 Complexty Analyss In ths paper we do not present tght upper bounds on the runnng tme of analyzes. We only take the necessary precautons to keep the worst case runnng cost of our fast algorthms below or equal to O(n 2 ), where n s the number of Jmple statements n the method body. It s mportant to note that the sze of the constrant graph, [number of nodes]+[number of edges], s O(n). We wll use ths property throughout ths paper. Our mplementaton uses ecent data structures and 5

7 Object Component nt v0 v2 v1 v3 Button Choce Fgure 2: Constrant Graph for Program n Fgure 1 algorthms to keep the hdden constants as low as possble, or even reduce some costs to O(n log n) or O(n). But as we wll see n secton 5.1, the domnatng cost, that of mergng, s O(n 2 ) n the worst case. The worst case runnng tme to decde whether a node or an edge s already present n the graph s O(n), where n s the number of statements. Because the maxmum number of edges and nodes added to the constrant graph s constant for each nstructon, t follows that the upper bound on the runnng tme of the graph constructon algorthm s O(n 2 ). 5 Solvng Smple Constrants In ths secton, we descrbe three smple algorthms for reducng the number of soft nodes n the constrant graph bult n secton 4. Ths s acheved by mergng adjacent nodes together. For each of these algorthm, we present a soundness proof and a worst runnng tme analyss. But, rst, we ntroduce the merge operaton and analyze, once and for all, ts runnng tme complexty. The three algorthms presented later should be appled consecutvely, or more precsely n the order: rst, second, thrd and then second algorthm agan. Ths s mportant for the valdty of our soundness proofs. 6

8 5.1 Mergng The man operaton used by our smple algorthms s the merge operaton. Two nodes are merged together whenever we can prove that: f there exsts a non empty set of solutons to the type problem, then at least one of these solutons assgns the same type to both nodes. Mergng has the nce property of reducng both the number of nodes and the number of edges n the constrant graph. But t must be done carefully. Mergng conssts of two parts. Frst, both nodes (or more precsely sets) are uned, then edges are combned. We use the fast unon-set data structure [3]. Every tme a merge s performed, the set representatve s kept n the constrant graph, and all edges are xed to drectly pont to t. Ths gve us the property that all merges are only done on set representatves, so the actual runnng tme of the unon operaton s O(1). (We need not pay for the more expensve nd operaton). 5 The cost of xng edges, on the adjacency lst representaton of the constrant graph, s the prncpal cost. Frstly, parents and chldren lsts of merged nodes are combned, elmnatng duplcates and references to both nodes. Ths can be done n O(n), by usng a bt vector and addng the references one by one, settng a presence bt every tme. Secondly, each chld and parent node s vsted once, replacng references to the elmnated node by references to the representatve node (and avodng duplcates). It s easy to see that each edge of the constrant graph won't be vsted more than twce. So the total cost for one merge s O(n) + O(n) = O(n). The total number of nodes s O(n). The maxmum number of merges that can be performed on the constrant graph s O(n)? 1 = O(n). Ths gves us an upper bound of O(n 2 ) on the total runnng tme of all merges. We can now keep the cost of merges separate from the cost of other algorthms. Ths smples the remanng complexty analyzes. 5.2 Solvng Cyclc Constrants Our rst, and most smple transformaton of the constrant graph, conssts on ndng cycles n the constrant graph, and then mergng together all nodes of a cycle. Once cycles are removed, we are left wth a dag (drected acyclc graph). We also take advantage of the verer restrctons to merge respectvely all values n a transtve relaton wth any of the non-reference basc type: nt, long, oat, and double. Fgure 3 shows our prevous constrant graph after applyng ths analyss. The soundness of rst part of ths transformaton s easy to establsh 6. If k nodes are nvolved n a cycle x 1 x 2 ::: x k x 1, t follows that x j x 1 for 2 <= j <= k by transtvty of. But also, x 1 x j, usng the same argument. Therefore, x 1 = x j. It s then sound to assume that f there s a soluton to the type problem, t wll have the same type assgnment for all x 1 :::x k nodes. The soundness of the second part s trval. The algorthm used to detect cycles s the well known algorthm that nds strongly connected components n a drected graph [3]. The runnng tme of ths algorthm n lnear n the sze of the graph. Ths gves us O(n). Ths cost s eectvely hdden by the cost of merges, n the overall worst case tme analyss. Fndng all nodes n a transtve relaton wth a basc type s also lnear. (We start from the 5 Please note that unless speced otherwse n ths paper, n represents the number of Jmple statements n the analyzed method body or the sze of the constrant graph, whch s equvalent n the bg O notaton (see secton 4.1). 6 It s clear that the constrant relatons and are reexve and transtve. 7

9 Object Component v0 nt v2 v1 v3 Button Choce Fgure 3: Constrant Graph After Cycle Elmnaton basc type node, then merge wth all parents and chldren untl none are left). So ths cost s also hdden by the more expensve merge cost. 5.3 Solvng Sngle Constrants Our next transformaton conssts n mergng soft nodes wth wth ther sngle parents and chldren. More precsely, there are four cases: 1. A soft node has one parent: We merge the node and ts parent. 2. A soft node has no parents: We merge the node and java.lang.object. 3. A soft node has one chld: We merge the node and ts chld. 4. A soft node has no chldren: We merge the node wth null 7. The algorthm proceeds as follows. Frst, all soft nodes are vsted once, puttng nodes fallng nto any of the above four cases n a work lst. Then every node n the work lst s merged wth ts sngle relatve. Whle mergng, f we dscover that we have made a new sngly related soft node, we add t to the work lst. We contnue mergng untl no node s left on the work lst. Fgure 4 shows our prevous constrant graph after applyng ths analyss. 7 null s a new type that we ntroduce here. It s a descendant of all reference types (all classes, nterfaces and arrays). It s the opposte of java.lang.object whch s an ancestor of all reference types. 8

10 Object Component v0 nt v2 Button v1 Choce v3 Fgure 4: Constrant Graph After Sngle Relaton Elmnaton Soundness A soft node that has no chldren s a soft node that has never been assgned a value other than null. (A varable cannot be unntalzed due to the Java verer constrants). The null value s a reference value and can be used whenever a reference value s expected by a Jmple nstructon. The null type corresponds to ths expectaton 8. Obvously, f there exsts a soluton to the type problem, then ths soluton wll assgn a reference type x 1 to the soft node x. Snce the soft node has only parent relatons (xp 1 ; x p 2 ; :::; xp k ) and snce the null type s a descendant of all reference types, then null x 1 and therefore null p for = 0:::k, by transtvty of. So replacng x 1 by null n the soluton does not nvaldate t. A smlar argument holds for the no parents case. Except that n ths case, the soft node represents a varable that has never been used. If a soft node x has a sngle parent p, and chldren c 1 ; :::; c k, and f there exsts a soluton to the type problem such that x, c and p are assgned the types x 1, c 1 and p 1, respectvely. Then, p 1 x 1 because we have soluton and the constrant p x should be met. But, by transtvty of, p 1 c 1 for = 1:::k. The reexvty of also gves us p 1 p 1. Therefore, replacng x 1 by p 1 n the soluton does not nvaldate t. A very smlar argument holds for the sngle chld case. 8 Concretely, a varable of null type could be replaced n the Jmple code by the constant null. 9

11 5.3.2 Complexty The ntal pass over all nodes costs O(n). By nsertng an edge counter n the edge xng stage of the merge operaton, we can completely hde the cost of detectng newly created sngly related nodes. The work to be done on the work lst s O(1) for each merge, and s therefore already ncluded n the cost of mergng. So, our overall runnng tme s stll O(n 2 ). 5.4 Removng Transtve Constrants Our last smple algorthm conssts of removng transtve constrants. A transtve constrant from a node n to a node a, s an explct parent constrant 9 n 1 a of n such that there exsts another explct parent constrant n 1 p (where p 6= a) and p a (transtvely). To render ths algorthm as eectve as possble, we assume that ancestry nformaton s avalable for classes and nterfaces. It s reasonble to assume that ths nformaton should be already computed before the typng algorthm was launched, because ths nformaton s necessary to perform bytecode vercaton. We assume that the queston s a an ancestor of b can be answered n O(1), provded that the nformaton s sored usng a bt array. If ths nformaton s not alreay computed, t can be easly computed n a runnng tme that s n the worst case quadratc n the sze of the herarchy referenced by the constrant graph. In practce, ths s a very small cost. Furthermore, ths nformaton can be cached between many nvocatons of ths algorthm on methods of the same class herarchy. For ths reason we wll not nclude the cost of computng ths nformaton to our algorthm cost. Transtve constrants are removed regardless of the knd of nodes (soft, hard). Once the transtve constrants are removed, we apply the smple constrant algorthm (see secton 5.3) once agan. What s not obvous, at rst sght, s that no new transtve constrants wll be created by the smple constrant algorthm. So we do not need apply ths algorthm more than once. Fgure 5 shows our prevous constrant graph after applyng ths analyss Soundness It s obvous that the removal of a transtve constrant changes n no way the set of solutons of the graph constrant problem. On the other hand, t s more dcult to see that no new transtve edges wll be created n the second pass of the smple constrant algorthm. We proceed wth a proof by contradcton. Assume that a new transtve relaton n 1 a s created (wth n 1 p a). Assume ths s the rst transtve relaton created by a sngle relaton merge. Then, before mergng the sngle relaton that created the new transtve relaton, ether n 6 a, n 6 p, or p 6 a. n 6 a: Ths mples that ether (1) n x and a 1 x. The merge operaton nvolves a and x. But n 1 p a 1 x. Snce only one merge s allowed, n x s a transtve relaton. 9 In fact, the denton apples to both and constrant relatons. 10

12 Object Component v2 v0 nt Button v1 Choce v3 Fgure 5: Constrant Graph After Transtve Relaton Elmnaton Contradcton. Or, (2) n 1 x and a x. The contradcton s that a x s a transtve relaton. n 6 p: Ths mples that ether (1) n x, x 6 a and p 1 x. The merge operaton nvolves p and x. But p has at least two parents, and x has at least two chldren. So ths merge would not be trggered by the smple constrant algorthm. Contradcton. Or, (2)... p 6 a:... The same two arguments (transtve edge, untrggered merge) are used to prove the remanng contradctons Complexty Intally, we add edges between hard nodes whenever there s a relaton between two of them. Ths costs O(n 2 ) assumng ancestry nformaton s precomputed. Computng the a bt set vector (sze O(n)) of ancestors for each node can then be done n O(n 2 ). A rst pass uses a smple work lst algorthm, where a node s put on the lst once all of ts ancestors have been processed. A second pass does the same thng to calculate a bt set of the ancestor of parents of a node. O(n 2 ). A thrd pass vsts each node and removes parents that are set n the bt set of ancestors of parents. Easly mplemented n O(n 2 ). 11

13 6 An NP-Complete Problem As we have noted n the ntroducton, the constrant graph problem s NP-complete. The proof conssts n reducng the well known 3-SAT problem [4] to our graph problem. It s easy to see that our problem s a yes/no problem, and that a certcate could be checked n polynomal tme. In the remanng of ths secton, we wll only provde the necessary materal to carry the reducton through, and leave to the nterested reader the task of completng the proof. Frst, we should note that to completely specfy a constrant graph problem (CG), we need two graphs: (1) the class herarchy and (2) the constrant graph of soft and hard nodes. Gven an nstance of 3-SAT, we buld an nstance of CG. We rst buld the class herarchy. nterface Top For each varable x, { nterface x top { nterface x extends Top, x top { nterface x not { nterface x bottom extends Top, x top extends x, x not For each clause C = (c 1 ; c 2 ; c 3), { nterface C top { c 1 s equal to x j or x not j and x not k for some j. We ntroduce nterface c 1 extends all nterfaces x k where k 6= j and (x j when c 1 s equal to x j, or x not j { nterfaces c 2 and c 3, are smlar to c 1. { nterface C bottom extends c 1, c 2, c 3 nterface Bottom extends all nterfaces c j k Then we buld the constrant graph. hard nodes: Top and Bottom For each varable x, { hard nodes: x top { soft node: x and x bottom { constrants: x Top, x x top, x x bottom, For each clause C = (c 1 ; c 2 ; c 3), { hard nodes: C top { soft node: c and C bottom { c 1 s equal to x j or x not j otherwse) for some j. We ntroduce the constrant: c x j { smlarly, constrants c x k and c x m are ntroduced 12

14 constrants: Bottom c (for all ) The ntuton to understand the construct s to note that the soft node x should resolve to ether nterface x or x not. Ths gves us a truth assgnment for each varable. Also, the soft node c should resolve to ether nterface c 1, c 2 or c 3, whch corresponds to a true value satsfyng the clause. The mplcatons of ths result s that when we are not able to nd a soluton usng our fast algorthms, we use a nave exponental O(2 n+c ) algorthm, where C s the number of classes n the type herarchy and n s the sze of the method body, as usual. 7 Arrays and Integer Types Up to ths pont, we have gnored arrays and the derences between nteger types. In ths secton, we provde the materal needed for lftng these restrctons wthout presentng full soundness proofs and complexty analyss (due to space restrctons). 7.1 Arrays The man dea, for handlng arrays, s to ntroduce a new knd of constrant n the constrant graph. An array constrant a 7! b represents the ndrecton between the array type a, and ts element type b. (In example graphs, we represent these constrants as dotted drected edges from the array type to ts base type). Array constrants are collected along other constrants, though the ntal pass over Jmple nstructons. For example: a[d] = b; c = a; generates the followng constrants: a 7! b; d nt; and c a. Once the ntal constrant graph s bult, we apply the fast cycle removal algorthm presented n secton 5.2. Its soundness proof does not change. The next step s to calculate array depths. Wthout gong nto all the detals, we can state that f a b then array depth(a) >= array depth(b). Also, when we merge two nodes, we merge the nodes n array constrant relaton wth them. The last supplemental step t to propagate to array depth(0) all constrant relatons. Constrant relatons between nodes of the same level are propagated as s, and constrants between nodes of derent levels are replaced by a constrant x java.lang.cloneable, where x s the node of lowest depth. Ths s because all array types mplement the java.lang.cloneable nterface. Fnally we rerun the cycle detecton algorthm, and solve the array constrant free graph usng the prevously stated algorthms. Fgure 6 shows an example of a small array problem where the propagaton of constrants creates a cycle. 13

15 A a A a A[3] = b[2] B = A B b B (1) (2) b Fgure 6: Array Constrant Propagaton 7.2 Integers Bytecode nstructons do not derentate nteger types. Nether dd our typng algorthm up to now. But the ntroducton of arrays can cause some problems. For, whle nt and char are the same at the bytecode level, nt[] and char[] are dstnct types. To solve ths problem, we only need mergng basc array type nodes wth all ther chldren and parents of the same depth untl none are left. Obvously, ths step should be done after array depth calculaton. 8 Expermental Results The complete typng algorthm has been mplemented usng the Jmple ntermedate representaton. Gven untyped Jmple code, the algorthm provdes types for each local varable. Ths typed Jmple s then used by other projects n the Sable group, ncludng ponter analyzes and a Jmple to Java decompler. In ths secton we present the results of two experments done usng our mplementaton. The rst experment was performed to test the robustness of the typng algorthm as well as to gather emprcal data. In the second experment, the typng algorthm was used to mprove Class Herarchy Analyss done on a Jmple representaton of bytecode. 8.1 Typng Java Bytecode We have appled our typng algorthm on methods 10, extracted from 2787 classes. These are all of the classes found n the classes.zp le of the JDK 1.1.6, and n the SPEC jvm98 benchmarks. 10 A very few methods could not reach the typng stage due to out of memory errors n the bytecode to Jmple transformaton stage. The author of Jmple assured us that he s workng on the problem. We hope to have to soluton for the nal paper. 14

16 lnes per methods executon avg. executon method (#) (#) tme (ms) tme (ms) Fgure 7: Average executon tmes requred algorthm methods (#) Cyclc Relaton Elmnaton 7451 Sngle Relaton Elmnaton 9029 Transtve Relaton Elmnaton 12 Exponental Algorthm 0 Fgure 8: Requred analyses program call-graph edges usng call-graph edges usng name types n method sgnatures (#) typed Jmple (#) jmple jess raytrace db Fgure 9: Call Graph reducton 15

17 8.2 Improvng Class Herarchy Analyss The conservatve call graph s bult usng CHA ( Class Herarchy Analyss ). CHA assumes that the possble run tme types for an object o declared to be of type O could be O or any subtype of O, and thus elmnates any edges n the call graph to types that are not possble run types for a recever o at a callste o.m(). A more conservatve but correct strategy that could be adopted f the declared type of o s not known s to consder the type present n the nvoke expresson ( whch could be O or f m() s not declared n O, some supertype of O where m() s assumed to be dened n the supertype ). Ths would result n possbly more edges n the call graph bult usng CHA as the supertype could possbly have subtypes that are unrelated to O, and edges to them would be nserted n the call graph at callste o.m() f these subtypes declare an m(). 9 Related Work Type nference s a well known problem. For modern object-orented languages there has been consderable work. Palsberg and Schwartzbach ntroduced the basc type nference algorthm for Object-Orented languages [8]. Subsequent papers on the subject extend and mprove ths ntal algorthm [6, 1, 2]. These algorthms nfer dynamc types,.e. they descrbe the set of possble types that can occur at runtme. Further, most technques need to consder the whole program. As we emphaszed n the ntroducton, our type problem s derent n that we nfer statc types. Further, we have a very partcular problem of havng some tme nformaton from the bytecode, ncludng the types of methods. Ths means that our type nference can be ntraprocedural, and just consder one method body at a tme. Our technques are probably more related to the knd of type nference performed by decomplers and other Java complers that convert from bytecode to C, or other ntermedate representatons. We are not aware of any publshed work that detals the algorthms n these tools. 11 It s possble that many of the tools use a smple typng scheme that ntroduces type casts when dcult typng cases occur. We have certanly observed ths behavour n several decomplers. Our typng algorthm handles the dcult cases, ncludng nterfaces and arrays. 10 Conclusons and Future Work In ths paper we presented a statc type nference algorthm for typng Java bytecode. We based our methods on a 3-address-representaton of Java bytecode call Jmple. In eect, we perform the translaton of untyped Jmple to typed Jmple, where all local varables have been assgned a statc type. We have presented a constrant system that can be used to represent the type nference problem. Usng ths representaton, we developed smple, fast and eectve algorthms that were shown to handle all methods n a set of over 2,500 commercal Java classes. We also used the constrant system to prove the soundness of our algorthms and the NP-completeness of the type nference problem n general. Our expermental results show that ths practcally cheap analyss can sgncantly mprove the results of further analyses lke Class Herarchy Analyss. 11 We would be very open to addng a dscusson for any related work that we have not yet found. 16

18 11 Acknowlegements We oer our specal thanks to Mchael Schwartzbach for provdng us wth the basc constructon we use n the NP-complete proof. Also, thanks to Raja Vallee-Ra for hs work on developng the Soot and Jmple framework. References [1] Ole Agesen. Constrant-based type nference and parametrc polymorphsm. In Frst Internatonal Statc Analyss Symposum, September [2] Ole Agesen. The cartesan product algorthm : Smple and precse type nference of parametrc polymorphsm. In ECOOP '95, Aarhus, Denmark, August [3] Thomas H. Cormen, Charles E. Leserson, and Ronald L. Rvest. Introducton to Algorthms. MIT Press; McGraw-Hll Book, Cambrdge, ; New York,, [4] Mchael R. Garey and Davd S. Johnson. Computers and Intractablty: A Gude to the Theory of NP-Completeness. W. H. Freemann and Co., New York,, [5] James Goslng, Bll Joy, and Guy Steele. The Java Language Speccaton. The Java Seres. Addson- Wesley, [6] J.Plevyak and A.Chen. Precse concrete type nference for object-orented languages. In OOPSLA '94, pages 324 { 340, October [7] Tm Lndholm and Frank Yelln. The Java Vrtual Machne Speccaton. The Java Seres. Addson- Wesley, Readng, MA, USA, jan [8] Jens Palsberg and Mchael I.Schwartzbach. Object orented type nference. In OOPSLA '91, Phoenx, Arzona, October [9] Raja Vallee-Ra and Laure J. Hendren. Jmple: Smplfyng java bytecode for analyses and transformatons. Techncal report, McGll Unversty, July