Four JMH Cases Reveal How Java JIT Optimizes at the Assembly Level

Method Inlining

When a method is inlined the call overhead (parameter stack, jump, return) disappears, which is visible in assembly as the absence of a callq instruction. The benchmark defines four JMH methods: allInlined – calls tinyMethod and smallMethod inside a tight loop. mixedInlining – inlines the small methods but calls a large method notInlinable that exceeds the default inline size. virtualCall – invokes a virtual method that is de‑virtualized. forcedNoInline – forces the large method to stay out of line.

Benchmark results (average time, ns/op):

allInlined ≈ 440.9

mixedInlining ≈ 560.1

virtualCall ≈ 228.9

forcedNoInline ≈ 668 042.5

The non‑inlined version is about 1500× slower because each iteration incurs a callq (~5‑10 ns). Inline assembly of allInlined shows the tiny method expanded to:

leal   0x01(%rsi), %eax   ; eax = x*2 + 1 (LEA does the arithmetic)
addl   $0x01, %eax       ; eax += 1

The loop structure contains a back‑edge jump ( jl loop_start) that the JIT uses to decide when to compile a hot loop. Virtual call de‑virtualization inserts a guard:

cmpl   $0x..., 0x08(%rsi)   ; type check
jne    slow_path            ; rare slow path
leal   0x2A(%rsi), %eax    ; inline: x + 42

Decision factors (C2 compiler):

Method size – <35 bytes always inlined, <325 bytes possible.

Invocation frequency – hot paths are prioritized.

Method type – static/private/final inline easily; virtual methods need de‑virtualization.

Compiler – C2 is more aggressive than C1.