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 ... 

Question of the month: What memory am I measuring?

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 043 contents

My profiler shows a different memory value than both freeMemory() and the OS monitor. What is right?

You are getting three different values for JVM memory size from three different tools:

These three tools are measuring different things, and it is instructive to know what they are measuring. The process memory, as measured by the operating system process monitoring tools, includes the object heap plus extra memory space due to the process executable, the thread runtime stack space, the thread object heap space, any space taken by the JNI and objects created from JNI, and also any other JVM spaces like PERM space which is where classes are loaded in most JVMs.

The Runtime.freeMemory() method should be accurate in providing the size of the object heap. But this measurement does not include the process executable, nor the spaces allocated from JNI nor any JVM internal structures that may need spaces (like compilation tables, etc). This method is also not guaranteed to include the thread runtime stack space nor even the per-thread heap space. It may not even include PERM space - there is no specification telling what this method must return, and in any case it would be different for different JVMs. The value reported by Runtime.freeMemory() should be smaller than the operating system process size measurement.

Running with a profiler skews all the measures because the profiler itself requires heap and also process space (in the case of JVMPI based profilers). Although the profiler should be reporting something smilar to what you would get from running Runtime.freeMemory(), the profiler should be trying to report the memory usage excluding it's own use of the various memory spaces, hence there is likely to be a discrepancy. Profilers can require large amounts of memory if you run for long or are capturing object creation and garbage collection statistics, so the memory listed by the OS and Runtime.freeMemory() can be very different from what the profiler reports.

When profiling, use the values reported by the profiler to determine where to target your tuning. When not profiling, use the Runtime.freeMemory() method or -verboses:gc to monitor the heap size. Use the OS monitor to watch the process size, and make sure it fits comforatbly into RAM.

The team

Back to newsletter 043 contents

Last Updated: 2024-03-29
Copyright © 2000-2024 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