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

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


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
>>>> 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
>>>
>>> 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 " + act_results + 
>>> " results.");
>>> ---
>>>  > +            System.err.println("INFO: There are " + act_results 
>>> + " 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