Updated ARM Spec

Rémi Forax forax at univ-mlv.fr
Sat Aug 21 02:27:27 PDT 2010


Le 20/08/2010 23:50, Mandy Chung a écrit :
> Hi Remi,

Thanks Mandy.

Rémi

>
> Rémi Forax wrote:
>> Le 13/08/2010 05:28, Neal Gafter a écrit :
>>> When a stack overflow exception suppresses another exception, I assume
>>> it's suppressed exception list will be set.  But since there is only
>>> one such exception allocated by the VM, this will overwrite any data
>>> previously stored there.  Will the VM be modified to comply with this
>>> specification by allocating a new stack-overflow exception each time?
>>> Same question for out-of-memory error.
>>
>> This problem already exists with jdk6.
>> This code change the stack trace of permanently allocated 
>> OutOfMerroryError.
>>
>>   public static void main(String[] args) {
>>     Error last = null;
>>
>>     for(int i=0; i<100; i++) {
>>       try {
>>         Object o = new int[Integer.MAX_VALUE];
>>       } catch (Error e) {
>>         StackTraceElement[] stackTrace = e.getStackTrace();
>>         if (stackTrace != null && stackTrace.length>0 && 
>> stackTrace[0].getLineNumber() == -3) {
>>           e.printStackTrace();
>>           return;
>>         }
>>
>>         if (last == e) {
>>           StackTraceElement element = new StackTraceElement("Foo", 
>> "foo", null, -3);
>>           e.setStackTrace(new StackTraceElement[]{element});
>>         }
>>         last = e;
>>       }
>>     }
>>   }
>>
>>
>>
>> To avoid that the VM has to clear the stacktrace when using the 
>> default error:
>> in universe.cpp, in Universe::gen_out_of_memory_error:
>>
>>   if (next < 0) {
>>       // all preallocated errors have been used.
>>       // return default
>> +    java_lang_Throwable::clear_stacktrace(default_err);
>>       return default_err;
>>     } else {
>>
>>
>
> This is indeed a bug and I file 6978918 to fix it.   We should clear 
> the stacktrace and the suppressed exception fields as you suggest.
> Thanks
> Mandy
>
>> And we should do the same for the field suppressed exceptions.
>>
>> Rémi
>>
>



More information about the hotspot-runtime-dev mailing list