Updated ARM Spec
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.
More information about the hotspot-runtime-dev