Optimizing Java Bytecode Using the Soot Framework: Is It Feasible?

Vallée-Rai, Raja; Gagnon, Étienne; Hendren, Laurie; Lam, Patrick; Pominville, Patrice; Sundaresan, Vijay

doi:10.1007/3-540-46423-9_2

Cited by 246 publications

(214 citation statements)

References 9 publications

Supporting

Mentioning

199

Contrasting

Order By: Relevance

“…The key reason is dynamic dispatch: the target of a call depends on the runtime type of the receiver of the call. Because the receiver could have been created anywhere in the program, a sound algorithm must either analyze the whole program [1,6,17,21,34], or make very conservative assumptions about the receiver type (e.g., Class Hierarchy Analysis [9]). Additionally, due to the large sizes of common libraries, whole-program analysis of even trivial programs is expensive [7,27,28].…”

Section: Introductionmentioning

confidence: 99%

“…1 Construction of partial call graphs is an often-requested feature in static analysis frameworks for Java. On the mailing list of the Soot framework [34], which analyzes the whole program to construct a call graph, dozens of users have requested partial call graph construction [4]. One popular approach for generating partial call graphs, used for example in the Wala framework [17], is to define an analysis scope of the classes to be analyzed.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Application-Only Call Graph Construction

Ali

Lhoták

2012

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. Since call graphs are an essential starting point for all interprocedural analyses, many tools and frameworks have been developed to generate the call graph of a given program. The majority of these tools focus on generating the call graph of the whole program (i.e., both the application and the libraries that the application depends on). A popular compromise to the excessive cost of building a call graph for the whole program is to ignore all the effects of the library code and any calls the library makes back into the application. This results in potential unsoundness in the generated call graph and therefore in any analysis that uses it. In this paper, we present Cgc, a tool that generates a sound call graph for the application part of a program without analyzing the code of the library.

show abstract

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Application-Only Call Graph Construction

Ali

Lhoták

2012

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…We implemented the analysis on the Soot analysis framework [8] and evaluated it on the 19 Java programs shown in Table 1. All experiments were conducted on a quadcore machine with an Intel Xeon X3363 2.83GHZ processor, running Linux 2.6.18.…”

Section: Discussionmentioning

confidence: 99%

“…soot-c. soot-c is a part of the Soot analysis framework [8] benchmarked in the Ashes benchmarks [11]. One top data structure reported by our analysis is rooted at a StmtValueBoxPair object created in a loop (in a constructor of jimple.SimpleLocalUse) that builds def-use relationships as follows:…”

Section: Case Studiesmentioning

confidence: 99%

Static Detection of Loop-Invariant Data Structures

Yan

Rountev

2012

ECOOP 2012 – Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. As a culture, object-orientation encourages programmers to create objects, both short-and long-lived, without concern for cost. Excessive object creation and initialization can cause severe runtime bloat, which degrades significantly application performance and scalability. A frequently-occurring coding pattern that may lead to large volumes of (temporary) objects is the creation of objects that, while allocated per loop iteration, contain values independent of specific iterations. Finding these objects and moving them out of loops requires sophisticated interprocedural analysis, a task that is difficult for traditional dataflow analyses such as loop-invariant code motion to accomplish.Our work targets data structures that are loop-invariant, and presents a static type and effect system to detect loop-invariant data structures. For each loop, our analysis inspects each logical data structure in order to find those that have disjoint instances per loop iteration and contain loop-invariant data. Instead of automatically hoisting them to improve performance (which is over-conservative), we report hoistability measurements for each disjoint loop data structure detected by our analysis. Eventually these data structures are ranked based on these measurements and are presented to the user to help manual tuning. We have performed a variety of studies on a set of 19 moderate/large-sized Java benchmarks. With the help of hoistability measurements, we found optimization opportunities in most of the programs that we inspected and achieved significant performance improvements in some of them (e.g., 82.1% running time reduction).

show abstract

“…We have implemented a simple prototype of the OSP algorithm in Java for Java programs, using the Soot [17] framework for program instrumentation. The architecture of the implementation is described in Figure 2.…”

Section: Prototype Implementationmentioning

confidence: 99%

Online Subpath Profiling

Oren

Matias

Sagiv

2002

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. We present an efficient online subpath profiling algorithm, OSP, that reports hot subpaths executed by a program in a given run. The hot subpaths can start at arbitrary basic block boundaries, and their identification is important for code optimization; e.g., to locate program traces in which optimizations could be most fruitful, and to help programmers in identifying performance bottlenecks. The OSP algorithm is online in the sense that it reports at any point during execution the hot subpaths as observed so far. It has very low memory and runtime overheads, and exhibits high accuracy in reports for benchmarks such as JLex and FFT. These features make the OSP algorithm potentially attractive for use in just-in-time (JIT) optimizing compilers, in which profiling performance is crucial and it is useful to locate hot subpaths as early as possible. The OSP algorithm is based on an adaptive sampling technique that makes effective utilization of memory with small overhead. Both memory and runtime overheads can be controlled, and the OSP algorithm can therefore be used for arbitrarily large applications, realizing a tradeoff between report accuracy and performance. We have implemented a Java prototype of the OSP algorithm for Java programs. The implementation was tested on programs from the Java Grande benchmark suite and exhibited a low average runtime overhead.

show abstract

Optimizing Java Bytecode Using the Soot Framework: Is It Feasible?

Cited by 246 publications

References 9 publications

Application-Only Call Graph Construction

Application-Only Call Graph Construction

Static Detection of Loop-Invariant Data Structures

Online Subpath Profiling

Contact Info

Product

Resources

About