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

Coleen Phillimore coleen.phillimore at
Thu Feb 3 20:17:11 PST 2011

Okay, how about this:

Exception in thread "main" - java.lang.OutOfMemoryError thrown from the 

And nothing new from jni_ExceptionDescribe.   See webrev:

local webrev at
local bug link


On 2/3/2011 8:15 PM, David Holmes wrote:
> 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) {
>      t.printStackTrace();
>    }
> 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.
> David
> 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