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