Identity-sensitive Points-to Analysis for the Dynamic Behavior of JavaScript Objects

Transcription

1 Identity-sensitive Points-to Analysis for the Dynamic Behavior of JavaScrit Objects Shiyi Wei and Barbara G. Ryder Deartment of Comuter Science, Virginia Tech, Blacksburg, VA, USA. Abstract. JavaScrit object behavior is dynamic and adheres to rototyebased inheritance. The behavior of a JavaScrit object can be changed by adding and removing roerties at runtime. Points-to analysis calculates the set of values a reference roerty or variable may have during execution. We resent a novel, artially flow-sensitive, context-sensitive oints-to algorithm that accurately models dynamic changes in object behavior. The algorithm reresents objects by their creation sites and local roerty names; it tracks roerty udates via a new control-flow grah reresentation. The calling context is comrised of the receiver object, its local roerties and rototye chain. We comare the new oints-to algorithm with an existing JavaScrit oints-to algorithm in terms of their resective erformance and accuracy on a client alication. The exerimental results on real JavaScrit websites show that the new oints-to analysis significantly imroves recision, uniquely resolving on average 11% more roerty looku statements. Keywords: JavaScrit, rogram analysis, oints-to analysis 1 Introduction Dynamic rogramming languages, including JavaScrit, Ruby and PHP, are widely used in develoing sohisticated software systems, esecially web alications. These languages share several dynamic features, including dynamic code generation and dynamic tying, used in real-world rograms [19]. For examle, JavaScrit code can be generated at runtime using eval and JavaScrit functions can be variadic (i.e., functions can be called with different numbers of arguments). Desite the oularity of these dynamic languages, there is insufficient tool suort for develoing and testing rograms because their dynamic features render many traditional analyses, and tools which deend on them, ineffective. In addition, instead of class-based inheritance JavaScrit suorts rototyebased inheritance [15, 26] that results in a JavaScrit object inheriting roerties from a chain of (at least one) rototye objects. The model also allows the roerties of a JavaScrit object to be added, udated, or deleted at runtime. This means that JavaScrit objects can exhibit different behaviors at different

2 2 times during execution. Moreover, object constructors may be olymorhic so that objects created by the same constructor may have distinct roerties. These asects of JavaScrit further comlicate tool building. Some tools have been develoed to suort JavaScrit software develoment (e.g., [18, 21]). Points-to analysis is the enabling analysis for such tools. Researchers have roosed several oints-to analyses that handle different features of JavaScrit (e.g., [8, 16, 25]). Nevertheless, there are oortunities to significantly imrove the recision of oints-to analysis through better modeling of object roerty set changes. In this aer, we resent a novel oints-to algorithm that can accurately model JavaScrit objects. Changes to object roerties are tracked more accurately to reflect object run-time behavior at different rogram oints. A new grah decomosition for control-flow grahs is used to better track object roerty changes. Prototye-based inheritance is more accurately modeled to locate delegated roerties. The analysis identifies objects by their creation site as well as their local roerty names uon construction, more accurately than the er-creation-site reresentation. To distinguish olymorhic constructors, this analysis can incororate dynamic information collected at runtime (see Section 3.6). Technically, the analysis is artially flow-sensitive (on our new controlflow grah structure) and context-sensitive, using a new form of object sensitivity [17]. 1 Rather than using the receiver object creation site as a calling context in the analysis, we use an aroximation of the receiver object and its roerties at the call site (i.e., object identity). In order to comare this algorithm with revious techniques, we instantiated our new oints-to analysis as the static comonent of the JavaScrit Blended Analysis Framework (JSBAF) [27]. Blended analysis collects run-time information through instrumentation to define the calling structure used by a subsequent static analysis, and to cature dynamically generated code. It has been demonstrated that blended analysis is ractical and effective on JavaScrit rograms [27]. We measured the erformance and accuracy of our new analysis on a statement-level oints-to client (REF analysis) that calculates how many objects are returned by a roerty looku (e.g., a read of x.). The major contributions of this work are: We have designed a novel identity-sensitive oints-to analysis that accurately and safely handles dynamic changes in the behavior of JavaScrit objects. This algorithm resents a new rogram reresentation that enables artially flow-sensitive analysis, a more accurate object reresentation, and an exanded oints-to grah that facilitates strong udates on the statements changing object roerties. 1 Informally, a flow-sensitive analysis follows the execution order of statements in a rogram; a flow-sensitive analysis can erform strong udates, but a flow-insensitive one cannot. A context-sensitive analysis distinguishes between different calling contexts of a method, roducing different analysis results for each context [20, 23]. A context-insensitive analysis calculates one solution er method.

3 3 Exerimental results from our new analysis comared to a recent ointsto analysis [25], both imlemented in JSBAF, showed that identity-sensitive analysis significantly imroved recision. On average over all the benchmarks (i.e., 12 oular websites), 48% of the roerty looku statements were resolved to a single object by our new analysis, while the existing analysis [25] uniquely resolved only 37% of these statements. Although our analysis incurred a 135% time overhead on average to achieve the increased recision, it was able to analyze each of the rograms in the benchmarks in under 5 minutes, attesting to its scalability in ractice. Overview. Section 2 defines the notion of object identity and then uses an examle to illustrate the sources of imrecision in JavaScrit oints-to analysis. Section 3 describes our new oints-to analysis algorithm and imlementation. Section 4 resents the REF analysis and the exerimental results. Section 5 discusses related work, and Section 6 offers conclusions and future work. 2 Background In this section we define key concets using an examle to illustrate the sources of imrecision in current oints-to analyses for JavaScrit. 2.1 JavaScrit Object Identity JavaScrit is a dynamically tyed rogramming language whose object behavior can change as object roerties are added or deleted at runtime. In strongly tyed rogramming languages, the notion of tye is used to abstract the ossible behavior of an object (e.g., the class of an object in Java) [22]; however, in dynamically tyed languages, the tye of an object can change during execution. In order to avoid confusion, we call the tye of a JavaScrit object its object identity. 2 Definition 1. The identity of an object at a rogram oint denotes all of its accessible roerties and their non-rimitive values. The accessible roerties of an object conform to the roerty looku mechanism imlemented in JavaScrit. Every JavaScrit object includes an internal reference to its rototye object from which it inherits non-local roerties. A JavaScrit object may have a sequence of rototye objects (i.e., a rototye chain) whose roerties it can inherit. When reading a roerty of an object o, the JavaScrit runtime checks the local roerties of o to see if o has a roerty named. If not, the JavaScrit runtime checks to see if the rototye object of o has a roerty named, continuing to check along the rototye chain from object to object until the roerty is found (or not) [7]. 2 This general notion can be used for other dynamic languages and is related to structured tying for strongly tyed languages [22].

