Garbage collection race condition before final checks

[Mandy Chung]

  On 11/10/11 06:41, Gary Adams wrote:
>  On 11/ 8/11 11:13 PM, Mandy Chung wrote:
>>
>>
>> Thanks for picking up this bug and fixing this intermittent issue.  
>> PlatformLoggingMXBeanTest.java in the same directory has the same 
>> issue.  It'd be good to fix that with the same CR.  These tests were 
>> copied from test/java/util/logging/LoggingMXBeanTest.java.  I haven't 
>> looked in details but I wonder why the test/java/util/logging tests 
>> don't have this intermittent issue and I suspect it holds a strong 
>> reference.
>
> I attempted to break PlatformLoggingMXBeanTest.java with a generous 
> application of
> GC calls, but I could not get it to fail in the same manner as the 
> other test. It may be
> failing due to a different condition.
>

It's a timing issue when Logger.getLogger and setLogLevel method are 
called.  If you move these 2 lines:

         Logger logger1 = Logger.getLogger( LOGGER_NAME_1 );
         Logger logger2 = Logger.getLogger( LOGGER_NAME_2 );

to the PlatformLoggerMXBeanTest constructor (this is about the same 
place to when LoggingMXBeanTest calls Logger.getLogger), I am able to 
reproduce the problem.

It's harder to reproduce the problem when the timing window between 
Logger.getLogger that creates a reference the logger on stack and 
setLogLevel method call is probably too small that GC hardly occurs in 
the systems I tried.  Give it a try to see if this helps.

I took your patch and generate the webrev:
    http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7067691/webrev.00/

line 46: about the name, how about simply renaming it to "test" ?

line 230-232: I wonder if the bracket is intentional?

Mandy