UseCompressedOops JVM标志有什么作用,什么时候应该使用它?


85

HotSpot JVM标志-XX:+UseCompressedOops有什么作用,什么时候应该使用它?在64位Java实例上使用它时(相对于未使用它),我会看到什么样的性能和内存使用差异?


1
它压缩64位指针。您会发现,由于指针大小的增加,在GC上花费的时间减少,性能可能有所下降,从而减少了内存膨胀。jdk1.6.0_22是默认情况下禁用此标志的最后一个Sun JVM。
sjr 2012年

Answers:


86

默认情况下,去年的大多数HotSpot JVM均已启用它。此选项允许引用在64位JVM中为32位,并访问接近32 GB的堆。(可以使用32位以上的指针)(您也可以拥有几乎无限的堆外内存)。这样可以节省大量内存,并有可能提高性能。

如果要使用此选项,建议您更新到默认情况下已启用的版本,因为可能有充分的理由(例如错误),为什么以前未启用它。尝试使用Java 6 Update 23或Java 7 Update 5。

简而言之,不要打开它,使用默认打开它的版本。


更新:

在Java 8中,您可以选择设置-XX:ObjectAlignmentInBytes=,实际上,如果您将堆大小设置为64 GB,它将使用-XX:ObjectAlignmentInBytes=16并且仍然使用32位引用。


我读了这篇文章:community.oracle.com/message/10019916 ,它指出我们应该始终手动使用此标志,即使默认情况下已启用它也是如此。有什么想法吗?
2014年

1
@vanval如果使用的话,建议这样做。JE cache 这是因为由于某种原因,无论是否使用compress oop ,它都无法确定。我可以想到一些可以告诉您的方法。您不需要在命令行恕我直言中指定它,除非您希望JVM在未启用的情况下失败。如您有关于Java 8中的64 GB堆
彼得Lawrey

3
我刚刚在Win8 x64 i7-4702MQ JDK 8 u40(具有7 GB xms和xmx)上运行了一些测试,从Access db加载的一棵大树使用了7 GB中的5.4 GB。我的观点是:手动指定-XX:+ UseCompressedOops标志会导致性能下降20%(生成大树时),并导致GC暂停时间延长了1个(从3到4)(使用默认GC)。您可以将其视为性能下降或GC暂停时间增加。无论哪种方式,它都慢了20%。
zmirc

1
每个应用程序都有自己的内存和使用情况配置文件。在我们的案例中,来自32位jvm的桌面应用程序+ UseCompressedOops标志节省了一天的时间,因为与32位jvm相比,它使内存使用率足够低以适合客户端的旧4gb计算机,并且性能提高了30%。
亚历克斯·伯斯
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.