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

John Rose john.r.rose at oracle.com
Thu Dec 3 21:47:51 UTC 2015


On Dec 3, 2015, at 1:35 PM, mark.reinhold at oracle.com wrote:
> 
>> 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.

We are takeing a crack at it with Panama, since using C APIs
often requires timely deallocation of (non-Java) temps.

The basic components are two: 1. A type called "Scope" which is bound
to a Java stack frame using try-with-resources, and whose open, append,
and close operations can do things like malloc and free.  2. A smart pointer
type which is a tuple (value type some day) of <base, offset, type, scope>,
whose indirection operations always check for a dead scope.  This requires
tricky compiler optimizations to make the scope checks fold up and go away.
But it seems doable.  One hard part is race conditions, but if we have fast
path for operations within the thread owning the Scope, we can win, I think.
(This is one reason it's important for a Scope to be bound to a stack frame.)
In the absence of value types there will be a little bit of garbage created
to represent the scopes and smart pointers, but it's O(N) where N is the
number of operations, not O(M) where M is the number of bytes being
operated on.  And moving stuff to value types will reduce GC overhead
even more.  Basically, the little dribble of GC activity is the cost of safety.

— John




More information about the core-libs-dev mailing list