Review request for a test fix for 6992968
David Holmes
David.Holmes at oracle.com
Mon Oct 18 21:21:09 PDT 2010
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
>>>
>
More information about the serviceability-dev
mailing list