Accidental Choices—How JVM Choice and Associated Build Tools Affect Interpreter Performance

Abstract

Considering the large number of optimisation techniques that have been integrated into the design of the Java Virtual Machine (JVM) over the last three decades, the Java interpreter continues to persist as a significant bottleneck in the performance of bytecode execution. This paper examines the relationship between Java Runtime Environment (JRE) performance concerning the interpreted execution of Java bytecode and the effect modern compiler selection and integration within the JRE build toolchain has on that performance. We undertook this evaluation relative to a contemporary benchmark suite of application workloads, the Renaissance Benchmark Suite. Our results show that the choice of GNU GCC compiler version used within the JRE build toolchain statistically significantly affects runtime performance. More importantly, not all OpenJDK releases and JRE JVM interpreters are equal. Our results show that OpenJDK JVM interpreter performance is associated with benchmark workload. In addition, in some cases, rolling back to an earlier OpenJDK version and using a more recent GNU GCC compiler within the build toolchain of the JRE can significantly positively impact JRE performance.

A Simulation Framework for Function as a Service

“…• Function Runtime -The programming language has a big influence on the execution time of the function when thinking about compiled languages like Java compared to interpreted languages like JavaScript [107,141,182,189]. Also different runtime versions for the same programming language may vary in performance [143].…”

Design and Implementation of a Malfunction Detection System for Livestock Ventilation Devices in Smart Poultry Farms

“…The software as shown in Figure 4, composed of the following layers: an execution environment, a malfunction detection engine, an interface, and a user interface. The execution environment layer runs on a Java runtime environment (JRE) and consists of JRE code (that facilitates development in the Java language), the Hadoop platform (for the distributed processing of big data), Spark (for big data processing and real-time data streaming), and HBase (that facilitates non-stop data-saving for massive volumes of distributed data) [19][20][21][22][23][24]. The malfunction detection engine layer is composed of an ontology-based predictor (for deducing malfunctions using the RNN-based prediction model and information collected from smart livestock farms [25]), an RNN-based prediction model (for training and prediction using input data [26]), and a statistical computation module (that detects malfunctions using the basic statistics of the training data and the predicted values provided by each model).…”

“…distributed processing of big data), Spark (for big data processing and real-time data streaming), and HBase (that facilitates non-stop data-saving for massive volumes of distributed data) [19][20][21][22][23][24]. The malfunction detection engine layer is composed of an ontology-based predictor (for deducing malfunctions using the RNN-based prediction model and information collected from smart livestock farms [25]), an RNN-based prediction model (for training and prediction using input data [26]), and a statistical computation module (that detects malfunctions using the basic statistics of the training data and the predicted values provided by each model).…”