[14]RFR: 8233453: MLVM deoptimize stress test timed out

[Rahul Raghavan]

Thank Igor, Tobias.

On 06/12/19 10:53 pm, Tobias Hartmann wrote:
> +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
>>