六狼论坛

 找回密码
 立即注册

QQ登录

只需一步,快速开始

新浪微博账号登陆

只需一步,快速开始

搜索
查看: 29|回复: 0

java stack size

[复制链接]

升级  73.6%

272

主题

272

主题

272

主题

进士

Rank: 4

积分
868
 楼主| 发表于 2013-1-15 02:37:07 | 显示全部楼层 |阅读模式
摘录自 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.
 
您需要登录后才可以回帖 登录 | 立即注册 新浪微博账号登陆

本版积分规则

快速回复 返回顶部 返回列表