bat*_*man 25 java performance jvm
在这里读这本书的时候.
我可以看到以下部分,其中说:
32或64位?如果您有32位操作系统,则必须使用32位版本的JVM.如果您有64位操作系统,则可以选择使用32位或64位版本的Java.不要以为仅仅因为您拥有64位操作系统,您还必须使用64位版本的Java.
如果堆的大小小于约3 GB,则32位版本的Java将更快并且占用空间更小.这是因为JVM中的内存引用只有32位,操作这些内存引用比操作64位引用要便宜(即使你有64位CPU).32位引用也使用较少的内存.
第8章讨论了压缩oops,这是JVM甚至可以在64位JVM中使用32位地址的一种方式.但是,即使进行了这种优化,64位JVM的占用空间也会更大,因为它使用的本机代码仍然具有64位地址.
32位JVM的缺点是总进程大小必须小于4GB(在某些版本的Windows上为3GB,在某些旧版本的Linux上为3.5GB).这包括堆,permgen以及JVM使用的本机代码和本机内存.在32位JVM上广泛使用长变量或双变量的程序会更慢,因为它们不能使用CPU的64位寄存器,尽管这是一种非常特殊的情况.
适合32位地址空间的程序在32位JVM中的运行速度比类似配置的64位JVM快5%到20%.例如,本章前面讨论的库存批处理程序在桌面上运行32位JVM时速度提高了20%.
这些行说明,对于较小的堆大小(小于3GB),32位会更快.如果这是真的,我想知道它背后的原因,是什么让32位JVM更快?
我对作者声称使用32位版本的JVM会使性能提高5%到20%持怀疑态度.但是,我不太使用Java,所以我不确定.但为了调查这一说法,我查看了SPEC的一些结果.
我搜索了SPECjEnterprise2010的结果,x86-64架构的最高分是一个使用64位版本JVM的Oracle系统.
我还查看了SPECjvm2008,以防这些较小的工作负载可能受益于32位架构.但同样来自华为的最佳性能x86-64系统使用的是64位版本的JVM.
如果32位版本的JVM确实更好,我希望人们提交他们的SPEC结果会在调整他们的工作负载时选择(但我可能是错的).
我不怀疑有一些工作负载,其中32位版本的JVM将胜过64位版本.正如其他人已经注意到它为地址使用更多内存.但是,x86-64架构有更多可用的寄存器,我怀疑64位操作模式是大多数优化工作的重点.
系统性能有很多组件,我认为32位版本的JVM不一定会胜过64位版本(对于这一点,这只会对CPU绑定工作负载产生影响).我要说如果你在性能调优过程中达到这一点,你会想要检查自己的工作负载以获得两个不同的选项,并使用你自己的测试结果做出决定而不是假设使用32 -bit优于64位,因为根据经验节省了地址的内存空间,因为还有其他因素可能比这更重要.
这更多是一般表现的问题.如果你有一个最近的64位处理器和大量未使用的内存,使用JVM 32而不是JVM 64的唯一可能的增益是一些循环可以完全适合具有32位地址的高速缓存而不是64位那些导致较少的主存储器使用32位JVM访问.我真的无法评估增益,但除非在非常特殊的情况下我怀疑它达到5%到20% - 注意我只是怀疑,不确定......
但是,如果您使用的是资源有限的系统,最终因为您希望优化硬件并在其上运行许多虚拟机,32位JVM将使用远远少于64位的内存.它将为其他应用程序和系统留下更多可用内存,从而避免交换并允许系统更好地缓存磁盘IO.
恕我直言,没有一般规则.我只会使用以下经验法则:如果JVM 和所有其他应用程序运行时,系统仍有足够的内存用于缓存IO,我会使用64位JVM,而相反的情况下使用32位JVM.
当然,只有Java应用程序本身不需要大量使用64位JVM的内存 - 并且最终在必要时向系统添加更多内存时才有意义,因为现在内存不是那么昂贵
| 归档时间: |
|
| 查看次数: |
3908 次 |
| 最近记录: |