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

[coleen.phillimore at oracle.com]

Thanks Harold!
Coleen

On 8/31/18 9:33 AM, Harold David Seigel wrote:
> +1
>
> Harold
>
> On 8/30/2018 4:54 PM, Ioi Lam wrote:
>> Hi Coleen,
>>
>> This looks good! Thanks for bearing with my requests :-)
>>
>> - 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
>>>>>
>>>>
>>>
>>
>