So many times have I heard people at work imply in words that developers /programmers /coders /technologists tend to be arrogant and I often wonder if it has any truth to it.The more I think about it the more it seems to the contrary.
Being in the field of technology is supremely humbling. By the sheer rate of obsolescence, it ensures that even in a limited scope of one's field it's rather difficult to claim to be a know-all. The good thing about that is that it urges one to rejuvenate that thirst for new things which IMO should be the single most significant reason to want to be in this field to start with.It's certainly not for the faint of the heart narcissists.
Thursday, September 2, 2010
Wednesday, September 1, 2010
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.
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.
Subscribe to:
Comments (Atom)