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

[Gary Adams]

For the vmTestbase tests recently moved to the open repos,
see test/hotspot/jtreg/vmTestbase/nsk/share/TimeoutHandler.java.
It uses a simple wrapper around a test to ensure a single test completes
within a specific time window. The vmTestbase tests were only minimally
changed so they could be run with the jtreg test harness, but were not
fully ported to rely on features in the jtreg harness itself.

     /**
      * Perform test execution in separate thread and wait for
      * thread finishes or timeout exceeds.
      */
     public void runTest(Thread testThread) {
         long millisec = waitTime * 60 * 1000;
         testThread.start();
         try {
             testThread.join(millisec);
         } catch (InterruptedException ex) {
             throw new Failure(ex);
         }
     }

For the jtreg TimeoutHandlers,
see <jtreg-src>/build/images/jtreg/doc/jtreg/usage.txt.

...
Timeout Options
                 These options control the behavior when tests run 
longer than
                 their specified timeout value.
     -th:<classname> | -timeoutHandler:<classname>
                     Specifies the class to handle timeouts. The class must
                     extend com.sun.javatest.regtest.TimeoutHandler. E.g.
                     -th:MyHandler
     -thd:<path> | -timeoutHandlerDir:<path>
                     Specifies the pathname of a directory or .jar file 
in which
                     the timeout handler class is located. The given 
pathname is
                     simply appended to the CLASSPATH used for the 
tests, thus
                     care should be taken when naming an timeout handler 
not to
                     collide with the names of classes internal to the 
JavaTest
                     harness or the JRE, e.g., put the timeout handler 
class in
                     its own named package.
     -thtimeout:<#seconds> | -timeoutHandlerTimeout:<#seconds>
                     Specifies execution time limitation for the timeout 
handler.
                     If the timeout handler does not finish its actions 
within
                     the specified period of time, it will be interrupted.
                     Non-positive values mean no limitation. The default 
value is
                     5 minutes (300 seconds).
     -timeout:<number> | -timeoutFactor:<number>
                     A scaling factor to extend the default timeout of 
all tests.
                     Typically used when running tests on slow systems 
or systems
                     with slow file systems.
     -tl:<#seconds> | -timelimit:<#seconds>
                     Do not run tests which specify a timeout longer 
than a given
                     value. The comparison is done against any values 
specified
                     in the test, before any timeout factor is applied.

Which would you prefer at this point in time :
   - increase the timeout so it can run on the slower platforms
   - problem list the test so it is bypassed completely

On 6/26/18, 1:45 AM, David Holmes wrote:
> 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
>>>>>
>>>>>
>>>>
>>>
>>