A framework for interprocedural optimization in the presence of dynamic class loading

Abstract

Dynamic class loading during program execution in the Java TM Programming Language is an impediment for generating code that is as e cient as code generated using static wholeprogram analysis and optimization. Whole-program analysis and optimization is possible for languages, such a s C + + , that do not allow new classes and/or methods to be loaded during program execution. One solution for performing wholeprogram analysis and avoiding incorrect execution after a new class is loaded is to invalidate and recompile a ected methods. Runtime invalidation and recompilation mechanisms can be expensive in both space and time, and, therefore, generally restrict optimization. To address these drawbacks, we propose a new framework, called the extant analysis framework, f o r i n terprocedural optimization of programs that support dynamic class (or method) loading. Given a set of classes comprising the closed world, w e perform an o ine static analysis which partitions references into two categories: (1) unconditionally extant references which p o i n t only to objects whose runtime type is guaranteed to be in the closed world and (2) conditionally extant references which p o i n t to objects whose runtime type is not guaranteed to be in the closed world. Optimizations solely dependent on the rst category can be statically performed, and are guaranteed to be correct even with any future class/method loading. Optimizations dependent o n the second category are guarded by dynamic tests, called extant safety tests, for correct execution behavior. We describe the properties for extant safety tests, and provide algorithms for their generation and placement.

Application-Only Call Graph Construction

“…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]. Practical programs generally have many library dependencies, and in many cases, the whole program may not even be available for static analysis.…”

Method Inlining, Dynamic Class Loading, and Type Soundness.

“…This design choice simplifies our notation considerably. Note here that Sreedhar, Burke, and Choi [12] showed that in practice there are many inlinings that cannot be invalidated by class loading. Such stable inlinings are called unconditionally-monomorphic call sites.…”

“…For example, the 1 INTRODUCTION preexistence analysis of Detlefs and Agesen [5] determines a set of methods for which on-the-fly changes to the stack will not be needed (recompilation is needed for future method invocations). Additionally, the extant analysis of Sreedhar, Burke, and Choi [12] determines a set of method inlinings which cannot be invalidated by class loading. Still, aggressive inlining and class loading will inevitably require updates of the code memory, the stack memory, or both.…”

“…Previous work has explored inlining for whole programs (see, e.g., [4]) and for programs that use dynamic class loading (see, e.g., [9,3,1,5,12]). That work has devised analysis and transformations for devirtualisation and method inlining, shown the effectiveness of these optimisations, and argued informally for their correctness.…”

Component Composition for Embedded Systems Using Semantic Aspect-Oriented Programming

“…Although the analyses as described reflect this compilation model, it would be straightforward to use extant analysis [184] to apply transformations to only the closed-world portions of a program which used dynamic class loading. The space allocated to the class index could be updated during garbage collection as new classes are discovered.…”