-d64交换机对Sun JVM驻留内存使用有何影响?

Stu*_*son 11 java performance 64-bit jvm sun

我有这个需要一些内存调整的webapp.虽然我已经在分析应用程序本身并削减了一些东西,但JVM本身在我们最繁忙的实例上看起来过于臃肿.(较低的卷实例没有此问题.)详细信息:

  • 平台:
    • RHEL4 64位(Linux 2.6.9-78.0.5.ELsmp #1 SMP x86_64)
    • Sun Java 6(Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode))
    • Tomcat 6 -d64startup.sh
  • 我的webapp目前有一些代码,在生产中需要运行64位的好处.
  • 我观察到经过一段时间(一周)后,JVM驻留内存大小(如上图所示)是我-Xmx设置大小的三倍.
  • 非堆内存大小等都是相对微不足道的,只是堆大小的一位数百分比
  • 只有一段代码需要64位的地址空间

如果我可以重构64位JVM的需要,并放弃-d64交换机,那会不会使JVM的常驻内存占用更小?换一种说法...

-d64交换机对Sun JVM驻留内存使用有何影响(如果有)?

Vin*_*lds 18

使用d64开关可使JVM进入64位模式.从技术上讲,在Solaris/Linux和大多数Unix上,JVM进程将在LP64模型中执行.

LP64模型是从32位模型(ILP32)中的指针碰巧是64位宽的,而不是32位指针的不同.对于JVM,这允许更大的内存寻址能力,但它也意味着单独的对象引用占用的大小增加了一倍.因此,在32位JVM和64位JVM中,给定时间内相同数量的对象会有更大的膨胀.

经常被遗忘的另一件事是指令本身的大小.在64位JVM上,指令的大小将占用本机计算机寄存器大小.

但是,如果在64位环境中使用压缩对象指针,则JVM将尽可能对堆大小超过4 GB的指针进行编码和解码.简而言之,当您使用压缩指针时,JVM会尝试尽可能多地使用32位宽的值.

提示:打开UseCompressedOops标志,使用-XX:+ UseCompressedOops来消除一些膨胀.YMMV,但人们已经报告使用压缩oops导致内存膨胀下降高达50%.

编辑

Java HotSpot VM 14.0版支持UseCompressedOops标志,从Java 6 Update 14开始提供.

  • 关于UseCompressedOops标志:"Java SE 6u23及更高版本中默认支持并启用压缩oops.在Java SE 7中,当未指定-Xmx时,使用压缩oops是64位JVM进程的默认值,并且对于值-Xmx小于32千兆字节.对于6u23版本之前的JDK 6,使用-XX:+ UseCompressedOops标志和java命令来启用该功能." http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html (4认同)