Run Java with Java

·1 hr 2 min·5 clips

Christian Wimmer explains his bachelor thesis project: a Java bytecode interpreter written entirely in Java.

Host Adam Bien welcomes back guest Christian Wimmer to continue their technical deep dive, picking up from a previous discussion on Truffle. Christian begins by recounting his bachelor thesis, which explored the feasibility of writing a Java bytecode interpreter in Java itself, comparing its performance to HotSpot's C++ interpreter. The episode outlines the three iterations of the Espresso project: the initial bytecode interpreter proof-of-concept, a second version that hacked ASTs into class files for Truffle, and the current production version that properly interprets bytecode. A significant portion of the conversation focuses on Just-In-Time (JIT) compilation mechanics within the Java Virtual Machine. Christian explains the process of hot spot detection, compilation, and the crucial role of deoptimization—where optimized code jumps back to the interpreter when runtime assumptions (guards) fail. He contrasts this with external invalidation, used for assumptions like new class loading. The discussion expands to the broader GraalVM ecosystem. They cover Native Image and its closed-world assumption, which allows ahead-of-time compilation and aggressive dead code elimination. Christian mentions profile-guided optimization as a way for Native Image to approach HotSpot's performance. The topic of security and sandboxing emerges, highlighting how GraalVM's control over the entire stack enables robust isolation, contrasting with the deprecated Java Security Manager. A compelling use case is presented: using GraalVM's sandbox to safely execute untrusted, AI-generated Java code. Tooling and future directions are briefly touched upon, with a promise to cover debugging frameworks in a subsequent episode. The conversation concludes with technical details on the T-regex engine, which compiles regular expressions to optimized machine code, and the ongoing development of a DSL for generating efficient bytecode interpreters.

As heard by us

Espresso follows Java-in-Java interpretation toward build-time specialization, while reusing Hotspot instead of rebuilding it.

Christian's return gives the episode a practical tour through Espresso, with the core choice made clear early: write a Java bytecode interpreter in Java and reuse Hotspot rather than rebuild the runtime from scratch.

Read the full review in PlayNext →

Why you'd press play

You want the JVM plumbing behind Espresso, without the usual museum dust.

Read the full recommendation in PlayNext →

Listen to the show on

Apple Podcasts Spotify

Play clips from this episode More from airhacks.fm podcast with adam bien