Garbage collection race condition before final checks

[Alan Bateman]

On 08/11/2011 15:35, Gary Adams wrote:
>  Here's another intermittent bug that is attributed
> to the garbage collection of the loggers before the
> final static check can be applied in the test.
>
> CR#7067691 : 
> java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java 
> failing intermittently
I agree with Mandy that it would be great to do a quick audit of the 
other logging (and PlatformLoggingMXBean) tests to see if we have 
similar issues. I should explain that one reason why these test failures 
may not have been observed in the past is because most people ran jtreg 
in its default mode (called othervm mode, where each tests runs in its 
own VM). Nowadays we run the tests via the make file or use jtreg 
-agentvm so that tests are running sequentially in an agent VM. Not all 
areas can run in agent VM mode yet but for the areas that do then we get 
a good speed up as the startup cost is eliminated and also it's possible 
to have a pool of agent VMs to make use of all cores when doing test 
runs (-agentvm -concurrency:auto for example). However agent VM makes 
things less predictable and for these tests it means that the GC will be 
unpredictable which is why this test was failing only very intermittently.

Anyway, the changes look fine to me. I agree with Mandy that many 
logger1 and logger2 could be instance variables. I would suggest "proxy" 
or something more readable rather than "testp" for the LoggingMXBean 
proxy. I also agree with Mandy's comment about adding the @bug.

-Alan.