java - -d64 开关对 Sun JVM 常驻内存使用有什么影响(如果有的话)？

Question

我有一个需要一些内存调整的网络应用程序。虽然我已经对应用程序本身进行了概要分析并进行了精简，但在我们最繁忙的实例中，JVM 本身对我来说似乎过于臃肿了。 (低容量的实例没有这个问题。)详情:

• 平台:
  • RHEL4 64 位(Linux 2.6.9-78.0.5.ELsmp #1 SMP x86_64)
  • Sun Java 6(Java HotSpot(TM) 64 位服务器 VM(构建 10.0-b23，混合模式))
  • startup.sh 中带有 -d64 的 Tomcat 6>
• 我的网络应用目前有一些代码在生产中需要运行 64 位的好处。
• 我观察到一段时间后(一周)JVM 的常驻内存大小(如顶部所示)是我的 -Xmx 设置大小的三倍。
• 非堆内存大小等都是比较微不足道的，只是堆大小的个位数百分比
• 只有一段代码需要64位地址空间

如果我可以重构 64 位 JVM 的需要，并删除 -d64 开关，是否会使 JVM 的常驻内存占用空间更小？换句话说……

-d64 开关对 Sun JVM 常驻内存使用有什么影响(如果有的话)？

Answer 1

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

LP64 model与 32 位模型 (ILP32) 的不同之处在于指针恰好是 64 位宽而不是 32 位指针。对于 JVM，这允许更大的内存寻址能力，但这也意味着单独对象引用占用的大小增加了一倍。因此，在 32 位 JVM 和 64 位 JVM 中，给定时间相同数量的对象会出现更大的膨胀。

另一件经常被遗忘的事情是指令本身的大小。在 64 位 JVM 上，指令的大小将占用 native 机器寄存器大小。

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

提示:打开 UseCompressedOops 标志，使用 -XX:+UseCompressedOops 去除一些膨胀。 YMMV，但是 people have reported upto 50% drop in memory bloat by using compressed oops .

编辑

The UseCompressedOops flag is supported in version 14.0 of the Java HotSpot VM, available from Java 6 Update 14 onwards .