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

[Filipp Zhinkin]

Igor,

thank you for review.

Here is updated webrev: 
http://cr.openjdk.java.net/~fzhinkin/6848902/webrev.02/

I've fix small issues mentioned by Vladimir and remove this test from 
needs_compact2 group.

Thanks,
Filipp.

On 07/18/2014 07:38 PM, Igor Ignatyev wrote:
> Filipp,
>
> since the test doesn't depend on 'java.rmi.RMISecurityException', you 
> can remove it from needs_compact2 group.
>
> otherwise, it looks good to me.
>
> // empty group looks like: '<group_name> = '
>
> Igor
>
> On 07/15/2014 06:58 PM, Filipp Zhinkin wrote:
>> 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.
>>>>>>
>>>>
>>