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

[Peter Levart]

On 01/25/2016 02:31 PM, Alan Bateman wrote:
> 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.

Right, the hope is that Reference(s) and referents that only live for a 
few seconds get this timely 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. 

There could be a method on MBB to register a callback to be called after 
the buffer is unmapped.

> 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.

Yes, that could be a problem. If the access to mapped memory blocked for 
a very long time, then the guard and its Cleaner could be promoted to 
old gen in the meanwhile. But let me ask something. Doesn't GC 
processing require (at least in some phases) that user threads be 
stopped in a safepoint? What happens when a user thread is blocked by 
kernel on memory access? Such thread can't be stopped in a safepoint. 
Safepoint can't begin, so GC can't proceed and therefore can't promote 
objects to old generation at that time. Am I right? If yes, then time 
does not pass for objects while a user thread is blocked on memory 
access, so they won't get promoted to old gen any time sooner after the 
user thread is unblocked.

Regards, Peter

>
> That said, maybe it is an option for Uwe.
>
> -Alan.