Re: [Swig-user] Java Finalizer Alternatives

[Vallon, J. <Jus...@de...>]

I think the problem that is alluded to here is that while the JVM collects garbage when java-heap memory is low, the native-side might consume more resources than the JVM could anticipate.  It is a specific instance of mismatches between heap-memory and resources.
 
It can manifest itself in many ways:
*	While an open file takes only a small amount of memory (a file descriptor), it consumes a limited resource (file descriptors).  Letting an open File become unreachable is dangerous, since the JVM might not decide to collect garbage until it runs out of heap memory, which could occur before the process runs out of file descriptors.
*	A client could get a proxy to a server resource that consumes a significant amount of memory.  If the client lets the proxy go but does not actively release the resource, you could have unreachable proxy references to a significant amount of server resources.
*	The java/swig application could allocate a large amount of data on the native side through a small handle on the Java-side.  If the JVM does not actively garbage collect, the process could have unreferenced handles to a large amount of native-side data, and run out of memory on the native-side before the JVM heap fills up.
*	A process opens a TCP connection, and just releases the connection object, leaving cleanup to the garbage collector.  The process could easily end up with too many open files, because the JVM does not need to collect garbage, because it is not low on heap space.
*	In general, the java object represents a resource.  The JVM computes the cost of the resource as the amount of memory it uses, which frequently does not match the actual resource cost.
 
In most of these cases, the solution is to either/both: enable the periodic garbage collector, or require resource management (close(), release(), etc).  (Or, I suppose the JVM could implement GC guarantees - which would not conflict with the "no guarantee" behavior of JVMs in general - to make GC deterministic).
 
The finalizer/weak ref optimization makes the gc more efficient, but it does not change the root cause due to resource mismatching.  That is, my understanding of weak refs is that they are only zeroed/queued when the garbage collector finds that the referenced objects are unreachable.
 
-Justin
________________________________

From: Brian Cole [mailto:co...@ey...] 
Sent: Tuesday, January 20, 2009 5:11 PM
To: swi...@li...
Subject: [Swig-user] Java Finalizer Alternatives
 
...
<snippet page 126 in java.sun.com/docs/books/jni/download/jni.pdf> 
Defining a finalize method is a proper safeguard, but you should never rely 
on finalizers as the sole means of freeing native data structures.The reason is that 
the native data structures may consume much more resources than their peer 
instances. The Java virtual machine may not garbage collect and finalize instances 
of peer classes fast enough to free up their native counterparts. 
Defining a finalizer has performance consequences as well. It is typically 
slower to create and reclaim instances of classes with finalizers than to create and 
reclaim those without finalizers. 
</snippet>
...