[14]RFR: 8233453: MLVM deoptimize stress test timed out
Tobias Hartmann
tobias.hartmann at oracle.com
Fri Dec 6 17:23:09 UTC 2019
+1
Best regards,
Tobias
On 06.12.19 18:12, Igor Ignatyev wrote:
> Hi Rahul,
>
> the fix sound reasonable to me.
>
> Thanks,
> Igor
>
>> On Dec 6, 2019, at 6:20 AM, Rahul Raghavan <rahul.v.raghavan at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review the following fix changeset.
>>
>> <webrev> - http://cr.openjdk.java.net/~rraghavan/8233453/webrev.00/
>>
>> # https://bugs.openjdk.java.net/browse/JDK-8233453
>> # test-[open/test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java]
>>
>> Issue is intermittent timeout failures of the test;
>> mostly with solaris-sparc and sometimes with windows-x64.
>>
>> The proposed fix here is to increase the timeout factor for the test.
>> [test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java]
>> - * @run main/othervm
>> + * @run main/othervm/timeout=300
>> .......
>> - * @run main/othervm
>> + * @run main/othervm/timeout=300
>>
>> For some timeout failure cases of the test run, logs got generated with extra thread dump info.
>> e.g.: one attached to JBS page -
>> https://bugs.openjdk.java.net/secure/attachment/85805/Test_id0--JDK13.jtr
>> But could not find any hint of blocking threads or deadlocks from the analysis of these thread dumps.
>> Also instead it seems as if the timeout factor for the test is less
>> and that test just need more time to execute.
>> Got no failures with repeat test run after above proposed fix, also supports this.
>>
>>
>> Also checking the comments, fix done for old -
>> - https://bugs.openjdk.java.net/browse/JDK-8212028
>> (Use run-test makefile framework for testing in Oracle's Mach5)
>> - http://hg.openjdk.java.net/jdk/jdk/rev/28375a1de254
>> Found that similar '/timeout=300' addition was done for some '../vmTestbase/vm/mlvm/..' tests.
>>
>>
>> It seems the intermittent timeouts for the test started with jdk-13+17, with fix changeset of -
>> https://bugs.openjdk.java.net/browse/JDK-8221393
>> ResolvedMethodTable too small for StackWalking applications
>> (could not get any timeout failure for the test with sources updated to jdk-13+16 or updated to changeset version just before 8221393 fix.)
>> Opened a separate task - JDK-8235485 - to check if this slowdown is expected.
>>
>>
>> Not getting any timeout failure, for repeat test run with above fix proposal.
>>
>>
>> Thanks,
>> Rahul
>
More information about the hotspot-compiler-dev
mailing list