1 Reply Latest reply on Oct 25, 2010 12:58 PM by peterj

    stopping a war doesn't release memory?

    gregarine

      I have an instance of JBoss 4.0.5.GA running 3 wars.  When JBoss starts up it looks like it has almost 2 gig of free memory. Over 3 or 4 days that free memory is used up and JBoss locks up requiring a restart.  So I suspect a memory leak.  This weekend i watched the memory decline and when it got pretty low (200 meg) I stopped and restarted each war from the JMX console one at a time.  I thought if one of my wars had a memory leak I would see GC and the free memory would jump back up.  This is not what happened.  There was no memory recovered.  I had to restart JBoss. I do see little GCs happening occasionally but I don't understand why stopping a war would not release a chunk of memory? Xmx is 2g so is Xmx. I am running Java 1.5.0_17.

        • 1. Re: stopping a war doesn't release memory?
          peterj

          It would appear that the class loaders are hanging on to several classes/instances, which in turn are holding on to the consumed memory. After all, the GC will not free up objects that are still in use (i.e., being referenced by other objects).

           

          What you need to do is take a heap dump and see what is using up all of the space. You can use VisualVM to do this. It comes with JDK 6 as jvisualvm (and yes you can use it to diagnose an app runnign with JDK 5), or you can download it from https://visualvm.dev.java.net/download.html. Or you can set the -XX:+HeapDumpOnOutOfMemoryError JVM option, which will do as it says and then load the dump into VisualVM.

           

          Then there is also jhat and jmap, but that will work only on Linux for JDK 5.

           

          Also, when loading the heap dump, give yourself about 3x the amount of heap as what you dumped. For example, you have a 2GB heap, you will need to allocate a 6GB heap for VisualVM to analyze that heap dump, which means you will need a 64-bit JVM.