RFR: 8064909: FragmentMetaspace.java got OutOfMemoryError

[Michail Chernov]

Hi,

Can you please look this review?

Thanks,
Michail

On 27.11.2014 16:28, Michail Chernov wrote:
> Hi,
>
> CC'ed hotspot-runtime-dev.
>
> Here is not test failure - test works as expected. OOME is occurred in 
> compiler instance.
>
> private JavaCompiler javac;
> ...
>         javac = ToolProvider.getSystemJavaCompiler();
> ...
>         int exitcode = javac.run(null, null, null, 
> file.getCanonicalPath());
>         if (exitcode != 0) {
>             throw new RuntimeException("javac failure when compiling: " +
>         file.getCanonicalPath());
>
> Here is 2 ways - rewrite getGeneratedClass 
> (runtime/testlibrary/GeneratedClassLoader.java) to allow them to throw 
> not only RuntimeException, or to catch RuntimeException and check 
> exception message comparing with "javac failure when compiling:". Both 
> ways seem to me are not as clear as expected for this simple test. 
> More - javac does not throw anything - it just returns exitcode 
> (non-zero) and writes its messages to System.err.
>
> Also I can add comment to code like "OOME with message 
> "java.lang.OutOfMemoryError: Java heap space" doesn't mean that 
> something wrong with metaspace - need just to increase -Xmx".
>
> Thanks,
> Michail
>
> On 27.11.2014 2:00, Jon Masamitsu wrote:
>> Dima,
>>
>> If this test fails with an OOME in the future, I would like it to be
>> obvious that the failure is not that an OOME occurred.   I cannot
>> tell that from looking at the test.    Can the test be changed so
>> I don't have to spend time figuring out that the OOME is not
>> a failure mode  of the test?
>>
>> Jon
>>
>>
>> On 11/26/2014 12:51 PM, Dmitry Fazunenko wrote:
>>> Hi Jon,
>>>
>>> The original version of test worked for 80 seconds trying to perform 
>>> as many iterations as possible. The number of iterations performed 
>>> depended on how fast is the machine. With each next iteration the 
>>> size of generated and loaded classes is growing, so on fast enough 
>>> machines 80 seconds is enough to run out of heap while generating a 
>>> class.
>>>
>>> The fix not only sets the heap, but limits iterations.  300m heap is 
>>> enough for 200 iterations.
>>>
>>> Your approach, with catching OOME(heap) and passing will also work, 
>>> but it will reduce the test readability (and potentially could bring 
>>> more problems).
>>>
>>> An alternative approach would be to limit metaspace and heap 
>>> accordingly and load classes until we don't run out metaspace... But 
>>> this might take awhile.
>>>
>>> So, I hope that Michael's fix is good.
>>>
>>> Thanks for looking and expressing comments.
>>> Dima
>>>
>>>
>>>
>>>
>>> On 26.11.2014 22:04, Jon Masamitsu wrote:
>>>> Michail,
>>>>
>>>> Your change makes this test pass but it seems like at
>>>> some future date 300m might not be big enough
>>>> (for whatever reason).  Could the test be make to
>>>> caught an OOME, print out a message saying that
>>>> an OOME doesn't mean the test failed  but that
>>>> the test needs a larger heap?  Then pass an
>>>> exception up (maybe some type of Runtime
>>>> exception - sorry if that is vague but I don't
>>>> what type of exception would make sense).  That
>>>> would mean we wouldn't have to spend time
>>>> diagnosing what the OOME means again.
>>>>
>>>> Jon
>>>>
>>>> On 11/26/2014 5:36 AM, Michail Chernov wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this simple fix for nightly test failure:
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8064909/webrev.00/
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8064909
>>>>>
>>>>> Problem: test fails because of OOME (not enough heap size).
>>>>> Solution: heap size were increased.
>>>>>
>>>>> Testing:
>>>>> jtreg
>>>>>
>>>>> Thanks,
>>>>> Michail
>>>>
>>>
>>
>>
>>
>