What is a compressed pointer:
Usually 64-bit JVM consumes up to 1.5 times more memory than 32-bit, because the object pointer is doubled in size under 64-bit architecture. For those applications that will be ported from a 32-bit platform to a 64-bit platform, the memory usage is increased by 1/2, which developers do not want to see. Fortunately, as of JDK 1.6 update14,
64 bit JVM officially supports -XX:+UseCompressedOops (requires jdk1.6.0_14) , a new parameter that can compress pointers and save memory usage.
What is OOP?
OOP = "ordinary object pointer" Ordinary object pointer. When CompressOops is enabled, the objects that will be compressed:
※The attribute pointer (static member variable) of each Class
※ Property pointer for each object
※ Each element pointer of ordinary object array
Of course, compression is not a panacea. For some special types of pointers, the JVM will not optimize them. For example, the Class object pointer to PermGen, local variables, stack elements, input parameters, return values, and NULL pointers will not be compressed.
The principle of CompressedOops:
A maximum of 4GB can be represented in 32 bits. The 64-bit address is divided into the base address + offset of the heap. When the heap memory is less than 32GB, in the compression process, the offset/8 is saved to the 32-bit address. After decompression, the 32-bit address is enlarged by 8 times, so the condition for enabling CompressedOops is that the heap memory should be within 4GB*8=32GB .
So the reason why compressed pointers can improve performance is that it compresses 64-bit pointers into 32-bits through Alignment and Offset. In other words, the performance improvement is due to the use of smaller, more space-efficient compressed pointers instead of full-length 64-bit pointers, the improved CPU cache usage, and the faster application execution.
Zero Based Compressed Oops:
Zero-base compression is a further optimization for compression and decompression actions. It further improves the efficiency of compression and decompression by changing the random address allocation characteristics of normal pointers and forcing heap addresses to be allocated from zero (requires OS support). To enable zero-base compression, the memory size you allocate to the JVM must be above 4G and below 32G. If the GC heap size is below 4G, directly cut off the upper 32 bits,
Avoid the encoding and decoding process. If GC heap size is above 4G and below 32G, enable UseCompressedOop. If the GC heap size is larger than 32G, the compression finger will fail, and the original 64-bit will be used (so the server memory is too large...) .
Applicable scene:
CompressedOops allows JVMs running on 64-bit platforms to avoid the cost of Heap capacity loss due to wider addressing. However, it is implemented by embedding compression and decompression instructions in the machine code, potentially adding additional overhead to the JVM.
refer to:
【1】https://github.com/13428282016/elasticsearch-CN/wiki/%E4%BB%80%E4%B9%88%E6%98%AFjava%E5%8E%8B%E7%BC%A9%E5%AF%B9%E8%B1%A1%E6%8C%87%E9%92%88
[2] "The Definitive Guide to Java Performance Optimization", translated by Liu Fei and Lu Minggang