Support for ByteBuddy as an alternative to CGLIB [SPR-8190]

[spring-projects-issues]

Chris Beams opened SPR-8190 and commented

Tracking issue for CGLIB problems and possible solutions when moving to Javassist or, as recently suggested, Byte Buddy.

---

Attachments:

• permgen-leak-spring.tar.gz (492.76 kB)

Issue Links:

• Latest Spring AOP + CGLib caches classes from the same classloader causing CCE in Grails [SPR-4153] #8831 Latest Spring AOP + CGLib caches classes from the same classloader causing CCE in Grails ("depends on")
• Consider using javassist for proxy generation [SPR-5654] #10325 Consider using javassist for proxy generation ("depends on")
• @Configuration with AspectJ instead of CGLIB [SPR-7484] #12142 @Configuration with AspectJ instead of CGLIB ("depends on")
• Look at phasing out cglib with javaassist [SPR-3279] #7964 Look at phasing out cglib with javaassist ("is duplicated by")

44 votes, 45 watchers

[spring-projects-issues]

Kyrill Alyoshin commented

Is it possible to give this issue a bit for weight. CGLIB is one big disaster. It comes with an old ASM version, unmaintained, and buggy. I think Spring is the only project left that is actually using it.

[spring-projects-issues]

Chris Beams commented

@Kyrill,

It's definitely on the radar. It would be helpful to hear about exactly what pain this causes you... is it actually ASM version conflicts, for example? What else?

[spring-projects-issues]

Kyrill Alyoshin commented

ASM is huge. I have no firm evidence for it, but I also think CGLIB still leaks memory in some scenarios. Fundamentally, CGLIB prevents us from using what you, Chris, have been working so hard on: configuring Spring in Java. :-)

[spring-projects-issues]

Jason Day commented

I have issues with CGLIB leaking memory in OSGi environments where a bundle that uses CGLIB to create proxies will not let them go, even after removing the bundle. I suspect it's related to the root of #8831. The result is that the permgen space eventually runs out after multiple re-deploys of bundles that use CGLIB. Currently, it's merely an inconvenience in our development environments that requires us to occasionally restart our instances since we plan to restart production instances on every application deployment.

To reproduce the issue, create a Spring bundle with a CGLIB enhanced, for example an empty @Configuration file such as the following:

@Configuration
public class MyConfig {
  // class is enhanced by CGLIB
}

Then deploy the bundle to an OSGi environment. Each time the bundle is stopped and started again a new instance of the MyConfig class is re-created, each time enhanced by CGLIB, which gets cached. Take a thread dump and search for "MyConfig" in the heap and you'll see each CGLIB enhanced instance hanging around. This was produced with Spring 3.1.1 and CGLIB 2.2.

[spring-projects-issues]

Phil Zoio commented

Get a similar issue when using module redeploys using Impala. Any module which uses the @Transactional where the proxying is class rather than interfaces based is affected. Each time module reloading recurrs for these modules, some more perm gen space is used up, until it eventually runs out.
Ultimately, this issue strongly discourages making any hot redeploy of modules available in production environments, so it would be a real bonus to get it sorted.

Have been using Spring 3.0.6 and Cglib 2.2. Is this problem likely to have been fixed by an upgrade to Spring 3.2, and if not, how much longer should we expect for a resolution?

[spring-projects-issues]

Chris Beams commented

Phil, I'd like to make sure this is pinned down once and for all. Can you provide me with reproduction steps to get up and running with the simplest possible impala-based app that demonstrates this issue? While you're at it, please double check against 3.2. We did make some tweaks to how CGLIB caching is done there, but I cannot be sure whether it will solve your problem without looking more closely.

[spring-projects-issues]

Tim Jones commented

I am not sure how far this issue has progressed but if it helps I have created a few reproducible tests that can be run in Karaf that I think highlight the issues discussed here and in https://jira.springsource.org/browse/SPR-5654

Attached is a zip file that contains the tests and hopefully reasonable instructions on how to set up the tests. 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

[spring-projects-issues]

Tim Jones commented

Tests highlighting perm gen leaks using Karaf

[spring-projects-issues]

Chris Beams commented

Tim, thank you for the detailed report. An actual move from CGLIB to Javassist is not high on our priority list right now. Could you create a new Bug, copy your comment over as the description and attach the zip there? That is more likely to get attention in the near term.

[spring-projects-issues]

Tim Jones commented

I have created a new bug as requested https://jira.springsource.org/browse/SPR-10573

[spring-projects-issues]

Rafael Winterhalter commented

Did you ever consider moving to something else then javassist? I want to suggest Byte Buddy (http://bytebuddy.net) as an option which is a rather new library. For full disclosure, note that I am the author of this library but I still hope this posting is not conceived as too self-promotional. I wrote the library after working with cglib and javassist for quite a while and I believe that I took the best ideas out of both frameworks but replaced the bad ideas with something better. I think Spring could profit especially by Byte Buddy's retention of primitive types, the smaller-sized proxy classes and the improved support for implementing around-advice. At last, with Byte Buddy repackaging ASM correctly from day one, users would not have to deal with cglib version conflicts anymore.

Finally, note that the makers of cglib moved their project to GitHub where they however stated that the library is officially not longer under active development. (cglib/cglib#3)

[spring-projects-issues]

Juergen Hoeller commented

We intend to stick with CGLIB for the time being, picking up CGLIB 3.2 whenever it gets released (which still seems to be planned).

Juergen

[spring-projects-issues]

cemo koc commented

Spock also has just started use ByteBuddy. Mockito is using as well. It might be a good idea to revisit ByteBuddy to replace CGLIB for Spring 5.

[spring-projects-issues]

Juergen Hoeller commented

From my perspective, we're happy enough with our repackaged version of CGLIB 3.2.4 against our custom ASM fork at this point, so this isn't a high priority for us in 5.0. I'm sure ByteBuddy is a fine piece but I'm also sure we're going to have some trouble and some regressions, beyond the migration effort to begin with. Keep in mind that we are not just using CGLIB for AOP proxies but also for runtime-generated configuration subclasses and generated lookup methods, for example.

In any case, I've brought this ticket back to life, leaving it in the 5.x backlog for the time being.

[spring-projects-issues]

Rafael Winterhalter commented

I am currently helping Hibernate to migrate from Javassist to Byte Buddy after they had some issues and Spring is a big enough framework that I can offer you to try building a prototype.

Since Byte Buddy is just a class generator, it should be easy enough to switch library. In the end, only the generated code is exposed. If you wanted to, you could even mimic the "PoweredByCglib" part of the class name even though I would suggest something more meaningful such as SpringProxy or the like. Let me know if you are interested in my help, porting something from the cglib Enhancer is usually very straight forward!

Also, FYI, I still use some time maintaining cglib but the development has ended. We are only integrating critical bug fixes but we do not plan to apply any bigger extensions for future Java releases.