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