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

[coleen.phillimore at oracle.com]

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
>