I've searched much on the topic. But no concrete solution/guide is present.
From the docs,
Some virtual machines may, under some circumstances, omit one or more stack frames from the stack trace. In the extreme case, a virtual machine that has no stack trace information concerning this throwable is permitted to return a zero-length array from this method.
Can someone shed light on what conditions this may/will happen?
I know it happens if the same stack trace is produced over and over again (There is no hard-and-fast-rule on the count, AFAIK- Correct me otherwise). But must not this be having a defined behaviour?
Also,As per this, passing -XX:-OmitStackTraceInFastThrow will make sure my StackTrace is not lost. Isn't it wise always to do that in Production machines?
OmitStackTraceInFastThrowis an optimization in C2 compiled code to throw certain implicit exceptions without stack traces.- The optimization applies only to implicit exceptions, i.e. exceptions thrown by JVM itself, not by user code. These implicit exceptions are:
- NullPointerException
- ArithmeticException
- ArrayIndexOutOfBoundsException
- ArrayStoreException
- ClassCastException
- Stack traces are omitted, only if JVM knows the exception has happened earlier at this particular place.
So, in HotSpot JVM an exception won't have a stack trace, if all of the following conditions are met: 1) a throwing method is hot, i.e. compiled by C2; 2) it is an implicit exception, e.g. NPE thrown by obj.method(), but not by throw new NullPointerException(); 3) an exception is thrown at least for the second time.
The purpose of the optimization is to eliminate performance impact of those (arguably rare) cases when an implicit exception is repeatedly thrown on the fast path. In my opinion, this isn't a normal situation. Exceptions, especially implicit, typically denote an error condition which needs to be fixed. In this sense, it's OK to disable -XX:-OmitStackTraceInFastThrow. E.g. in our production environment we always disable it, and it saved us much debugging time. However, I admit that if such an optimization exists, there were cases where it helped to solve performance issues.
TL;DR Adding -XX:-OmitStackTraceInFastThrow option can be indeed a good idea, unless there are many implicit exceptions on a hot path in your application.