java stack size

摘录自 http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=f621bd69b8b1a1425b9a88233de3?bug_id=4765019

 

 

the default stack size is 1 MB if not specified with -Xss and this result in calculation of _os_thread_limit be around 1800 (= (2GB - 200 MB ) / 1MB. After hit the limit, jvm code begins to try to reserve 20 MB first to see if there is enough virtual memory left, if not, "OutOfMemeory Error" thrown. The reserve only purpose for test, then released if reserve succeed. JVM create native Windows thread using the default stack size 0. Problem happens when on a MP machine with multiple thread creation that reserving 20 MB and commmiting stack space interlaced results in memory fragmented so finally, no single block is bigger enough than 20 MB even the total available virtual memory is far more than 20 MB.

 

 

With -Xss256K, the _os_thread_limit is about 7200. The question lands on the stack size used in calling _beginthreadex, since within the _os_thread_limit, reserve memory will not be invoked. Calling _beginthreadex even worse with specifying a stack commit size, even there is alot explaination of better not to specify stack size to create thread, a question still exists there like in attached example(C++): in this example, the stack size never grow out of 256K, but we still fail to create more threads, failed btw 1300-1700 with specifying 256K as stack size. Think it is a Microsoft bug.

 

 

Current solution is supply a XX flag(VM) upon turned on 0 as the argument passed to _beginthreadex as the commit stacksize, and meanwhile use -Xss256K to avoid triggering reserving 20 MB , and thread number can go up to 7000.