Updated ARM Spec

Rémi Forax forax at univ-mlv.fr
Mon Aug 23 03:23:34 PDT 2010


Le 23/08/2010 12:09, David Holmes a écrit :
> 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.

Yes, setStackTrace() can 'not succeed'.
And the way to recognize such Throwable instance is to check is the 
field 'cause' is null.

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

Yes, and the spec must be also updated accordingly.

>
> David

Rémi


More information about the hotspot-runtime-dev mailing list