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

[Ioi Lam]

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