RFR 9: 8165641 : Deprecate Object.finalize

classic Classic list List threaded Threaded
72 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

RFR 9: 8165641 : Deprecate Object.finalize

roger riggs
Finalizers are inherently problematic and their use can lead to
performance issues,
deadlocks, hangs, and other problematic behavior.

The problems have been accumulating for many years and the first step to
deprecate Object.finalize and the overrides in the JDK to communicate the
issues, recommend alternatives, and motivate changes where finalization
is currently used.

The behavior of finalization nor any uses of finalize are not modified
by this change.
Most of the changes are to suppress compilation warnings within the JDK.

Please review and comment.

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641/

Issue:
    https://bugs.openjdk.java.net/browse/JDK-8165641

Thanks, Roger


Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Kim Barrett
> On Mar 10, 2017, at 4:40 PM, Roger Riggs <[hidden email]> wrote:
>
> Finalizers are inherently problematic and their use can lead to performance issues,
> deadlocks, hangs, and other problematic behavior.
>
> The problems have been accumulating for many years and the first step to
> deprecate Object.finalize and the overrides in the JDK to communicate the
> issues, recommend alternatives, and motivate changes where finalization is currently used.
>
> The behavior of finalization nor any uses of finalize are not modified by this change.
> Most of the changes are to suppress compilation warnings within the JDK.
>
> Please review and comment.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641/
>
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8165641
>
> Thanks, Roger

looks good.


Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hans Boehm-2
IIUC, all of the replacements for finalizers (Cleaners, PhantomReferences)
still have the problem that they can't easily share a single thread across
separately-developed libraries to actually run the cleanups? It seems to me
that has been the only even halfway-convincing reason to still use
finalizers for a long time, but it seems to be a pretty good one in
practice.


On Fri, Mar 10, 2017 at 5:36 PM, Kim Barrett <[hidden email]> wrote:

> > On Mar 10, 2017, at 4:40 PM, Roger Riggs <[hidden email]> wrote:
> >
> > Finalizers are inherently problematic and their use can lead to
> performance issues,
> > deadlocks, hangs, and other problematic behavior.
> >
> > The problems have been accumulating for many years and the first step to
> > deprecate Object.finalize and the overrides in the JDK to communicate the
> > issues, recommend alternatives, and motivate changes where finalization
> is currently used.
> >
> > The behavior of finalization nor any uses of finalize are not modified
> by this change.
> > Most of the changes are to suppress compilation warnings within the JDK.
> >
> > Please review and comment.
> >
> > Webrev:
> > http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641/
> >
> > Issue:
> >   https://bugs.openjdk.java.net/browse/JDK-8165641
> >
> > Thanks, Roger
>
> looks good.
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Andrew Haley
In reply to this post by roger riggs
On 10/03/17 21:40, Roger Riggs wrote:
> Finalizers are inherently problematic and their use can lead to
> performance issues,
> deadlocks, hangs, and other problematic behavior.

Wow.  I totally agree with the sentiment, but it's a bit late in the
JDK 9 timeframe to be talking about this.  Has this been discussed
internally within Oracle for some time?  I can't believe this is an
idea you just came up with.  :-)

Andrew.


Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Alan Bateman
On 11/03/2017 07:59, Andrew Haley wrote:

> :
> Wow.  I totally agree with the sentiment, but it's a bit late in the
> JDK 9 timeframe to be talking about this.  Has this been discussed
> internally within Oracle for some time?
For years, long before SUNW was finalized :-)   Note that Roger's patch
just deprecates it, the only implication is warnings at compile-time,
nothing else.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

roger riggs
In reply to this post by Hans Boehm-2
Hi,

A common cleaner was considered but it would be susceptible to one of
the same problems
as finalizers. A bug in the cleanup code could block the thread due to
locks or deadlock,
and hold up cleanup for all of its clients.  It would be an attractive
nuisance.
Library or modules can create a cleaner shared and any issues can be
resolved within that context.

Roger


On 3/10/2017 9:15 PM, Hans Boehm wrote:

