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.
