Understanding Fast Throw Optimization and Missing Exception Stack Traces in Java

During large‑scale promotional events such as the 618 sale, missing exception stack traces can severely hinder online problem resolution because stack information is a key clue for debugging.

The disappearance is caused by the HotSpot JIT compiler’s Fast Throw optimization: when the same exception is thrown many times at the same code location, the C2 compiler replaces it with a pre‑allocated exception that has no message or stack trace, effectively hiding the stack.

Fast Throw applies only to HotSpot VMs (e.g., Oracle JDK, Liberica JDK) and requires that the exception be thrown repeatedly at a specific point, that the C2 compiler be used, and that the generated exception be a pre‑allocated empty one.

Performance tests show a dramatic speed gain when Fast Throw is enabled. For example, 1 000 000 throws of NullPointerException took 5.983 s with Fast Throw versus 28.345 s without it, and 5 000 000 throws completed in 35.678 s with Fast Throw while the disabled case timed out.

The recommendation is not to disable Fast Throw merely because stack traces disappear; the optimization provides significant performance benefits.

When Fast Throw is triggered in production, the problem can be located by tracing logs that contain many lines like Caused by: java.lang.NullPointerException without detailed stacks. The article includes sample log excerpts illustrating this pattern.

In a real incident, a machine’s performance fluctuation caused a timeout, leading to a cached fallback object whose Boolean field conversion threw a NullPointerException. Further analysis revealed high TCP retransmission rates on the host, indicating network instability that affected Docker instances.

Overall, the article emphasizes the importance of quickly fixing observed symptoms while also performing root‑cause analysis to improve system reliability and team processes.