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

[Filipp Zhinkin]

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.
>>