RFR 8135188: RunFinalizationTest.java Exception java.lang.Error: Test failure: Object was not finalized

Daniel D. Daugherty daniel.daugherty at oracle.com
Mon Oct 12 17:09:15 UTC 2015


 > http://cr.openjdk.java.net/~jbachorik/8135188/webrev.02

test/serviceability/dcmd/gc/RunFinalizationTest.java
     No comments.

test/serviceability/dcmd/gc/FinalizationRunner.java
     L58:         o = new MyObject();
     L59:         o = null;

     L79:         o = new MyObject();
     L80:         o = null;
         So now two different threads are initializing this static field:

         55     public static MyObject o;

         and both are clearing it. Is that just a left over
         from simplifying the test?

Dan



On 10/12/15 2:00 AM, Jaroslav Bachorik wrote:
> On 9.10.2015 20:05, Martin Buchholz wrote:
>>
>>
>> On Thu, Oct 8, 2015 at 11:51 PM, Jaroslav Bachorik
>> <jaroslav.bachorik at oracle.com <mailto:jaroslav.bachorik at oracle.com>> 
>> wrote:
>>
>>     On 8.10.2015 18:56, Martin Buchholz wrote:
>>
>>         Hi Jaroslav,
>>
>>         we all keep writing finalization code like this... welcome to
>>         the club!
>>
>>             I think it would be better :
>>         - never use currentTimeMillis to measure elapsed time; use
>>         nanoTime instead
>>
>>
>>     Ok. I suppose this would be because currentTimeMillis() is dependent
>>     on the OS time, right?
>>
>>         - why use complex Phaser when simple CountDownLatch will do?
>>
>>
>>     The logic is more complex than just waiting for the finalization to
>>     happen. I need to make sure the finalization happened due to
>>     GC.run_finalization command and not because of an ordinary GC run or
>>     JVM shutdown. I will update the test comments to make this clear.
>>
>>
>> Oh, now I see what you're doing - you need to block the regular
>> finalizer thread to make sure there will be objects available for the
>> secondary finalizer thread to process.  Although Phaser works for this,
>> I like using simple latches - CountDownLatch(1) - because they are
>> easier to understand.
>>
>> CountDownLatch done = new CountDownLatch(1);
>>
>> in primary finalizer thread, call done.await
>> in secondary finalizer thread, call done.countDown to release the
>> primary finalizer thread
>
> Ok, I took a look at the test from distance and simplified it a bit. 
> Did a test run of 500 iterations in tight loop without failure.
>
> http://cr.openjdk.java.net/~jbachorik/8135188/webrev.02
>
> -JB-



More information about the serviceability-dev mailing list