JIT and AOT in the JVM
summary
Compares JIT, AOT and caching approaches on the JVM with concrete numbers and tools: OpenJ9’s dynamic AOT and shared class cache reuse JIT-generated code to cut startup and ramp costs while hitting within 5–10% of peak JIT performance; pure AOT often reaches only ~50–90% of JIT without profile feedback and needs curated profiles. Describes a remote JIT server prototype that moves compile spikes off clients, stabilizes memory in containers, and (after optimization) halves client CPU overhead versus naive remote calls, with AWS and Docker experiments reported.
AI-written summary · about
chapters (15)
- 0:00Intro
- 2:06Native compilers in today's Java ecosystem
- 4:32Life of a running Java application
- 8:291. Speculate on class hierarchy
- 10:202. JIT uses profile data collected as program runs
- 12:39But JIT performance advantage isn't free
- 17:41BUT there are a few big BUTS
- 22:01Class loader objects can invalidate the inlining...
- 23:20Contrived example?
- 24:50Some AOT Fallacies
- 29:08Profile Directed Feedback (PDF) may help
- 34:23Two implementations
- 36:19Open9 Shared Classes Cache
- 47:53Strengths and Weaknesses
- 52:41Wrapping up
related talks
38mAOT or JIT: Faster Startup or Faster Code?
50mAOT or JIT: Faster Startup or Faster Code?
24mJITServer: Disaggregated Caching JIT Compiler for the JVM in the Cloud
01h 11mAOT Caching - Netflix' Practice vs OpenJDK's Theory
56mBaselining AArch64 Java AOT Performance
38mThe Next Frontier in Open Source Java Compilers: Just-In-Time Compilation as a Service
29mThe Next Frontier in Open Source Java Compilers: Just-in-Time Compilation as a Service
06mSimple Tweaks to Get the Most Out of your JVM