Garbage collection race condition before final checks
mandy.chung at oracle.com
Mon Nov 14 20:53:10 UTC 2011
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
> 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:
line 46: about the name, how about simply renaming it to "test" ?
line 230-232: I wonder if the bracket is intentional?
More information about the core-libs-dev