The -XX:-UseCompressedOops flag disables the use of compressed object pointers. It is only available or relevant on 64-bit JVMs.
A 64-bit CPU is capable of addressing a theoretical maximum of 16 exabytes of
RAM (2 to the power 64 bytes) when storing each memory address as a 64-bit
number. However in applications that do not need to use very large amounts of
memory, the Compressed Pointers feature allows memory addressed to be stored
as 32-bit numbers, which improves performance and reduces memory usage.
Note that a 32-bit variable can have 4,294,967,296 distinct values, suggesting
that only 4 GB of RAM would be addressable by a 32-bit pointer. However
objects in the Java heap are spaced at intervals of at least 8 bytes (though this
can be modified with the -XX:ObjectAlignmentInBytes). Therefore a 32-bit
pointer can actually address up to 32 GB of heap space, i.e. 8 × 4 GB. However
it is impossible to address more than 4,294,967,296 distinct Java objects with
The -XX:-UseCompressedOops flag turns off the compressed pointers feature.
There is little reason ever to do this except if it is suspected to be the cause of a
bug or JVM crash.
The -XX:+UseCompressedOops flag re-enables the use of Compressed Pointers.
Where both -XX:-CompressedPointers and -XX:+UseCompressedOops have
been used on a command line, the last one takes precedence.
Compressed Pointers are enabled by default on Java 1.7 and above when the
maximum heap size (as specified by -Xmx) does not exceed 32 GB.
Arguments Related to -XX:-CompressedOops:
• TODO: link to -Xmx
• TODO: link to -XX:-UseCompressedClassPointers
• TODO: link to -XX:ObjectAlignmentInBytes
• Compressed OOPs in the JVM
If you have additional comments, interesting experiences or even point of disagreement with this JVM argument description, please leave a comment. Your
insights will help the entire 10+ million java developer community to develop
one standard source of documentation for all the JVM arguments.