On 2010-06-04 16.14, Stuart McCulloch wrote:
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
I know. But sometimes when I press "Perform GC" through VisualVM, which
I have connected to Glassfish, it will actually be GC'ed. And sometimes,
no matter how many times I click, the classloader just stays there.
Sometimes the classloader is GC'ed, sometimes not.
just wondering, did you use the "refresh" command after updating bundles?
Yes, I do refresh after each update.I noticed that if I don't, then
Felix will have a reference to it in the "uninstalled bundles" list.
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
That is possible, but what I don't get is that the *exact* same bundle
which I just start and then immediately stop, will *sometimes* be GC'ed
(through forced GC) and sometimes not. And VisualVM, when I look at
active instances in a heap dump, says that none of the instances of the
classes have GC roots. How is that possible!?
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!
If you have any tricks to suggest, I'm all ears. I've been chasing
threadlocals, classloaders and static class fields for weeks now, and
managed to get it down to at least being random (as opposed to "never
working").
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
I've noticed that a lot during the past couple of weeks. But still,
after having chased down every static reference, and after having at
least gotten to the point where the behaviour is random (as opposed to
never working before I did the cleanup), it is a bit distressing...
(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)
Yes, I've had to manually clean up a lot of threadlocals in other
libraries, Restlet specifically (which don't have a single threadlocal
clear call).
It's hard to be really enthusiastic about OSGi since it is indeed very
cool but also very easy to screw up.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
