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.
Wednesday, February 10, 2010
RubyConf India , 2010
India is all set to host the first ever RubyConf on March 20-21, 2010. And ThoughtWorks is all the more part of the Ruby history in India by virtue of being the Platinum and technology sponsor.
RubyConf is a community event that brings together Ruby enthusiasts from across India (and even some international participants - yes people are flying down for this from as far as LA!!). It usually happens internationally and is now happening for the FIRST time in India.It features prominent authors and speakers such as Chad Fowler, Ola Bini and Nick Sieger.TW is the main sponsor and organizer supported by Ruby Central and co-sponsors.
A great platform to network and learn abt the latest in the Ruby world.No wonder 200 delegates from the Ruby community will attend and we're almost sold out even before the first week of opening registrations.
RubyConf is a community event that brings together Ruby enthusiasts from across India (and even some international participants - yes people are flying down for this from as far as LA!!). It usually happens internationally and is now happening for the FIRST time in India.It features prominent authors and speakers such as Chad Fowler, Ola Bini and Nick Sieger.TW is the main sponsor and organizer supported by Ruby Central and co-sponsors.
A great platform to network and learn abt the latest in the Ruby world.No wonder 200 delegates from the Ruby community will attend and we're almost sold out even before the first week of opening registrations.
Subscribe to:
Comments (Atom)