4 4 Definition 2. Identity-udate statements are: (1) roerty write statement (i.e., x. = y or x[ ] = y), (2) roerty delete statement (i.e., delete x. or delete x[ ]), and (3) an invocation that directly or indirectly results in execution of (1) and/or (2). The identity-udate statements are the set of statements in JavaScrit that may affect the object identities. In Figure 1, we illustrate the identity of an object with an examle. Figure 1 shows the objects connected to O 1 at a rogram oint. The local roerties of object O 1 are named 1 and 2 and O 4 is its rototye object. O 7 is visible from O 1 by accessing O 1. 4 while O 6 is not visible from O 1 by accessing O 1. 2 because a local roerty named 2 exists for O 1. To sum u, the shaded nodes (i.e., O 6 and O 9 ) are not accessible from O 1 and the unshaded nodes constitute O 1 s identity. O _roto_ O 6 2 O 2 _roto_ O 3 O 4 _roto_ 4 O 7 O 5 O 9 4 O 8 Fig. 1: Object identity for O 1. (Unshaded nodes only) 2.2 Imrecision of Points-to Analysis A flow-insensitive analysis may roduce imrecise results when object identity changes, because it must safely aroximate oints-to relations and it cannot do strong udates. Existing context-sensitive analyses may roduce imrecise results because they lack the ower to distinguish between different object identities for the same JavaScrit object. In Figure 2, we resent a JavaScrit examle to illustrate the sources of imrecision of a flow-insensitive, context-insensitive oints-to analysis resulting from several dynamic features of JavaScrit. We also demonstrate that an existing context-sensitive analysis using the same object reresentation as [17] is ineffective at distinguishing the function calls in the examle. Lines 2-6 show a constructor function X(). Objects created by X() may or may not have the local roerty named or q (lines 4 and 5) deending on the value of its argument. The statement in line 12 udates the value of local roerty of an object ointed to by x if exists; otherwise, the statement adds the local roerty named to the object. Figures 3(a) and 3(b) show the oints-to grahs that reflect the run-time behavior of this code. We use the line number to reresent the object created (e.g., the object created at line 7 (new X) is O 7 ). We focus on two rogram oints in the execution, lines 10 and 15. The nodes O 7, O 4, and O 3 and O 9 constitute the identity of O 7 at line 10 and the nodes O 7, O 12, O 3 and O 14 constitute the identity of O 7 at line 15. Note that

5 5 1 function P(){ this. = new Y1(); } 2 function X(b){ 3 this. roto = new P(); 4 if(b) { this. = new Y2(); } 5 else this.q = new Y3(); 6 } 7 var x = new X(true); 8 x.bar = function(v, z){ v.f = z; } 9 var z1 = new Z(); 10 x.bar(x., z1); x. = new A(); var z2 = new Z(); 15 x.bar(x.,z2); Fig. 2: JavaScrit examle. O 1 is not visible from O 7 at lines 10 or 15 because of the existence of the local roerty named. The identity of object O 7 is different at these two rogram oints. Constructor olymorhism (lines 2-6), object roerty change (line 12) and function invocations (lines 10 and 15) in the examle make recise static ointsto analysis hard to achieve with current techniques. Figure 3(c) shows a oints-to grah for the examle built by a flow- and context-insensitive oints-to analysis. Dashed nodes and edges are imrecise oints-to relations that cannot exist at runtime. There are several sources of imrecision. Line 7 creates an object ointed to by variable x by invoking the olymorhic constructor X(). Not knowing the value of b, static analysis conservatively builds all the oints-to relations ossible from execution of X(). 3 When reading the roerty of x (line 10), static analysis returns objects O 4 and O 1 because a conservative analysis cannot distinguish whether or not O 4 actually exists. Furthermore, because of the imrecise result of the read of x., invoking the bar() function results in imrecise roerty reference from O 1 to O 9. Flow-insensitive oints-to analysis simly adds O 12 to O 7. (line 12) because it cannot erform strong udates. Because the analysis does not distinguish which objects v and z oint to on different calls of bar(), line 15 results in additional imrecision with resect to O 4.f and O 12.f. Flow-sensitive analysis is not sufficient to resolve the imrecision in the examle without an aroriate context for call sites. First, indirect assignment statements cannot be strongly udated in general. Second, assuming x. is strongly udated to oint to O 12 at line 12, a context-insensitive analysis does not remove the imrecise edges (< O 4, f >, O 14 ) and (< O 12, f >, O 9 ) because calls to bar() (lines 10 and 15) are not distinguished by calling contexts. Object sensitivity [17] 3 In this short examle, constant roagation of arameters would hel static analysis recision but clearly this is not always ossible.

