RFR: JDK-8205508: hotspot/jtreg/vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java fails with Prompt is not received during 300200 milliseconds.

David Holmes david.holmes at oracle.com
Tue Jun 26 05:45:23 UTC 2018


Hi Gary,

On 26/06/2018 4:27 AM, Gary Adams wrote:
> The first time I looked into problems with exclude001 test,
> we discovered a large number of new packages in the jdk.internal
> classes that were introduced in jdk9. The test needed to add excludes for
> any of the jdk.* methods or it could not finish in time.
> 
> As a follow up I'll try a test run with unlimited time and no methods 
> excluded to get
> a specific count of methods that are being processed. Over time new 
> features
> have been added, e.g. string concatenation optimizations, lambda functions,
> etc., etc., etc. For a test that does method tracing, each new method 
> adds to the
> collective time. If you can  not reduce the number of methods called, 
> then the time
> for the test needs to be increased.

That sounds quite reasonable. I'm just wondering how the "-waittime=7" 
interacts with the jtreg timeout handling?

Thanks,
David

> ...
> 
> On 6/25/18, 2:11 PM, Chris Plummer wrote:
>> I'm also wondering how fast this test runs on other platforms and when 
>> passing on solaris-sparc. 5 minutes already seems like a long time for 
>> this test. There could be an underlying issue that needs to be addressed.
>>
>> Chris
>>
>> On 6/25/18 11:00 AM, serguei.spitsyn at oracle.com wrote:
>>> Hi Gary,
>>>
>>> It looks Okay.
>>> But I'm curious when this started failing and what triggered it to fail?
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 6/25/18 10:20, Gary Adams wrote:
>>>> The exclude001 test times out on solaris sparc debug builds.
>>>>
>>>> Basically, this test is all about tracing method calls and introduces
>>>> exclude filters to reduce the callbacks to a select set of packages.
>>>> The time spent tracing/filtering method callbacks is purely a function
>>>> of the number of methods that are processed. On this particularly slow
>>>> target platform, more time is needed before issuing a timeout.
>>>>
>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8205508
>>>>
>>>> Proposed fix:
>>>> diff --git 
>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jdb/exclude/exclude001/exclude001.javab/test/hotspot/jtreg/vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java 
>>>>
>>>> --- 
>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java
>>>> +++ 
>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java
>>>> @@ -63,7 +63,7 @@
>>>>   * nsk.jdb.exclude.exclude001.exclude001a
>>>>   * @run main/othervm PropertyResolvingWrapper 
>>>> nsk.jdb.exclude.exclude001.exclude001
>>>>   * -arch=${os.family}-${os.simpleArch}
>>>> - * -waittime=5
>>>> + * -waittime=7
>>>>   * -debugee.vmkind=java
>>>>   * -transport.address=dynamic
>>>>   * -jdb=${test.jdk}/bin/jdb
>>>>
>>>>
>>>
>>
> 


More information about the serviceability-dev mailing list