Compiling lazy functional programs for the Java Virtual Machine

Abstract

In this paper, we show how lazy functional programs can be compiled for the Java Virtual Machine using a mapping between a version of the 〈v, G〉-machine and the Java Virtual Machine. This mapping is elegant – the description is entirely straightforward – and efficient – using it, both code size and execution speed are of the same order of magnitude as those obtained with a traditional functional language bytecode interpreter. In future, our work could serve as the basis of an interface between Haskell and Java.

GCspy

“…As it is important that the server experiences no GCspy-imposed performance penalty when the visualiser is not connected, data collection in the HotSpot JVM was done by complete heap sweeps (as described in Section 5.4). The benchmarks used to measure performance were 213 javac from the widely used SPECjvm98 suite [35] and reptile, the kernel of an Escher drawing package translated from Haskell into Java bytecodes [44]. Table 2 gives performance results for several configurations.…”

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

“…Initially being developed with a model of execution that did not rely upon ahead-of-time compilation to machine instructions, its early architecture specifically relied upon an interpretation of its intermediate formats bytecode [7][8][9] with possible just-in-time (JIT) compilation [10]. The robustness of Java, its cross-platform capabilities and security features [11] has seen the Java Virtual Machine (JVM) in its early days be the target for many languages, for example, Ada [12], Eiffel [13], ML [14], Scheme [15], and Haskell [16] as cited in [17][18][19]. 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].…”