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

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