Stuart McCulloch wrote:
On 19/02/2008, Sahoo <[EMAIL PROTECTED]> wrote:
Our scenarios are likely to be different. In my case, the autostart
property is making the difference. I can clearly see it when I run my
test case in two configurations as described below:
Case 1. I use autostart property to install only the test bundle. In its
Activator.start(), the test bundle installs, starts, stops, and
uninstalls another bundle called foo. After foo is uninstalled, I force
gc to happen. This happens as part of Activator.start() and I see
classes from foo bundle getting garbage collected.
Case 2. I use autostart property to install both the test bundle as well
as aforementioned foo bundle. In its Activator.start(), the test bundle
stops and uninstalls foo bundle. After foo is uninstalled, I force gc to
happen. This happens as part of Activator.start(). In this case, I don't
see class from foo bundle getting garbage collected.
I later on figured out the reason for this as well. The attached patch
solves the issue.
Thanks,
Sahoo
Index: framework/src/main/java/org/apache/felix/framework/Felix.java
===================================================================
--- framework/src/main/java/org/apache/felix/framework/Felix.java
(revision 628995)
+++ framework/src/main/java/org/apache/felix/framework/Felix.java
(working copy)
@@ -1145,6 +1145,7 @@
// Always release bundle lock.
releaseBundleLock(impl);
}
+ bundles[i] = null; // help garbage collect the bundle
}
if (m_systemBundleInfo.getState() == Bundle.ACTIVE)
the "bundles" array is a local variable initialized by the "getBundles"
method,
this method just creates a new bundle array and passes it back - so when the
"setFrameworkStartLevel" method returns this local variable goes out of
scope
and is no longer reachable.
so if nulling out this array element is really having an effect on class
unloading
this suggests that one of your bundles is hanging in either the "start" or
"stop"
method, as otherwise the "setFrameworkStartLevel" method would return and
the "bundles" array would go out of scope, leaving the classes eligible for
GC.
have you tried instrumenting your bundles to verify they all start and stop
as
expected - or perhaps instrument the "setFrameworkStartLevel" method to
confirm whether it's returning or not?
You are right. I also observed that bundles is a local variable and it
would eventually get garbage collected. I was not seeing it getting
garbage collected during normal testing (probably) because there was
enough room in the heap. Later today during testing, I forced GC using
jconsole and I saw it getting garbage collected and then I did see the
classes getting unloaded as well.
Having said that, I still think setFrameworkStartLevel method is holding
a reference to a bundle for longer than it actually needs. The patch
addresses that.
Thanks,
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
