RFR 8069291: [TESTBUG] Fibonacci test: OutOfMemoryError: unable to create native thread

[Dmitry Dmitriev]

Hello David,

I ran this test in a loop 1000 times on two Arm devices and test never fail.
I ran it on armv7 trimslice with ~900 Mb of memory for Java 9 fastdebug 
b52 and on armv5 with ~500 Mb of memory for Java 8u26 fastdebug b13.

Regards,
Dmitry

On 23.02.2015 4:53, David Holmes wrote:
> On 19/02/2015 7:04 PM, Dmitry Dmitriev wrote:
>> Hello David,
>>
>> Thank you for proposal. I was think about it, but finally decided to
>> implement different fix. I leave the original thread creation logic, but
>> exclude running this test on 32 bit JVM on Windows(via "@requires" jtreg
>> tag).
>
> I'm surprised this is only an issue on Windows. I would expect our 
> smaller test devices to also struggle with this test.
>
> David
>
>> New open webrev:
>> http://cr.openjdk.java.net/~ctornqvi/webrev/8069291/webrev.01/
>> <http://cr.openjdk.java.net/%7Ectornqvi/webrev/8069291/webrev.01/>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8069291
>>
>> Regards,
>> Dmitry
>>
>> On 17.02.2015 2:24, David Holmes wrote:
>>> On 17/02/2015 7:31 AM, Dmitry Dmitriev wrote:
>>>> Hi Christian,
>>>>
>>>> With this fix the N threads will be alive at the same time for N
>>>> Fibonacci number. E.g. for 15th Fibonacci number at the same time
>>>> will be 15 threads alive. Test takes small amount of time to run,
>>>> less than a minute.
>>>>
>>>> But now I understand that for finding possible thread corruption it
>>>> will be better to keep previous logic for creation threads. But in
>>>> this case we need to limit maximum Fibonacci number for 32 bit
>>>> systems to lower value, e.g. to 13. In this case only 751 threads
>>>> will be created. For example 1973 threads are created for 15th
>>>> Fibonacci number.
>>>
>>> So the usefulness of this seems to be as a stress test - in which case
>>> scaling it back renders it less useful.
>>>
>>> I'm still inclined to treat the OOME as a transient error that may
>>> affect some systems. Have the test not fail when that occurs if you
>>> want to reduce testing noise.
>>>
>>> David
>>>
>>>> Thanks,
>>>> Dmitry
>>>>
>>>> ----- Original Message -----
>>>> From: christian.tornqvist at oracle.com
>>>> To: dmitry.dmitriev at oracle.com, hotspot-runtime-dev at openjdk.java.net
>>>> Sent: Tuesday, 17 February, 2015 12:02:44 AM GMT +03:00 Iraq
>>>> Subject: RE: RFR 8069291: [TESTBUG] Fibonacci test: OutOfMemoryError:
>>>> unable to    create native thread
>>>>
>>>> Hi Dmitry,
>>>>
>>>> How many threads will usually be alive at the same time? How long
>>>> does the test usually take to run?
>>>>
>>>> Thanks,
>>>> Christian
>>>>
>>>> -----Original Message-----
>>>> From: hotspot-runtime-dev
>>>> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of
>>>> Dmitry Dmitriev
>>>> Sent: Friday, February 13, 2015 3:12 PM
>>>> To: hotspot-runtime-dev at openjdk.java.net
>>>> Subject: RFR 8069291: [TESTBUG] Fibonacci test: OutOfMemoryError:
>>>> unable to create native thread
>>>>
>>>> Hello!
>>>>
>>>>
>>>>
>>>> Please review this fix for JDK-8069291. Unfortunately, the bug report
>>>> isn't visible outside Oracle.
>>>>
>>>>
>>>> This test calculates Fibonacci numbers "recursively" via threads and
>>>> compares the result with the classical calculation. I correct
>>>> out-of-memory error which sometimes occurred on 32 bit systems. I
>>>> changed how the recursive threads are created. Now left & right
>>>> branches creates separately and thread wait one branch to finish
>>>> before creating thread for another branch.
>>>>
>>>>
>>>> As part of the fixing the OOM issue I am moving the test to OpenJDK.
>>>>
>>>>
>>>> Open webrev:
>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8069291/webrev.00/
>>>>
>>>>
>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8069291
>>>>
>>>>
>>>> I run this test on all main platforms; Linux x64, Linux x32, Win x32,
>>>> Win x64, MacOS x64, Solaris x64, Solaris Sparc64
>>>>
>>>>
>>>> Thanks,
>>>> Dmitry
>>>>
>>>>
>>