Language-Agnostic Optimization and Parallelization for Interpreted Languages

Strout, Michelle Mills; Debray, Saumya; Isaacs, Katherine E.; Kreaseck, Barbara; Cárdenas-Rodríguez, Julio; Hurwitz, Bonnie; Volk, Kathryn; Badger, Sam; Bartels, Jesse; Bertolacci, Ian J.; Devkota, Sabin; Encinas, Anthony; Gaska, Benjamin; Neth, Brandon; Sackos, Theo; Stephens, John Lloyd; Willer, Sarah; Yadegari, Babak

doi:10.1007/978-3-030-35225-7_4

Cited by 1 publication

(1 citation statement)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Nonetheless, performance analysis of early releases of the language was characterised as providing poor performance relative to traditional compiled languages [7,9], with early comparisons of execution time performance of Java code showing significant underperformance relative to C or C++ code [7,[20][21][22][23]. The Java interpreter was especially slow [8,24] in contrast to code compiled to native code [25][26][27], or even Java JIT-compiled code [27], performance challenges that persist with contemporary language interpreters [28][29][30].…”

Section: Introductionmentioning

confidence: 99%

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

2022

View full text Add to dashboard Cite

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.

show abstract