Fast and Compact: Reducing Size of AOT-Compiled Java Code Without Sacrificing Performance
summary
GraalVM Native Image executables shrink by storing rarely used methods as bytecode and running them with a lightweight interpreter, then simulating a JIT for interpreted methods that become hot; this reduces DaCapo binary sizes up to 36.9% while keeping peak performance, with only about 5% of interpreted methods needing recompilation to recover speed. The interpreter and JIT simulation add a roughly 14 MB interpreter/JIT overhead, so applications must save ~15% of machine code before the approach pays off.
AI-written summary · about
chapters (17)
- 0:00AOT-compiled Java intro
- 1:06Why AOT Java is large
- 2:54Size reduction approach
- 4:37Execution mode heuristics
- 7:27Heuristics limitations
- 8:31Combining AOT, interpretation and JIT
- 10:16Simulating JIT for balance
- 11:40Size savings vs interpreter cost
- 13:07Benchmark results
- 14:36Related work
- 16:01Future research
- 17:27Summary
- 17:48Q&A: JIT vs AOT sizes
- 18:53Q&A: Reducing file size
- 20:17Q&A: Server vs device use
- 20:38Q&A: JIT code generation
- 21:41Q&A: Compiled code storage
