[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: 8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing
From: David Holmes <david.holmes () oracle ! com>
Date: 2019-03-25 6:28:04
Message-ID: c891b371-49b6-6116-3977-b66e5b562157 () oracle ! com
[Download RAW message or body]
On 25/03/2019 3:14 pm, Chris Plummer wrote:
> Using that logic, we may at some point not be able to reliably run the
> JVMTI tests since Graal may always be present.
We can't reliably run a lot of them now with JVMCI/Graal. We either need
to modify all the affected tests, or we need to change how JVMCI/Graal
interacts with JVM TI - which is currently under discussion.
Some tests, like these resource exhaustion tests, may never be reliable
in an execution environment where the VM components can encounter the
resource exhaustion rather than the application/test code.
David
> 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@oracle.com <mailto:daniil.x.titov@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@oracle.com
>>>> <mailto:chris.plummer@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@oracle.com <mailto:chris.plummer@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
>>>
>>>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic