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

[Igor Ignatyev]

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