> IIUC, all of the replacements for finalizers (Cleaners,
> PhantomReferences) still have the problem that they can't easily share
> a single thread across separately-developed libraries to actually run
> the cleanups? It seems to me that has been the only even
> halfway-convincing reason to still use finalizers for a long time, but
> it seems to be a pretty good one in practice.
>
>
> On Fri, Mar 10, 2017 at 5:36 PM, Kim Barrett <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     > On Mar 10, 2017, at 4:40 PM, Roger Riggs <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >
>     > Finalizers are inherently problematic and their use can lead to
>     performance issues,
>     > deadlocks, hangs, and other problematic behavior.
>     >
>     > The problems have been accumulating for many years and the first
>     step to
>     > deprecate Object.finalize and the overrides in the JDK to
>     communicate the
>     > issues, recommend alternatives, and motivate changes where
>     finalization is currently used.
>     >
>     > The behavior of finalization nor any uses of finalize are not
>     modified by this change.
>     > Most of the changes are to suppress compilation warnings within
>     the JDK.
>     >
>     > Please review and comment.
>     >
>     > Webrev:
>     >
>     http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641/
>     <http://cr.openjdk.java.net/%7Erriggs/webrev-finalize-deprecate-8165641/>
>     >
>     > Issue:
>     > https://bugs.openjdk.java.net/browse/JDK-8165641
>     <https://bugs.openjdk.java.net/browse/JDK-8165641>
>     >
>     > Thanks, Roger
>
>     looks good.
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hans Boehm-2
How does that scale to independently developed libraries?

In my world, finalizer deadlocks are relatively easy to diagnose, and a
relatively minor annoyance.

Stepping back, I'm a little surprised at the deprecation. In my opinion,
the problems with finalizers are, in rough order of significance:

1) Premature finalization issues in the absence of reachabilityFence. And I
would be pleasantly surprised if reachabilityFence saw much use.

2) Lack of ordering guarantees.

3) Some less significant issues, like runFinalization() synchronization,
difficulty in properly triggering GC for non-memory resource exhaustion,
slow and deadlocked finalizers, inability to finalize more than once,
potential need for finalizer guardians, etc.

The first two appear on top since they can cause memory corruption in a
world with JNI.

The problems with PhantomReference or Cleaner appear to be:

1) Premature cleanup issues in the absence of reachabilityFence.

2) Too many cleanup threads in large multi-author systems. (Can't cause
memory corruption, but seems to be a serious issue for complex systems
running on resource-constrained hardware.)

3) A similar, though perhaps slightly shorter list of less significant
issues. At least it seems shorter at the moment; most real experience in my
world still seems to be with finalizers. Some of the old problems, like
runFinalization() seem to get worse with the number of clients, since each
client needs to invent its own mechanism.

Although I agree we'd be marginally better off without finalizers, it's
unclear to me the improvement is substantial enough to bother without more
of a replacement story.

On Sat, Mar 11, 2017 at 9:24 AM, Roger Riggs <[hidden email]> wrote:

> Hi,
>
> A common cleaner was considered but it would be susceptible to one of the
> same problems
> as finalizers. A bug in the cleanup code could block the thread due to
> locks or deadlock,
> and hold up cleanup for all of its clients.  It would be an attractive
> nuisance.
> Library or modules can create a cleaner shared and any issues can be
> resolved within that context.
>
> Roger
>
>
>
> On 3/10/2017 9:15 PM, Hans Boehm wrote:
>
> IIUC, all of the replacements for finalizers (Cleaners, PhantomReferences)
> still have the problem that they can't easily share a single thread across
> separately-developed libraries to actually run the cleanups? It seems to me
> that has been the only even halfway-convincing reason to still use
> finalizers for a long time, but it seems to be a pretty good one in
> practice.
>
>
> On Fri, Mar 10, 2017 at 5:36 PM, Kim Barrett <[hidden email]>
> wrote:
>
>> > On Mar 10, 2017, at 4:40 PM, Roger Riggs <[hidden email]>
>> wrote:
>> >
>> > Finalizers are inherently problematic and their use can lead to
>> performance issues,
>> > deadlocks, hangs, and other problematic behavior.
>> >
>> > The problems have been accumulating for many years and the first step to
>> > deprecate Object.finalize and the overrides in the JDK to communicate
>> the
>> > issues, recommend alternatives, and motivate changes where finalization
>> is currently used.
>> >
>> > The behavior of finalization nor any uses of finalize are not modified
>> by this change.
>> > Most of the changes are to suppress compilation warnings within the JDK.
>> >
>> > Please review and comment.
>> >
>> > Webrev:
>> > http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641/
>> >
>> > Issue:
>> >   https://bugs.openjdk.java.net/browse/JDK-8165641
>> >
>> > Thanks, Roger
>>
>> looks good.
>>
>>
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Andrew Haley
In reply to this post by Alan Bateman
On 11/03/17 11:08, Alan Bateman wrote:
> On 11/03/2017 07:59, Andrew Haley wrote:
>
>> :
>> Wow.  I totally agree with the sentiment, but it's a bit late in the
>> JDK 9 timeframe to be talking about this.  Has this been discussed
>> internally within Oracle for some time?
> For years, long before SUNW was finalized :-)

