On 8/17/09 5:27, Holger Hoffstätte wrote:
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.
Well, we are aware of the issue surrounding deleting native libraries on
Windows, so we check to see if we were successful deleting the bundle's
cache directory and if not, we try to force a GC and then try to delete
it again...so maybe that is happening here.
-> richard
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
