JVM的内存限制(JVM maximum heap size)
IT瘾
关于互联网、软件开发的网页收藏、分享、发现
订阅 
最新文章
Log me in using 
I've gathered some excerpts from over the net about the heap size limitations on 32-bit/64-bit architectured hardwares. It seems that the topic has some tricks rather than configuring heap with -Xms & -Xmx.
What could be the maximum heap size in a 32-bit environment?
'The maximum theoretical heap limit for the 32-bit JVM is 4G. Additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower. On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems.'
What's with the OS'es while dealing with the heap? Different behaviours?
'Windows provides each application with its own 32-bit (4GB) address space. The lower 2GB is 'local' to the application, the upper 2GB contains (read-only) windows code which is shared by all applications.'
(But the local segment, our heap, gets smaller & smaller...)
'The java JRE also uses DLLs to interact with windows, drivers and other applications on your system. Now those DLLs are loaded (mapped) in the 2GB 'local' address space of the JRE. Now you can imagine that loading those DLLs in the empty 2GB 'local' address space divides up the remaining space. This means the largest possible contiguous single block of memory only gets smaller as more and more DLLs are being used by the JRE and your application.'
(Maybe Solaris is the key :) )
'And for Solaris, it actually allows just over 3 GB for heap size. The problem is how much of the address space is reserved for the OS. On most OSes this is 2 GB (half the address space) but on Solaris this is 512 MB'
(Or Linux...)
'In newer kernels it is possible to use a 4G/4G mapping, which allows up to 4G RAM to be allocated to a single process. The only distribution I know of that enables this mapping is Fedora Core 2, although it is a planned feature for RedHat Enterprise Linux 4.0 as well.'
The problem with the JVM's stated as continugous heap size problem. The local segment gets smaller & smaller by the dll's used by jre.
64-bit is the saviour?
'The benchmark is done using the Jikes Research VM as well as the IBM JDK 1.4.0 production VM on a PowerPC-based IBM machine. We conclude that the space an object takes in the heap in 64-bit mode is 39.3% larger on average than in 32-bit mode.
We identify three reasons for this:
(i) the larger pointer size,
(ii) the increased header
(iii) the increased alignment.
The minimally required heap size is 51.1% larger on average in 64-bit than in 32-bit mode. In addition, we observe that when a sufficiently large heap is available, the IBM JDK 1.4.0 VM is 1.7% slower on average in 64-bit mode than in 32-bit mode.'
If a heap under 4gigs could suffice your needs, it'd be best to stick with the 32-bit architecture & JVM 'cause it's faster & reasonable to use it instead of 64-bit machines & JVMs.