A live trial of the UseCompressedOops JVM argument (-XX:+UseCompressedOops) has shown to reduce the memory usage of the application by 14% and the number of garbage collections by 24%. This means reduced latency due to fewer pauses when performing a full Garbage collection, reduced load on the CPU due to fewer minor Garbage Collections, and a reduced memory requirement on the machine.
The results of this trial clearly show that this VM option should be used, though since the release of 6u23 this option is actually set on by default.
The application currently runs on the 64 bit version of the 6u21 JVM and due to the larger 64 bit memory adresses the java heap is significantly larger than when running on a 32bit JVM. Fortunately since version 6u14 there has been a JVM option, UseCompressedOops, intended to win back much of the memory lost due to the larger address space. How this is achieved is by representing the addresses on the heap in 32-bits then, when they are loaded, scaled by a factor of 8 and added to a base address to decode them to the full 64-bits. You can read a more detailed write up here;
One thing to beware of is that the maximum heap size of the JVM will be limited to 32Gb.
We set a single application server to use use compressed oops and compared its memory and GC characteristics over the following hours with a placebo without compressed oops.
Over a 1 hour period the following number of garbage collections occurred.
|Reduction||Minor GC||Full GC||Avg. Sec. Between GC|
This table shows the average memory over the hour retained in the old generation after a full GC, this is a good guide to the overall reduction in memory used by the application.