Garbage collection race condition before final checks

[Rémi Forax]

On 11/15/2011 01:26 PM, Gary Adams wrote:
>  Added PlatformLoggingMXBeanTest to the 7067691 bug fix,
> e.g. instance variables for Logger variables to prevent premature
> weak reference collection.
>
>   http://cr.openjdk.java.net/~gadams/7067691/

Hi Garry,

>
> Fresh webrevs for the other work in progress bug fixes.
>
>   http://cr.openjdk.java.net/~gadams/6731620/

You can declare and initialize elapsed at the same place :
   final long elapsed = System.currentTimeMillis() - start;
otherwise, it looks ok.

>   http://cr.openjdk.java.net/~gadams/6818464/

if you want to have a variable changed in an inner class, the usual idiom
is to use an array of one element.

      public static void main (String[] args) throws Exception  {
+        final Thread[] tdThread = new Thread[1];
          Timer t = new Timer();

          // Start a mean event that kills the timer thread
          t.schedule(new TimerTask() {
              public void run() {
+                tdThread[0] = Thread.currentThread();
                  throw new ThreadDeath();
              }
          }, 0);

          // Wait for mean event to do the deed and thread to die.
          try {
+            do {
              Thread.sleep(100);
+            } while(tdThread[0] == null);
          } catch(InterruptedException e) {
          }
+        tdThread[0].join();

          // Try to start another event
          try {
              // Timer thread is dead now
              t.schedule(new TimerTask() {



>   http://cr.openjdk.java.net/~gadams/6860309/

This one is ok for me :)

>   http://cr.openjdk.java.net/~gadams/7084033/

Thumb up for this one too !

cheers,
Rémi

>
> On 11/10/11 09:41 AM, 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 reference.
>>
>> 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.
>>
>