Here's a crazy idea:   the whole problem, as I see it, arises because the JVM's garbage collector only knows of one resource pool, the heap, when in fact there are other resource pools outside the JVM that it should also concern itself with.  Say, for example, you implement a class, FooBar, that is a wrapper for some legacy "C" code... when you create an instance of this class, it allocates some resource outside the JVM (memory, file handles, whatever).  This object is using a resource that the JVM does not know about, but it is a resource that will be freed with the instance of the class is garbage collected.

So, what I think the JVM needs is an extensible concept of resources...  for example, sun could add to the System class the following method:

   public static synchronized void incrementResourceUsage( String resourceName, int amount );

The "amount" is generic... it is compared only to thresholds that can be set on the command-line, or in a properties file.   So, when you instantiate FooBar, it increments the resource "foobar" the appropriate amount.  If a threshold is exceeded, it causes garbage-collection, which will hopefully reduce the amount of the "foobar" resource in use.  The finalize method for FooBar would increment the same resource by the appropriate negative amount.

(This example is bad, because you normally wouldn't want the resource to be class specific... for example you would have a resource for memory allocated outside the JVM's heap (a wrapper for malloc() and free() would be the way to go, for the legacy code example), a resource for x-server resouces held, etc.)
 
 
 
 
 

-- 
----------------------
Rob Clark
Dot Wireless, Inc.
(858)552-2946
[EMAIL PROTECTED]
----------------------
 


Reply via email to