On 11/9/11 4:08 AM, Alan Bateman wrote:
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.
"proxy" was my first choice, but that was already used for another local
variable.
The original variable was just "p", but that seemed unwise for a global
variable name.
... lather & rinse
