RFR (S) 8207793: [TESTBUG] runtime/Metaspace/FragmentMetaspace.java fails: heap needs to be increased

[coleen.phillimore at oracle.com]

On 8/30/18 4:54 PM, Ioi Lam wrote:
> Hi Coleen,
>
> This looks good! Thanks for bearing with my requests :-)

Thank you for the requests!
Coleen

>
> - Ioi
>
>
> On 8/30/2018 1:51 PM, coleen.phillimore at oracle.com wrote:
>>
>> I've fixed the GeneratedClassLoader to detect OOM, so that's ignored 
>> by FragmentMetaspace, but not any compilation or other error from the 
>> javac call.  See:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8207793.02/webrev
>>
>> Thanks,
>> Coleen
>>
>> On 8/30/18 3:27 PM, coleen.phillimore at oracle.com wrote:
>>>
>>>
>>> On 8/30/18 1:49 PM, Ioi Lam wrote:
>>>> Hi Coleen,
>>>>
>>>> The new exception handling code doesn't match with what the comment 
>>>> says:
>>>>
>>>>
>>>>   58                 // getGeneratedClasses throws a 
>>>> RuntimeException in cases where
>>>>   59                 // the javac exit code is not 0. If the 
>>>> original reason for the exception is
>>>>   60                 // a "java.lang.OutOfMemoryError: Java heap 
>>>> space",
>>>>   61                 // increase the heap size in the @run tag and 
>>>> rerun the test.
>>>>   62                 // The heap can be exhausted by this test, but 
>>>> heap exhaustion
>>>>   63                 // is not a failure mode of this test and 
>>>> should be ignored.
>>>> 64 c = gcl.getGeneratedClasses(i, 100)[0];
>>>>   ...
>>>>   71             } catch (RuntimeException oome) {
>>>>   72                 System.out.println("OOM Java heap space 
>>>> ignored from javac.");
>>>>   73                 return; // occasional failure mode.
>>>>
>>>> getGeneratedClasses doesn't actually check "the original reason" 
>>>> for the non-zero exit code.
>>>>
>>>> Maybe the both the comments and the message should be changed to 
>>>> match the actual implementation, something like "javac probably 
>>>> failed with MM"?
>>>>
>>>
>>> How about I add this as a comment at line 72?
>>>
>>>    // javac probably failed with OOM.
>>>
>>>> Alternatively, if you really want to know why javac failed, you can 
>>>> pass in stdout/sterr here, instead of null.
>>>>
>>>>         int exitcode = javac.run(null, null, null, 
>>>> file.getCanonicalPath());
>>>>
>>>> when OOM happens inside javac, this code will be exercised
>>>>
>>>> http://hg.openjdk.java.net/jdk/jdk/file/0cd55d573893/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java#l325 
>>>>
>>>>
>>>>         } catch (OutOfMemoryError | StackOverflowError ex) {
>>>>             resourceMessage(ex);
>>>>             return Result.SYSERR;
>>>>
>>>> and I think it will print into your stdout/stderr (I've not tried :-)
>>>>
>>>>
>>>
>>> Actually whether I pass NULL or not, the OOM is printed to stderr in 
>>> the jtr file.
>>>
>>> I think catching the OOM (or in this case, RuntimeException) keeps 
>>> this test from being noisy in the future in the unlikely event 1g 
>>> isn't enough to run javac plus these large classes that it is 
>>> generating.
>>>
>>> Coleen
>>>
>>>> Thanks
>>>> - Ioi
>>>>
>>>>
>>>>
>>>>
>>>> On 8/30/18 9:59 AM, coleen.phillimore at oracle.com wrote:
>>>>> Summary: Reduce test time and allow OOM.
>>>>>
>>>>> This test attempts to fragment metaspace by loading increasingly 
>>>>> large classes that are compiled with javac in a loop.  It doesn't 
>>>>> really check anything about metaspace sizes or fragmentation, but 
>>>>> looks like it has caught other problems in people's testing, so 
>>>>> may be a beneficial test. I verified that the GCs were reclaiming 
>>>>> memory for each iteration in the loop.
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8207793.01/webrev
>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8207793
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>
>>>
>>
>