4

In my application I have a PermGen out of memory error and I want to see what led to it.

I have connected to my application via VisualVM.

I want to see what exactly consumes so much PermGen memory in my application but I cannot take a special "PermGen Heap" in VisualVM. I can only take a standard HeapDump.

Is it possible to find out what exactly consumes all my PermGen memory using VIsualVM or some other tool?

UPDATE This question was marked as "duplicate" but in fact I dont see an answer to my question in the topic mentioned. The problem is that I dont see a way to list exactly what consumes memory in my permgen space.

Currently from that topic I know the following hints:

  1. Run jmap -permstat and see how much of PermGen is used by intern Strings. Good idea, it works: now I know that String Pool is not a problem in my case.

  2. Run jmap -permstat and see how the memory is consumed by the classloaders. It works, but there are hundreds of classes in AppClassLoader, this doesn't help me a lot.

  3. Run PrintStringTable.java util to see which Strings occupy memory. I cannot run it in my Windows 7 PC because I get

Attaching to process ID XXXX, please wait... Error attaching to process: Timed out while attempting to connect to debug server (please start SwDbgSrv.exe).

Whatever, its not my case.

  1. Trace the classloading in the runtime by specifying JVM properties. It works, but does not help me to understand what takes the memory away, there thousands of classes loaded.

So I cannot see an answer to my question here. I know that PermGen is consumed not only by classes themselfs, but also by their static members. How can I track which static members of which classes consume the memory?

Please let me know if I have missed this answer.

MiamiBeach
  • 3,261
  • 6
  • 28
  • 54

1 Answers1

2

VisualVM's heap dump should be enough to investigate your permgen problem - I have had to solve far too many PermGen memory leaks and VisualVM is always my starting point.

If you perform the heap dump it will include the info about permgen also - classes, classloader etc - Personally, I then use Eclipse Memory Analyser tool - just load the entire dump in and it can provide leak suspect reports, duplicate class reports etc. Generally, I just go to the duplicate classes list, right-click and select "Find GC Roots" and from there you can normally narrow in on some problems.

this might help (although not read in detail): http://java.jiderhamn.se/2011/12/11/classloader-leaks-i-how-to-find-classloader-leaks-with-eclipse-memory-analyser-mat/

This seems to be the same question/answer: How to analyze PermGen space?

As an aside, are you doing anything particular with classloading etc? Explicitly reloading or loading with classloaders? Is it just straight Java? Is it in a container etc?

Community
  • 1
  • 1
rhinds
  • 9,976
  • 13
  • 68
  • 111