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

[Hans Boehm]

On Mon, Aug 2, 2021 at 11:32 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:
>
...
>
> When using cleaners or references then the typical response to resource
> exhaustion will be System.gc with back-off/retry in a loop until the
> resource can be allocated. Privileged ops in the JDK can do a bit better
> by polling the pending reference list to see if there is still work to
> do. So all a bit primitive.

I agree that this is a bit primitive. Perhaps more importantly,
it seems like a regression from finalization, where
I can be reasonably sure that System.gc(); System.runFinalization();
(with no locks held) will finalize all objects that can be finalized.
(This ignores the case in which finalizers generate more Java garbage,
but in most cases that's not a very significant effect.)

AFAICT, the spec currently provides no promise that System.gc() will
"expend effort" towards enqueueing References; it only talks about
reclaiming
memory in the positive, though oddly enough, it does make a negative
statement about enqueueing references.  The spec does not make it sound
like System.gc() waits for the right condition before returning. So the
back-off in the suggested retry loop seems critical, even if I can
explicitly
wait on the queue. That seems unfortunate to me.
>
> It's not clear to me that it's worth trying to do anything with
> runFinalization now. Yes, it is deadlock prone. It might help if it were
> changed from an untimed to a timed-wait when waiting for the secondary
> finalizer thread but that may just move the problem for finalizers that
> interact with locking.

My problem with the current situation is that it's not clear how to write
client
code. If runFinalization() does not have the timeout, I need to be very
careful where
I call it, in ways that probably make it less effective.

But I'm also not at all sure this is worth addressing now. If we want to
move away
from finalizers, I think it is important to make things easier in the new
world
with Cleaners. Currently there seem to be at least two things that make it
significantly
harder:

1) The lack of a default user-visible Cleaner seems to effectively tie up
an additional
thread per Cleaner-using-library. AFAICT, the decreased interference
between Cleaners makes
that desirable in some contexts, but the additional threads make it
untenable in others.

2) The lack of a clean runFinalization alternative. I think this is
actually an opportunity
to improve things and motivate people to switch away from finalization. But
currently
it pushes in the wrong direction.

Hans

>
> -Alan