Potential timeout issues - tests running in the same vm

Gary Adams gary.adams at oracle.com
Thu Nov 17 12:35:18 UTC 2011

On 11/17/11 6:36 AM, Chris Hegarty wrote:
> On 17/11/2011 11:22, Gary Adams wrote:
>> On 11/17/11 4:14 AM, Chris Hegarty wrote:
>>> On 17/11/2011 08:29, Alan Bateman wrote:
>>>> .....
>>>> I see Chris's mail points out that some tests do have an unusually 
>>>> small
>>>> timeout. For those tests then I would be tempted to just remove the
>>>> timeout. Most likely the original author of the test put a small 
>>>> timeout
>>>> to make it quick to test on a JDK that didn't have the fix.
>>> Right, I've seen this before ( bug in JDK that causes deadlock, set
>>> small timeout on test so doesn't block for too long before being
>>> interrupted by jtreg). But if these tests ever fail then it means we
>>> have a problem, the small timeout is just not necessary at all in a
>>> JDK that doesn't have the issue being tested for.
>>> Maybe this would be a good place to start and eliminate some of the
>>> low hanging fruit ;-)
>> It would help to know which of the quick timeouts
>> were intentional and which ones are required for
>> proper execution of the tests.
> Unfortunately, with most of these intermittent failures there is no 
> silver bullet, each test may have to be looked at individually. We've 
> been going through this process for months now :-(
> From the original list you sent out the obvious candidates for removal 
> of the timeout parameter are:
> jdk/test/java/util/logging/LoggingDeadlock.java:32: * @run 
> main/timeout=15 LoggingDeadlock
> jdk/test/java/util/logging/LoggingDeadlock2.java:31: * @run 
> main/timeout=15 LoggingDeadlock2
> jdk/test/java/util/logging/LoggingDeadlock3.java:30: * @run 
> main/timeout=80 LoggingDeadlock3
> jdk/test/java/util/logging/LoggingDeadlock4.java:30: * @run 
> main/timeout=15 LoggingDeadlock4

Can we confirm with the test author if the timeouts could be removed?
> If these tests ever encounter a java level deadlock and need to be 
> interrupted by the jtreg harness, then there is a JDK implementation 
> bug that needs to be fixed. It looks like these timeouts were added 
> when developing the original bug fix ( and test ) so the test times 
> out in a timely manner when running a JDK without the fix. This is not 
> needed for correct operation of the test itself.
> Are you seeing issues with these test when running embedded on slow 
> hardware?
I haven't had the cycles to get to the test run on embedded hardware, but
I may get to it today.
> -Chris.
>> Not all "drops" are good for "applesauce".

More information about the core-libs-dev mailing list