the free space is not shrinking evenhough the used space is shrinking at times.
I'm not quite sure what you meant by this. Is your expectation that the native memory allocated to the JVM process will shrink based on this parameter (MaxHeapFreeRatio) ? That is not how it works. The JVM asks the OS to allocate some native memory and uses it to scale the heap. It is the heap that shrinks and grows and not the native memory itself. No matter what the value for MaxHeapFreeRatio, it will not release any native memory on the OS.
From the documentation for this VM option.
-XX:MaxHeapFreeRatio=70 Maximum percentage of heap free after GC to avoid shrinking.
If you want more breathing room for other processes on the OS, reduce the size of the Xmx parameter. This also effectively reduces your overall heap size.
Depending on the circumstances, the JVM can be configured to return the native memory to the OS. See this thread, especially the link Ulf has provided there, as I was initially mistaken about that too....
Martin Vajsar wrote:Depending on the circumstances, the JVM can be configured to return the native memory to the OS. See this thread, especially the link Ulf has provided there, as I was initially mistaken about that too....
Thank you for correcting me. I did not know that the JVM releases memory back to the OS. knowledge++
Quoting stolsvik's comment from that thread
The default values are 70 and 40 respectively, which means that the JVM only
shrinks its memory use after 70% (!!!) of the heap is free, and it only shrinks
to the point that 40% of the heap is still free. A few numbers to put this
waste into perspective: If your JVM's heap grew to 300 MB, and now only
requires 100 MB, it will NOT shrink (because only 66% is free). If later
you need just 90 MB, the heap will finally shrink, but only to 150 MB (so
that 40% still remains free).
In the OP's case around 27% of the heap is used. Going by the default values of 70% / 40% the heap should have shrunk. I wonder if the value for Xms also affects the way this feature behaves. If the Xms requested is 8GB, it would go against the contract of that command line argument to reduce the heap any further than 8GB. I'd consider reducing that value to check if it helps. I have not seen any documentation to prove that the last statement will have any affect. Its just an intuition of mine.
As a side note, a large range between Xms and Xmx can lead to performance troubles since the JVM must continually allocate new space every time your application frees it and then needs it.
Deepak Bala wrote:I wonder if the value for Xms also affects the way this feature behaves.
It does. -Xms and -Xmx set hard lower and upper limits on heap size.
Joined: Jul 10, 2008
Thank you all for your responses.. I did go through all your links and experimented with smaller xms & xmx values..I will get back and post here if I find more appropriate solution for releasing the unused (heap) memory..