Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought

David Holmes David.Holmes at
Thu Feb 3 17:15:13 PST 2011

Hi Coleen,

I think there are two different cases here that need to be handled 
differently, or at least the message printed needs to be different.

jni_ExceptionDescribe is a JNI method that can be called by a thread to 
do a stack dump of any currently pending exception. It is the native 
equivalent of doing:

    catch (Throwable t) {

However, the method says nothing about the possibility of a secondary 
exception occurring during this process - afterall this does not have to 
be implemented using Java code, so exceptions (or not) are an 
implementation artifact. Hence dropping the exception is not 
unreasonable. But this is not uncaught-exception handling so I'm not 
sure we should be reporting this secondary exception. If we do report it 
then the message should provide some context:

"jni_ExceptionDescribe encountered an internal exception: ..."

Then for the actual uncaught-exception handler case:

"Secondary exception thrown from the UncaughtExceptionHandler: ..."

I think it would be confusing to report the same info in both cases as 
they are very, very different.

I also suspect that we may get complaints about "noise" here because we 
may find that in some circumstances (such as when applets get destroyed 
etc) that exceptions during uncaughtException handling are common.


Coleen Phillimore said the following on 02/04/11 02:16:
> Summary: Print an additional message for OOM during stack trace printing
> ie:
> Exception in thread "main" . Uncaught exception of type 
> java.lang.OutOfMemoryError.
> open webrev at
> bug link at
> thanks,
> Coleen

More information about the hotspot-runtime-dev mailing list