RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

[Peter Levart]

On 12/08/2015 07:44 PM, Kim Barrett wrote:
> On Dec 8, 2015, at 7:44 AM, David Holmes <david.holmes at oracle.com> wrote:
>> But thinking more on this approach this is simply not scalable. A
>> Cleaner per cleanable-class could result in hundreds of threads being
>> active!
> That would indeed be awful.  However, the scope of a Cleaner should
> not usually be a class.  More typically it would be a subsystem,
> module, plugin, or some other sensible unit of sharing.  I assume
> Peter's example had a class-scoped Cleaner for simplicity of
> presentation.  A class-scoped Cleaner probably should be treated as a
> canonical anti-pattern for Cleaner usage; appropriate in rare
> circumstances, but usually a mistake.
>
>> What exactly are the advantages over finalization again?
> The same as PhantomReference-based cleanup vs finalization.
>
> - Performance (especially after JDK-8071507).
>
> - Semantic simplicity, avoiding the need to deal with resurrection of
>    objects, and objects not needing to protect themselves from some
>    kinds of post-cleanup misuse.
>
... the last thing is applicable only if Cleanable.clean() is never 
invoked. If it is invoked (as part of on-demand cleaning like 
AutoCloseable.close()) the object will still have to protect itself from 
misuse.

That's what the problem with direct/mapped ByteBuffer is. The protection 
from post-cleanup misuse would be to costly so there was rather no 
on-demand unmapping implemented (in public API)...

Regards, Peter