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
