A study of devirtualization techniques for a Java Just-In-Time compiler

Abstract

Many devirtualization techniques have been proposed to reduce the runtime overhead of dynamic method calls for various objectoriented languages, however, most of them are less effective or cannot be applied for Java in a straightforward manner. This is partly because Java is a statically-typed language and thus transforming a dynamic call to a static one does not make a tangible performance gain (owing to the low overhead of accessing the method table) unless it is inlined, and partly because the dynamic class loading feature of Java prohibits the whole program analysis and optimizations from being applied.We propose a new technique called direct devirtualization with the code patching mechanism. For a given dynamic call site, our compiler first determines whether the call can be devirtualized, by analyzing the current class hierarchy. When the call is devirtualizable and the target method is suitably sized, the compiler generates the inlined code of the method, together with the backup code of making the dynamic call. Only the inlined code is actually executed until our assumption about the devirtualization becomes invalidated, at which time the compiler performs code patching to make the backup code executed subsequently. Since the new technique prevents some code motions across the merge point between the inlined code and the backup code, we have furthermore implemented recently-known analysis techniques, such as type analysis and preexistence analysis, which allow the backup code to be completely eliminated. We made various experiments using 16 real programs to understand the effectiveness and characteristics of the devirtualization techniques in our Java Just-InTime (JIT) compiler. In summary, we reduced the number of dynamic calls by ranging from 8.9% to 97.3% (the average of 40.2%), and we improved the execution performance by ranging from -1% to 133% (with the geometric mean of 16%).

Subclass Instantiation Distribution

“…With leaves accounting for 1718 of the 2120 instantiated classes (2120 is the dynamic class count and thus does not match the static count shown in column three of Figure 3), the fol- lowing speculative optimization akin to copy on write may be worthy of investigation [10]. The optimization creates a specialized version of a class that assumes the class is final and injects a check to test if this assumption is ever violated.…”

“…At the one end, dynamic distribution information obtained from a prior execution of a program has several immediate uses. For example, with the aim of increasing performance, heavily used classes could be favored with advantageous memory placement or additional resources, such as registers by the JIT [10]. Alternatively, testers might focus more attention on those classes with a higher frequency in the distribution.…”

Fast and Precise Points-to Analysis

“…Examples are all client applications that require a call graph as input, i.e., most types of inter-procedural program analysis. Other examples of SourceCode clients are: virtual call resolution to avoid dynamic dispatch and facilitate method inlining [9], [15], cast safety analysis to avoid unnecessary run-time type checking [9], [16], metrics-based analyses to compute coupling and cohesion metrics involving members and classes [17], [18], source code browsers that need to resolve various source code references, and software testing where class dependencies determine the test order [19]- [21].…”

Static Analysis Based Application Specific Dispatch Table Compaction

“…It devirtualizes the dynamic dispatch by replacing the polymorphic call either by single static function call or conditional construct coupled with static function call. Kazuaki et al [10] has discussed several techniques regarding devirtualization of dynamic dispatch. Static analysis can be empowered by runtime profile information.…”