[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing
From:       Chris Plummer <chris.plummer () oracle ! com>
Date:       2019-03-22 21:08:50
Message-ID: a2f3384c-fa0e-25b4-a192-42f9c5f302c2 () oracle ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]