JEP 132: More-prompt finalization

[Srinivas Ramakrishna]

Hi David --


On Sun, Jan 8, 2012 at 3:23 PM, David Holmes <david.holmes at oracle.com>wrote:

> 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).
>

The VM can probably keep track of its own descriptors, but you are right
that pure native code may make the final calculation noisy unless the
underlying
platform provides suitable query API's. Rates are easy (modulo the noise in
numbers) given that the VM/libs can keep track of the numbers it
understands. Don't think of it as (this is what the libraries cab do abd
this is what the VM can do, but rather as, this is what the VM+libs can
provide to the (pure) Java application.


>
> 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.
>

Yes, it would be a heuristic-driven policy (or set of policy choices), but
it's better than each application rolling
its own policy and infrastructure from scratch.

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

The objective is to do the resource tracking from within the libraries
(+JVM), so the user wouldn't have to bother.
For example, by providing suitable high level API's at the library level
which would be wrappers
around specific native resources that would be subject to such tracking.

-- ramki


>
> 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
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120108/cbbc302d/attachment.html