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

[Ioi Lam]

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

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


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