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