What the profile sees at a call site
The program models the receiver-type profile C2 uses. In a real JVM, the moment a third type shows up at a hot monomorphic site, compiled code hits its type guard and deoptimises.
HotSpot starts by interpreting bytecode, counts which methods and loops are hot, and compiles those to machine code: quickly with C1, then aggressively with C2 using the profile it gathered. C2's big wins are inlining, escape analysis and speculative optimisations that are undone (deoptimised) if their assumptions break.
Change the code and press Run (Ctrl+Enter). Try to predict the output first, then break it on purpose and read the error. Your edits are saved and match the lesson page.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write a program that counts how many times a small method is called inside a loop and prints the count at which it would cross the tier-3 and tier-4 thresholds (200 and 5000), for loop sizes 100, 1000 and 10000.
Rewrite a loop over a List<Shape> with three shape types so that each type is processed in its own loop (keeping call sites monomorphic), and show that the total area is the same.
Write a method that builds a StringBuilder, appends three values and returns the String, and explain in a comment whether the StringBuilder escapes.
Explain it without notes
Explain tiered compilation in HotSpot.
Why is inlining called the mother of all optimisations?
What is escape analysis and what does it enable?
What is deoptimisation, and when does it happen?
Expected output
13 | [Square] | monomorphic: one type check, then area() inlined
10 | [Square, Rect] | bimorphic: two type checks, both bodies inlined
6 | [Square, Rect, Triangle] | megamorphic: real virtual call, no inlining