General purpose CPUs used in high performance computing (HPC) support a vector instruction set and an out-of-order engine dedicated to increase the instruction level parallelism. Hence, related optimizations are currently critical to improve the performance of applications requiring numerical computation. Moreover, the use of a Java run-time environment such as the HotSpot Java Virtual Machine (JVM) in high performance computing is a promising alternative. It benefits from its programming flexibility, productivity and the performance is ensured by the Just-In-Time (JIT) compiler. Though, the JIT compiler suffers from two main drawbacks. First, the JIT is a black box for developers. We have no control over the generated code nor any feedback from its optimization phases like vectorization. Secondly, the time constraint narrows down the degree of optimization compared to static compilers like GCC or LLVM. So, it is compelling to use statically compiled code since it benefits from additional optimization reducing performance bottlenecks. Java enables to call native code from dynamic libraries through the Java Native Interface (JNI). Nevertheless , JNI methods are not inlined and require an additional cost to be invoked compared to Java ones. Therefore, to benefit from better static optimization, this call overhead must be leveraged by the amount of computation performed at each JNI invocation. In this paper we tackle this problem and we propose to do this analysis for a set of micro-kernels. Our goal is to select the most efficient implementation considering the amount of computation defined by the calling context. We also investigate the impact on performance of several different optimization schemes which are vector-ization, out-of-order optimization, data alignment, method inlining and the use of native memory for JNI methods.
There is so far no performance comparison between pure Java and JNI that takes into account both the overhead of JNI calls and potential deeper optimization provided by the static compilation. presented a split auto-vectorization framework @cite_0 combining dynamic compilation with an off-line compilation stage aiming at being competitive with static compilation while conserving application portability. @cite_10 designed an API called jSIMD that uses JNI as a bridge to map Java code to SIMD instructions using vectorized data of various types. Regarding JNI performance issues, implemented the Graal Native Function Interface (GNFI) for the Graal Virtual Machine @cite_8 as an alternative to JNI. GNFI aims to mitigate all the disadvantages met using JNI both concerning programming flexibility than performance. @cite_2 proposed an approach for the IBM TR JIT compiler to widen the compilation span by inlining native code. Finally, Kurzinyec and Sunderam @cite_11 studied the performance of different JNI implementations for several different JVM.
@cite_8 @cite_0 @cite_2 @cite_10 @cite_11
2088840230 2116129553 2135740686 2122254232
Just-in-time (JIT) compilation of running programs provides more optimization opportunities than offline compilation. Modern JIT compilers, such as those in virtual machines like Oracle's HotSpot for Java or Google's V8 for JavaScript, rely on dynamic profiling as their key mechanism to guide optimizations. While these JIT compilers offer good average performance, their behavior is a black box and the achieved performance is highly unpredictable. In this paper, we propose to turn JIT compilation into a precision tool by adding two essential and generic metaprogramming facilities: First, allow programs to invoke JIT compilation explicitly. This enables controlled specialization of arbitrary code at run-time, in the style of partial evaluation. It also enables the JIT compiler to report warnings and errors to the program when it is unable to compile a code path in the demanded way. Second, allow the JIT compiler to call back into the program to perform compile-time computation. This lets the program itself define the translation strategy for certain constructs on the fly and gives rise to a powerful JIT macro facility that enables "smart" libraries to supply domain-specific compiler optimizations or safety checks. We present Lancet, a JIT compiler framework for Java bytecode that enables such a tight, two-way integration with the running program. Lancet itself was derived from a high-level Java bytecode interpreter: staging the interpreter using LMS (Lightweight Modular Staging) produced a simple bytecode compiler. Adding abstract interpretation turned the simple compiler into an optimizing compiler. This fact provides compelling evidence for the scalability of the staged-interpreter approach to compiler construction. In the case of Lancet, JIT macros also provide a natural interface to existing LMS-based toolchains such as the Delite parallelism and DSL framework, which can now serve as accelerator macros for arbitrary JVM bytecode. We introduce a strategy for inlining native functions into Java™ applications using a JIT compiler. We perform further optimizations to transform inlined callbacks into semantically equivalent lightweight operations. We show that this strategy can substantially reduce the overhead of performing JNI calls, while preserving the key safety and portability properties of the JNI. Our work leverages the ability to store statically-generated IL alongside native binaries, to facilitate native inlining at Java callsites at JIT compilation time. Preliminary results with our prototype implementation show speedups of up to 93X when inlining and callback transformation are combined. While the concept of online profile directed dynamic optimizations using hardware performance monitoring unit (PMU) data is not new, it has seen fairly limited or no use in commercial JVMs. The main reason behind this fact is the set of significant challenges involved in (1) obtaining low overhead and usable profiling support from the underlying platform (2) the complexity of filtering, interpreting and using precise PMU events online in a JVM environment (3) demonstrating the total runtime benefit of PMU data based optimizations above and beyond regular online profile based optimizations. In this paper we address all three challenges by presenting a practical framework for PMU data collection and use within a high performance product JVM on a highly scalable server platform. Our experiments with JavaTM workloads using the SunTM HotspotTM JDK 1.6 JVM on the Intel ® Itanium ® platform indicate that the hardware data collection overhead (less than 0.5 ) is not as significant as the challenge of extracting the precise information for optimization purposes. We demonstrate the feasibility of mapping the instruction IP address based hardware event information to the runtime components as well as the JIT server compiler internal data structures for use in optimizations within a dynamic environment. We also evaluated the additional performance potential of optimizations such as object co-location during garbage collection and global instruction scheduling in the JIT compiler with the use of PMU generated load latency information. Experimental results show performance improvements of up to 14 with an average of 2.2 across select Java server benchmarks such as SPECjbb2005[16], SPECjvm2008[17] and Dacapo[18]. These benefits were observed over and above those provided by profile guided server JVM optimizations in the absence of hardware PMU data. With traditional testing, the test case has no control over non-deterministic scheduling decisions, and thus errors dependent on scheduling are only found by pure chance. Java Path Finder (JPF) is a specialized Java virtual machine that can systematically explore execution paths for all possible schedulings, and thus catch these errors. Unfortunately, execution-based model checkers, including JPF, cannot be easily adapted to support real-time programs. We propose a scheduling algorithm for JPF which allows testing of Safety Critical Java (SCJ) applications with periodic event handlers at SCJ levels 0 and 1 (without aperiodic event handlers). The algorithm requires that deadlines are not missed and that there is an execution time model that can give best- and worst-case execution time estimates for a given program path and specific program inputs. Our implementation, named RSJ, allows to search for scheduling dependent memory access errors, certain invalid argument errors, priority ceiling emulation protocol violations, and failed assertions in application code in SCJ programs for levels 0 and 1. It uses the execution time model of the Java Optimized Processor (JOP). We test our tool with Collision Detector and PapaBench application benchmarks. We provide an SCJ version of the C PapaBench benchmark, which implements an autopilot that has flown real UAVs.