Todor, Richard - thank you for your responses. I understand how various GC schemes work - I guess I should have asked a more concise question like "does the framework explicitly keep a reference to the classloader, and if so, when is that reference released". :) However in the meantime I found out more that might be useful to know (if only for the archives) and mostly answers my question.
Richard S. Hall wrote: > As with everything, stuff can only be garbage collected when there are > no more references to it. Native is referenced from a ClassLoader. > ClassLoaders are referenced from Classes. Classes are referenced from > instances. So, you cannot have any references to any of these things > from a bundle, otherwise it won't be able to be garbage collected. Right - I understand that the runtime cannot really do anything about GC except maybe by explicitly hooking into reference queues. But that does not really seem to be necessary as I found out. > Windows is particularly annoying, since it locks its native libraries, > which prevents them from being deleted. However, I believe Felix does > delete them at least in some cases. If you have a specific case where > this isn't working, perhaps you could create a simple test case and > attach it to a JIRA issue. This would help a lot in resolving it. The native library I am working with is closed-source/proprietary and was originally not written with Java in mind, so I created a small "clean-room" bundle from scratch that simply loads apr.dll in Activator.start(). Turns out Felix does all the right things. :) When the bundle is installed/resolved, the apr.dll (as declared in the bundle headers) is unpacked but not yet loaded; you can still delete it manually from the bundle cache. After bundle start this is no longer true as the library has been mapped into the JVM process (though you can move it, supposedly because Windows tracks the file "inode" or whatever it uses). The interesting thing is that the dll _is_ successfully deleted as soon as the bundle is uninstalled. So all this works as intended - great! A bit surprising actually, as I would not have expected the GC to be this aggressive..probably client VM specific behaviour. Anyway, this verifies my suspicion that there are indeed some outstanding references on the Java side of the proprietary library that prevent the bundle from being collected properly - probably static singletons or the like. thanks & cheers Holger --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
