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: Classic Tuning Parameters

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

What is a "classic tuning parameter"?

This is an adjustable parameter or variable in your application that can be set to a number of different values, where some of the permissable values are more optimal for performance than others. The parameter or variable can have a defined set of discrete values, or often one of a continuous range of a values. Each different value alters the performance of the application, and the tuning procedure is to identify or come near to the optimal values by analysis of the performance variations obtained by using some subset of allowable values.

Well, that was a mouthful. Let's look at a concrete example, the JVM heap size. Ideally, you would tune the object creation within your application, and the young generation parameters and the garbage collection (GC) algorithm to avoid any old generation GCs. But often you unavoidably get old generation GC, at least for some versions of your application before you can tune the code adequately. In this situation, you may need to identify the optimal heap size. Why not just set it to "as big as possible"?

Ah, that's because the heap size is a class tuning parameter. A bigger value increases the duration of the GC pause, because the time taken for old generation GC is proportional to the size of the heap. Really big values also incur the possibility of the underlying OS paging the heap which is really really bad for performance. Smaller values mean that the GC pause is smaller, but then the GC occurs more often, and the overall time spent in GC increases, leading to a less efficient application overall. Really small values can lead to the heap thrashing, where there is only enough space to create some objects which must be immediately be reclaimed to allow more objects in; ultimately too small a value leads to an out-of-memory error.

So somewhere between too big and too small is just right (the goldilocks value), when the tradeoff between minimizing GC pause time and minimizing overall GC time is reached. That's a classic tuning parameter. You choose some values to test the performance with, analyze which values are more optimal and preferably why those values are more optimal (though that is not essential), and zero in on a more optimal value for the heap.

Classic tuning parameters are present in almost every application (the optimal buffer size, the optimal cache size, the optimal time-to-live for sessions or cache elements, etc). Algorithmic improvements can sometimes eliminate such a tuning parameter. For example, the concurrent GC algorithm runs GC concurrently with the application, so that the pause time is minimized. In this case, it is possible that the heap no longer needs to be tuned, and the biggest heap that fits into the OS without paging may be ideal in most cases.

The team

Back to newsletter 046 contents

Last Updated: 2023-08-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