8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing
Chris Plummer
chris.plummer at oracle.com
Mon Mar 25 05:14:34 UTC 2019
Using that logic, we may at some point not be able to reliably run the
JVMTI tests since Graal may always be present.
Chris
On 3/24/19 5:49 PM, David Holmes wrote:
> +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
>>
>>
More information about the serviceability-dev
mailing list