The SAP Memory Analyzer team gets asked from time to time about perm space issues and how to solve them. Unfortunately, HPROF binary heap dumps, which are the basis for the SAP Memory Analyzer, don't contain much valuable information from perm space. The only thing you get are class names and some few bits of information on the classes themselves like their inheritance hierarchy or their defining classloader, but that's mainly it.
However, there is one query that might help you: Open Query Browser (fourth button on the tool bar) -> Core -> Duplicate Classes. This lists you all classes loaded twice (more precise: all classes with the same package and class name and their corresponding class loader). What also might help (a bit) is to use grouping by class loader in the class histogram or in the dominator tree. Usually perm space problems also manifest in heap.
But if it is just about big classes, then you have a problem. You have a problem fixing it, too, because you can't do much about big classes. What we found out, though: If you use lots of generators for a model/proxy-driven approach, then you might save a lot of memory by improving the generator templates (and factor out some often repeating code) or, if this suits your use case, deploy them only once instead of with every consumer.
Last but not least, try jmap. This tool is by Sun and may help you with your problem. For us it turned out to be not precise enough as the accounting of the memory that goes to the various perm space pools is pretty poor. Another group at SAP improved jmap for the SAP JVMs. There the accounting of memory to a class is now much more useful, but as said, you have this option only if you run your application on the SAP JVM.
If you even have a heap dump from a SAP Application Server you could use some special features within the SAP Memory Analyzer, e.g. Leaking Loaders (again Open Query Browser -> SAP -> Leaking Loaders) gives you all class loaders that shouldn't be in memory anymore, but which are. We know about them because we know in our own application server where to look for the still registered class loaders. All other class loaders in heap are unregistered ones which are still hold in memory "somehow". The SAP Memory Analyzer helps you e.g. with the Paths From GC Roots query to show you this "somehow" in detail. One reason for this behavior could be a poor shutdown of the corresponding service or application. Unfortunately we can't tell that for an arbitrary heap dump, because this is application server specific.
I hope this was somehow helpful to you. Tracking down perm space issues is kind of hard with heap dumps only, but there are options worth exploring.
The SAP Memory Analyzer team gets asked from time to time about perm space issues and how to solve them. Unfortunately, HPROF binary heap dumps, which are the basis for the SAP Memory Analyzer, don't contain much valuable information from perm space. The only thing you get are class names and some few bits of information on the classes themselves like their inheritance hierarchy or their defining classloader, but that's mainly it.
However, there is one query that might help you: Open Query Browser (fourth button on the tool bar) -> Core -> Duplicate Classes. This lists you all classes loaded twice (more precise: all classes with the same package and class name and their corresponding class loader). What also might help (a bit) is to use grouping by class loader in the class histogram or in the dominator tree. Usually perm space problems also manifest in heap.
But if it is just about big classes, then you have a problem. You have a problem fixing it, too, because you can't do much about big classes. What we found out, though: If you use lots of generators for a model/proxy-driven approach, then you might save a lot of memory by improving the generator templates (and factor out some often repeating code) or, if this suits your use case, deploy them only once instead of with every consumer.
Last but not least, try jmap. This tool is by Sun and may help you with your problem. For us it turned out to be not precise enough as the accounting of the memory that goes to the various perm space pools is pretty poor. Another group at SAP improved jmap for the SAP JVMs. There the accounting of memory to a class is now much more useful, but as said, you have this option only if you run your application on the SAP JVM.
If you even have a heap dump from a SAP Application Server you could use some special features within the SAP Memory Analyzer, e.g. Leaking Loaders (again Open Query Browser -> SAP -> Leaking Loaders) gives you all class loaders that shouldn't be in memory anymore, but which are. We know about them because we know in our own application server where to look for the still registered class loaders. All other class loaders in heap are unregistered ones which are still hold in memory "somehow". The SAP Memory Analyzer helps you e.g. with the Paths From GC Roots query to show you this "somehow" in detail. One reason for this behavior could be a poor shutdown of the corresponding service or application. Unfortunately we can't tell that for an arbitrary heap dump, because this is application server specific.
I hope this was somehow helpful to you. Tracking down perm space issues is kind of hard with heap dumps only, but there are options worth exploring.