RFR: 7153107 com/sun/jdi/InterruptHangTest.java fails in nightlies

Staffan Larsen staffan.larsen at oracle.com
Tue Mar 22 18:09:12 UTC 2016


> On 22 mars 2016, at 18:15, serguei.spitsyn at oracle.com wrote:
> 
> Hi Staffan,
> 
> It looks good.
> One question though.
> 
> I do not see that the timeout is increased in the com/sun/jdi/InterruptHangTest.java.
> It remains 20 sec as was before.
> 
> +                    float timeoutFactor = Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));
> +                    long sleepSeconds = (long)(20 * timeoutFactor);
> 
> ...
> -                            Thread.sleep(20000);
> +                            Thread.sleep(sleepSeconds * 1000);
> Or an increase is because of the "test.timeout.factor" property?

Yes, the increase will be because outside systems will set the timeout factor.

/Staffan


> Thanks, Serguei On 3/22/16 07:14, Staffan Larsen wrote:
>> Anyone up for a review of this change?
>> 
>>> On 21 mars 2016, at 09:16, Staffan Larsen <staffan.larsen at oracle.com> <mailto:staffan.larsen at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> For a while we have had various timeout related problem in the JDI tests. The root cause of this seems to be the Indy String Concatenation work which makes stepping over the first string concatenation horrendously slow in debug version of the jdk. It is not ISC itself that is to blame, instead it gets the blame for the full setup of the invokedynamic framework. See JDK-8151887 for a longer discussion about this.
>>> 
>>> One of the tests that fail because of this is com/sun/jdi/InterruptHangTest.java. In this fix, I have simply increased the timeout that is used internally in the test to take the jtreg timeoutfactor into consideration. This seems to allow enough time for stepping through the indy setup code. 
>>> 
>>> I have also added timestamped logging to the TestScaffold superclass to make it easier to see what is taking a long time and how far a test has proceeded. 
>>> 
>>> webrev: http://cr.openjdk.java.net/~sla/7153107/webrev.01/ <http://cr.openjdk.java.net/~sla/7153107/webrev.01/>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-7153107 <https://bugs.openjdk.java.net/browse/JDK-7153107>
>>> 
>>> Thanks,
>>> /Staffan
>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160322/feba4ebe/attachment-0001.html>


More information about the serviceability-dev mailing list