Oh, absolutely, I know about that.  I was just wondering why now, and
is this something you just came up with, and are we going to have the
compatibility discussion?

I have no problem with the deprecation, BTW.  It's what happens next
that is more problematic.

Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Andrew Haley
In reply to this post by Hans Boehm-2
On 11/03/17 18:56, Hans Boehm wrote:
>
> Stepping back, I'm a little surprised at the deprecation. In my opinion,
> the problems with finalizers are, in rough order of significance:

I would have thought the most significant problem with finalizers is
that finalizers may never run unless the application runs out of
memory.  In practice, this means that finalizers (and
PhantomReferences, Cleaners, and anything else where cleanup is based
on reachability) can't be used to manage scarce resources.  Given that
this is a primary use case for finalizers, I think we're done.

> 3) Some less significant issues, like runFinalization()
> synchronization, difficulty in properly triggering GC for non-memory
> resource exhaustion, slow and deadlocked finalizers, inability to
> finalize more than once, potential need for finalizer guardians,
> etc.

I guess "difficulty in properly triggering GC for non-memory resource
exhaustion" is closest to what I just described.

> Although I agree we'd be marginally better off without finalizers,
> it's unclear to me the improvement is substantial enough to bother
> without more of a replacement story.

I can't disagree with that.  But I welcome this move as an opening
gambit.

Andrew.
Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Phil Race

On 3/12/17, 3:07 AM, Andrew Haley wrote:
> 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.

-phil.
Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Andrew Haley
On 12/03/17 16:40, Philip Race wrote:

>
> On 3/12/17, 3:07 AM, Andrew Haley wrote:
>> 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.  :-)

Andrew.
Reply | Threaded
Open this post in threaded view
|

RE: RFR 9: 8165641 : Deprecate Object.finalize

Uwe Schindler-4
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 😊)


Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hans Boehm-2
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 <[hidden email]>
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 😊)
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Alan Bateman
In reply to this post by Andrew Haley
On 12/03/2017 09:55, Andrew Haley wrote:

> :
> I have no problem with the deprecation, BTW.  It's what happens next
> that is more problematic.
>
I think it has to be baby steps and I would expect going further will
involve years and several major releases. That should give time to look
at use-cases that aren't adequately handled by the Cleaner API so that
the support in place long before there is any proposal to remove anything.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Andrew Dinn
In reply to this post by Andrew Haley
On 12/03/17 09:55, Andrew Haley wrote:
> Oh, absolutely, I know about that.  I was just wondering why now, and
> is this something you just came up with, and are we going to have the
> compatibility discussion?

Perhaps now is the chosen moment (and a good choice at that, I say)
because deprecation in release N is necessary to allow removal or
modification of semantics in release N+k, k >= 1. So, rather N == 10
than N == 9 (n.b. in this case, I strongly suspect that inequality on k
will not actually encompass the equals case).

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Andrew Dinn


On 13/03/17 12:15, Andrew Dinn wrote:

> On 12/03/17 09:55, Andrew Haley wrote:
>> Oh, absolutely, I know about that.  I was just wondering why now, and
>> is this something you just came up with, and are we going to have the
>> compatibility discussion?
>
> Perhaps now is the chosen moment (and a good choice at that, I say)
> because deprecation in release N is necessary to allow removal or
> modification of semantics in release N+k, k >= 1. So, rather N == 10
> than N == 9 (n.b. in this case, I strongly suspect that inequality on k
> will not actually encompass the equals case).

Oops, obviously I meant:

 So, rather N == 9 than N == 10

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

David M. Lloyd-3
In reply to this post by Hans Boehm-2
In regards to the optimized-out "this" stuff - remember that a while ago
Paul Sandoz introduced java.lang.ref.Reference#reachabilityFence()...

On 03/12/2017 06:55 PM, Hans Boehm wrote:

> 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 <[hidden email]>
> 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 😊)
>>
>>
>>

--
- DML
Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Doug Lea
In reply to this post by Hans Boehm-2
On 03/12/2017 07:55 PM, Hans Boehm wrote:

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

