13

I have a perm gen memory leak, that I know. Profiling using jvisualvm shows that when doing hot deployment (e.g. stop and start an application without killing the JVM, in tomcat, WebSphere, WebLogic etc) - the PermGen space is constantly increasing.

After reading, using jhat, and other advanced tools I realized that I probably have a reference to the WebAppClassLoader from a class somewhere in its parent class loaders.

I couldn't pin it down even though I did some massive JavaScript based queries on jhat

Isn't there a simple utility that finds out who is responsible for you class loader to not be garbage collected (thus allowing garbage collection of classes loaded by it)?

I tried JProfiler, jvisualvm, jhat, and a lot of Google

to all the LMGTFY friends - I've spent about a day and a half reading forums with step by steps instructions, no luck. I'm looking for a utility or code that outputs:

Object X of class Y is the sole GC root that keeps your classes from being removed.

Wes
  • 6,697
  • 6
  • 34
  • 59
Eran Medan
  • 44,555
  • 61
  • 184
  • 276
  • what information did JProfiler give you? What objects stay when you explicitely call the garbage collector? – Bozho Jan 03 '10 at 20:17
  • and how are you doing hot deployment (on tomcat) ? – Bozho Jan 03 '10 at 20:49
  • @Bozho - using Tomcat Manager, pressing stop / start. The objects that stay are the WebAppClassLoader, and all of it's loaded classes. the closest GC root hunt didn't give practical results. – Eran Medan Jan 04 '10 at 06:08
  • 1
    aha. Well, that fails for everyone, not only for you :) use it only in development – Bozho Jan 04 '10 at 06:47

4 Answers4

11

There is an unsatisfiying but easy solution: Don't hotdeploy in production environments. You could setup a cluster of two servlet containers and them update one at a time with a restart.

user242772
  • 134
  • 2
  • 1
    This is a pretty common pattern for high availability deployment architectures. – Paul Morie Jan 03 '10 at 22:25
  • So how to convince the client? Is there a white paper describing this pattern? – Eran Medan Jan 04 '10 at 06:17
  • 2
    This shouldn't be the accepted answer. I am having the same problem on a local test environment, and I'd really like to avoid restarting the Tomcat if I can. – ripper234 May 20 '10 at 13:39
  • If it's a test environment - just crank up MaxPermGen until you can do it `x` times without crashing – vikingsteve Apr 07 '14 at 11:41
  • Isn't it better to attempt to find the cause of the leak in your code? It is after all a mistake. Shouldn't I want to avoid making the same mistake in the future? Is this really the answer that would be recommended by experienced programmers? – theyuv Apr 08 '20 at 12:37
5

The realities of frequent redeployments... Best you can do is increase the size of perm gen using -XX:MaxPermSize=256m. This may buy you some redeployments more per jvm restart. Or read on at http://my.opera.com/karmazilla/blog/2007/03/15/permgen-strikes-back

Beware that if the classloaders can't be gc-ed at all, fiddling with the jvm won't help at all. You'd better forget about frequent deployments, especially in production, for dev it's handy, nevertheless.

julius
  • 815
  • 2
  • 7
  • 12
2

I used the method from this site and it helped. http://www.mkyong.com/tomcat/tomcat-javalangoutofmemoryerror-permgen-space/

Sana
  • 9,895
  • 15
  • 59
  • 87
1

Few pointers here as well, http://minmaxmim.blogspot.com/2010/01/javalangoutofmemoryerror-java-heap.html

also check the javalangoutofmemoryerror-permgen-space article.

MM.
  • 11
  • 1