6 6 x O 7 O 3 _roto_ O 4 v z f O 9 O 1 O O 4 5 q x O 7 _roto_ f f x v z1 (a) O 12 O 7 O 3 _roto_ z2 O 14 f O 1 z z1 z z2 f O 3 O 9 O 14 f O 12 f f O 1 v z1 O 9 (b) (c) Fig. 3: Imrecision of static oints-to analysis. (a) Run-time oints-to grah at line 10. (b) Run-time oints-to grah at line 15. (c) Flow- and context-insensitive oints-to grah. has been shown to erform better than call-string context sensitivity [23] for the idioms used in object-oriented languages [14]. However, object-sensitive analysis is not able to differentiate these two call sites because they have the same receiver object O 7, which has two different identities at these call sites. Our new oints-to analysis is designed to handle these constructs more accurately and to address the challenges raised by object identity udating and rototye-based inheritance. 3 Identity-sensitive Points-to Analysis In this section we will resent our identity-sensitive oints-to analysis for JavaScrit. We will exlain key ideas used in the analysis, including the intra-rocedural rogram reresentation (i.e., the block-sensitive decomosition of control-flow grahs), the solution sace (i.e., the annotated oints-to grah with access ath edges and in-construction nodes), the transfer functions of the identity-udate statements as well as the identity-reserving statements, identity sensitivity (i.e., a form of context sensitivity based on object sensitivity that catures changes in object behavior during execution) and block sensitivity (i.e., a artial flow sensitivity erformed on the transformed CFG). Finally, we will discuss the imlementation details of our algorithm.

7 7 3.1 Identity-Preserving Block Grah A flow-insensitivie analysis ignores the control flow of a rogram while a flowsensitive analysis tyically uses an intra-rocedural control-flow grah (CFG). Our analysis aims to rovide a better model of a JavaScrit object whose identity exhibits flow-sensitive characteristics (e.g., allowing addition and deletion of object roerties at any rogram oint). Cognizant of the ossible overhead introduced by a fully flow-sensitive analysis, we designed a artially flow-sensitive analysis that only erforms strong udates when ossible on identity-udate statements using a transformed CFG, called the Identity-Preserving Block Grah (IPBG). Recall that the identity-udate statements, including the roerty write (i.e., add or udate a roerty) and delete (i.e., remove a roerty), directly change the object identity in JavaScrit; all other statements (e.g., roerty read) are identity-reserving statements. Figure 4 shows an examle IPBG (Figure 4(b)) comared to its original CFG (Figure 4(a)). An IPBG is a transformed control-flow grah whose basic blocks are aggregated into region nodes according to whether or not they contain an object identity-udate statement. The IPBG also contains identity-udate statements as secial singleton statement nodes (i.e., identity-udate nodes). An examle of a region node (i.e., identity-reserving node) is in Figure 4(b) whereas node x = new A() is an examle of a identity-udate node. Note that in creating singleton nodes the algorithm breaks aart former basic blocks (e.g., 1 {1, x = new A(), 1 }). 1 x = new A(); delete x.; red: a, b red: b succ: a a x = new A(); b delete x.; succ: a 9 red: b succ: a, b 9 succ: a, b (a) (b) Fig. 4: IPBG generation. (a) CFG. (b) IPBG. We first slit any basic blocks in the CFG that contain at least an identityudate statement (see Definition 2 in Section 2), obtaining a slit-cfg. Identityudate statements (1) and (2) can be detected syntactically and invocations that may result in an identity change (i.e., category (3)) are found by a linear

8 8 call grah traversal. 4 We then use a variant of the standard CFG construction algorithm [1] to build the slit-cfg. The header nodes used include the standard headers [1] lus (i) any identity-udate statement is a region header of an identity-udate node containing only that statement, and (ii) any identityreserving statement that immediately follows an identity-udate statement is a region header of an identity-reserving node. In an IPBG, identity-reserving region nodes are formed based on grouing nodes in the slit-cfg that share the same control-flow relations with resect to identity-udate nodes. The ossible control-flow relations of node n 1 and n 2 in a slit-cfg include: (1) n 1 is a successor of n 2, (2) n 1 is a redecessor of n 2, (3) n 1 is both a successor and a redecessor of n 2 (i.e., n 1 and n 2 exist in a loo) and (4) n 1 and n 2 have no control-flow relation (e.g., n 1 and n 2 are resent in different branches). We label each node in a slit-cfg with its relations to each identity-udate node via deth-first searches. The set of labels form a signature for that node. If nodes share the same signature it means that they have the same control-flow relationshi(s) to a (set of) identity-udate statement(s) so that they can be collased to an identity-reserving node in the IPBG. Figure 4(b) shows the signatures of the identity-reserving regions in the generated IPBG; a and b reresent the identity-udate statements x=new A() and delete x., resectively. Basic blocks 2, 4, 5 and 7 are aggregated because they only aear as successors of x=new A() and have no control-flow relation to delete x.. The region node is not further aggregated with basic block 9 because 9 is a successor of delete x. but is not. 3.2 Points-to Grah Reresentation Our oints-to grah reresentation includes constructs that facilitate the handling of strong udates by our analysis. Our algorithm design allows strong udates when ossible for identity-udate statements. In contrast, most flowsensitive Java analysis algorithms cannot erform strong udates for indirect assignment statements (e.g., x. = y) and few analyses consider roerty delete statements, which are uncommon in object-oriented languages. Two existing techniques hel to enable strong udates for such statements in JavaScrit: recency abstraction and access ath mas. Recency abstraction [2, 11] associates two memory-regions with each allocation site. The most-recently-allocated block, a concrete memory-region, allows strong udates and the not-most-recently-allocated block is a summary memoryregion. We adat the idea of recency abstraction to enable strong udates during analysis of constructor functions. De et al. [6] erformed strong udates at indirect assignments by comuting the ma from access aths (i.e., a variable followed a sequence of roerty accesses) to sets of abstract objects. This work demonstrated the validity of using access ath mas to erform strong udates for indirect write statements in 4 Our analysis requires a re-comuted call grah as inut. See Section 3.6 for details.

