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

mark.reinhold at oracle.com mark.reinhold at oracle.com
Thu Dec 3 21:35:02 UTC 2015


2015/11/25 3:42 -0800, aph at redhat.com:
> On 11/24/2015 05:47 PM, Roger Riggs wrote:
>> Memory is an increasingly critical resource, we should be giving
>> developers more tools to manage their use of memory.  The Weak and
>> Soft reference forms of the cleaner make it easier to be aware of
>> and respond to increased memory pressure.
>> 
>> ...
> 
> By "memory" here, do you mean native memory for buffers, etc?  I'm
> guessing so.  If so, I'm not sure that it makes sense to think of this
> as a cure for flaky finalization.  We've got a cure for early
> finalization now with keepAlive() (or whatever it gets called) but
> late (or never) finalization is as far as I can see unfixable.  IMVHO
> it makes more sense to encourage developers to get away from lifecycle
> maintenance based on reachability.

I could not agree more strongly!

> Unfortunately the current design for ByteBuffers does not allow
> unmap(), so large mapped buffers may hang around for a long time.
> 4724038 says
> 
>  "We ... have given this problem a lot of thought ...  We have yet to
>  come up with a way to implement an unmap() method that's safe,
>  efficient, and plausibly portable across operating systems.  We've
>  explored several other alternatives aside from the two described
>  above, but all of them were even more problematic.  We'd be thrilled
>  if someone could come up with a workable solution, so we'll leave
>  this bug open in the hope that it will attract attention from someone
>  more clever than we are."
> 
> I'm very tempted to take a bite at this, but the above text is rather
> forbidding.  I think I know how to do it. (Famous last words?)

As the author of the above-quoted paragraph, I wish you luck.  It's
a tough problem.

Random musing: I wrote those words in 2005.  At this point in time I
suspect that an unmap method that works on some operating system but
not others might be more acceptable than it would have been back then.

- Mark



More information about the core-libs-dev mailing list