RFR: 8064909: FragmentMetaspace.java got OutOfMemoryError

[Michail Chernov]

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
>>>
>>
>
>
>