9 9 node N variable v v abstract object O o oints-to grah G variable reference v O (v, φo) edge roerty reference O i O j E (< φo i, >, φo j) annotation access ath v O (< v, >, φo) d annotation v d A * annotation * O i O j Table 1: Exanded oints-to grah with annotations. Java. We adat this aroach to oints-to analysis for JavaScrit by exanding the oints-to grah reresentation instead of using searate mas. Table 1 lists the nodes, edges and annotations in our oints-to grah. In addition to variable nodes v and abstract object nodes o, our oints-to grah contains in-construction object 5 Details of the in-construction objects will be discussed in Section 3.3. For sake of simlicity, we use φo to reresent either kind of object node (i.e., o There are three kinds of edges. Variable reference and roerty reference edges exist in a traditional oints-to grah. An access ath edge, (< v, >, φo), denotes that the roerty of variable v refers to object φo. < v, > reresents an access ath with length of 2 (i.e., a variable followed by one field access v.). 6 Our analysis calculates may ointer information, meaning that a oints-to edge in the grah may or may not exist at runtime. To better aroximate the identities of JavaScrit objects, we introduce annotations on roerty reference edges as well as access ath edges. The annotations hel to calculate must exist information for object roerty names. In our analysis, the d annotation on a roerty name (i.e., d ) denotes that the local roerty named must not exist. This annotation only alies to access ath edges in our oints-to grah. The other annotation,, alies to both roerty reference edges and access ath edges. denotes that the local roerty named may not exist. Proerty reference edges without annotation or access ath edges without annotation 5 Similar to the recency abstraction, an in-construction object always describes exactly one concrete object. In our analysis, it exists only during analysis of a constructor. 6 The length of an access ath is one more than the number of field accesses [6]. d

10 10 reresent must exist information for the roerty names. We use φ to reresent any kind of d, or edge. These annotated edges hel us erform a more accurate roerty looku (see Section 3.3). P t(x) denotes the oints-to set of x and P t(< φo, >) denotes the oints-to set of the roerty of φo. P t(< v, >) denotes the oints-to set of access ath v.. We also define the oeration Alias(v) which returns the set of variables W such that v and w W oint to the same object. aset(v) denotes the set of all access ath edges of v (i.e., aset(v) = q : {(< v, q φ >, φo)}). In addition to the oints-to grah, we use a maing data structure to store intermediate information in the analysis. The ma M is used to record the list of roerty names when an object is constructed. An abstract object (e.g., o) is the key in M whose value is the set of local roerty names that exist when the constructor function of the abstract object returns (e.g., {1, 2, 3}). 3.3 Points-to Analysis Transfer Functions In this section we describe the data-flow transfer functions for the statements shown in Table 2. Object creation (x = new X(a 1, a 2,..., a n )). In our analysis, an object creation statement (i.e., new statement) is modeled in three stes. x = new X creates an in-construction i. Then the invocation of the constructor new X((a 1, a 2,..., a n )) is modeled as a function call i. Uon the return of the constructor (i.e., ret X ), the analysis removes the in-construction object from the oints-to grah and redirects all oints-to relations i to an abstract object i )). If the local roerty set of the in-construction object matches that of an existing abstract object with the same allocation site, the inconstruction object is merged into the abstract object; otherwise, a new abstract object is created to relace the in-construction object. There is at most one inconstruction object for each creation site. 7 The transfer function of the object creation statement ensures that abstract objects are based on their allocation site as well as their constructed local roerties (i.e., an aroximation of actual object identity); in other words, the objects created at the same allocation site that contain the same set of local roerty names share the same abstract object in our analysis. This object reresentation is more recise than using one abstract object er creation site. Proerty write (x. = y). In general, strong udates cannot be erformed on the roerty write statement because an abstract object may summarize multile run-time objects; however, use of in-construction objects and access ath edges enable strong udates in our analysis. In the oints-to grah G, if x only refers to one object and the object is an in-construction object, we know 7 Recursive constructor calls involve the creation of an in-construction object when the in-construction object for the same allocation site already exists (before it resolves into an abstract object). In our analysis, the existing in-construction object is resolved into a secial abstract object whose set of roerties uon construction is unknown. A fixed oint calculation is done using the secial abstract object.

11 Statement Transfer function (1) x = new X : (G aset(x)) (2) new X((a1, a2,..., an)) : G {invoke(g, a1, a2,..., an)} si : x = new X(a1, a2,..., an) (3) retx : (1) if P t(x) = 1 and φoi P t(x)} : G φ >, P t(x) φoj P φ >)}) >, P t(x) φoj P t(y)} (2) otherwise : (2.1) (G {(< x, φ >, φoi) φoi P t(< x, φ >)}) {(< x, >, φoj) φoj P t(y)} x. = y (2.2) G {(< φoi, >, φoj) φoi P t(x) φoj P t(y)} (2.3) G {(< z, >, φoi) z Alias(x) P t(z, φ ) φoi P t(y)} (1) if P t(x) = 1 and φoi P t(x)} : G φ >, P t(x) φoj P φ >)} (2) otherwise : (2.1) (G {(< x, φ >, φoi) φoi P t(< x, φ >)}) {(< x, d >, null)} delete x. (2.2) G {(< φoi, >, φoj) φoi P t(x) φoj P t(< φoi, >)} {(< φoi, >, φoj) φoi P t(x) φoj P t(< φoi, >)} (2.3) G {(< z, >, φoi) z Alias(x) P t(z, ) φoi P t(< z, >)} {(< z, >, φoi) z Alias(x) P t(z, ) φoi P t(< z, >)} (G aset(x)) {(x, φoi) φoi P t(y)} x = y (G aset(x)) {(< x, φoi >) oi looku(y, )} x = y. (G aset(x)) {invoke(g, M, φoi, a1, a2,..., an) φoi P t(y) M looku(y, m)} x = y.m(a1, a2,..., an) 11 Table 2: Transfer functions of rogram statements.

