Java 32位和64位优化模式(-XX:-UseCompressedOops)内存开销 [英] Java 32bit vs 64bit optimization mode (-XX:-UseCompressedOops) memory overhead

问题描述

当我在配置为使用超过32GB内存的JVM中运行Java应用程序时，我试图预测堆内存需求的变化.

I'm trying to predict the heap memory requirements change for the case when I run my Java application unchanged in a JVM configured to use more than 32GB of memory.

我希望将Xmx参数从32GB重新配置为64GB之后，对于我保留在内存中的相同数量的有用"对象，将会有大量的内存开销.

I expect that there will be significant memory overhead for the same amount of "useful" objects I keep in memory just after reconfiguring the Xmx parameter from 32GB to 64GB.

我试图通过在运行有小堆(8GB)的本地计算机上应用-XX:-UserCompressedOps来模拟和估算差异，但是还不能得出结论. 根据运行时计算，两种情况下我的对象占用相同的内存量.带有关闭优化功能的堆通常要多一些，但绝不会多出两倍，因为我可以期望阅读一些解释.

I've tried to simulate and estimate the difference by applying the -XX:-UserCompressedOps on my local machine running with small heap (8GB) but could not come to the conclusion yet. According to runtime calculations my objects take same amount of memory in both cases. The used heap with switched off optimization tend to be a bit more but in no way twice more as I could expect reading some explanations.

在我的用例中，我只是在程序的整个生命周期中将大量相对较大的POJO对象(每个100-1K)保留在堆中.

In my use case I simply keep a large amount of relatively big POJO objects 100-1K each in heap for the entire life time of the program.

是否有一个经验法则，仅通过超过32GB的限制(当32位优化不再适用时)，内存需求将如何增长?

Is there a rule of thumb for how the memory requirements grow just by crossing the 32GB limit (when 32bit optimizations do not apply any more)?

推荐答案

但绝不会再重复两次，因为我可以期待阅读一些解释.

but in no way twice more as I could expect reading some explanations.

我的理解是，禁用CompressedOops只会使指针大小(引用类型)加倍，而不会与原始类型加倍，尤其是字符串，字节数组等不会. 因此，如果您的堆由原始类型的数组控制，那么增加可能很难注意到.

My understanding is that disabling CompressedOops would only double pointer sizes (reference types) and not primitive types, especially not Strings, bytes arrays and the like. So if your heap is dominated by arrays of primitive types then the increase might be difficult to notice.

对齐要求也使大小差异不那么直接，因为较大的指针可能最终只会填充一些对齐填充.

Alignment requirements also makes the size differences not as straight-forward because the larger pointers might simply end up filling some alignment padding.

这篇关于Java 32位和64位优化模式(-XX:-UseCompressedOops)内存开销的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！