8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing

[David Holmes]

+2

VM components written in Java (of which JVMCI/Graal is the first) can 
simply not be anticipated by the existing JVM TI tests.

David

On 23/03/2019 3:57 pm, Chris Plummer wrote:
> +1
> 
> Chris
> 
> On 3/22/19 8:42 PM, Jean Christophe Beyler wrote:
>> For what it's worth Daniil,
>>
>> Webrev.02 LGTM :-)
>>
>> I do believe at some point we go seem to go back and forth about JVMCI 
>> testing and what we should do or not. I understand it should be a case 
>> by case in a lot of spots but perhaps we should document somewhere our 
>> stance for JVMCI test-bugs? Just food for thought?
>>
>> Thanks,
>> Jc
>>
>> On Fri, Mar 22, 2019 at 8:26 PM Daniil Titov 
>> <daniil.x.titov at oracle.com <mailto:daniil.x.titov at oracle.com>> wrote:
>>
>>     Thank you, Chris!
>>
>>     Please review a new version of the change that makes the test
>>     ignored if Graal is enabled.
>>
>>     Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.02/
>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8217827
>>
>>     Best regards,
>>     Daniil
>>
>>
>>
>>     On 3/22/19, 7:59 PM, "Chris Plummer" <chris.plummer at oracle.com
>>     <mailto:chris.plummer at oracle.com>> wrote:
>>
>>         Hi Daniil,
>>
>>         So 8mb is enough to do at least 10,000 iterations and trigger
>>     JVMCI
>>         initialization, but the amount of memory needed after the
>>     System.gc() is
>>         more than the memory used by the loop (and then freed)? I
>>     wonder if more
>>         compilation is being triggered after the System.gc() call, and
>>     that uses
>>         a lot of memory.
>>
>>         Also, I'm not comfortable with this concept of considering
>>     JVMCI to be
>>         initialized. You're making assumptions on the internal state
>>     of JVMCI.
>>         Other compilations could require other allocations that could
>>     end up
>>         failing. You also don't know how JVMCI behavior might change
>>     in the
>>         future, causing this test to fail again. Perhaps it is best
>>     not to run
>>         these ResourceExhausted tests with JVMCI. Their reliability is
>>     dubious
>>         enough already.
>>
>>         thanks,
>>
>>         Chris
>>
>>         On 3/22/19 4:02 PM, Daniil Titov wrote:
>>         > Hi Chris,
>>         >
>>         > Addind -XX:+PrintCompilation flag shows that the first
>>     compiled method is java.lang.Object::<init>.
>>         >
>>         > Max heap size and parameter for the warmup stage (10K
>>     iterations) were found a posteriori, to ensure that JVMCI
>>     initialization is kicked but without throwing OutOfMemoryError.
>>         >
>>         > The heap increase is required otherwise a second OOME is
>>     thrown in the main thread after line 75 and in some cases even
>>     after line 86. It seems as JVMCI eats out all 8Mb of the heap.
>>         >
>>         >    75         System.gc();
>>         >    76         if ( ! Helper.checkResult("creating " + count
>>     + " objects") )
>>         >    77             return Consts.TEST_FAILED;
>>         >    78
>>         >    79         return Consts.TEST_PASSED;
>>         >    80     }
>>         >    81
>>         >    82     public static void main(String[] args) {
>>         >    83         args = nsk.share.jvmti.JVMTITest.commonInit(args);
>>         >    84
>>         >    85         int result = run(args, System.out);
>>         >    86         System.out.println(result ==
>>     Consts.TEST_PASSED ? "TEST PASSED" : "TEST FAILED");
>>         >    87         System.exit(result + Consts.JCK_STATUS_BASE);
>>         >    88     }
>>         >
>>         > Best regards,
>>         > Daniil
>>         >
>>         > On 3/22/19, 2:09 PM, "Chris Plummer"
>>     <chris.plummer at oracle.com <mailto:chris.plummer at oracle.com>> wrote:
>>         >
>>         >      Hi Daniil,
>>         >
>>         >      What triggers the JVMCI initialization, what (in
>>     general) is done during
>>         >      the initialization, and how did you come up with the
>>     10k iterations and
>>         >      a 10s sleep to ensure that initialization is complete?
>>         >
>>         >      What was the reason for the heap size increase? Does
>>     the OOME happen
>>         >      before 10k iterations if you don't increase the heap size?
>>         >
>>         >      thanks,
>>         >
>>         >      Chris
>>         >
>>         >      On 3/22/19 1:53 PM, Daniil Titov wrote:
>>         >      > Please review the change that fixes the failure of
>>     the test when running with Graal.
>>         >      >
>>         >      > The problem here is that the test consumes all memory
>>     before JVMCI runtime is fully initialized. As a result the call to
>>     JVMCIRuntime::get_HotSpotJVMCIRuntime(CHECK_EXIT)
>>         >      > at src/hotspot/share/jvmci/jvmciCompiler.cpp:132
>>     throws OutOfmemoryError that is caught by CHECK_EXIT macro that in
>>     turn calls JVMCICompiler::exit_on_pending_exception that performs
>>     vm_exit(-1).
>>         >      >
>>         >      > The fix increases the maximum heap size the test uses
>>     and adds a delay to ensure the JVMCI Runtime is fully initialized
>>     before proceeding with provoking OutOfMemoryError.
>>         >      >
>>         >      > Before the change  the test failure rate in Mach5
>>     builds was about 25% . With this change after 900 rounds in Mach5
>>     no failure was detected. The test execution time with the change
>>     is 50 second.
>>         >      >
>>         >      > Webrev:
>>     http://cr.openjdk.java.net/~dtitov/8217827/webrev.01/
>>         >      > Bug: https://bugs.openjdk.java.net/browse/JDK-8217827
>>         >      >
>>         >      > Thanks!
>>         >      > --Daniil
>>         >      >
>>         >      >
>>         >
>>         >
>>         >
>>         >
>>
>>
>>
>>
>>
>>
>>
>> -- 
>>
>> Thanks,
>> Jc
> 
>