12 12 that x refers to a secific concrete object. The analysis then erforms strong udates on the roerty reference edges by removing the oints-to edges in G i. (if they exist) and adding the new edges imlied by P t(y). In other cases (i.e., the cardinality of Pt(x) is more than 1 or x refers to an abstract object), we use access ath edges to enable strong udates on roerty write statements. First, the access ath of x. can be strongly udated by removing the access ath edges in G denoting x. (if they exist) and adding the new edges (e.g., (< x, >, o j ) where o j is referred to by y). Second, the object(s) x oints to are weakly udated (e.g., the edge (< o i, >, o j ) is inserted if x oints to o i and y oints to o j ). The roerty reference edges are inserted with the annotation because the roerty write statement may not affect all variables ointing to the udated object. Last, the access ath edges of the variables that have a may alias relation to x need to be weakly udated. For examle, (< z, >, o i ) is inserted to G if z may be an alias of x, and there exists at least an edge denoting z. (with or without annotation). In Figure 5, we show an examle of the effects of roerty write statement on the oints-to grah. Figure 5(a) illustrates the inut oints-to grah for the roerty write statement x. = y. In Figure 5(b), our analysis erforms a strong udate on the access ath x. (i.e., delete (< x, >, O 4 ) and add (< x, >, O 2 ), (< x, >, O 3 )) and inserts the edges (< O 1, >, O 2 ), (< O 1, >, O 3 ) (i.e., weak udates). O 3 y x O 2 O 4 O 1 z (a) * O 5 O 3 y * x * O 4 O * 2 O 1 z (b) O 5 Fig. 5: Proerty write examle. (a) Inut oints-to grah. (b) Udated oints-to grah. Proerty delete (delete x.). The transfer function of the delete statement is similar to the roerty write statement. Our analysis strongly udates the access ath edges by removing the existing edges and adding a new edge (i.e., (< x, d >, null)) that denotes x must not have a local access ath x.. When erforming weak udates on the roerty reference edges of an object o i that is referred to by x, all existing edges denoting o i. should be annotated by because the roerty named may not exist locally for o i. The same rule alies when udating the access ath edges of the aliases of x. Direct write (x = y). The effects of direct variable assignment on the ointsto grah are relatively straightforward. x = y creates oints-to edges from x to all objects ointed to by y. Note that we erform weak udates on direct

13 13 assignments. Although the analysis removes all the access ath edges of x from the oints-to grah (i.e., G - aset(x)), soundness is ensured because lookus through the abstract objects reflect less recise, yet safe aroximations. Also, the access ath edges of y cannot be coied to x because access ath edges can only be added via strong udates. Proerty read (x = y.). JavaScrit enforces an asymmetry between reading and writing roerty values. When writing the value of a roerty or deleting a roerty, JavaScrit always uses the local roerty, ignoring the rototye object. When reading a roerty of a variable (e.g., x = y.), recall that JavaScrit suorts rototye-based inheritance. In some existing oints-to analyses for JavaScrit, when reading roerty of an object, the roerty looku mechanism is modeled by reorting all roerties named in the rototye chain of the object to ensure analysis safety. Procedure 1 Otimized object roerty looku: looku(v, ) Outut: accessible objects v.: P 1: if P t(< v, >) then 2: P P t(< v, >) P t(< v, >) 3: return 4: else if P t(< v, >) or P t(< v, d >) then 5: P P t(< v, >) 6: for each object φo in looku(v, roto ) do 7: S.ush(φo) 8: end for 9: else 10: for each object φo in P t(v) do 11: S.ush(φo) 12: end for 13: end if 14: while S is not emty do 15: φo i S.o() 16: P P t(< φo i, >) P t(< φo i, >) 17: if P t(< φo i, >) = 0 and (P t(< φo i, roto >) null or P t(< φo i, roto >) null) then 18: for each object φo j in P t(< φo i, roto >) P t(< φo i, roto >) do 19: S.ush(φo j) 20: end for 21: end if 22: end while Procedure 1 illustrates our otentially more recise roerty looku rocedure enabled by our edge tyes and their annotations. This worklist algorithm iterates through all the accessible objects in the oints-to grah when roerty of variable v is read. Intuitively, it favors the use of access ath edges in roerty looku because they reflect the results of strong udates, before examining roerty reference edges. Lines 1 to 12 initialize the algorithm uon three conditions.

