Could you analyze which classes need most of the space?
Can i do this analysis with Jconole or visual vm?
If we narrow it down to some classes, what are the next steps we could take?
You can dump it with jmap -dump:format=b,file=x and to analyze you might use visialvm or java profiler.
If you identify classes you might check JIRA whether you find issues, i.e. REM3-171.
If there is a solution you might pick the component with the fix and change the module. That might not work all the time as there might be API changes.
The other option is to switch to a server version where this component is included.
Okay. We will try that and find out if we can find which class takes the maximum of space
We took a heap dump for the application running. The maximum space is taken by class org.jboss.modules.ModulesClassLoader. We analyzed the heap dump using Memory Analyzer Tool. In a leaked report, it points to two suspects. How do we identify what is causing the NON-HEAP space to increase.
6,904 instances of "java.lang.ref.Finalizer", loaded by "<system class loader>" occupy 167,651,984 (36.18%) bytes.
305 instances of "org.jboss.modules.ModuleClassLoader", loaded by "sun.misc.Launcher$AppClassLoader @ 0x40001a598" occupy 36,307,664 (12.15%) bytes.
•org.jboss.modules.ModuleClassLoader @ 0x400d00f00 - 16,237,392 (5.43%) bytes.
•org.jboss.modules.ModuleClassLoader @ 0x401123010 - 9,325,864 (3.12%) bytes.
sun.misc.Launcher$AppClassLoader @ 0x40001a598
One more pattern that I observed was that there are too many sun.reflect.DelegatingClassLoaders as well. We are using JDK java 1.6.0_27-b07 along with JBOSS AS 7.1.2
Any update or any further information on this one?