RFR: JDK-8260707: java/lang/instrument/PremainClass/InheritAgent0100.java times out

Serguei Spitsyn sspitsyn at openjdk.java.net
Tue Feb 2 11:44:52 UTC 2021


On Mon, 1 Feb 2021 10:38:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> may I please have reviews for this trivial fix.
> 
> We see timeouts with this test on slow large (memory wise) AIX machines, as well as large core files.
> 
> This test is a negative test which tests that the VM corectly recognizes an error condition and aborts. Code goes through jni_FatalError()->os::abort(), writes a core and aborts the process.
> 
> No parameters are given for that VM invocation, so heap size depends on machine size. On my Linux box, the generated core takes about 500m. On AIX we see cores of 16G and more.
> 
> The difference between AIX and other platforms is that AIX does not have the notion of "committing" memory (we have no MAP_NORESERVE flag), so all mmapped memory counts toward the commit charge from the moment it is mapped. That makes core files on AIX annoyingly large. I'd expect a similar behavior on other platforms with overcommit disabled.
> 
> The fix is to run the test without CreateCoredumpOnCrash. For good measure, I also reduced the heap size to 128m.
> 
> Thanks to @ArnoZeller for figuring that one out.
> 
> 
> -----
> Tests: manual jtreg tests, verifying that no cores are written.

Hi Thomas,
The fix looks good. Thank you fixing it.
I've submitted mach5 test job with 40 runs of the java/lang/instrument/PremainClass tests.
All are passed while they were failing before.
Also, David is right, the option -XX:-CreateCoreDumpOnCrash can be removed from tests:
 test/jdk/java/lang/instrument/PremainClass/NoPremainAgent.java
 test/jdk/java/lang/instrument/PremainClass/ZeroArgPremainAgent.java
 
 But I can file a separate bug on it.
 Also, I've closed bug https://bugs.openjdk.java.net/browse/JDK-8260469 as a dup of this one.
  
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2332


More information about the serviceability-dev mailing list