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

[coleen.phillimore at oracle.com]

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