CGLIB PermGen memory leaks under Karaf [SPR-10573]

[spring-projects-issues]

Tim Jones opened SPR-10573 and commented

There appears to be an issue with the use of CGLIB and permgen class loader leaks. Attached is a zip file containing some tests that can be run in a Karaf container that highlight this issue. I have also added a few observations of my own.

In summary I have set up 2 bundles, with one bundle exporting a transaction manager and the other bundle referencing the transaction manager with a class that has been transactionally advised via a @Transactional annotation.

The tests are further divided with one group dependent on Spring 3.1.4 and the second group dependent on Spring 3.2.2. Within these two groups there are two referencing bundles, one that is coded against interfaces (=> JDK proxy) and the other without interfaces (=> CGLIB).

Both the Spring 3.1.4 and Spring 3.2.2 test bundles that use interfaces seem to be fine, i.e. the referencing bundle can be loaded and unloaded many times without resulting in a OutOfMemoryError: PermGen space error. I was able to verify using JVisualVM that the classes are collected although there seems to be a difference as to when they are collected (details of which are in the readme of the zip).

Both the Spring 3.1.4 and Spring 3.2.2 test bundles that do not use interfaces and hence CGLIB comes into play ultimately fail with a OutOfMemoryError: PermGen space error. I was able to verify using JVisualVM that the classes are not collected and that after uninstalling the referencing bundle that instances of the test classes still remain.

It is possible that the tests could be simplified further, perhaps one bundle rather than two would suffice but I think separating the transaction manager is more realistic.

I realise that class loader permgen leaks are an old well trodden issue that came to the forefront when undeploying web apps but because OSGI permits breaking an application down into fine grained modules I think this issue will become even more apparent as the promise of undeploying/stopping/starting parts of an application becomes a significant driver for the adoption of OSGI.

I hope this helps.

Regards,

Tim

---

Affects: 3.2.2

Reference URL: https://jira.springsource.org/browse/SPR-8190

Attachments:

• permgen-leak-spring.tar.gz (492.76 kB)
• Screen Shot 2013-06-03 at 11.37.44 AM.png (177.43 kB)

Issue Links:

• Upgrade to CGLIB 3.2.2 [SPR-13934] #18506 Upgrade to CGLIB 3.2.2

1 votes, 7 watchers

[spring-projects-issues]

Juergen Hoeller commented

Let's mark this as "Won't Fix" from a Spring Framework perspective since there is nothing we intend to do as a follow-up in the core framework here...

Juergen

[spring-projects-issues]

Tim Jones commented

I had raised the issue here as I thought the Spring Framework had repackaged CGLIB internally http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/migration-3.2.html. Admittedly if this is the case and the prime motive for packaging CGLIB was to ensure no classpath conflicts with other third party frameworks then I can understand your reluctance to spend time fixing what you would probably argue is an issue with CGLIB not the Spring Framework. However from an end user's point of view we receive 'Spring code' that is packaged with a known issue.

Although I have provided a reproducible test based on OSGI which may or may not be something that fits the strategic Spring direction, the same issue will be felt by undeploying/deploying on Web servers or other (a search on google will highlight many instances of CGLIB as the cause of permgen leaks).

Perhaps the Spring team could keep in mind to look at permgen leaks if migration to an alternative e.g. Objenesis is looked at?