Java Virtual Machine Implementation Research Articles

Constructing exception handling chains for testing Java virtual machine implementations

AbstractThe Java virtual machine (JVM) is the cornerstone of the Java platforms. A JVM's exception handling implementation interrupts, when the objective application encounters an exception (or an error), the normal execution of the application and performs specific handling tasks. However, little research has been done in systematically validating JVMs' exception handling implementations—test programs or even applications need to be carefully designed for throwing/catching exceptions at runtime; a JVM's exception handling implementation is also complicated, making it challenging to design tests for testing all of its functionalities. Inspired by the recent success of fuzz testing of compilers and JVM implementations, we introduce EHCBuilder, the first technique for fuzzing JVMs' exception handling implementations. The key idea is to construct exception handling chains, each of which abstracts a program's execution into a sequence of exception throwings, catchings, and/or handlings. A classfile seed can then be mutated into test programs with diverse exception handling chains, enabling (1) exceptions to be continuously thrown and caught at runtime, and (2) JVMs' exception handling implementations to be much more thoroughly tested. We have implemented EHCBuilder and evaluated EHCBuilder on popular JVM implementations including OpenJDK's HotSpot, Eclipse's OpenJ9, Azul's Zulu, and Oracle's GraalVM. Our results show that EHCBuilder can generate programs with very intricate exception handling chains and reveal differences among JVMs' exception handling implementations: Up to thousands of lines of source code in HotSpot's exception handling implementation are covered more than the original benchmarks; during 39 K iterations, EHCBuilder generates exception handling chains of different lengths, revealing 258 runtime differences. We classify the differences into four categories, and reveal a fast throw issue confirmed by HotSpot developers and another initCause issue confirmed by the OpenJ9 community.

Coverage-directed differential testing of JVM implementations

Java virtual machine (JVM) is a core technology, whose reliability is critical. Testing JVM implementations requires painstaking effort in designing test classfiles (*.class) along with their test oracles. An alternative is to employ binary fuzzing to differentially test JVMs by blindly mutating seeding classfiles and then executing the resulting mutants on different JVM binaries for revealing inconsistent behaviors. However, this blind approach is not cost effective in practice because most of the mutants are invalid and redundant. This paper tackles this challenge by introducing classfuzz, a coverage-directed fuzzing approach that focuses on representative classfiles for differential testing of JVMs’ startup processes. Our core insight is to (1) mutate seeding classfiles using a set of predefined mutation operators (mutators) and employ Markov Chain Monte Carlo (MCMC) sampling to guide mutator selection, and (2) execute the mutants on a reference JVM implementation and use coverage uniqueness as a discipline for accepting representative ones. The accepted classfiles are used as inputs to differentially test different JVM implementations and find defects. We have implemented classfuzz and conducted an extensive evaluation of it against existing fuzz testing algorithms. Our evaluation results show that classfuzz can enhance the ratio of discrepancy-triggering classfiles from 1.7% to 11.9%. We have also reported 62 JVM discrepancies, along with the test classfiles, to JVM developers. Many of our reported issues have already been confirmed as JVM defects, and some even match recent clarifications and changes to the Java SE 8 edition of the JVM specification.

JDMM

As the number of cores continuously grows, processor designers are considering non coherent memories as more scalable and energy efficient alternatives to the current coherent ones. The Java Memory Model (JMM) requires that all cores can access the Java heap. It guarantees sequential consistency for data-race-free programs and no out-of-thin-air values for non data-race-free programs. To implement the Java Memory Model over non-cache-coherent and distributed architectures Java Virtual Machines (JVMs) are most likely to employ software caching. In this work, i) we provide a formalization of the Java Memory Model for non-cache-coherent and distributed memory architectures, ii) prove the adherence of our model with the Java Memory Model and iii) evaluate, regarding its compliance to the Java Memory Model, a state-of-the-art Java Virtual Machine implementation on a non-cache-coherent architecture.

Maxine

A highly productive platform accelerates the production of research results. The design of a Virtual Machine (VM) written in the Java™ programming language can be simplified through exploitation of interfaces, type and memory safety, automated memory management (garbage collection), exception handling, and reflection. Moreover, modern Java IDEs offer time-saving features such as refactoring, auto-completion, and code navigation. Finally, Java annotations enable compiler extensions for low-level “systems programming” while retaining IDE compatibility. These techniques collectively make complex system software more “approachable” than has been typical in the past. The Maxine VM, a metacircular Java VM implementation, has aggressively used these features since its inception. A co-designed companion tool, the Maxine Inspector, offers integrated debugging and visualization of all aspects of the VM's runtime state. The Inspector's implementation exploits advanced Java language features, embodies intimate knowledge of the VM's design, and even reuses a significant amount of VM code directly. These characteristics make Maxine a highly approachable VM research platform and a productive basis for research and teaching.

Java heap protection for debugging native methods