14 14 (1) If there exist access ath edges for v. without annotation (i.e., roerty must exist locally), the objects in the P t(< v, >) and P t(< v, >) are considered to be accessible roerties (line 2) and the algorithm returns (line 3). (2) If there exist access ath edges for v. with either annotation, the algorithm needs to looku objects in the rototye chain. In this case, the objects in the P t(< v, >) (if v. exists) are considered to be accessible roerties (line 5) and the algorithm ushes all the immediate rototye objects of v onto the worklist (lines 6 to 8). (3) Otherwise (i.e., no access ath edge for v. exists), only the abstract objects are used for looking u so that all the objects in the P t(v) are ushed onto the worklist (lines 10 to 12). Lines 14 to 22 iterate the worklist. All the objects in P t(< φo, >) and P t(< φo, >) are considered to be accessible roerties by our analysis (Line 16). Since an edge annotated with means that the roerty may not exist locally, the algorithm will continue looking u the rototye chain, until it reaches at least one oints-to edge named without annotation or the end of the rototye chain (Line 17 to 21). Thus, instead of finding all the roerties named in the rototye chain (i.e., looku all(v, )), our algorithm can sto when it finds an existing roerty (i.e., a roerty named without annotation). This new roerty looku algorithm looku(v, ) mimics the run-time roerty looku mechanism of JavaScrit while still assuring the safety of our analysis. For the examle in Figure 5(b), looku(z, ) results in O 2 and O 3 through the access ath while looku(x, ) results in O 2, O 3, O 4 and O 5 through the abstract object O 1. In Table 2, the transfer function of the roerty read statements refers to this otimized object roerty looku algorithm. Because we erform weak udates on the roerty read statements, similar to direct writes, the analysis removes all the access ath edges of x from the oints-to grah to ensure safety. Method invocation (x = y.m(a 1, a 2,..., a n )). The method invocation (e.g., x = y.m(a 1, a 2,..., a n )) resolves for every receiver object ointed to by y. The invoked methods are determined by reading the roerty y.m through our otimized looku algorithm. Uon the return of method invocation, x is weakly udated by removing all its access ath edges from G. 3.4 Identity Sensitivity Identity sensitivity for JavaScrit is a new form of context sensitivity derived from the notion of object sensitivity for languages such as Java [17]. In object sensitivity, each method is analyzed searately for each object on which it may be invoked. For strongly tyed languages like Java, often object sensitivity identifies objects in the analysis by their creation sites. Calls of a method using two different receiver objects (i.e., created at different sites) will result in two searate analyses of the method, even if the calls originated from the same call site. However, this is insufficient for JavaScrit analysis, because object behavior may change dynamically at any rogram oint during execution. Ideally, identity sensitivity would analyze each method searately for each object identity on which it may be invoked. However, the grah reresentation

15 15 O 2 _roto_ O * 1 O 3 O 1 O 5 2 * O 4 _roto_ (a) _roto_ O O 6 7 O 9 _roto_ O 1 O 4 O * _roto_ (b) O 2 O 3 O 7 Fig. 6: Aroximate object identity as a context. (a) Object identity of O 1. (b) Aroximate object identity of O 1. of object identity may contain many edges and nodes both locally and along rototye chains (e.g., object identity of O 1 in Figure 6(a)), which would be rohibitively exensive to use as a context. Therefore, we use an aroximation of the object identity of the receiver object to differentiate calls that will be analyzed searately. Our aroximation consists of the object, its local roerties and their object values lus its chain of rototye objects. In Figure 6(b) we show the aroximation corresonding to the object identity of object O 1 in Figure 6(a). Note that the edges with the same local roerty name (annotated and not annotated) in the oints-to grah are merged in the aroximate object identity (e.g., (< O 1, 1 >, O 2 ) and (< O 1, 1 >, O 3 ) in Figure 6(a)). An objectsensitive analysis grous the calls using a receiver object created at the same allocation site and our identity-sensitive analysis more accurately grous the calls where receiver objects have the same aroximate object identity. We intend to study the effects of using different object identity aroximations as calling contexts in future work. 3.5 Block-sensitive Analysis Our new oints-to analysis algorithm is a fixed oint calculation on the call grah, initialized with an emty oints-to grah on entry to the JavaScrit rogram, in which every constitutent IPBG is traversed in a flow-sensitive manner. Essentially, we have designed the oints-to algorithm to emhasize recision for the object identity information in the oints-to grah and the IPBG to hide control flow not relevant to identity udates. More secifically, our analysis solves for the oints-to grah on exit of each IPBG node. The transfer function for a node in the IPBG is one of two kinds: (1) for a identity-udate node erform strong udate of the changed roerty, if ossible (as in Table 2), or (2) for a identity-reserving node erform a flowinsensitive analysis of the statements in that node, using an initial oints-to grah (IN) and storing the fixed oint reached in oints-to grah OUT.

16 16 (a) v. d v. v. v. d v. d v. v. v. v. v. v. v. v. v. v. (b) o. o. o. o. o. o. o. o. o. o. o. o. Table 3: Union rules. (a) Access ath edges union rules. (b) Proerty reference edges union rules. Normally in a oints-to analysis, we would form IN as a union of the OUT oints-to grahs of redecessors of a node. In our algorithm, we need to maintain the invariant of our annotated roerty edges, namely that a roerty name without an annotation means that roerty exists and a roerty name with the d annotation means that roerty must not exist. Table 3 shows the union rules for the access ath edges and roerty reference edges when two oints-to grahs are unioned. For the access ath edges: (1) if access ath v. φ does not exist in at least one redecessor, then v. φ does not exist after union; (2) if v. d or v. exists in both redecessors, then v. d or v. resectively exists after union; (3) otherwise, v. exists after union. For the roerty reference edges: (1) if o. exists in both redecessors, then o. exists after union; (2) otherwise, if o. or o. exists in at least one redecessor, then o. exists after union. These rules ensure analysis safety when roerty looku is erformed. 3.6 Imlementation of Identity-sensitive Analysis in JSBAF Our new oints-to analysis was imlemented with a client as the static comonent of the JavaScrit Blended Analysis Framework (JSBAF), a general-urose analysis framework for JavaScrit [27]. This framework was designed to strongly coule dynamic and static analyses to account for the effects of the dynamic features of JavaScrit. JSBAF can be alied to analyze a JavaScrit rogram (i.e., JavaScrit code on a webage) automatically in the resence of a good test suite. The dynamic hase gathers run-time information by executing tests. A trace of each test is collected, including call statements, object creations, variadic function calls with arameters, and dynamically created code. The imlementation searates each trace into its constituent age traces. Each subtrace on a age is analyzed searately in the static hase. Data-flow solutions from different age subtraces are combined into a entire solution for that age. Blended analysis uses only the observed calling structure as a basis to model the JavaScrit rogram. Knowledge of unexecuted calls or object creations can be used to rune other unexecuted code sharing the same control deendence. For examle, knowing Y 3() is not called at line 5 in Figure 2, blended analysis runes this unexecuted statement so that the imrecise node O 5 and its connected edges will not be created. Thus, blended analysis is unsafe because not all executions are exlored, but sound on the observed executions.

