Rickard Oberg is popular among Java developers. He has given seminars at all main Java conferences world wide. He worked as an architect at JBoss and other popular OpenSource Java frameworks, and wrote a book on RMI. In recent years, he has become famous as an Aspect Oriented Programming (AOP) crusader. He has worked with bleeding edge AOP in a portal product that has become a great commercial success, and is currently working on Qi4j at Jayway. Rickard is a DZone MVB and is not an employee of DZone and has posted 16 posts at DZone. You can read more from them at their website. View Full User Profile

OSGi and Classloading

06.04.2010
| 6075 views |
  • submit to reddit

For the past couple of weeks I've been porting my Streamflow app to use OSGi, with Glassfish/Felix as the container. It's been going pretty well with actually running the app, but the one thing I can't get to work consistently is classloader GC. Basically, if I start a bundle with my app, and then uninstall it or update it, sometimes the old classloader with its thousands of classes will be GC'ed, sometimes not. If I do a heap dump and analyze the references there are no GC roots holding the classloader, and yet it doesn't get GC'ed. But sometimes the exact same app when uninstalled will get GC'ed. Just doing reinstall a couple of times will cause a couple of classloaders to hang around in the "permgen", while others get GC'ed.

 What to do? The conclusion seems to be that this is not Glassfish' fault, or Felix as the container, since they are really not holding any references. It seems like it's Java that is screwing it up!

I've also noticed that it is tremendously easy to screw things up in the OSGi model, when it comes to bundle uninstalling. The  main culprits I've found while doing this work are threadlocals that are not cleared and  libraries hanging on to application classloaders. Restlet, Solr and CGLIB have been the worst 3rd party offenders. I've now replaced CGLIB in Qi4j with just using ASM instead, so I have more control over the classloaders, and
that helped, but not to the point where I can get consistent classloader GC. Restlet has just added some cleanup of their threadlocals, so hopefully that will be better. For Solr I have to manually find the static fields holding classloaders and clear them using reflection. That's the kind of length you have to go to.

What to conclude from this, if I'm not missing something, is quite depressing. It means that the OSGi model as such is pretty useful, but that the dynamic classloading/unloading simply won't work consistently. I'll have to restart the whole VM to be sure that the classes are not hanging around. Quite sad.

From http://www.jroller.com/rickard/entry/osgi_and_classloading

Published at DZone with permission of Rickard Oberg, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Alessandro Santini replied on Fri, 2010/06/04 - 5:55pm

Rickard, you can easily use a non-Sun JVM and mostly get rid of the problem. To me, this is cheap rant.

Sudheer Krishna replied on Mon, 2010/06/07 - 1:46am

I have also been using OSGi( with equinox and Spring Dm for quite soem time  . I think care has to be taken to ensure that there is not classlaoder leaks happenings.

 We did face a a similar issue when we tried to laod a native library twice inside a bundle.

But with some precautions and careful monotiring i think we can get away with this problem.I did use eclipse MAT to check for any classlaoder leaks.

 Whenever there was a leak it was due to my applications issues and in one instance it was some issue wirth spring code base.

 I have never seen any inconsistences in teh classlaoder GC yet.

Michael Eric replied on Wed, 2012/09/26 - 3:46pm

You may be being bitten by the same JVM bug* we struggled mightily with for a while. It is to do with the VM internals maintaining strong references to classloaders, and is a complete pain as you can't really workaround it. We managed to reduce the amount of stuff the CLs themselves were referencing, and so keep it to minimum impact, and we figure that in production people don't recycle CLs much (far more prevalent in development and test), but if it really hurts the the guys on hotspot-dev are pretty helpful.

debian 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.