Java virtual machine (JVM) crashes are often due to an invalid memory reference to the JVM heap. Before the bug that caused the invalid reference can be fixed, its location must be identified. It can be in either the JVM implementation or the native library written in C invoked from Java applications. To help system engineers identify the location, we implemented a feature using page protection that prevents threads executing native methods from referring to the JVM heap. This feature protects the JVM heap during native method execution; if the heap is referred to invalidly, it interrupts the execution by generating a page-fault exception. It then reports the location where the exception was generated. The runtime overhead for using this feature depends on the frequency of native method calls because the protection is switched on each time a native method is called. We evaluated the runtime overhead by running the SPECjvm98, SPECjbb2000, VolanoMark, and JFCMark benchmark suites on a PC with two Intel Xeon ® 1.6 GHz processors. The performance loss was less than 2% for the benchmark items that do not call native methods so frequently (∼10 4 times per second) and 5%–20% for the benchmark items that do (10 4–10 5 times per second). The worst performance loss was 54%, which was recorded for a benchmark item that calls native methods 2.0×10 6 times per second.

A Platform-Independent Distributed Runtime for Standard Multithreaded Java

JavaSplit is a portable runtime environment for distributed execution of standard multithreaded Java programs. It gains augmented computational power and increased memory capacity by distributing the threads and objects of an application among the available machines. Unlike previous works, which either forfeit Java portability by using a nonstandard Java Virtual Machine (JVM) or compromise transparency by requiring user intervention in making the application suitable for distributed execution, JavaSplit automatically executes standard multithreaded Java on any heterogenous collection of Java-enabled machines. Each machine carries out its part of the computation using nothing but its local standard (unmodified) JVM. Neither the programmer nor the person submitting the program for execution needs to be aware of JavaSplit or its distributed nature. We evaluate the efficiency of JavaSplit on several combinations of operating systems, JVM implementations, and communication hardware.

Java runtime systems: characterization and architectural implications

The Java Virtual Machine (JVM) is the cornerstone of Java technology and its efficiency in executing the portable Java bytecodes is crucial for the success of this technology. Interpretation, Just-in-Time (JIT) compilation, and hardware realization are well-known solutions for a JVM and previous research has proposed optimizations for each of these techniques. However, each technique has its pros and cons and may not be uniformly attractive for all hardware platforms. Instead, an understanding of the architectural implications of JVM implementations with real applications can be crucial to the development of enabling technologies for efficient Java runtime system development on a wide range of platforms. Toward this goal, this paper examines architectural issues from both the hardware and JVM implementation perspectives. The paper starts by identifying the important execution characteristics of Java applications from a bytecode perspective. It then explores the potential of a smart JIT compiler strategy that can dynamically interpret or compile based on associated costs and investigates the CPU and cache architectural support that would benefit JVM implementations. We also study the available parallelism during the different execution modes using applications from the SPECjvm98 benchmarks. At the bytecode level, it is observed that less than 5 out of the 256 bytecodes constitute 90 percent of the dynamic bytecode stream. Method sizes fall into a trinodal distribution with peak of 1, 9, and 26 bytecodes across all benchmarks. The architectural issues explored in this study show that, when Java applications are executed with a JIT compiler, selective translation using good heuristics can improve performance, but the saving is only 10-15 percent at best. The instruction and data cache performance of Java applications are seen to be better than that of C/C/sub +/+ applications except in the case of data cache performance in the JIT mode. Write misses resulting from installation of JIT compiler output dominate the misses and deteriorate the data cache performance in JIT mode. A study on the available parallelism shows that Java programs executed using JIT compilers have parallelism comparable to C/C++ programs for small window sizes, but falls behind when the window size is increased. Java programs executed using the interpreter have very little parallelism due to the stack nature of the SVM instruction set, which is dominant in the interpreted execution mode. In addition, this work gives revealing insights and architectural proposals for designing an efficient Java runtime system.

Supporting object accesses in a Java processor

Due to Java's object-based nature and support for garbage collection, efficient object manipulation and relocation are critical to the execution speed of Java code. Java Virtual Machine implementations that utilise handle representation such as Sun's Java Development Kit 1.1 enable efficient object relocation at the cost of an additional indirection for each object access. The direct address object representations such as those used in CACAO and NET compiler eliminate the indirection overhead, but update during object relocation is complex. A virtual address object cache that reduces the indirection overhead while maintaining the efficiency of object relocation is proposed. The objects in the virtual address cache are addressed directly using the object reference and field offset pair. This eliminates the indirection overhead and off-set addition overhead associated with the handle representation model. A hardware object table that maintains the handles is used to obtain the actual object location on a virtual address cache miss. The performance of the virtual address cache is analysed using various Java programs, and is found to reduce 1.5 cycles per object access on an average as compared to the handle representation model for the various benchmarks studied.

The evolution of a high-performing Java virtual machine

Early JavaTM virtual machines (Jvms) possessed several significant performance bottlenecks that inhibited the speed of Java workloads. This paper presents the methodology that was used by IBM to identify and eliminate these bottlenecks for improving the performance of Java applications running on several operating system platforms. In addition, several of the key performance problems that were common to all early Java virtual machine implementations and how they were solved for IBM enhanced Jvms are described in detail. The issues discussed in this paper are focused on problems found in core Jvm components, such as object synchronization, object allocation, heap management, text rendering, run-time resolution, and Java class library methods. The results obtained from applying the described methodology and eliminating the identified performance bottlenecks increased the performance of IBM Java virtual machines by as much as four times on some workloads. The technology discussed in this paper is applicable to other Jvm implementations.