XX:10 Program Tailoring:Slicing by Seguential Criteria infeasible for SCline 25,according to the points-to information provided for this program. Let us see how SCEXT works in growing SCline 25 to become ESCline 25.Initially,SCline25 has one statement at line 25.which resides in method renderBody().The (abstract)receiver object pointed to by renderer at line 12 is allocated only at the allocation site at line 11 and is considered as the calling context for line 25 in an object-sensitive pointer analysis. There is another allocation site at line 18 for the same type,HTMLRenderer,but this is not considered,since the abstract object created at line 18 does not flow to line 12(according to the points-to information available).At this stage,we have SCline 25:line 11line 25. Similarly,we now look for the allocation sites that can be used as the calling contexts for line 11 contained in method render()at line 10,which is called from this.render()at line 8 in method end()defined in the AbstractRenderer class.Thus,the receiver obiects on which method render()(line 10)is invoked are the ones pointed to by renderer at line 5.These objects are returned from the call to createRenderer()at line 4.Thus,renderer points to the objects created by the allocation sites in all different branches in createRenderer(). According to the points-to information,the target method end()invoked at the virtual call site at line 5 can only be made on an receiver object of type SummaryHTMLRenderer.Thus, we now have an even longer SCline 25 line 20-line 11-line 25. The allocation site at line 3 is the object-sensitive context for the target method createRenderer(),which contains line 20,invoked at line 4.No further extension is possible, since main()has been reached.Now,we have SCline 25:line 3-line 20-line 11-line 25. If we apply SCDFA to this four-point SCline 25,T(SCline 25)will consist of all the lines except lines 16,18 and 22.However,including line 3 does not help as it dominates line 20 in GICFG.By removing it,we obtain ESCline 25:line 20-line 11-line 25 as desired.Applying SCDFA to ESCline25 yields the same tailored program obtained for the three-point SCline25. When lengthening SCs,we aim to reduce infeasible paths by exploiting branch correlations. However,with longer SCs,SCDFA will end up using more data-flow facts,as seen in Figure 5, making it less efficient than before.So a precision/scalability tradeoff has to be made.Our key observation is to keep a SC extension point found if it is inside one branch in a multi-way branching statement or a target method invoked at a polymorphic call site (Figure 3), provided that the point is not in a cycle.This way,the other branches (or target methods) are infeasible (with respect to a given SC)and will not show up in the tailored program. Let us return to the program understanding task at hand.From the tailored program T(ESCline 25)obtained for ESCline 25,we can see clearly that the allocation site at line 20 in method createRenderer()is responsible for the rendering-related write at line 25. 4 Formalism We first formalize SCDFA and SCEXT and then prove some properties about TAILOR. 4.1 SC-based Data-Flow Analysis We provide a context-insensitive formalization of SCDFA as context sensitivity is achieved on top of this formalization via CFL-reachability,as shown in Figure 6.Essentially,we describe the data-flow equations needed for solving its BU and TD passes in the IFDS framework [38] The IFDS problem framework is precise and efficient for solving data-flow problems with three properties.First,the set D of data-flow facts is finite.Second,the domain and range of each flow,i.e.,transfer function is the power set of D,denoted 2,the lattice ordering relation E on 2 is or 2,and the meet operator nis nor U.Finally,each fow function f must be distributive over 2:VS1,S2 E2D:f(S1nS2)=f(S1)nf(S2).XX:10 Program Tailoring: Slicing by Sequential Criteria infeasible for SCline 25, according to the points-to information provided for this program. Let us see how SCEXT works in growing SCline 25 to become ESCline 25. Initially, SCline25 has one statement at line 25, which resides in method renderBody(). The (abstract) receiver object pointed to by renderer at line 12 is allocated only at the allocation site at line 11 and is considered as the calling context for line 25 in an object-sensitive pointer analysis. There is another allocation site at line 18 for the same type, HTMLRenderer, but this is not considered, since the abstract object created at line 18 does not flow to line 12 (according to the points-to information available). At this stage, we have SCline 25 : line 11 → line 25. Similarly, we now look for the allocation sites that can be used as the calling contexts for line 11 contained in method render() at line 10, which is called from this.render() at line 8 in method end() defined in the AbstractRenderer class. Thus, the receiver objects on which method render() (line 10) is invoked are the ones pointed to by renderer at line 5. These objects are returned from the call to createRenderer() at line 4. Thus, renderer points to the objects created by the allocation sites in all different branches in createRenderer(). According to the points-to information, the target method end() invoked at the virtual call site at line 5 can only be made on an receiver object of type SummaryHTMLRenderer. Thus, we now have an even longer SCline 25 : line 20 → line 11 → line 25. The allocation site at line 3 is the object-sensitive context for the target method createRenderer(), which contains line 20, invoked at line 4. No further extension is possible, since main() has been reached. Now, we have SCline 25 : line 3 → line 20 → line 11 → line 25. If we apply SCDFA to this four-point SCline 25, T (SCline 25) will consist of all the lines except lines 16, 18 and 22. However, including line 3 does not help as it dominates line 20 in GICFG. By removing it, we obtain ESCline 25 : line 20→line 11→line 25 as desired. Applying SCDFA to ESCline 25 yields the same tailored program obtained for the three-point SCline 25. When lengthening SCs, we aim to reduce infeasible paths by exploiting branch correlations. However, with longer SCs, SCDFA will end up using more data-flow facts, as seen in Figure 5, making it less efficient than before. So a precision/scalability tradeoff has to be made. Our key observation is to keep a SC extension point found if it is inside one branch in a multi-way branching statement or a target method invoked at a polymorphic call site (Figure 3), provided that the point is not in a cycle. This way, the other branches (or target methods) are infeasible (with respect to a given SC) and will not show up in the tailored program. Let us return to the program understanding task at hand. From the tailored program T (ESCline 25) obtained for ESCline 25, we can see clearly that the allocation site at line 20 in method createRenderer() is responsible for the rendering-related write at line 25. 4 Formalism We first formalize SCDFA and SCEXT and then prove some properties about Tailor. 4.1 SC-based Data-Flow Analysis We provide a context-insensitive formalization of SCDFA as context sensitivity is achieved on top of this formalization via CFL-reachability, as shown in Figure 6. Essentially, we describe the data-flow equations needed for solving its BU and TD passes in the IFDS framework [38]. The IFDS problem framework is precise and efficient for solving data-flow problems with three properties. First, the set D of data-flow facts is finite. Second, the domain and range of each flow, i.e., transfer function is the power set of D, denoted 2 D, the lattice ordering relation v on 2 D is ⊆ or ⊇, and the meet operator u is ∩ or ∪. Finally, each fow function f must be distributive over 2 D: ∀S1, S2 ∈ 2 D: f(S1 u S2) = f(S1) u f(S2)