RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode

[serguei.spitsyn at oracle.com]

On 5/23/16 23:35, Staffan Larsen wrote:
>
>> On 23 maj 2016, at 23:39, serguei.spitsyn at oracle.com 
>> <mailto:serguei.spitsyn at oracle.com> wrote:
>>
>> Staffan,
>>
>> I do not see any issues, the fix looks good to me.
>
> Thanks!
>
>> One question though.
>>
>> Where does the TESTTIMEOUTFACTOR environment variable come from?
>> I do not see it used anywhere in the jtreg tests.
>
> It is set by jtreg. See: 
> http://openjdk.java.net/jtreg/tag-spec.html#testvars

Ok, I see.
It looks like it was not used in the jtreg tests.
But maybe my grep was not consistent.

Thanks,
Serguei

>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 5/23/16 02:17, Staffan Larsen wrote:
>>> This is my second attempt at fixing this timeout by taking the jtreg 
>>> timeout factor into account in the tests. The first fix [1] looked 
>>> at the wrong environment variable, and also would have caused the 
>>> test to run unnecessarily slow since it set sleep_seconds to a 
>>> higher value instead of changing the timeout.
>>>
>>> In this version I have tried to fix these problems. I now look at 
>>> the env variable TESTTIMEOUTFACTOR which will contain the jtreg 
>>> timeout factor in floating point notation. Since it is easier to 
>>> work with integers in shell scripts, I truncate this value using and 
>>> awk expression. I then use this value to set up time limits in the 
>>> two places where we have them. To simplify the code in the cmd() 
>>> function, I no longer print out stack traces after half the 
>>> timeLimit, only when the limit has expired. I think this is reasonable.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8157555
>>> webrev: http://cr.openjdk.java.net/~sla/8157555/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Esla/8157555/webrev.00/>
>>>
>>> Thanks,
>>> /Staffan
>>>
>>> [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc
>>
>

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