17 17 Our oints-to algorithm was imlemented on the IBM T.J. Watson Libraries for Analysis (WALA) oen-source static analysis framework 8 which contains several existing static oints-to analysis algorithms. WALA has been extended to enable blended analysis by roviding dynamic information (i.e., a run-time collected call grah, dynamically generated code, object creation sites) [27]. We chose this imlementation latform because blended analysis has been demonstrated to be more efficient and effective in analyzing real JavaScrit rograms. 9 Our algorithm takes as inuts the run-time collected calling structure (i.e., call grah 10 ) and source code including dynamically generated code. Code runing was erformed on function bodies so that the code in olymorhic constructors and variadic functions was secialized. Hence, constructor olymorhism was handled by our imroved object reresentation combined with dynamic information (i.e., objects created at the same allocation site with different sets of roerty names are reresented as searate abstract objects). x O 7 O 3 _roto_ v C1 f O 1 zc1 v C2 f O 14 O f * 12 z C2 * O 7 O 3 _roto_ O 1 x z2 O 4 f * z1 (a) O 9 v C1 f z C1 O f * 4 O 9 z1 (b) Fig. 7: Blended identity-sensitive oints-to analysis. (a) oints-to grah at line 10. (b) oints-to grah at line 15. Examle. In comarison to the inaccurate oints-to solution of a flow- and context-insensitive analysis for the JavaScrit code in Figure 2, we now demonstrate the results of our identity-sensitive oints-to analysis in the context of blended analysis. Figures 7(a) and 7(b) show the oints-to grahs obtained at lines 10 and 15, resectively. Because blended analysis executes the rogram and does not observe an object created by the constructor Y3, the code at line 5 is runed so that our analysis does not generate the inaccurate node O 5 nor the edge (< O 7, q >, O 5 ). For the call statement at line 10, our oints-to analysis calculates the identity aroximation of O 7, namely C1: {O 7, :O 4, roto : O 3 }. Also, when looking u x. at line 10, our algorithm returns O 4 because there is 8 htt://wala.sourceforge.net/ 9 A static analysis was not able to finish analyzing most webages in [27]. 10 Each node in the call grah is associated with the object creations observed during its execution.

18 18 no annotation on the roerty reference edge so that further looku through the rototye chain is not necessary. Note that the oints-to grah in Figure 7(a) is as recise as the run-time oints-to grah (Figure 3(a)). At line 12, x. is strongly udated via the access ath edge (< x, >, O 12 ). For the call statement at line 15, our oints-to analysis calculates the identity aroximation of O 7, C2: {O 7, :[O 4, O 12 ], roto : O 3 }. Our oints-to algorithm distinguishes this call site from line 10 because O 7 has a different identity here. The looku of x. at line 15 follows the access ath edge so that the node O 12 is returned. Thus, in this examle our analysis results in none of the inaccurate edges in the flow- and context-insensitive analysis (Figure 3(c)) and reflects the run-time behavior of JavaScrit objects (Figure 3(b)). 4 Evaluation In this section, we resent exeriments using JSBAF with our identity-sensitive oints-to analysis comared to an existing oints-to analysis [25], evaluating both with a REF client. 4.1 Exerimental Design REF Analysis. To evaluate the recision and erformance of our oints-to analysis, we imlemented a JavaScrit reference analysis (REF). The REF client calculates the set of objects returned by roerty looku at a roerty read statement (i.e., x = y.) or call statement (i.e., x = y.(...)). 11 For each of these statements s in a function being analyzed in calling context c, we comute REF (s, c), the set of objects returned by a roerty looku for each o. where o is ointed to by y. The cardinality of the REF set deends on the recision of the oints-to grah and the roerty looku oeration; the smaller the set returned, the more useful for rogram understanding, for examle. In Figure 2, assume we add the function roerty x.foo = function(){var a = this.; return a; } Effectively, foo() returns the roerty looku result for this.. If x.foo() is called at line 11 before the roerty udate statement x.=new A(), it will return O 4. If x.foo() is called at line 13 after x.=new A(), it will return O 12. For an analysis that is flow-insensitive or that cannot distinguish these call sites by calling context, the return value of each of these function calls will contain at least two objects (i.e., O 4 and O 12 ). Comarison with Points-to Analysis in [25]. We use the term Corr to refer to a blended version of correlation-tracking oints-to analysis [25] (see Section 5 for more details) and its REF client. To demonstrate the additional 11 All source code instances of roerty lookus (e.g., return y. ) occur as one of these two statements in the WALA intermediate code.

