After analyzing thousands of GC logs uploaded by users through the GCeasy tool, the technical team found a phenomenon: there are still many Java programs that pass in JVM startup parameters -XX:+UseCompressedOops.
In fact, if the JVM version is Java SE 6 update 23 or above, you don’t need to set -XX:+UseCompressedOopsthe parameter, because it will be enabled by default.
"OOP" stands for Ordinary Object Pointer, which is a managed pointer to an object. The length of space occupied by OOP is usually the same as the native machine pointer of the host machine; that is, OOP is 64 bits on a 64-bit operating system, and 32 bits on a 32-bit operating system.
Due to the limitations of the operating system, the 32-bit version of the JVM can only have a maximum memory address space of 4GB ( 2 ^ 32bytes).
If you want to manage larger memory, you need to use 64-bit JVM.
And if the JVM uses 64-bit OOP, it can manage up to 18.5 Exabytes ( 2 ^ 64bytes).
This is a very large space. There is no server with such a large physical memory in the world today.
So here comes the question: How to use 32-bit compressed pointers to manage 32GB of memory on a 64-bit JVM?
We can notice that 4x8=32; think about it, if the memory address uses 8-byte alignment (8x8=64bit), and then maps And conversion, can it be enlarged by 8 times?
Of course, if it is handled in this way, it is not easy to operate a single byte more finely.
To understand the memory layout and alignment mechanism of the JVM, you can refer to: Analyzing how much memory space a Java object occupies
The memory space for storing pointers is doubled, and a larger memory area can be located.
But it's not "without cost".
Switching from 32-bit JVM to 64-bit JVM, you will find that the consumption of available memory will become about 1.5 times of the original, because the space consumption of storing address pointers becomes larger.
To solve this problem, JVM developers invented Compressed Oopsfunctions. For more information about compressed OOPs, please refer to: HotSpot JVM Performance Enhancements
.
To enable this feature, a JVM startup parameter can be passed -XX:+UseCompressedOops.
But starting from Java SE 6U23, the JVM will enable compressed pointers by default.
Therefore, we don't need to pass this parameter manually anymore.
- Original link: Avoid passing -XX:+UseCompressedOops
- GitHub version: No need to manually specify JVM startup parameters
-XX:+UseCompressedOops - Gitee version: No need to manually specify JVM startup parameters
-XX:+UseCompressedOops