On 4 June 2010 11:51, Rickard Öberg <[email protected]> wrote: > Hi, > > I'm pretty much done porting Streamflow over to OSGi, but I have to admit > that the result is pretty depressing. The model itself is awesome, and I > like the abilities, but classloading in Java seems to be just broken. See > here for details: > http://www.jroller.com/rickard/entry/osgi_and_classloading > > Basically, I was not able to get class GC to be deterministic when a bundle > is updated or uninstalled.
fwiw GC (either class or object) should never be considered deterministic, there is nothing in the spec that says exactly when an object will be GC'd > Sometimes the classloader is GC'ed, sometimes not. just wondering, did you use the "refresh" command after updating bundles? updating an application in OSGi is usually a two-step process: 1) update one or more bundles 2) refresh (cf. commit updates) if you don't refresh then old bundle versions can be kept around even if it appears that no-one is using them (this behavior is defined in the spec) Heap dump analysis (using VisualVM, which is *great* if not exactly well > documented) shows that there are no hanging references (which is logical > since *sometimes* the GC works!), and yet sometimes the old classloder > simply won't be GC'ed. Depressing! > if the HotSpot JVM is not unloading the classloader even after multiple attempts at forcing GC then there must be something holding onto it, but maybe VisualVM is not detecting / reporting it I've not yet found a non-GC'able classloader that didn't have something holding onto it - although tracking down the culprit is not always trivial! > My conclusion is that it is fine to use OSGi in production, if a restart of > the VM is done on each update. For development you can dynamically update > bundles, as long as you're prepared to restart the VM every once in a while > due to OutOfMemory errors. > ditto for any Java system - a lot of third-party libraries assume that you'll be restarting the JVM when updating, and don't bother providing ways to clean up after them (especially wrt. ThreadLocals which actually have a bug in their cleanup implementation - you have to explicitly remove them when you're done as you can't rely on the JDK removing them when the ThreadLocal instance is no longer accessible, as per the spec) /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- Cheers, Stuart
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
