Efficient hosted interpreters on the JVM

Savrun-Yeniçeri, Gülfem; Zhang, Wei; Zhang, Huahan; Seckler, Eric; Li, Chen; Brunthaler, Stefan; Larsen, Per; Franz, Michael

doi:10.1145/2532642

Cited by 5 publications

(3 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…The most common is duplicating the dispatch sequence at the end of every handler (referred to in this paper and elsewhere, if somewhat imprecisely, as a threaded interpreter or threaded dispatch), and is used in all the interpreters we tested. Threaded dispatch has even been applied to hosted interpreters on the JVM [57]. For stack machines, stack caching [51] [32] [49] VMs try to keep the top-of-stack cached in a register, reducing loads and stores to the value stack.…”

Section: Optimizing Fixed Format Interpretersmentioning

confidence: 99%

A fast in-place interpreter for WebAssembly

Titzer¹

2022

Preprint

View full text Add to dashboard Cite

WebAssembly (Wasm) is a compact, well-specified bytecode format that offers a portable compilation target with near-native execution speed. The bytecode format was specifically designed to be fast to parse, validate, and compile, positioning itself as a portable alternative to native code. It was pointedly not designed to be interpreted directly. Instead, design considerations at the time focused on competing with native code, utilizing optimizing compilers as the primary execution tier. Yet, in JIT scenarios, compilation time and memory consumption critically impact application startup, leading many Wasm engines to later deploy baseline (single-pass) compilers. Though faster, baseline compilers still take time and waste code space for infrequently executed code. A typical interpreter being infeasible, some engines resort to compiling Wasm not to machine code, but to a more compact, but easy to interpret format. This still takes time and wastes memory. Instead, we introduce in this article a fast in-place interpreter for WebAssembly, where no rewrite and no separate format is necessary. Our evaluation shows that in-place interpretation of Wasm code is space-efficient and fast, achieving performance on-par with interpreting a custom-designed internal format. This fills a hole in the execution tier space for Wasm, allowing for even faster startup and lower memory footprint than previous engine configurations.CCS Concepts: • Software and its engineering → Interpreters.

show abstract

Section: Optimizing Fixed Format Interpretersmentioning

confidence: 99%

A fast in-place interpreter for WebAssembly

Titzer¹

2022

Preprint

View full text Add to dashboard Cite

show abstract

“…The system later partially evaluates these interpreters to generate machine code. Savrun-Yeniceri et al [59] consider forms of threaded code generation to speed up JVM-hosted interpreters, by reducing indirect jumps to improve branch prediction. While these approaches help improve the runtime performance of executing dynamic languages, they still do not influence how such languages are amenable to static analysis.…”

Section: Multilingual Virtual Machinesmentioning

confidence: 99%

A Study of Call Graph Construction for JVM-Hosted Languages

Ali

Lai

Luo

et al. 2021

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

Call graphs have many applications in software engineering, including bug-finding, security analysis, and code navigation in IDEs. However, the construction of call graphs requires significant investment in program analysis infrastructure. An increasing number of programming languages compile to the Java Virtual Machine (JVM), and program analysis frameworks such as WALA and SOOT support a broad range of program analysis algorithms by analyzing JVM bytecode. This approach has been shown to work well when applied to bytecode produced from Java code. In this paper, we show that it also works well for diverse other JVM-hosted languages: dynamically-typed functional Scheme, statically-typed object-oriented Scala, and polymorphic functional OCaml. Effectively, we get call graph construction for these languages for free, using existing analysis infrastructure for Java, with only minor challenges to soundness. This, in turn, suggests that bytecode-based analysis could serve as an implementation vehicle for bug-finding, security analysis, and IDE features for these languages. We present qualitative and quantitative analyses of the soundness and precision of call graphs constructed from JVM bytecodes for these languages, and also for Groovy, Clojure, Python, and Ruby. However, we also show that implementation details matter greatly. In particular, the JVM-hosted implementations of Groovy, Clojure, Python, and Ruby produce very unsound call graphs, due to the pervasive use of reflection, invokedynamic instructions, and run-time code generation. Interestingly, the dynamic translation schemes employed by these languages, which result in unsound static call graphs, tend to be correlated with poor performance at run time.

show abstract

“…Si bien existen alternativas para evaluar el rendimiento de varias plataformas o lenguajes de programación "hasta ahora, ningún conjunto cohesivo de métricas ha cubierto adecuadamente las propiedades que varían sistemáticamente entre las cargas de trabajo de plataformas Java y las que no son Java" [7], sin embargo en [8] se presenta una propuesta de mejora y optimización a algunos problemas identificados con respecto a intérpretes alojados en Máquinas Virtuales Java, la misma que se evalúa con tres intérpretes: Jruby (Ruby), Jython (Python), y Rhino ( Java Script). De manera similar en [9] se caracteriza el comportamiento dinámico de los lenguajes interpretados Clojure, Python y Ruby sobre la Máquina Virtual de Java discutiendo brevemente sus implicaciones.…”

Section: Introductionunclassified