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

David Buck david.buck at oracle.com
Thu Jan 31 16:24:24 UTC 2013

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

More information about the core-libs-dev mailing list