RFR(XS): 8212220 add code to verify results to metaspace/stressDictionary/StressDictionary.java (original) (raw)

Daniel D. Daugherty daniel.daugherty at oracle.com
Tue Oct 23 15:57:40 UTC 2018

Greetings,

The following test has been timing out intermittently in the jdk/jdk CI lately:

    vmTestbase/metaspace/stressDictionary/StressDictionary.java

Those failures are being tracked by the following bug:

    JDK-8211211 vmTestbase/metaspace/stressDictionary/StressDictionary.java timeout     https://bugs.openjdk.java.net/browse/JDK-8211211

While investigating the timeouts, I noticed that the test is not doing explicit verification of the results from the ExecutorService so I have added code to do that.

With the fix for JDK-8212028 in place, the test is timing out much more frequently in the jdk/jdk CI; the total timeout for the test went from 20 minutes down to 8 minutes. I have changed the default timeout value for the test to 5 minutes (from 2 minutes) and with the new default TIMEOUT_FACTOR of 4 (was 10), the total timeout for the test will be restored to 20 minutes.

The total timeout changes will allow the new results verification code to be used in the infrequent 20 minute timeout cases that we originally saw when JDK-8211211 was filed.

Here's the URL for the test changes:

http://cr.openjdk.java.net/~dcubed/8212220-webrev/0-for-jdk-jdk/

Here's the sub-task bug ID for the test changes:

    JDK-8212220 add code to verify results to metaspace/stressDictionary/StressDictionary.java     https://bugs.openjdk.java.net/browse/JDK-8212220

I'm currently running the revised test thru the Mach5 system:

    builds-tier1,jdk-tier1,jdk-tier2,hs-tier1,hs-tier2,hs-tier3

It's a bit of overkill, but I don't know how much of the timeout is being caused by test system load so I'm trying to replicate what is being done by the jdk/jdk CI system.

Thanks, in advance, for any comments, questions or suggestions.

Dan.

More information about the hotspot-runtime-dev mailing list