[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Review request for a test fix for 6992968
From:       David.Holmes () oracle ! com (David Holmes)
Date:       2010-10-19 4:21:09
Message-ID: 4CBD1CB5.7080500 () oracle ! com
[Download RAW message or body]

Hi Mandy,

Those few comments make a huge difference - thanks! Yep this all looks 
good to me.

David

Mandy Chung said the following on 10/19/10 13:44:
>  David,
> 
> Thanks for taking a look at that.  I added the comments to describe the 
> works being done by the threads (please let me know if that's 
> inadequate). This test was written before jsr166 was added in the jdk 
> and I took the chance to clean that up.
>    http://cr.openjdk.java.net/~mchung/6992968/webrev.01/
> 
> Your feedback is very much appreciated.
> 
> Mandy
> 
> On 10/18/10 4:37 PM, David Holmes wrote:
>> Hi Mandy,
>>
>> It's hard to evaluate this without knowing what the coordination 
>> protocol is between the different threads. However you have removed 
>> some very strange looking synchronization code, and that can only be a 
>> good thing!
>>
>> David
>>
>> Mandy Chung said the following on 10/19/10 08:21:
>>>  6992968: 
>>> test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh 
>>> should not hang
>>>
>>> Webrev at:
>>>    http://cr.openjdk.java.net/~mchung/6992968/webrev.00/
>>>
>>> If the test fails, the main thread is waiting for the checker thread 
>>> to finish checking the result but the checker thread terminates with 
>>> an exception.  The test hangs and the main thread is forever waiting 
>>> for a monitor to be notified.  I update the test to use the new 
>>> concurrent utility and reset a CyclicBarrier that causes a 
>>> BrokenBarrierException to be thrown in the main thread.
>>>
>>> I also add @ignore to CollectionUsageThresholdConcMarkSweepGC.sh test 
>>> until 6982965 is fixed.
>>>
>>> Mandy
>>>
> 

[prev in list] [next in list] [prev in thread] [next in thread]