RFR  8148117: Move sun.misc.Cleaner to jdk.internal.ref
Alan.Bateman at oracle.com
Mon Jan 25 13:31:37 UTC 2016
On 24/01/2016 17:10, Peter Levart wrote:
> 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:
> 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
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
That said, maybe it is an option for Uwe.
More information about the core-libs-dev