[jboss-jira] [JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment

[Martin Kouba (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241430#comment-13241430 ] 

Martin Kouba edited comment on WFLY-6173 at 5/24/16 9:47 AM:
-------------------------------------------------------------

To sum it up:
* undeploy does not necessarily mean class unloading - it depends on JVM settings ({{-XX:MaxMetaspaceSize}} and friends for Java8)
* I've verified that after 50 deploy/undeploy cycles of the attached reproducer (and using {{-XX:MaxMetaspaceSize=128m}}):
** for WildFly 10.0.0.Final "java.lang.OutOfMemoryError: Metaspace" occurs
** for WildFly 10.1.0-SNAPSHOT (fix for WFLY-6347 merged) no OOM error occurs (metaspace is garbage collected)

After examining the heap dump I've identified the {{org.jboss.el.cache.BeanPropertiesCache}} as *the root cause*. In this case, it keeps a hard reference to the {{person.joey.test.TestClientBean}} class, thus effectively blocking the relevant {{ModuleClassLoader}} from GC. Enum values are treated similarly to static constants - i.e. it's not garbage collected unless the class loader of the owner class is. That's why {{person.joey.test.RequestType}} values remain in memory. OmniFaces only amplifies the impact - as mentioned above, it holds a reference to a BeanManager.

I think we can resolve/close this issue.


was (Author: mkouba):
To sum it up:
* undeploy does not necessarily means class unloading - it depends on JVM settings ({{-XX:MaxMetaspaceSize}} and friends for Java8)
* I've verified that after 50 deploy/undeploy cycles of the attached reproducer (and using {{-XX:MaxMetaspaceSize=128m}}):
** for WildFly 10.0.0.Final "java.lang.OutOfMemoryError: Metaspace" occurs
** for WildFly 10.1.0-SNAPSHOT (fix for WFLY-6347 merged) no OOM error occurs (metaspace is garbage collected)

After examining the heap dump I've identified the {{org.jboss.el.cache.BeanPropertiesCache}} as *the root cause*. In this case, it keeps a hard reference to the {{person.joey.test.TestClientBean}} class, thus effectively blocking the relevant {{ModuleClassLoader}} from GC. Enum values are treated similarly to static constants - i.e. it's not garbage collected unless the class loader of the owner class is. That's why {{person.joey.test.RequestType}} values remain in memory. OmniFaces only amplifies the impact - as mentioned above, it holds a reference to a BeanManager.

I think we can resolve this issue.

> Classes not unloaded after undeployment
> ---------------------------------------
>
>                 Key: WFLY-6173
>                 URL: https://issues.jboss.org/browse/WFLY-6173
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>            Reporter: Joey Wang
>            Assignee: Martin Kouba
>            Priority: Blocker
>             Fix For: 10.1.0.Final
>
>         Attachments: memory-leak.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. 
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)