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

[Igor Ignatyev]

good, thanks for fixing this.

I'll sponsor your fix.

Igor

On 07/18/2014 07:58 PM, Filipp Zhinkin wrote:
> 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.
>>>>>>>
>>>>>
>>>
>