RFR (M): 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out
Vladimir Kozlov
vladimir.kozlov at oracle.com
Mon Jul 14 16:58:00 UTC 2014
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.
>
More information about the hotspot-compiler-dev
mailing list