Fate of {System|Runtime}.runFinalization (Re: Ad removing finalize eventually

[Erik Osterlund]

Hi Hans,

> On 2 Aug 2021, at 22:53, Hans Boehm <hboehm at google.com> wrote:
> 
> I think we will eventually need something analogous to runFinalization()
> for Cleaners and/or References. If you are out of some resource managed by
> Cleaners and want to allocate another one, how do you wait for resources of
> that kind to be reclaimed? What do you do if you're testing code using
> Cleaners or References to reclaim resources?

I thought that’s the purpose ish for java.lang.ref.Reference.enqueue(). It lets the cleanup run before the GC gets around to it. If you need more precise synchronization, that can seemingly be managed by the queue owner.

/Erik

> This may also be a great opportunity to resolve the long-standing issue of
> whether it's safe to call runFinalization() with user-visible locks held.
> What happens when runFinalization's caller holds a lock needed by a
> finalizer? This should be more tractable for Cleaners and References, since
> it's easier to maintain separate queues for different classes.
> 
> 
>> On Mon, Aug 2, 2021 at 6:12 AM Rony G. Flatscher <Rony.Flatscher at wu.ac.at>
>> wrote:
>>> On 01.08.2021 21:02, Alan Bateman wrote:
>>> On 01/08/2021 14:01, Rony G. Flatscher wrote:
>>>> Maybe a last question in this context: is it planned that
>>>> {System|Runtime.getRuntime()}.runFinalization() gets removed when
>> finalize() gets removed? If so,
>>>> would there be an equivalent?
>>> There isn't a proposal or JEP yet for the next steps for finalization.
>> The runFinalization method
>>> should probably be deprecated. It might be that the method is eventually
>> "degraded" to do nothing
>>> or throw an exception, too early to say. Aside from System.gc, there
>> isn't an API exposed to
>>> "help" reference processing.
>> Thank you very much for clarifying, so it is safest to remove its usage!
>> ---rony