RFR(xs): 8225200: runtime/memory/RunUnitTestsConcurrently.java has a memory leak
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Mon Jul 1 19:13:21 UTC 2019
+1
Thank you for taking care of this!
Coleen
On 7/1/19 3:07 PM, Thomas Stüfe wrote:
> Thanks Stefan!
>
> On Mon, Jul 1, 2019, 21:06 Stefan Karlsson <stefan.karlsson at oracle.com>
> wrote:
>
>> On 2019-07-01 20:56, Thomas Stüfe wrote:
>>> Hi all,
>>>
>>> may I please have reviews and opinions about the following patch:
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8227041
>>> cr:
>>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8227041-rununittestsconcurrently-has-a-mem-leak/webrev.00/webrev/index.html
>>> There is a memory leak in test_virtual_space_list_large_chunk(), called
>> as
>>> part of the whitebox tests WB_RunMemoryUnitTests(). In this test
>> metaspace
>>> allocation is tested by rapidly allocating and subsequently leaking a
>>> metachunk of ~512K. This is done by a number of threads in a tight loop
>> for
>>> 15 seconds, which usually makes for 10-20GB rss. Test is usually OOM
>> killed.
>>> This test seems to be often excluded, which makes sense, since this leak
>>> makes its memory usage difficult to predict.
>>>
>>> It is also earmarked by Oracle for gtest-ification, see 8213269.
>>>
>>> This leak is not easy to fix, among other things because it is not clear
>>> what it is it wants to test. Meanwhile, time moved on and we have quite
>>> nice gtests to test metaspace allocation (see e.g.
>>> test_metaspace_allocation.cpp) and I rather would run those gtests
>>> concurrently. Which could be a future RFE.
>>>
>>> So I just removed this metaspace related test from
>> WB_RunMemoryUnitTests()
>>> altogether, since to me it does nothing useful. Once you remove the
>> leaking
>>> allocation, not much is left.
>>>
>>> Without this part RunUnitTestsConcurrently test runs smoothly through its
>>> other parts, and in that form it is still useful.
>>>
>>> What do you think?
>> I think this makes sense and it looks good to me.
>>
>> Thanks,
>> StefanK
>>
>>> Cheers, Thomas
>>
More information about the hotspot-dev
mailing list