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.