The motivation seems more along the lines of "denigration" vs
deprecation. But even if so, I agree with Hans's implicit claim that
it might be better to thoroughly document all the issues encountered
when using finalization and/or PhantomReferences and/or cleaners, etc.
This coverage will necessarily convey the high expertise required to
implement and use them effectively, and to not use them otherwise.
Currently no single authoritative account exists, so a lot of
errors are due to confusion or ignorance. Doing better would seem
to be the highest priority. But maybe adding deprecation warnings
on top of this will have some beneficial effect. So, like Hans,
I'm not completely opposed to this, but not excited either.

-Doug



Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

roger riggs
Hi,

A reasonably complete treatment of finalizers and suggestions for correct
use are in Josh Bloch' Effective Java.  It may be a bit dated but is a
good start for the casual reader.

Josh provided an excerpt:
http://www.informit.com/articles/article.aspx?p=1216151&seqNum=7

There is a lot more to do to design better APIs and mechanisms for the most
difficult cases.  Project Panama is working on some of them and more
than a few
ideas are being developed (as noted in earlier emails).

Roger


On 3/13/2017 9:07 AM, Doug Lea wrote:

> On 03/12/2017 07:55 PM, Hans Boehm wrote:
>
>> 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. ...
>
> The motivation seems more along the lines of "denigration" vs
> deprecation. But even if so, I agree with Hans's implicit claim that
> it might be better to thoroughly document all the issues encountered
> when using finalization and/or PhantomReferences and/or cleaners, etc.
> This coverage will necessarily convey the high expertise required to
> implement and use them effectively, and to not use them otherwise.
> Currently no single authoritative account exists, so a lot of
> errors are due to confusion or ignorance. Doing better would seem
> to be the highest priority. But maybe adding deprecation warnings
> on top of this will have some beneficial effect. So, like Hans,
> I'm not completely opposed to this, but not excited either.
>
> -Doug
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR 9: 8165641 : Deprecate Object.finalize

Hans Boehm-2
This is great as far as it goes. But (due to its age?) it seems to omit
what I would consider the top two issues:

1. Objects can be finalized while a method on the object is still running.
Yes, reachabilityFence addresses this, and is an important improvement. But
it reachabilityFence remains extremely difficult to use, and essentially no
current code does. This problem is shared with java.lang.ref and Cleaner.
In my experience, the large majority of existing code using finalize() is
broken by this, though failures in the field tend to be fairly rare. Any
code deallocating native memory needs to be aware of this issue. Code that
just reports "you forgot to close this" is probably OK. Where I sit, the
former is much more common than the latter.

2. Objects are finalized in arbitrary order, which means that finalizers
can see objects that have already been finalized. This is fixed by the
later APIs. In my mind, it's the main argument for deprecating
Object.finalize(). (I would personally argue for deprecate then fix, rather
than deprecate then remove. But that's controversial, and we probably don't
want to go there.)

Unlike the other complaints, both of these, when used to manage native
memory through JNI, can result in corruption of the native heap, and are
thus particularly difficult to recover from.

They are discussed in e.g.
https://www.hboehm.info/misc_slides/java_finalizers.pdf

Hans

On Mon, Mar 13, 2017 at 6:32 AM, Roger Riggs <[hidden email]> wrote:

> Hi,
>
> A reasonably complete treatment of finalizers and suggestions for correct
> use are in Josh Bloch' Effective Java.  It may be a bit dated but is a
> good start for the casual reader.
>
> Josh provided an excerpt:
> http://www.informit.com/articles/article.aspx?p=1216151&seqNum=7
>
> There is a lot more to do to design better APIs and mechanisms for the most
> difficult cases.  Project Panama is working on some of them and more than
> a few
> ideas are being developed (as noted in earlier emails).
>
> Roger
>
>
>
> On 3/13/2017 9:07 AM, Doug Lea wrote:
>
>> On 03/12/2017 07:55 PM, Hans Boehm wrote:
>>
>> 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. ...
>>>
>>
>> The motivation seems more along the lines of "denigration" vs
>> deprecation. But even if so, I agree with Hans's implicit claim that
>> it might be better to thoroughly document all the issues encountered
>> when using finalization and/or PhantomReferences and/or cleaners, etc.
>> This coverage will necessarily convey the high expertise required to
>> implement and use them effectively, and to not use them otherwise.
>> Currently no single authoritative account exists, so a lot of
>> errors are due to confusion or ignorance. Doing better would seem
>> to be the highest priority. But maybe adding deprecation warnings
>> on top of this will have some beneficial effect. So, like Hans,
>> I'm not completely opposed to this, but not excited either.
>>
>> -Doug
>>
>>
>>
>>
>
1234