> >> > Hi, > >> > > >> > I am a bit surprised to see that classes are not getting unloaded when > I > >> > uninstall my bundle. In my program, I try to force the GC by calling > >> > Runtime.gc() a couple of times. Looking at the gc log, I do see "Full > >> > GC" happening. I am using -verbose:gc option to see class unloading > >> > details. If I run the same program using some other implementation, I > >> > see classes are getting unloaded. I have verified the same using > >> > jconsole as well. Am I missing any flag? Is it a known issue? > >> > >> > >> I just tried a very simple bundle with trunk and see classes unloaded: > >> ( note - I customized shell.tui to force a couple of GCs per command ) > >> > >> ========================================================== > >> -> ps > >> START LEVEL 1 > >> ID State Level Name > >> [Loaded java.util.TreeMap$3 from > >> /home/stuart/Tools/j2sdk1.4.2_15/jre/lib/rt.jar] > >> [ 0] [Active ] [ 0] System Bundle (1.1.0.SNAPSHOT) > >> [ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.0) > >> [ 2] [Active ] [ 1] Apache Felix Shell TUI (1.1.0.SNAPSHOT) > >> [ 3] [Active ] [ 1] Apache Felix Bundle Repository > (1.1.0.SNAPSHOT) > >> -> ps > >> START LEVEL 1 > >> ID State Level Name > >> [ 0] [Active ] [ 0] System Bundle (1.1.0.SNAPSHOT) > >> [ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.0) > >> [ 2] [Active ] [ 1] Apache Felix Shell TUI (1.1.0.SNAPSHOT) > >> [ 3] [Active ] [ 1] Apache Felix Bundle Repository > (1.1.0.SNAPSHOT) > >> -> install file:/tmp/foo.jar > >> Bundle ID: 4 > >> -> ps > >> START LEVEL 1 > >> ID State Level Name > >> [ 0] [Active ] [ 0] System Bundle (1.1.0.SNAPSHOT) > >> [ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.0) > >> [ 2] [Active ] [ 1] Apache Felix Shell TUI (1.1.0.SNAPSHOT) > >> [ 3] [Active ] [ 1] Apache Felix Bundle Repository > (1.1.0.SNAPSHOT) > >> [ 4] [Installed ] [ 1] foo (1.0.0.SNAPSHOT) > >> -> start 4 > >> DEBUG: WIRE: 4.0 -> foo -> 4.0 > >> DEBUG: WIRE: 4.0 -> org.osgi.framework -> 0 > >> [Loaded foo.internal.ExampleActivator] > >> STARTING foo > >> REGISTER foo.ExampleService > >> [Loaded foo.ExampleService] > >> [Loaded foo.internal.ExampleServiceImpl] > >> -> ps > >> START LEVEL 1 > >> ID State Level Name > >> [ 0] [Active ] [ 0] System Bundle (1.1.0.SNAPSHOT) > >> [ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.0) > >> [ 2] [Active ] [ 1] Apache Felix Shell TUI (1.1.0.SNAPSHOT) > >> [ 3] [Active ] [ 1] Apache Felix Bundle Repository > (1.1.0.SNAPSHOT) > >> [ 4] [Active ] [ 1] foo (1.0.0.SNAPSHOT) > >> -> uninstall 4 > >> STOPPING foo > >> [Loaded org.apache.felix.framework.Felix$RefreshHelper] > >> [Unloading class foo.internal.ExampleServiceImpl] > >> [Unloading class foo.ExampleService] > >> [Unloading class foo.internal.ExampleActivator] > >> -> ps > >> START LEVEL 1 > >> ID State Level Name > >> [ 0] [Active ] [ 0] System Bundle (1.1.0.SNAPSHOT) > >> [ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.0) > >> [ 2] [Active ] [ 1] Apache Felix Shell TUI (1.1.0.SNAPSHOT) > >> [ 3] [Active ] [ 1] Apache Felix Bundle Repository > (1.1.0.SNAPSHOT) > >> -> > >> ========================================================== > >> > >> the foo bundle installs a simple service with the OSGi framework. > >> > >> if you can provide a simplified testcase that shows a bundle not > >> unloading, please open a JIRA issue and attach the files needed > >> to recreate it so we can investigate. > >> > >> ( diagnosing the issue is much faster when we have a testcase ) > >> > >> alternatively, if you want to diagnose it yourself, I'd suggest using > >> a heap profiling tool to find out what's holding on to your application > >> classes - and see what's different between other frameworks. > >> > >> HTH > >> > >> > >> > >> Thanks, > >> > Sahoo > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> -- > >> Cheers, Stuart > >> > > > > > > Furthermore, If you uninstall a bundle that has a used export you > > while have to refresh before the classes can get unloaded. > > > > regards, > > > > Karl > > > I shall look closely at my test case, but I am a bit surprised, because > if the test were incorrect, how was I seeing classes being gced while > using other implementations? > This is the basic flow of my test case: > 1. I start the framework from a Java class. > 2. I have listed a bunch of bundle names in the autostart property, so > framework installs and starts them automatically. > 3. The last bundle (I call it the test bundle) is a special one, which > when starts, stops all the other bundles except itself and the framework > bundle. The test bundle does not depend on any of the other bundles. I > do see bundles getting uninstalled. The framework should not depend on > any any of these bundles, right? > 4. If I understand correctly, when a bundle is uninstalled, its exported > packages are eligible for gc if there is no other bundle which uses the > bundle (section 4.3.11 of r4 spec). To ensure that I take care of > dependencies among bundles, I stop the bundles in the reverse order (I > am assuming the bundle id is strictly increasing). Is this the correct > way of doing things?
I'm a bit confused by your usage of stop and uninstall. Are you stopping the bundles or uninstalling them? In case that you uninstall them make sure you do a refresh after you did so just in case. Stopping, however, will not make the classes available for gc. Furthermore, I just did some tests in a relative big project (lots of bundles, lots of dependencies) and after some random updates and subsequent uninstalls of all bundles I do see classes getting unloaded. So I'd like to ask you as well for a test set-up to reproduce the issue. > In my test case, the framework is responsible for starting the bundles > (I use autostart property to start the bundles). Could it be the problem? I don't think so. In the case mentioned above about 50 bundles are installed using the autostart property and I see classes being unloaded from the bundles in question. regards, Karl > Thanks, > Sahoo > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Karl Pauls [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
