What does the UseCompressedOops JVM flag do and when should I use it?

Question

What does the HotSpot JVM flag -XX:+UseCompressedOops do and when should I use it? What sort of performance and memory-usage differences will I see when using it on a 64-bit Java instance (vs. not using it)?

Livre

It compresses 64-bit pointers. You will see reduced memory bloat from the increased pointer size, less time spent in GC, maybe a small dip in performance. jdk1.6.0_22 was the last Sun JVM to have this flag off by default. – Suppletion

See blog.juma.me.uk/2008/10/14/… – Im

Answer 1

Most HotSpot JVM in the last year have had it on by default. This option allows references to be 32-bit in a 64-bit JVM and access close to 32 GB of heap. (more than 32-bit pointers can) (You can have near unlimited off heap memory as well). This can save a significant amount of memory and potentially improve performance.

If you want to use this option I suggest you update to a version which has it on by default as there may have been a good reason, such as bugs, why it wasn't enabled previously. Try Java 6 update 23 or Java 7 update 5.

In short, don't turn it on, use a version which has it on by default.

---

Update:

In Java 8 you have the option to set the -XX:ObjectAlignmentInBytes= and in fact if you heap size to 64 GB it will use -XX:ObjectAlignmentInBytes=16 and still use 32-bit references.

Verla

I read this article : community.oracle.com/message/10019916 which states that we should always use this flag manually even if it is enabled by default. Any thoughts? – Engud

@Engud That is recommended if you are using JE cache This is because it can't work out whether you are using compresses oops or not for some reason. I can think of a few methods which can tell you this btw. You shouldn't need to specify it on the command line IMHO unless you want the JVM to fail if it's not enabled. e.g. you have a 64 GB heap on Java 8. – Verla

I've just run some tests on Win8 x64 i7-4702MQ JDK 8 u40 with 7 GB xms and xmx, Out of 7 GB, 5.4GB are used by a big tree loaded from an Access db. My point is: manually specifying the -XX:+UseCompressedOops flag leads to a 20% decrease in performance (when generating the big tree) and 1 more (from 3 to 4) long GC pause (with default GC). You either take it as a decrease in performance or as an increase in GC pause. Either way, it was 20% slower. – Fictionist

Each application has it own memory and usage profile. In our case, a desktop app coming from 32bits jvm, the +UseCompressedOops flag save the day, as it kept the memory usage low enough to fit on client's old 4gb machine and increased performance in 30%, when compared to 32bits jvm. – Epagoge