RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

[Alan Bateman]

On 24/01/2016 17:10, Peter Levart wrote:
> Hi,
>
> I had an idea recently on how to expedite the collection of an object. 
> It is simple - just don't let it live long.
>
> Here's a concept prototype:
>
> http://cr.openjdk.java.net/~plevart/misc/CloseableMemory/CloseableMemory.java 
>
>
> The overhead of the check in access methods (getByte()/setByte()) 
> amounts to one volatile read of an oop variable that changes once per 
> say 5 to 10 seconds. That's the period a special guard object is 
> alive. It's reachability is tracked by the GC and extends to the end 
> of each access method (using Reference.reachabilityFence). Every few 
> seconds, the guard object is changed with new fresh one so that the 
> chance of the guard and its tracking Cleaner being promoted to old 
> generation is very low.
>
> Could something like that enable a low-overhead 
> CloseableMappedByteBuffer?
>
If I read this correctly then this still depends on timely reference 
processing. The switching guard trick to keep the Cleaner from being 
promoted is interesting of course. So if we were to do something like 
this with MBB then it would mean the file mapping would still exist and 
so we'd have the usual issue of trying to delete the underlying file. 
Then we have the issue of file or socket I/O where threads could be 
blocked doing I/O with regions of the buffer and so delay indefinitely 
any release.

That said, maybe it is an option for Uwe.

-Alan.