Java performance techniques The cost of HotSpot runtime optimizations
summary
HotSpot C2 (threshold ~10k) often makes aggressive assumptions that can yield 100x faster runs versus the interpreter but a single unexpected branch triggers an uncommon trap and bails to the interpreter, costing roughly 100x for that call. Null checks often rely on hardware signals (segfault handler) and are expensive when they first occur. Loop unrolling up to 8x and inlining (default max depth 9, avoid >325-byte hot methods) improve throughput; string dedup reduces heap but increases Stop-The-World pauses and biased locking can cause ~1ms pauses. Tools: JITWatch, JMH, HPjmeter.
AI-written summary · about
chapters (14)
- 0:00Start
- 0:25About Me
- 0:48Agenda
- 2:01My Configuration
- 2:50Just In Time Compiler - HotSpot
- 8:29Uncommon Traps
- 19:38Null Sanity Checks
- 29:22Loop Unrolling
- 35:35String Deduplication
- 39:52Biased Locking
- 43:26Inlining
- 50:04Huge Methods
- 51:45Too Many Arguments
- 52:51In Closing
related talks
01h 01mAn Introduction to JVM Performance
59mAn Introduction to JVM Performance
49mAn Introduction to JVM Performance
55mThe Performance Engineer's Guide To Java HotSpot
35mJava at Speed: Building a Better JVM
41mAn Introduction to JVM Performance
01h 09mFrom Bytecode to Native Code in HotSpot JVM
01h 09mWhat it means to be Just In Time