Review request:7197210: java/lang/invoke/CallSiteTest.java failing on armsflt
Jiangli Zhou
jiangli.zhou at oracle.com
Fri Oct 26 16:52:02 PDT 2012
Hi Alan,
I tried a few experiments with the makefiles. Looks like
jdk/make/java/invoke/Makefile is not the right place to set the
-timeoutFactor option. I'm reluctant to set a large timeoutFactor in
jdk/test/Makefile. Some of the java.lang.invoke jtreg test take long
time to run. For example, the test.java.lang.invoke.MethodHandlesTest
takes about 1.5 hour to run on certain devices. Since there are only 3~4
java.lang.invoke tests have the timeout issue and each of them has very
different execution duration, I'm inclined to set each specific timeout
value for different test. Please let me know your opinion.
Thanks,
Jiangli
On 10/26/2012 10:16 AM, Jiangli Zhou wrote:
> Hi Alan,
>
> Thanks for bring up the -timeoutFactor option. I was told about the
> option but didn't go that way. Looking at the jdk/make directory now,
> there are individual Makefile under each test directory (wasn't aware
> that earlier). If we can just control the java/lang/invoke tests
> timeout factor by adding the option in jdk/make/java/invoke/Makefile,
> that seems to be a better way than changing individual test as there
> are multiple tests in the category times out.
>
> Thanks,
>
> Jiangli
>
> On 10/26/2012 01:41 AM, Alan Bateman wrote:
>> On 26/10/2012 00:14, Jiangli Zhou wrote:
>>> Hi,
>>>
>>> Please review the timeout change to
>>> test/java/lang/invoke/CallSiteTest.java. The CallSiteTest.java takes
>>> longer time to execute on certain embedded devices. It takes about
>>> 23 minutes to run on an ARM softfloat device with fastdebug binary.
>>> Using a 2000s timeout here just to be sure.
>>>
>>> http://cr.openjdk.java.net/~jiangli/7197210/webrev.00/
>>>
>>> Thanks,
>>> Jiangli
>>>
>> You might know this already but the jtreg -timeoutFactor option can
>> be used to apply a scaling factor to the timeout. This may not be
>> fine grained enough to only increase it for tests that are floating
>> point intensive but it is generally useful to use this when running
>> tests on slow machines. The downside is that it increases the overall
>> execution time when there are tests that fail due to reaching the
>> timeout (but such tests could be added to the exclude list to avoid
>> running them).
>>
>> -Alan
>
More information about the hotspot-dev
mailing list