RFR 9: 8165641 : Deprecate Object.finalize

[Hans Boehm]

I agree that's indeed a solvable problem, perhaps not terribly elegantly,
but without too much user-visible complication. Cf. Android's
(internal-use-only) NativeAllocationRegistry. Basically the GC triggering
heuristic needs to consider other resources as well as Java memory. And
"other resources" seems to mean "native heap" in 90+% of cases.

The premature cleanup issues (due to e.g. optimized out "this" pointers)
scare me much more, since they require either significant changes to
compiler guarantees and the language spec, or a really difficult user
education effort. It seems to take on the order of an hour one-on-one
conversation to convince the typical developer that their finalizer or
java.lang.ref use is broken, which it seems to be about 80% of the time.

But I think we agree that it doesn't matter for this discussion; neither of
these problems are addressed by deprecating finalizers. PhantomReferences
have exactly the same issues. And in my experience it's unfortunately
unrealistic to say we're going to use neither. There will be Java wrappers
for native objects. And they will be embedded in Java data structures.
Requiring explicit management for those amounts to mostly throwing out Java
garbage collection.

On Sun, Mar 12, 2017 at 12:02 PM, Uwe Schindler <uschindler at apache.org>
wrote:

> Hi,
>
> > >> I guess "difficulty in properly triggering GC for non-memory resource
> > >> exhaustion" is closest to what I just described.
> > >
> > > This has long been an issue in the Java client area where native
> desktop
> > > resources or the like need to be managed carefully, but it is not just
> > > native window handles but any resource not managed by GC.
> > >
> > > So more precisely "non-Java Heap" resource exhaustion as you could
> > > allocate 2GB of native heap and the GC would not care at all if
> > > it were tied solely to a 32 byte finalizable Java object.
> >
> > Indeed.  For what it's worth, I have a plan to design and implement a
> > mechanism to allow native memory to be safely deallocated without
> > using finalization, but it's proving rather difficult to find a nice
> > way to design the API and make it fit the JMM.  I hope to get it done
> > by JDK 10.  :-)
>
> Yeah, make it work! If you have some time, don't mind to share updated
> ideas with Robert Muir and me!
>
> Thanks, Uwe
> (for Apache Lucene MMapDirectory where a few bytes of heap space bind up
> to terabytes of mmap fulltext index data ��)
>
>
>