Garbage collection race condition before final checks

[Gary Adams]

  Here's an updated diff :
    - added current CR# to the @bug tag
    - made logger1 and logger2 instance variables
    - renamed test instance variable lmxbeantest
    - removed excessive diagnostic print outs


--- a/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
+++ b/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
@@ -23,7 +23,7 @@

  /*
   * @test
- * @bug 7024172
+ * @bug 7024172 7067691
   * @summary Test if proxy for PlatformLoggingMXBean is equivalent
   *          to proxy for LoggingMXBean
   *
@@ -43,6 +43,13 @@
      static String LOGGER_NAME_2 = "com.sun.management.Logger.Logger2";
      static String UNKNOWN_LOGGER_NAME = "com.sun.management.Unknown";

+    // These instance variables prevent premature logger garbage collection
+    // See getLogger() weak reference warnings.
+    Logger logger1;
+    Logger logger2;
+
+    static LoggingMXBeanTest lmxbeantest;
+
      public static void main(String[] argv) throws Exception {
          MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
          LoggingMXBean proxy =
@@ -51,7 +58,7 @@
                  LoggingMXBean.class);

          // test LoggingMXBean proxy
-        LoggingMXBeanTest p = new LoggingMXBeanTest(proxy);
+        lmxbeantest = new LoggingMXBeanTest(proxy);

          // check if the attributes implemented by PlatformLoggingMXBean
          // and LoggingMXBean return the same value
@@ -59,14 +66,16 @@
              ManagementFactory.getPlatformMXBean(mbs, PlatformLoggingMXBean.class);

          checkAttributes(proxy, mxbean);
+
+    lmxbeantest = null;
      }

      // same verification as in java/util/logging/LoggingMXBeanTest2
      public LoggingMXBeanTest(LoggingMXBean mbean) throws Exception {

-        Logger logger1 = Logger.getLogger( LOGGER_NAME_1 );
+        logger1 = Logger.getLogger( LOGGER_NAME_1 );
          logger1.setLevel(Level.FINE);
-        Logger logger2 = Logger.getLogger( LOGGER_NAME_2 );
+        logger2 = Logger.getLogger( LOGGER_NAME_2 );
          logger2.setLevel(null);

          /*
@@ -207,6 +216,7 @@
          // verify logger names
          List<String> loggers1 = mxbean1.getLoggerNames();
          List<String> loggers2 = mxbean2.getLoggerNames();
+
          if (loggers1.size() != loggers2.size())
              throw new RuntimeException("LoggerNames: unmatched number of 
entries");
          List<String> loggers3 = new ArrayList<>(loggers1);
@@ -219,7 +229,10 @@
              if (!mxbean1.getLoggerLevel(logger)
                      .equals(mxbean2.getLoggerLevel(logger)))
                  throw new RuntimeException(
-                    "LoggerLevel: unmatched level for " + logger);
+                    "LoggerLevel: unmatched level for (" + logger
+            + ", " + mxbean1.getLoggerLevel(logger)
+            + ", " + mxbean2.getLoggerLevel(logger) + ")");
+
              if (!mxbean1.getParentLoggerName(logger)
                      .equals(mxbean2.getParentLoggerName(logger)))
                  throw new RuntimeException(


On 11/ 9/11 04: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.