Tracing vs. partial evaluation: comparing meta-compilation approaches for self-optimizing interpreters

Abstract

Tracing and partial evaluation have been proposed as metacompilation techniques for interpreters to make just-in-time compilation language-independent. They promise that programs executing on simple interpreters can reach performance of the same order of magnitude as if they would be executed on state-of-the-art virtual machines with highly optimizing just-in-time compilers built for a specific language. Tracing and partial evaluation approach this metacompilation from two ends of a spectrum, resulting in different sets of tradeoffs.This study investigates both approaches in the context of self-optimizing interpreters, a technique for building fast abstract-syntax-tree interpreters. Based on RPython for tracing and Truffle for partial evaluation, we assess the two approaches by comparing the impact of various optimizations on the performance of an interpreter for SOM, an objectoriented dynamically-typed language. The goal is to determine whether either approach yields clear performance or engineering benefits. We find that tracing and partial evaluation both reach roughly the same level of performance. SOM based on meta-tracing is on average 3x slower than Java, while SOM based on partial evaluation is on average 2.3x slower than Java. With respect to the engineering, tracing has however significant benefits, because it requires language implementers to apply fewer optimizations to reach the same level of performance.

Amalgamating different JIT compilations in a meta-tracing JIT compiler framework

“…Second, a compilation unit has the complete control flow of a target method. Therefore, methodbased compilation can be applied not only for various types of programs and also for programs that are not suitable for trace-based compilation [23,24]. However, when a method-based compiler compiles a method with many biased branches, the compiled code includes colds spots of the method.…”

“…One significant advantage of a meta-tracing JIT compilation strategy depicted by RPython is that it is more comfortable to write interpreters in comparison to the abstractsyntax-tree (AST) rewriting specialization in Truffle. In [24], Marr and Ducasse stated that a significant difference between RPython and Truffle is the number of optimizations a language implementer needs to apply in order to reach the same level of performance. In their experiments, SOM [19] built with RPython achieves excellent performance without adding many optimizations.…”

“…By adding some optimizations, SOM with Truffle reaches the same level as that of SOM with RPython. According to the result, they concluded that the meta-tracing strategy has significant benefits from an engineering perspective [24].…”

STRAF: A Scala Framework for Experiments in Trace-Based JIT Compilation

“…Similarly to straf, RPython thus enables language implementers to provide a regular interpreter, annotated with certain hints to guide tracing and optimization, to benefit from the advantages of trace-based compilation without having to construct a dedicated JIT compiler for the language. RPython greatly reduces the engineering effort required by language implementers and is also successful in lifting the performance of the meta-traced interpreter to the same order of magnitude than a dedicated JIT compiler [9]. However, the complexity of RPython and its focus on performance makes it less suited for experimenting with novel trace recording or trace optimization strategies.…”

Staged abstract interpreters: fast and modular whole-program analysis via meta-programming

“…Moreover, a procedure that can specialize an interpreter to any input program is equivalent to a compiler. In recent years, the idea of Futamura projections has attracted more attention, and has been successfully applied to many real-world scenarios, such as building JIT compilers for dynamic languages [Bolz et al 2009;Marr and Ducasse 2015] and building query compilers for databases . The question here is can we apply Futamura projections to an abstract interpreter and obtain a compiler for abstract interpretation?…”