JEP 132: More-prompt finalization

[David Holmes]

On 7/01/2012 2:07 AM, Tony Printezis wrote:
> David,
>
> On 01/06/2012 06:14 AM, David Holmes wrote:
>> Hi Tony,
>>
>> On 6/01/2012 8:34 PM, Tony Printezis wrote:
>>> If each library could indicate to the GC whether the resource it manages
>>> is running low or not, using the API I mentioned, the GC could do the
>>> above automatically, behind the scenes, without the user having to do
>>> anything else.
>>
>> I'm not sure a library writer has the necessary information to do
>> this. Seems to me that how an application uses a particular type
>> determines the scarcity of the resource.
>
> I will be very surprised if the majority of application developers will
> be willing to measure at what rate the application consumes certain
> resources and update said measure when the application changes, load
> increases, OS changes, hardware changes, etc. And, sure, I think there
> will be many cases where the library writer has a good idea / can find
> out the max number of instances of a particular resource (file
> descriptors, sockets, etc.).

Perhaps, but the library writer may only have partial knowledge. The 
library can use reference counts to track how much of a resource it has 
handed out, and what has been handed back. It might know what the 
absolute limit for a resource is (via getrlimit etc). But can it know 
the absolute usage rate of a given resource? Can you query how many 
available file descriptors a process has left? Some resources will be 
used by native code outside the libs (including the VM).

So at best this is a heuristic, so the library tracks the resource and 
at some threshold it invoke System.runFinalization. The GC itself 
doesn't make an informed decision because, as you said your self, the VM 
(and hence GC) knows nothing about the resource being tracked.

But would we want to burden all users of these classes with the overhead 
of resource tracking?

Cheers,
David

> Tony
>
>> I can imagine something like:
>>
>> void setFinalizationLimit(Class<?> cls, int limit)
>>
>> so that GC runs finalization once a "reference count" reaches "limit".
>> That limits the frequency of finalization, but the actual finalization
>> cost may still be unacceptably high.
>>
>> Cheers,
>> David
>>
>>> Tony
>>>
>>>> Afterall the key thing about GC is it relieves the programmer from
>>>> having to manage object lifetimes, so if you don't know when the
>>>> object is no longer used you don't know when to call close.
>>>>
>>>> David