19 19 Website Corr CorrBSIS facebook.com 38% 52% 10% 50% 47% 3% google.com 32% 51% 17% 53% 42% 5% youtube.com 41% 47% 12% 54% 41% 5% yahoo.com 48% 46% 6% 52% 45% 3% wikiedia.org 29% 45% 26% 43% 39% 18% amazon.com 45% 52% 3% 46% 51% 3% twitter.com 32% 53% 15% 39% 49% 12% blogsot.com 35% 34% 31% 53% 36% 11% linkedin.com 34% 49% 17% 44% 50% 6% msn.com 40% 36% 24% 48% 37% 15% ebay.com 30% 40% 30% 46% 40% 14% bing.com 41% 34% 25% 54% 37% 9% Average 37% 45% 18% 48% 43% 9% Table 4: REF analysis recision. recision of our analysis over Corr, we alied the correlation extraction transformation to our JavaScrit benchmarks before erforming our oints-to analysis. We use the term CorrBSIS to refer to a blended version of this augmented new oints-to analysis and its REF client. For each algorithm, an object roerty looku returns a REF set whose cardinality REF (s, c) is calculated. For Corr, the looku all() aroximate algorithm described in Section 3.3 is used. For CorrBSIS, we use our otimized looku algorithm looku() in Procedure 1. Benchmarks. We conducted the exeriments with the benchmarks collected from 12 websites among the to 25 most oular sites on alexa, reusing website traces originally used in [27]. The results in [27] showed that the collected traces covered a large ortion of the executable JavaScrit code in those websites, including dynamically generated code. Although the benchmarks we used cover the most oular websites, it will require further investigation to determine how reresentative these benchmarks are of other websites. The exerimental results were obtained on a 2.53GHz Intel Core 2 Duo MacBook Pro with 4GB memory running the Mac OS X 10.5 oerating system. 4.2 Exerimental Results Imroved REF Precision. Table 4 shows the REF client results for the 12 websites. Columns 2-4 resent the results for Corr and columns 5-7 resent the results for CorrBSIS. For each website, columns 2 & 5, 3 & 6, and 4 & 7 in Table 4 corresond to the ercentage of roerty looku statements that return 1 object, 2-4 objects, and more than 4 objects, resectively. The result shown for each website is averaged over the corresonding ercentage numbers for all the webages in that domain; for examle, the 38% entry for facebook.com in column 2 is the average for Corr over the 27 webages analyzed of the ercentage of roerty looku statements returning only 1 object.

20 20 Website Corr CorrBSIS overhead facebook % google % youtube % yahoo % wiki % amazon % twitter % blog % linkedin % msn % ebay % bing % Average % Table 5: REF analysis cost (in seconds) on average er webage. Comaring columns 2-4 with 5-7 in Table 4 for each website, we see the relative recision imrovement of CorrBSIS over Corr. For REF analysis, the best result is that the looku returns only one object and the roerty looku is more recise if the number of objects returned is smaller. On average over all the websites, Corr reorted 37% of the roerty looku statements were resolved to a single object, while CorrBSIS imroved this metric to 48%, a significant imrovement. In addition, REF analysis results may become too aroximate to be useful if too many objects are returned. Although 18% of the statements returned more than 4 objects for Corr, CorrBSIS reduced that number to 9%. These imroved recision results indicate the otential for greater ractical use of identity-sensitive oints-to information by client analyses. We also investigated the average number of objects returned by a roerty looku statement. For each website, we calculated the number of objects er statement on average over all its webages. Over all the benchmarks, Corr roduced on average 2.8 objects and CorrBSIS only reorted on average 2.3 objects. Intuitively, this means that on average fewer objects at each roerty looku statement must be examined to gain better understanding of the code. REF Performance. An analysis aroach is ractical if it scales to realworld rograms, such as JavaScrit code from actual websites. Because CorrBSIS is artially flow-sensitive and context-sensitive, it is imortant to demonstrate that this analysis is scalable. Table 5 shows the time erformance of Corr versus CorrBSIS. 12 Columns 2 and 3 resent the average webage analysis time for each website, averaging over all of its webages. Both Corr and CorrBSIS comletely analyzed all the benchmark rograms. On average over all the websites, Corr comletely analyzed a webage in 22.3 seconds, while CorrBSIS did so in The time cost in Table 5 reflects the erformance of the static hase of blended analysis. In the exeriments, the dynamic hase of Corr and CorrBSIS is the same for both analyses. The work in [27] has demonstrated that the static hase dominates the blended analysis cost.

21 Website No. of % of functions % of identity- No. of functions w/ udate(s) udate stmt contexts facebook % 8% 4.0 google % 6% 6.7 youtube % 6% 3.9 yahoo % 4% 2.4 wiki % 19% 4.8 amazon 729 6% 6% 1.9 twitter % 5% 3.4 blog % 14% 6.1 linkedin 920 8% 11% 3.6 msn % 8% 2.8 ebay % 13% 7.5 bing % 11% 4.9 Average % 9% 4.3 Table 6: Benchmark and context statistics. (Total contexts er website is aroximately column 2 times column 5.) seconds, incurring an 135% average time overhead er webage, accetable for a research rototye imlementation which has not been otimized. Discussion. We collected data characterizing benchmark rogram structure and comlexity to relate these characteristics to observed analysis recision and erformance. The entries in Table 6 all reresent averages er webage that are averaged over an entire website. Column 2 shows the average number of functions in a JavaScrit rogram. Column 3 shows the ercentage of functions containing at least one identity-udate statement. Column 4 shows the ercentage of statements that are identity-udate statements. Column 5 shows the number of contexts roduced by CorrBSIS as a multilier for column 2. On average over all the websites, 10% of the functions contained local identity-udate statement(s); these averages ranged from 4% for yahoo.com to 18% for msn.com. This suggests that the identity-udate statements are localized in a relatively small ortion of the JavaScrit rogram (e.g., in constructor functions). Manual insection of several websites (i.e., facebook, google and youtube) revealed there were significant object behavior changes in JavaScrit code outside of constructors. On average over all the websites, 9% of the statements were identified as identity-udate statements. The relatively small number of identity-udate statements means that our IPBG contained many fewer nodes than the corresonding CFGs; therefore the flow-sensitive analysis was more ractical in cost on the IPBGs. Now we comare the analysis recision observed in Table 4 with the number of contexts generated on average er function er age (column 5 in Table 6) to observe the effect of identity sensitivity. google, blog, and ebay were the websites for which CorrBSIS imroved recision the most, whereas amazon, yahooo, twitter, and msn were the websites for which CorrBSIS roduced similar results to Corr. For the former websites, CorrBSIS generated the greatest number of contexts er function er webage. For the latter websites, CorrBSIS generated the 21