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

[Peter Levart]

On 11/25/2015 12:42 PM, Andrew Haley wrote:
> 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.
>>
>> The management of memory is not hypothetical for most large
>> applications.  It was one topic that came up in questions at J1.
>> Developers do quite a bit of work trying to figure out algorithms
>> for working caches, serializing to disk, and having the data
>> available when it is needed.  There is a lot of guesswork about how
>> GC is working and how it behaves at/near the limits.  SoftReferences
>> are a bit of a blunt instrument but they provide evidence an
>> application can use to regulate its long term memory use.
>>
>> The WeakReference forms, if provided, can be an alternative to the
>> ideosyncratic cleanup approaches used in various Weak keyed and weak
>> values collections.  If there are other mechanisms contemplated for
>> more efficient memory management then perhaps these are not
>> necessary but if not the current mechanisms should be easier to use.
> 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.
>
> 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?)
>
> Andrew.

I wish you luck, Andrew. But in case you find any obstacles on the road 
which you can't solve, I have an idea for an alternative solution. As I 
understand, the problem is when a ByteBuffer that lives long enough is 
moved to an old-generation region which is very rarely scanned and so 
its life is prolonged more than necessary. If that's the case then what 
about the following:

- reserve a special value of object age in the object header to mean: 
This is a "Dorian Grey" object. (or if there is a spare bit that could 
be used in object header, it could be used to mark it so)
- make collectors treat this value specially (i.e. don't increment it 
and treat it as a young object - don't ever move such object to 
old-generation)
- have an internal API to patch this value on a given object's header at 
construction time (maybe also reset it to initial young value if needed 
later)

direct ByteBuffer's could use this internal API to declare themselves 
"Dorian Greys" at construction. They would never be moved to 
old-generation and so would be scanned frequently enough to be found 
phantom-reachable in-time.

I think this could work as there are not many instances of direct 
buffers alive at any one time and so this would not affect young 
generation too much. I understand that such byte buffers would 
frequently have old-to-young links that would have to be tracked with 
all the needed overhead. But that might be a good solution anyway for 
some applications.

What do you think?

Regards, Peter