JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection 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 JProfiler 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:

• The operating system monitoring tool (Windows perfmon or task manager or ps/top on Unix) which reports the memory size of the JVM process
• The Runtime.freeMemory() method which reports how much space is available for more objects to be put in the JVM heap
• Your profiler's measure of space available in the JVM heap

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 JavaPerformanceTuning.com team

Back to newsletter 043 contents