Java HotSpot Compiler optimization causes missing stack traces

I recently started looking into the JVM internals and have been having a good time discovering a few things. Will keep documenting interesting stuff as and when I find them.


A particularly interesting JVM optimization is that if a certain type of exception is thrown a number of times closely together, the compiler optimizes the code to return the same exception instance, with an empty stack trace. It's easy to reproduce this behavior in a few lines. I saw this happening using JRE 1.5 on my machine.Looks like this is true for all kinds of Exceptions. Tried it for NullPointerExceptions, ClassCastException and ArrayOutOfBoundsException and it held true.


Although a useful optimization, missing stack traces in a production or any troubleshooting scenario can be baffling. To avoid missing stack traces , using -Xint flag or JAVA_COMPILER=false could force the VM to run in an interpreted mode at an obvious cost of performance. 
Another workaround is that with the JVM flag -XX:-OmitStackTraceInFastThrow we can disable the performance optimization of the JVM for this use case. If this flag is set, the stacktrace will be available.From the Sun release notes:
"The compiler in the server VM now provides correct stack backtraces for all "cold" built-in exceptions. For performance purposes, when such an exception is thrown a few times, the method may be recompiled. After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace. To disable completely the use of preallocated exceptions, use this new flag: -XX:-OmitStackTraceInFastThrow."


This has enticed me to look into JVM optimizations in details. More on that soon.