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

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Tue May 24 07:06:44 UTC 2016


On 5/24/16 00:01, serguei.spitsyn at oracle.com wrote:
> On 5/23/16 23:35, Staffan Larsen wrote:
>>
>>> On 23 maj 2016, at 23:39, 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.

Probably, it is used in the property form: " |test.timeout.factor".


Thanks,
Serguei
|
>
> 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/c6a5170c/attachment-0001.html>


More information about the serviceability-dev mailing list