One of the major benefits of the Java language in comparison with other object oriented languages (like C++) is that programmers do not have to handle memory allocation during execution of the program. It is totally delegated to the garbage collector (GC) which is in charge of removing unused objects to release memory.
On the bright side, it allows developers to not consider this topics when writing applications. On the other side, tuning the Java environment has become a major issue when it comes to enhance performance of the application. But even beside this, as a Java developer you’ve surely face a kind of “OutOfMemoryError”, don’t you ?
In this paper I will explain how the Java language intents to manage memory through the JVM (in this case the HotSpot VM which is the VM developed by Sun but most things apply also to other JVM).
JVM memory organisation
The memory of the JVM is first slitted into 2 parts :
– the heap memory
– the non heap memory
The heap memory
The heap contains all Objects created during execution, this space should be frequently visited by the GC in order to clean up unused objects (=objects not referenced anymore). It is also slitted into different section according to the lifetime of the objects. Initially all objects are stored into the Eden section. Most of this objects will then be destroyed at the next GC visit because they are not used anymore. But some of them need to be kept because they have a longer lifetime and they will be used in the future. Therefore they are moved into the Survivor bucket. In the Survivor bucket GC calls are less frequent than in the Eden bucket. This two buckets represent the Young generationand contains all the “newly created” objects.
If objects stored in Survivor buckets, survive to other GC visits they are then moved into the Tenured generation (or Old generation) bucket until they are destroyed by the Garbage Collector.
The non heap memory
Beside the heap memory containing the living data, the JVM needs additional information, especially classes descriptions or metadata. All this stuff is stored in a dedicated area named Permanent generation.
Bad tuning of the JVM can lead to several issues. The most obvious is that you set memory parameters too low to run your application so it cannot even start. But there are others.
If your memory parameters are too low you will probably have to tackle OutOfMemoryError since your application requires more space than what you allocated.
Non optimal performance
If your memory parameters are too low you will decrease the performance of the application. Indeed, the GC has to run very often in order to maintain the available space, which requires some time and also needs to stop the application.
On the other hand, allocating a huge memory to the JVM is also a bad practice because you will use (consume) much more than what you need and also because other resources won’t be able to use this unused space : OS, database, …. Therefore this may lead to non optimal performance as well.
Fixing memory errors
As a consequence, when the size of the data to be stored is bigger than the available size an error is raised by the JVM : OutOfMemoryError. Then you have two kinds of such errors :
– OutOfMemoryError: PermGen space, indicating the PermGen space (non heap memory) has to be increased because too many additionnal data are required by the JVM
– OutOfMemoryError: Java heap size, the heap memory is too low to create an store the living objects
To fix this you must tune your JVM, for instance saying as arguments : -Xmx128m to allocate a maximum amount of the heap size of 128mo or by setting -XX:MaxPermSize=128m to assign this value to the PermGen space.
Choosing the best Java hosting plan at Java-Hoster
As you’ve seen, designing correctly your JVM for your Java hosting is critical :
– to make the applications work
– to get the best performance level
Get in touch with our Java experts to know more.