Java virtual machine (JVM) has recently evolved into a general-purpose language runtime environment to execute popular programming languages such as JavaScript, Ruby, Python, and Scala. These languages have complex non-Java features, including dynamic typing and first-class function, so additional language runtimes (engines) are provided on top of the JVM to support them with bytecode extensions. Although there are high-performance JVMs with powerful just-in-time (JIT) compilers, running these languages efficiently on the JVM is still a challenge. This article introduces a simple and novel technique for the JVM JIT compiler called exceptionization to improve the performance of JVM-based language runtimes. We observed that the JVM executing some non-Java languages encounters at least 2 times more branch bytecodes than Java, most of which are highly biased to take only one target. Exceptionization treats such a highly biased branch as some implicit exception-throwing instruction. This allows the JVM JIT compiler to prune the infrequent target of the branch from the frequent control flow, thus compiling the frequent control flow more aggressively with better optimization. If a pruned path were taken, then it would run like a Java exception handler, that is, a catch block. We also devised de-exceptionization , a mechanism to cope with the case when a pruned path is executed more often than expected. Since exceptionization is a generic JVM optimization, independent of any specific language runtime, it would be generally applicable to other language runtimes on the JVM. Our experimental result shows that exceptionization accelerates the performance of several non-Java languages. For example, JavaScript-on-JVM runs faster by as much as 60% and by 6% on average, when experimented with the Octane benchmark suite on Oracle’s latest Nashorn JavaScript engine and HotSpot 1.9 JVM. Furthermore, the performance of Ruby-on-JVM shows an improvement by as much as 60% and by 6% on average, while Python-on-JVM improves by as much as 6% and by 2% on average. We found that exceptionization is more effective to apply to the branch bytecode of the language runtime itself than the bytecode corresponding to the application code or the bytecode of the Java class libraries. This implies that the performance benefit of exceptionization comes from better JIT compilation of the language runtime of non-Java languages.

Java supports the monitor construct for language-level synchronization in the context of multi-threading. This paper introduces the lightweight monitor, an efficient user-level monitor implementation. The lightweight monitor is useful for single-threaded Java programs as well as for multi-threaded Java programs with little lock contention. A 32-bit lock is embedded in each object for efficient lock access while other monitor data structures are managed using a hash table. We highly optimized the lock manipulation code, which is translated and inlined by a just-in-time (JIT) compiler. In the most probable cases, only nine SPARC instructions are spent for lock acquisition and five instructions are spent for lock release. Our experimental results indicate that the lightweight monitor is faster than the monitor implementation in the SUN JDK 1.2 RC1 by up to 21 times in the absence of lock contention and by up to seven times in the presence of lock contention. Copyright © 2004 John Wiley & Sons, Ltd.

Abstract Java uses exceptions to provide elegant error handling capabilities during program execution. However, the presence of exception handlers complicates the job of the just‐in‐time (JIT) compiler, while exceptions are rarely used in most programs. This paper describes two techniques for reducing such complications. First, we delay the translation of an exception handler until the exception really occurs. This on‐demand translation of exception handlers allows more optimizations when translating the main flow, without being hindered by constraints caused by the exception flows. Secondly, for those exceptions that are actually thrown during program execution we insert exception‐type check code and a direct branch to the translated exception handlers. This exception handler prediction is motivated by an observation that frequently thrown exceptions are likely to be handled by the same exception handlers, so this will eliminate the exception processing overhead of the Java virtual machine. Our experiments indicate that the code quality of the main flow is no longer affected by the presence of exception handlers. Also, frequently thrown exceptions can be efficiently handled by the exception handler prediction. Copyright © 2004 John Wiley & Sons, Ltd.