Microbenchmarks performance in the smaller scale
summary
Simple System.currentTimeMillis checks lie: a billion-iteration loop can compile away and report 2 milliseconds because of JIT inlining, dead‑code elimination and OSR. JVM specifics matter — server JIT threshold about 10,000 invocations (client ~1,500), escape analysis, classloading and GC all change timing. Practical fixes shown: run many JVMs, warm up until printCompilation/printInlining stops, preload classes, and use frameworks like Caliper (but watch runMillis behavior). A hashmap demo yields ~23 ns with good hashes and ~23,000 ns with a bad hash, showing the real effect.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 2:33Microbenchmarks deceptive trust issues
- 5:01JVM internals and JIT basics
- 10:53JIT optimizations: inlining and escape analysis
- 17:40On-stack replacement and BCI explained
- 25:59Measuring time precisely in Java
- 28:09GC and class loading benchmark impacts
- 29:59Reliable benchmarking setup
- 33:17Warmup phases in Java benchmarks
- 36:59Benchmark best practices
- 38:05Microbenchmark tools: Caliper, JMH, Japex
- 40:40Live demo: Caliper benchmarking
- 47:01Summary
related talks
46mJava vs CPU
45mHow difficult can it be to write efficient code?
38mBenchmarking Code Performance with JMH
59mAn Introduction to JVM Performance
54mJava performance techniques The cost of HotSpot runtime optimizations
51mJava vs CPU — round 2
01h 01mAn Introduction to JVM Performance
01h 09mWhat it means to be Just In Time