RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out

[Filipp Zhinkin]

Vladimir,

thank you for review.

On 07/14/2014 11:29 PM, Vladimir Kozlov wrote:
> Looks good.
>
> "is compiled":
>
> +         * Wait until InlinedArrayCloneTestCase::invokeArrayClone 
> compiled.
>
> Small notes. Keep it on one line (no need for new webrev):
>
>   63         return InlinedArrayCloneTestCase.verifyArguments(1, 2, 
> arr.clone(), 3,
>   64                 4);
>
I'll fix it.

Thanks,
Filipp.
> Thanks,
> Vladimir
>
> On 7/14/14 11:02 AM, Filipp Zhinkin wrote:
>> Here is new webrev: 
>> http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.01/
>>
>> What was done:
>> - threads count is min(100, 2 * availableProcessors) now;
>> - methods f and g were renamed to invokeArrayClone and verifyArguments.
>>
>> Thanks,
>> Filipp.
>>
>> On 07/14/2014 08:58 PM, Vladimir Kozlov wrote:
>>> On 7/14/14 8:13 AM, Filipp Zhinkin wrote:
>>>> Hi Vladimir,
>>>>
>>>> thank you for watching at it.
>>>>
>>>> On 07/11/2014 10:33 PM, Vladimir Kozlov wrote:
>>>>> 2 * availableProcessors() is still very big on Sparc machines (could
>>>>> be > 100). Do we need more threads then available
>>>>> processors for bug reproduction?
>>>> The more threads we have, the more our chances to reproduce issue.
>>>>
>>>> Issue could be reproduced when method deoptimized at particular
>>>> safepoint
>>>> and I don't see how to make this test more stable.
>>>>
>>>> I executed this test w/ jdk6u17 on different platforms w/ different
>>>> options
>>>> and here are results for three different approaches to choose threads
>>>> count:
>>>>
>>>> a) 2 * availableProcessors:
>>>> Test failed 111 times.
>>>> Test passed 57 times.
>>>>
>>>> b) 1 * availableProcessors:
>>>> Test failed 58 times.
>>>> Test passed 100 times.
>>>>
>>>> c) min(100, 2 * availableProcessors):
>>>> Test failed: 100 times.
>>>> Test passed:  68 times.
>>>
>>> I think you should use this c)
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>>
>>>> So I think we can cut off threads count by 100.
>>>>>
>>>>> Do not use one symbol f(), g() methods names. Use something like
>>>>> foo(), bar() or test1(), test2().
>>>> Sure, I'll rename it.
>>>>
>>>> Thanks,
>>>> Filipp.
>>>>>
>>>>> thanks,
>>>>> Vladimir
>>>>>
>>>>> On 7/11/14 8:24 AM, Filipp Zhinkin wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> please review fix for 6848902.
>>>>>>
>>>>>> compiler/6589834/Test_ia32.java starts 100 threads with spin-loop
>>>>>> inside
>>>>>> and on some hosts with small amount of CPU coresit takes too much
>>>>>> time.
>>>>>>
>>>>>> Also there is another issue - test intended to catch interpreter's
>>>>>> stack
>>>>>> corruption after deoptimization, but it can fail only on VM crash.
>>>>>> I've checked how it works w/ JDK 6u17 (where 6589834 was not fixed)
>>>>>> and
>>>>>> found that issue may not cause VM crash. In suchsituation test just
>>>>>> prints message "Bug!", but do not actually fail.
>>>>>>
>>>>>> I reduced amount of used threads to 2 * availableProcessors()
>>>>>> and add more asserts on test results, so now it can catch original
>>>>>> issue even if VM doesn't crash.
>>>>>>
>>>>>> Also, VerifyStackwas added to test's options as it was suggested in
>>>>>> original test.
>>>>>>
>>>>>> After all, test still can reproduce original issue w/ 6u17.
>>>>>>
>>>>>> Testing: on local machine, automated on all platforms.
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6848902
>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.00/
>>>>>>
>>>>>> Thanks,
>>>>>> Filipp.
>>>>
>>