Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

News March 2012

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC tuning

Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:

Training online
Threading Essentials course

Get rid of your performance problems and memory leaks!

Back to newsletter 136 contents

A long time ago, the first recommendation for initial heap size setting was that ms (starting/initial heap size) should be small, e.g. 4MB, and the mx (maximum heap size) should be big enough to avoid an out-of-memory error. This was intended to allow the heap to naturally grow to whatever it needed, then stabilize at some optimal value. Then after observing typical heap activities people started saying there was no point in having an ms different from mx, you should work out what you need and just set both to be the same, that way your application avoided any overhead in growing the heap to what it would need eventually anyway.

A note from this newsletter's sponsor

New Relic RPM - The Revolution in Java Performance Management is Here!
Affordable SaaS APM tool to monitor, troubleshoot, and tune apps
running on Websphere, Weblogic, Tomcat, Jetty, JBoss, Solr, Resin

Then came more sophisticated GC algorithms and a new suggestion, that ms should be just above the steady-state working memory requirement of the heap, while mx should be (as always) big enough to avoid the out-of-memory error that may otherwise be caused from memory requirements occasionally spiking (a rule of thumb mentioned was to start with ms at half mx, then see where your steady-state was). Some people clung to the "ms should be the same as mx" point of view regardless, saying the heap would stabilize within that anyway. Then we got ergonomic garbage collection algorithms which could vary the maximum heap size dynamically according to it's internal heuristics, and we were told that we shouldn't set ms to mx because this defeated the ergonomics.

The situation right now is that we have a proliferation of different garbage collectors and it's not at all clear whether there is any general recommendation for initial heap size compared to maximum heap size. I'm not certain myself any more. So I thought the best thing I could do is ask you - seeing as you include a majority of the very top Java performance people in the world. So, if you have any idea whether there is a current good recommendation for initial heap size, I'd love to hear it and why. Of course I'll report back next month as to whether there is any kind of consensus or interesting comments.

Now on to all our usual links to Java performance tools, news, articles, and the extracted tips from all of this month's referenced articles.

A note from this newsletter's sponsor

Free Java Performance Tool - From AppDynamics
Fight fires in production with less than 2% overhead.
Gain complete visibility into your java app. Free Download!


Java performance tuning related news.


Java performance tuning related tools.

A note from this newsletter's sponsor

ManageEngine: Application Performance Management for Java EE Apps.
Monitor App Servers: JBoss, WebSphere, WebLogic, JVMs and JMX Apps.
*** Monitor up to 25 App Servers, Databases & Servers at $795/Yr***.


Jack Shirazi

Back to newsletter 136 contents

Last Updated: 2023-09-28
Copyright © 2000-2023 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us