JVM memory and Java heap space

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.

Consequences

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.

Errors

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.

Excessive footprint

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

Java-Hoster offers several Java hosting plans designed for different requirements whether on Tomcat server or on Glassfish server.

Get in touch with our Java experts to know more.

About Matthieu

Hello, I joined Java-Hoster in 2009. After my engineering studies in France, I worked for several companies including some well known Natixis , Airbus and Air France . Now I am more focused and involved on Java open-source projects and of course in Java-Hoster which makes me learn a lot and feed me as well :-D I am also responsible for this blog, so if you have something to say about it feel free to contact me. Cheers.
This entry was posted in Performance and tagged , , , , . Bookmark the permalink.

5 Responses to JVM memory and Java heap space

  1. hinanos says:

    Hi,

    I’ve deployed my Java webapp successfully on Tomcat server but then I’ve made slight changes and now when I want to deploy it again I have this odd error : OutOfMemoryError: PermGen space

    Is it related to that ?
    Cheers.

  2. Matthieu says:

    Hi Hinanos,

    correct ! This is definitely related to that point. When you unload your webapp on the Tomcat server, some classes might stay in memory due to the mechanism of the Tomcat class loader which may not be totally clean up by the garbage controller (the some classes are still in the Permanent Generation space despite the application has been undeployed). So you can have conflicts between your classes. Normally this doesn’t happen with only one deployment but only when you unload your webapp several times.
    The only solution I know to fix it is to restart the Tomcat server to ensure it is now completely empty.

  3. Andrei says:

    Hi Matthieu,

    I came across to the similar article about Java Heap Space: http://batterywalam.wordpress.com/category/j2ee-diagnostics/jvm-tuning/jvm-memory-organization/
    Here is another explanation of how objects are normally moved between memory sections… It states, that if one of the sections becomes full, live objects are copied to the subsequent bucket and so on, without reference to the object lifetime.
    Please, provide your comments regarding this note.

    Thank You,
    Andrei

  4. Tom Singh says:

    I am my JVM Max heap size = 2GB and Max Perm Gen = 0.5GB. When i monitor the Solaris servers it reports the JVM using 4.5GB. What is being used by the additional 2GB is this the Method Area?

Leave a Reply to Matthieu Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>