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

[Vladimir Kozlov]

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);

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