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

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Thu Aug 30 19:13:12 UTC 2018



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

The exception handler that I have for OOM implements lines 62 and 63.  
So I think it matches.
>
> 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());

This is a good suggestion, I'll try this (tested with -Xmx20m), and not 
print a message at 72.
>
> 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,
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
>



More information about the hotspot-runtime-dev mailing list