Please review fix to StackOverflowError in jigsaw tracing

Mandy Chung mandy.chung at oracle.com
Wed May 19 11:29:07 PDT 2010


On 05/19/10 05:03, Alan Bateman wrote:
> Mandy Chung wrote:
>> I have a fix for:
>>   6951456: jigsaw JIGSAW_TRACE=3 stack overflow due to recursion
>>
>> Trace may be called while the classes for tracing (e.g. 
>> java.util.Formatter)
>> are being loaded. One solution is to cache the traces to avoid recursion
>> until the very first call completes.
>>
>> Webrev at:
>>   http://cr.openjdk.java.net/~mchung/6951456/webrev.00/
>>
>> Thanks
>> Mandy
> I didn't see any replies to this so I've looked at the webrev.

Thanks for the comment.  I revise the fix:
    http://cr.openjdk.java.net/~mchung/6951456/webrev.01/
>
> I realize tracing isn't critical but it looks like there is potential 
> to buffer messages that will never be printed. Say thread A observes 
> that we are initializing just before thread B sets the inited flag. 
> Maybe the simplest is to replace "calls" with an initializing flag 
> that is only accessed when holding a lock. That would ensure that you 
> can't buffer a trace message after the buffered messages have been 
> flushed.
>

I remove the inited and calls variable and have the methods in the Cache 
class to do the synchronization.
> Minor comment but would two Lists be a more appropriate collection for 
> the buffered messages?  Also when calling Cache.trace when maybe you 
> could do this:
>
> sb.append(fmt);
> sb.append("%n");
> Cache.trace(sb.toString(), args);
>

Thanks
Mandy




More information about the jigsaw-dev mailing list