XX:16 Program Tailoring:Slicing by Sequential Criteria To address RQ3,we perform a stress test on TAILOR by using a large number of randomly generated SCs.TAILOR scales well to relatively large Java programs,suggesting that program tailoring represents an attractive option as a practical tool. Table 1 Program characteristics.For each program,the numbers are produced for both the application and library code,including only reachable classes,methods and statements by SPARK[27. Application Description #Classes #Methods #ByteCodes LOC ANTLR (2.7.2) a recognizer and parser generator 2049 13.751 261.727 90.404 Avrora(1.7.117) an assembly program simulator 3196 17,186 276.340 92.505 Eclipse (4.5) IDE 2517 16.953 305.575 106.640 ApacheTM FOP (0.20.5) a formatting-objects processor 4681 28.105 492.686 171.087 JBoss AS (4.0.2) an application server 4039 25.634 448.163 154.290 PMD(4.0) a source code analyzer 4234 26.623 467.249 161.300 Apache TomcatTM(8.0.24) a Java Servlet container 3920 25.157 432.652 150.074 Our experiments are carried out on an Xeon E5-2650 2GHz machine with 64GB RAM We have selected seven large and diverse real-world Java programs under a large library,JDK 1.6.0 45,described in Table 1.For each program,with its bytecode representation generated by SooT [51],all the statistics are calculated by using Soor's SPARK pointer analysis [27]. 6.1 RQ1:Program Debugging and Understanding WALA 52 includes a traditional slicer [21]and a thin slicer [47(denoted TSLICER),with industry-strength implementations.Traditional slicing does not scale to large object-oriented programs due to the key bottleneck in handling of the heap [47.Thin slicing [47]alleviates the bottleneck by including only producer statements that affect directly the values at a program point.This unsound design can facilitate program debugging and understanding [25,50,59]. By focusing on producer statements,TSLICER is surprisingly effective,by producing often small (or thin)slices quickly.In this study,we show that TAILOR can make TSLICER even more effective,as highlighted in Figure 1,by exploiting the temporal order of statements in SCs to prune away more statements irrelevant to SCs.In addition,TAILOR achieves this improved precision by trimming a program more efficiently than TSLICER does.These results are significant given TSLICER's unsoundness(even for GICFG)and well-tuned implementation in WALA,demonstrating clearly the practical benefits of our SCoriented program tailoring. To ensure a fair comparison between TAILOR (implemented in Soor)and TSLICER (implemented in WALA),we have configured SooT to minimize the differences in the ICFGs constructed for a program in both frameworks.There are four main contributing factors:(1) pointer analysis,(2)reflection analysis,(3)exception handling,and(4)native code handling. Our bottom-line is to make sure that TAILOR is never more precise than TSLICER in dealing with (1)-(4).For(1),we select WALA's VanillaZeroOneCFA option to perform its allocation- site-sensitive pointer analysis,which is more precise than SooT's SPARK pointer analysis, as SPARK merges some java.lang.String allocation sites for improving performance.For (2),we use WALA's no flow to casts option to resolve reflective calls.In SooT,we have taken advantage of SoLAR [29]to perform reflection resolution in the same way.For(3)and (4).WALA and SooT model the same native methods in JDK 1.3 and handle both explicit and implicit exceptions with some differences.However,these differences do not affect the precision achievements obtained,validated by having inspected all results manually. Both TAILOR and TSLICER trim a program based on the writer/OutputStream-related SCs deduced from the results reported by a state-of-the-art typestate analysis tool,CLARA [9]. TSLICER is run context-sensitively by using the last point in each SC as its slicing criterionXX:16 Program Tailoring: Slicing by Sequential Criteria To address RQ3, we perform a stress test on Tailor by using a large number of randomly generated SCs. Tailor scales well to relatively large Java programs, suggesting that program tailoring represents an attractive option as a practical tool. Table 1 Program characteristics. For each program, the numbers are produced for both the application and library code, including only reachable classes, methods and statements by Spark [27]. Application Description #Classes #Methods #ByteCodes LOC ANTLR (2.7.2) a recognizer and parser generator 2049 13,751 261,727 90,404 Avrora (1.7.117) an assembly program simulator 3196 17,186 276,340 92,505 Eclipse (4.5) IDE 2517 16,953 305,575 106,640 Apache™ FOP (0.20.5) a formatting-objects processor 4681 28,105 492,686 171,087 JBoss AS (4.0.2) an application server 4039 25,634 448,163 154,290 PMD (4.0) a source code analyzer 4234 26,623 467,249 161,300 Apache Tomcat™ (8.0.24) a Java Servlet container 3920 25,157 432,652 150,074 Our experiments are carried out on an Xeon E5-2650 2GHz machine with 64GB RAM. We have selected seven large and diverse real-world Java programs under a large library, JDK 1.6.0_45, described in Table 1. For each program, with its bytecode representation generated by Soot [51], all the statistics are calculated by using Soot’s Spark pointer analysis [27]. 6.1 RQ1: Program Debugging and Understanding Wala [52] includes a traditional slicer [21] and a thin slicer [47] (denoted TSlicer), with industry-strength implementations. Traditional slicing does not scale to large object-oriented programs due to the key bottleneck in handling of the heap [47]. Thin slicing [47] alleviates the bottleneck by including only producer statements that affect directly the values at a program point. This unsound design can facilitate program debugging and understanding [25, 50, 59]. By focusing on producer statements, TSlicer is surprisingly effective, by producing often small (or thin) slices quickly. In this study, we show that Tailor can make TSlicer even more effective, as highlighted in Figure 1, by exploiting the temporal order of statements in SCs to prune away more statements irrelevant to SCs. In addition, Tailor achieves this improved precision by trimming a program more efficiently than TSlicer does. These results are significant given TSlicer’s unsoundness (even for GICFG) and well-tuned implementation in Wala, demonstrating clearly the practical benefits of our SC-oriented program tailoring. To ensure a fair comparison between Tailor (implemented in Soot) and TSlicer (implemented in Wala), we have configured Soot to minimize the differences in the ICFGs constructed for a program in both frameworks. There are four main contributing factors: (1) pointer analysis, (2) reflection analysis, (3) exception handling, and (4) native code handling. Our bottom-line is to make sure that Tailor is never more precise than TSlicer in dealing with (1) – (4). For (1), we select Wala’s VanillaZeroOneCFA option to perform its allocation￾site-sensitive pointer analysis, which is more precise than Soot’s Spark pointer analysis, as Spark merges some java.lang.String allocation sites for improving performance. For (2), we use Wala’s no_flow_to_casts option to resolve reflective calls. In Soot, we have taken advantage of Solar [29] to perform reflection resolution in the same way. For (3) and (4), Wala and Soot model the same native methods in JDK 1.3 and handle both explicit and implicit exceptions with some differences. However, these differences do not affect the precision achievements obtained, validated by having inspected all results manually. Both Tailor and TSlicer trim a program based on the writer/OutputStream-related SCs deduced from the results reported by a state-of-the-art typestate analysis tool, Clara [9]. TSlicer is run context-sensitively by using the last point in each SC as its slicing criterion