Code review request: 6973831 NPE when printing stack trace of OOME

[Brian Goetz]

So, this aspect of COIN is still somewhat new, and so I think it is worth looking at carefully.  There is a specification for this feature that was discussed on coin-dev.  You might want to take a look and comment -- its not too late.

On Aug 12, 2010, at 5:00 PM, David Holmes wrote:

> Mandy Chung said the following on 08/13/10 04:29:
>> On 08/11/10 18:26, David Holmes wrote:
>>> I'm a bit behind on this functionality as I have no ideas what a suppressed exception is. :) 
>> FWIW.  The suppressed exceptions are added for automatic resource management (6911258).
>>   http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html
> 
> Can't say I'm enthralled with the suppressed-exception part of this.
> 
>>> That aside I'm curious as to the expected multi-thread usage for an exception that requires these things to be thread-safe ? Given an exception occurs in a given thread, passing it to another thread should require some form of safe-publication.
>>> 
>> Agree.  May I count you as a reviewer?
>>   http://cr.openjdk.java.net/~mchung/6973831/webrev.02/
> 
> Reviewed. :)
> 
> David
> 
>> Thanks
>> Mandy
>>> David
>>> 
>>> Mandy Chung said the following on 08/12/10 07:57:
>>>> On 08/11/10 14:43, Mandy Chung wrote:
>>>>> On 08/11/10 14:03, Rémi Forax wrote:
>>>>>> Brian, Mandy,
>>>>>> It seems this is not the sole thread-safety issue,
>>>>>> access to fields 'cause' or 'stackTrace' aren't thread safe too and detailMessage is not final.
>>>>>> 
>>>>> 
>>>>> I agree that the getCause and setStackTrace method need to be synchronized.  On the other hand, the initCause and setStackTrace methods are used to override the values initialized in the constructor and so access to these fields are likely safe in practice.  I can fix it as part of this fix.
>>>>> 
>>>> 
>>>> Fixed the getCause and setStackTrace methods:
>>>>   http://cr.openjdk.java.net/~mchung/6973831/webrev.02/
>>>> 
>>>> Mandy
>>>> 
>>>>> The "detailMessage" is not final because the VM in fact preallocates Throwable object (OOME and ArithmeticException) and then sets the 'detailMessage' field directly (as the constructor is not invoked).
>>>>> 
>>>>> Mandy
>>>>