Review request for a test fix for 6992968
Mandy Chung
mandy.chung at oracle.com
Mon Oct 18 20:44:21 PDT 2010
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
>>
More information about the serviceability-dev
mailing list