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. 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.
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.
That said, maybe it is an option for Uwe.
-Alan.
