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

Daniel D. Daugherty daniel.daugherty at oracle.com
Wed Oct 24 14:59:05 UTC 2018

Thomas,

Thanks for the review!

Dan

On 10/24/18 10:58 AM, Thomas Stüfe wrote:

Hi Daniel,

this looks okay to me. Best Regards, Thomas On Wed, Oct 24, 2018 at 3:29 PM Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote: Ping! Looking for a second review. Would love to get this change in to reduce the frequency of metaspace/stressDictionary/StressDictionary.java failures in the jdk/jdk CI...

Dan

On 10/23/18 6:02 PM, Daniel D. Daugherty wrote: David, Thanks for the quick review! Dan P.S. I've been making progress on your comments and observations in https://bugs.openjdk.java.net/browse/JDK-8211211. Please check out my latest additions... On 10/23/18 6:00 PM, David Holmes wrote: Hi Dan,

This seems very reasonable. Thanks, David On 24/10/2018 5:20 AM, Daniel D. Daugherty wrote: On 10/23/18 11:57 AM, Daniel D. Daugherty wrote: 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 TIMEOUTFACTOR 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 Made one minor tweak to the new code: $ diff 8211211.diff.debug.txt.01 8211211.diff.debug.txt.03 20c20 < + System.out.println("INFO: There are " + actresults +_ _" results.");_ _---_ _> + System.err.println("INFO: There are " + actresults + " results."); 41c41 < + System.out.println("INFO: no tasks were cancelled.");_ _---_ _> + System.err.println("INFO: no tasks were cancelled."); 44c44 < + System.out.println("INFO: all tasks are done.");_ _---_ _> + System.err.println("INFO: all tasks are done."); During testing, the new "INFO" lines were getting lost in JTREG output truncation for System.out so I've moved the new INFO lines to System.err. Dan

More information about the hotspot-runtime-dev mailing list