On 5/24/16 00:01, [email protected] wrote:
On 5/23/16 23:35, Staffan Larsen wrote:
On 23 maj 2016, at 23:39, [email protected] 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
