code review request: Test case for JDK-7042126 HashMap.clone() memory leak

[David Buck]

Hi Alen (and everyone else)!

Thank you for your replies.

I have added an explicit-GC/sleep loop similar to the example fixes. I 
have also added type parameters to avoid use of raw types as suggested.

The updated webrev is available below. Please have a look and let me 
know if this is acceptable for pushing.

http://cr.openjdk.java.net/~dbuck/7042126/webrev.01/

Cheers,
-Buck

On 2013/01/31 23:05, Alan Bateman wrote:
> On 31/01/2013 09:40, David Buck wrote:
>> Hi!
>>
>> I was curious to see what others have done in the past and took a look
>> at about 15 different testcases for memory leaks in the jdk tree and
>> basically found 3 patterns:
> Another one that you'll find is tests that use jmap to look at the
> instance count of specific objects to see if they are increasing. I
> personally do not like these tests as they are too targeted, also they
> involve a second process and historically have been troublesome.
>
> Anyway, my concern with the test as proposed is that it will might fail
> intermittently. Last year there were fixes to several issues like this,
> here are two that Eric Wang that come to mind:
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad204cc7433
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/97eb7a4b1fdd
>
> Adding a loop + sleep to your test should be fine for now.
>
> I see Martin's suggestion about adding a supporting library to the test
> suite for use by tests like this. As it's something that tests in may
> areas then it may be worth exploring.
>
> -Alan