I don't know if this is related, but Sun has confirmed to me that the Windows version of the Java Client VM runtime contains some leakage within the components that interface Java with local filesystem. Notably when there are security objects associated to a file or directory. There's a system-specific hook in the filesystem core-class which uses a native function through JNI, implemented in C, and that returns data structures allocated by the OS API or by native calls to the C/C++ heap. Then the native security structures are converted to fields in some Java security object, but the Java JNI interface requires several calls to the JNI method implementation to specify when we are finished with the temporary objects.
If there's an exception in a thread, that causes a thread to be aborted, the thread will die with dead Java objects that will be reclaimed in the Java VM garbage collector, but native security objects will remain allocated and not freed (a finalizer is supposed to call a cleaner method, but finalizers do not run fast enough in the ClientVM).
May be the GC thread patch tried before may also try to call finalizers before performing the GC. I suspect that class finalizers are never called as long as LimeWire is running, probably because these classes are still active and have other active instances. In Java 1.4 or 1.5, Finalizers run in a dedicated Finalizer thread, but with very long delays and low priority.
Calling Runtime.runFinalization() within the GC thread patch indicated in a previous message may help...
A comment from Sun about finalization is shown in old Bug id #4026510(not a bug, will not be fixed):
Quote:
|
The Java Language Specification intentionally says nothing about the promptness with which finalizers are run. There are many reasons for this, perhaps the most important of which is that we don't want to constrain the GC design space too much. With some GC algorithms it's very difficult, if not impossible, to ensure prompt finalization with any efficiency. Finalization is only meant as a backstop for resource deallocation and cleanup.
|
The way and frequency at which finalizers are implemented and run in Apple's version of the VM may make the difference (on Windows we have a dedicated background thread, but is it true on MacOSX?).
Note that I have not seen any use of finalizers in LimeWire classes. But finalizers are frequent in internal implementation core classes bundled with the JVM that perform integrtion with the native host system.