In a 32 bit there are many constraints on memory a JVM can use. The total addressable memory is just 2^32 = 4GB and then there is memory reserved for OS. Further, out of this memory available to java process, some is needed for PermGen, threads etc so the JVM can only use a much smaller memory as heapsize. See java-process-memory-jvm-heap-size for details.
Now in a 64 bit environment we do not have such constraints, since total addressable memory is more than 18 EB (2^64 = 2^4x(1024)^6 = 16 Exbibyte ~ 18x10^18 Bytes). Most of the java based enterprise applications do not need to go beyond 32 GB (besides the hardware constraints) so there is plenty of room left. However, there are some unexpected challenges. One such is increased memory usage because of expanded size of managed pointers (ordinary object pointer) so same application can take upto 1.5 times the heap on 64 bit platform after switching from a 32 bit platform.
Now managed pointers are aligned to 8byte address boundaries so managed pointers are addresses - 0, 8, 16, 24, 32, ... (ie 000000, 001000, 010000,11000,100000,...) and so on. To "compress" these pointers JVM developers used this strategy - scale down the address by a factor of 8 (ie left shift bits by 3 places) to get compressed pointers - 0, 1, 2, 3, 4,... (000,001,010,011,100,...) and so on. Using this strategy up to a 35 bits of a 64 bit address can be "compressed" into a 32 bit word (half word on 64 bit architecture).
So using a Compressed OOP we can address 2^35 objects = 32 GB of heap space. Java SE 6u23 and later 64 bit JVM uses compressed OOP by default. However going beyond 32 GB of heap size will cause JVM to switch to regular OOP with increased size so total number of objects that can be referenced actually goes down even though heap size is increased. How big is this performance drop? This blog here shows around 48 GB was required to accommodate same number of objects as a 32 GB heap (with CompressedOOPs). So basically most java applications will see performance drop between 32 GB and ~ 48 GB!
There are other issues in going to large heap sizes like Garbage collection but that is a discussion for some other time.
Also see:
Now in a 64 bit environment we do not have such constraints, since total addressable memory is more than 18 EB (2^64 = 2^4x(1024)^6 = 16 Exbibyte ~ 18x10^18 Bytes). Most of the java based enterprise applications do not need to go beyond 32 GB (besides the hardware constraints) so there is plenty of room left. However, there are some unexpected challenges. One such is increased memory usage because of expanded size of managed pointers (ordinary object pointer) so same application can take upto 1.5 times the heap on 64 bit platform after switching from a 32 bit platform.
Now managed pointers are aligned to 8byte address boundaries so managed pointers are addresses - 0, 8, 16, 24, 32, ... (ie 000000, 001000, 010000,11000,100000,...) and so on. To "compress" these pointers JVM developers used this strategy - scale down the address by a factor of 8 (ie left shift bits by 3 places) to get compressed pointers - 0, 1, 2, 3, 4,... (000,001,010,011,100,...) and so on. Using this strategy up to a 35 bits of a 64 bit address can be "compressed" into a 32 bit word (half word on 64 bit architecture).
So using a Compressed OOP we can address 2^35 objects = 32 GB of heap space. Java SE 6u23 and later 64 bit JVM uses compressed OOP by default. However going beyond 32 GB of heap size will cause JVM to switch to regular OOP with increased size so total number of objects that can be referenced actually goes down even though heap size is increased. How big is this performance drop? This blog here shows around 48 GB was required to accommodate same number of objects as a 32 GB heap (with CompressedOOPs). So basically most java applications will see performance drop between 32 GB and ~ 48 GB!
There are other issues in going to large heap sizes like Garbage collection but that is a discussion for some other time.
Also see:
- This article has a little experiment that shows how going beyond 32 GB heap affects number of objects we can fit in the heap - Why 35GB Heap is Less Than 32GB
- About Compressed OOP on java docs - Java HotSpot™ Virtual Machine Performance Enhancements
- Wiki article by John Rose (Oracle) - CompressedOops
- A very good explanation of Compressed OOP - Answer on stackoverflow
