Daniel J. Heidinga

Mining Method Handle Graphs for Efficient Dynamic JVM Languages

The Java Virtual Machine (JVM) has been used as an execution platform by many dynamically-typed programming languages such as Ruby, Python, and Groovy. The main challenge to compile such dynamic JVM languages is choosing the most appropriate implementation of a method for various types of an object at runtime. To address this challenge, a new Java bytecode instruction, invokedynamic, has been introduced, allowing users to control the linkage between a call site and a method implementation. With this instruction, a method handle that refers to a method is linked to the call site and then potentially transforms the invocation to a real implementation. As a referenced method of a method handle might in turn refer to other method handles, multiple method handles constitute a Method Handle Graph (MHG). In order to support more efficient dynamic JVM language implementations, we present methods to mine patterns in the method handle graph. We investigate two kinds of method handle patterns: the transformation pattern and the instance pattern. The transformation pattern refers to a composition of multiple method handle transformations, and the instance pattern refers to equivalent method handles in MHGs. Both patterns are mined by the presented suffix tree and equivalency detector, respectively, which are implemented as modules in the Method Handle Mining System (MHMS). Our experiments on the JRuby Micro-Indy benchmark reveal several findings: a) the frequency of different transformation patterns varies significantly, and the JRuby interpreter prefers a small number of transformation patterns, b) a large proportion of method handles, 28.83%, are equivalent, and most of these equivalent method handles can be eliminated to reduce consumed memory, and c) the distribution of equivalent sets for length-two method handle chains is also uneven. For example, only 7% of these sets have more than 30 equivalent method handle chains. We believe these insights are important steps towards further optimizations based on method handle graphs.

Improving the performance of JVM startup using the shared class cache

The Java Virtual Machine (JVM) is responsible for executing all Java programs, so performance improvements in the JVM, especially pertaining to the startup of an application, have wide-ranging impact. This paper presents a solution that reduces the bottleneck by analyzing and optimizing various data structures inside the JVM before a Java application starts executing. The shared class cache, which was added to IBMs J9 VM to share classes and other immutable data across multiple runs of a JVM, is expanded to include additional data. Runtime improvements of between 15% and 20% were achieved in standard benchmark programs.

Fusing method handle graphs for efficient dynamic JVM language implementations

A Method Handle (MH) in JSR 292 (Supporting Dynamically Typed Languages on the JVM) is a typed, directly executable reference to an underlying method, constructor, or field, with optional method type transformations. Multiple connected MHs make up a Method Handle Graph (MHG), which transfers an invocation at a dynamic call site to real method implementations at runtime. Despite benefits that MHGs have for dynamic JVM language implementations, MHGs challenge existing JVM optimization because a) larger MHGs at call sites incur higher graph traversal costs at runtime; and b) JIT expenses, including profiling and compilation of individual MHs, increase along with the number of MHs. This paper proposes dynamic graph fusion to compile an MHG into another equivalent but simpler MHG (e.g., fewer MHs and edges), as well as related optimization opportunities (e.g., selection policy and inline caching). Graph fusion dynamically fuses bytecodes of internal MHs on hot paths, and then substitutes these internal MHs with the instance of the newly generated bytecodes at program runtime. The implementation consists of a template system and GraphJIT. The former emits source bytecodes for individual MHs, while the latter is a JIT compiler that fuses source bytecodes from templates on the bytecode level (i.e., both source code and target code are bytecodes). With the JRuby Micro-Indy benchmark from Computer Language Benchmark Game and JavaScript Octane benchmark on Nashorn, our results show that (a) the technique can reduce execution time of Micro-Indy and Octane benchmarks by 6.28% and 7.73% on average; b) it can speed up a typical MHG’s execution by 31.53% using Ahead-Of-Time (AOT) compilation; and (c) the technique reduces the number of MH JIT compilations by 52.1%.

MHDeS: deduplicating method handle graphs for efficient dynamic JVM language implementations

A method handle (MH) is a reference to an underlying Java method with potential method type transformations. Multiple inter-connected method handles form a method handle graph (MHG). Together with the Java Virtual Machine (JVM) instruction, invokedynamic, the implementation of MHGs is significant to dynamically typed language implementations on the JVM. Addressing the abundance of equivalent MHGs during program runtime, this paper presents an MHG equivalence model and an online Method Handle Deduplication System (MHDeS). The equivalence model determines the equivalence of two MHGs in terms of two kinds of keys, i.e., MH key and MHG key, which uniquely identify the transformation of an MH and an MHG, respectively. MHDeS is an implementation of the equivalence model. Instead of creating equivalent MHGs and then detecting their equivalence, MHDeS employs a light-weight structure, the MHG index key, which wraps constructor parameters of an MH. MHDeS uses a transformation index, fast-path comparison, and filters, to speed up the equivalence detection of an MHG index key. Our experimental results with the Computer Language Benchmark Game (CLBG) JRuby micro-indy show that 1) MHDeS with filtering off can speed up the benchmark by 4.67% and reduces memory usage by 7.19% on average; 2) the deduplication result can be affected by the choice of MH transformations for filtering; 3) MHDeS can have the MH JIT compilation performed earlier; and 4) as much as 32% of MHG index keys are detected as non-unique and eliminated by MHDeS, and the expense for a single detection is trivial.