Updated ARM Spec

[David Holmes]

Rémi Forax said the following on 08/23/10 20:06:
> Le 23/08/2010 11:50, David Holmes a écrit :
>> I said the following on 08/23/10 19:35:
>>> ...
>>> The "suppressedException" array as I currently understand it would 
>>> need to be cleared, if the pre-allocated instances with no backtrace 
>>> can still contain "suppressedExceptions" - which I believe they can.
>>
>> I just realized however that clearing the suppressed-exception state 
>> is simply not an option as the same exception instance could be thrown 
>> concurrently in multiple threads. In short these shared immutable 
>> exception instances must remain immutable if they are to be shared. 
>> Hence they can not contain suppressed-exception information.
>>
>> David Holmes
>>
>> PS: I am not a subscriber to coin-dev.
> 
> You can explicitly call setStackTrace() on a shared immutable exception, 
> hence there is a problem.
> addSupressedExceptions() will have the same issue.

I stand corrected. The Java side of the code couldn't care less about 
the VM level backtrace - it just installs a Java array. :(

> I think the fix is to:
> - silently discard the stack trace taken as argument of setStackTrace() 
> if the cause is 'null' (or not 'this')
> - silently don't register suppressed-exceptions if cause is 'null'

I think the Java code should be able to recognize a Throwable instance 
that should not allow these things to be set, and simply ignore the 
request. However that is a change in the spec for setStackTrace.

Suppressed-exceptions could then be modelled like backtrace support - an 
optional facility generally used but ignored for the pre-allocated 
immutable instances.

David

> Rémi
> 
>>
>>> Aside: StackOverflowException is created on demand, not 
>>> pre-allocated, in Hotspot.
>>>
>>> David Holmes
>>> ------------
>>>
>>>
>>> Rémi Forax said the following on 08/13/10 22:41:
>>>> 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 {
>>>>
>>>>
>>>> And we should do the same for the field suppressed exceptions.
>>>>
>>>> Rémi
>>>>
>