JEP 132: More-prompt finalization

[David Holmes]

On 9/01/2012 4:31 PM, Kirk Pepperdine wrote:
>>>
>>
>> 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?
>
> Isn't this what a pool is for? I don't know but IMHO, this as going off very quickly. My feeling we're trying to hack in a work-around for an API to do have GC do something that it was never intended for it to do. Further more, if reference objects need to be treated specially then maybe the should be tracked specially so that a different mechanism can be triggered, one that doesn't interfere with GC. Crazy idea, what if reference objects were loosely connected to a special GC root so one could trace them on their own and if you could quickly determine that they weren't connected to anything else,....

I'm not quite sure what you are arguing for or against :) but isn't what 
you describe called "reference counting"?

You can imagine a class that uses a "finalizable" resource tracking 
construction and close() itself and also initiating some kind of cleanup 
mechanism. The cleanup has to involve the GC though because unless you 
have reference-counted classes (ala C++ auto_ptr - which Java can not 
support) there is no way to know when a resource is reclaimable.

I also think the there will be an overhead associated with such resource 
tracking, and I don't think everyone should have to pay the price for 
that if they don't need it.

Anyway I'm just repeating myself so I'll stop :)

Cheers,
David

> Regards,
> Kirk
>