A DESCRIPTION OF THE REQUEST :
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.

For production environments, it is desirable to keep this optimization on, but in the case that exceptions start getting thrown, it becomes extremely difficult to debug the system without stack traces.  I propose the implementation of some means of resetting the counter, so that stack traces return without having to restart the system, perhaps via JMX.

JUSTIFICATION :
Currently, one can disable the performance optimization all together using -XX:-OmitStackTraceInFastThrow but in production environments, this optimization could be too valuable to completely forgo.

If an exception starts occurring, and some debugging is needed, if one were to restart the system and use the -XX:-OmitStackTraceInFastThrow flag, there are many circumstances where the exception will no longer be reproducible.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
If the JVM is running, and starts throwing exceptions without stack traces, the user should be able to some how trigger the JVM to once again return stack traces.    Even if this is just momentary, such that the stack trace will again have the potential to be optimized away, the ability to reset the stack trace production would be very beneficial.  I have no concrete suggestion for the form of the trigger, but JMX would be convenient.
ACTUAL -
There is no current way to reset stack traces without restarting the JVM.