What is the major problem with having large heap?

[YuWatanabe]

Hello .

I was reading this blog and appreciate if someone can help me out.

In the first chart , it says,

This screenshot from Marvel shows a heap that is too small: the garbage collections are barely able to free objects leaving little heap space free after each collection.

I understand that gc's are not able to free heap and won't go under 75 % .
However, I dont quite understand what the description of second chart trying to say.

This screenshot from Marvel shows a heap that is too large; the heap is almost exclusively garbage before each collection and this memory is likely better utilized by the filesystem cache.

The chart looks like there is a large consumption of heap usage periodically thus it leads to long gc which dominates the cpu usage. However, why is this sovled by setting the heap size lower ?

[Ben96 (Ben Martineau)]

That's a old document but he answer your "issue" with this :

An ordinary object pointer (or oops) is a managed pointer to an object and it has the same size as a native pointer. This means that on a 32-bit JVM an oop is 32-bits in size and on a 64-bit JVM an oop is 64-bits in size. Comparing an application that runs on a 32-bit JVM to an application that runs on a 64-bit JVM, the former will usually2 perform faster. This is because 32-bit pointers require half of the memory space compared to 64-bit pointers; this is friendlier to limited memory bandwidth, precious CPU caches, and leads to fewer garbage collection cycles as there is more room available on the heap.

Applications that run on a 32-bit JVM are limited to a maximum heap size of slightly less than 4 GB. For modern distributed server applications serving large volumes of data, this is usually too small. But there's a neat trick that can be employed: limit the heap to slightly less than 32 GB and then the JVM can get away with 35-bit oops (since 235 = 32 GB). Using thirty-five bits is not friendly to modern CPU architectures, though, so another trick is employed: keep all objects aligned on 8-byte boundaries and then we can assume the last three bits of 35-bit oops are zeros3. Now the JVM can get away with 32-bit object pointers yet still reference 32 GB of heap. These are compressed oops.

This is why, you typicaly set more than your really needs but you don't need to go overall

In my Infrastructure we got :

64GB RAM : 32GB for Heap and 32 for Swap

And now we're upgrading to 128GB for needs