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

[Peter Levart]

On 01/25/2016 05:14 PM, Alan Bateman wrote:
>
>
> On 25/01/2016 15:27, Peter Levart wrote:
>>
>> 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.
> With memory mapping then it's very possible that a memory access to 
> stall waiting for pages to be faulted in. So yes, I assume any 
> STW/safepoint is going to be stall. On the other hand then threads 
> doing file or socket I/O on these buffers will be in native (maybe 
> blocked, maybe not) and so aren't an issue. They will safepoint on 
> return or if they attempt to re-enter.
>
> -Alan

Ah, yes. I/O with direct buffers. All the places that use 
sun.nio.ch.DirectBuffer.address() to obtain address of DB and then 
access the memory directly would also have to obtain current guard from 
DB and keep it until after the last access to the memory. There are 28 
such usages in JDK.

Usages with blocking I/O could use a different strategy. They could use 
reference counting directly (invoke increment/decrement on the 
Deallocator's guardCount and deallocate when it drops to 0). I/O is 
usually invoked for bulk transfers, so adding an atomic increment and 
decrement of an int variable would not present too much overhead for 
such usages, I think.


Regards, Peter