RFR  8148117: Move sun.misc.Cleaner to jdk.internal.ref
peter.levart at gmail.com
Thu Jan 28 19:42:59 UTC 2016
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.
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.
More information about the core-libs-dev