GC & The "Expensive Object" Problem

[Mark S. Miller]

At 03:23 PM 5/7/99 , Bill Frantz wrote:
>[-]You need to run finalization during the unit of operation that failed.
>In the case of running out of file handles, you have the situation that an
>open fails with garbage File objects which refer to OS-opened files.  You
>would like to have those garbage File objects be collected, and their
>"finalize" method run to close the OS-open and free up the file handle.
>Then the Java-open would retry and as far as the Java code is concerned,
>the open succeeds on the first try.  That kind of recovery makes running
>out of file handles during an open behave the same as running out of memory
>during a "new".

[+] While you are correct, this is hard.

For example, if the process exhausts a file-handle resource specific to the 
process, logic local to that process can reclaim on demand as you explain.  
OTOH, if process A exhausts a shared pool while process B is holding some in 
outstanding garbage, then we're probably screwed.

The case most relevant for us, of course, is process B holding some proxies 
to process A.  If A otherwise runs out of storage, there's no possible way 
sitting on top of the jvm, no reasonable way otherwise, for A's condition to 
cause a gc in B in time to prevent A from throwing a 
java.lang.OutOfMemoryError.

But its still not clear if this is a real advantage of refcounts over 
gc-with-prompt-collection-of-expensive-objects.  The limited size of the 
scavenge area should bound the amount of uncollected expensive garbage in 
process B, so it should be equivalent to having a pool that much smaller.  
However, we'd now have to bring out the scavenge limit into the virtual 
machine contract.  This is getting messy.

In any case, whatever else we may run on, E is committed to running on stock 
jvms, so...