[concurrency-interest] DirectByteBuffers and reachabilityFence

Gil Tene gil at azul.com
Thu Dec 10 23:30:39 EST 2015


> On Dec 10, 2015, at 6:47 PM, Peter <jini at zeus.net.au> wrote:
> 
> Would another workaround be to use a phantom reference  for the DBB?

That's exactly what sun.misc.Cleaner already does, and DBB already uses a cleaner. Cleaners and phantom references (or weak, or soft, or finalizers) do not get rid of the race. A DBB 'this' can become unreachable between computing an address and accessing it, GC picks up on that and enqueues the phantom reference (the Cleaner object), and the Cleaner object explicitly frees the buffer memory that was held by the DBB instance. Even though the DBB memory isn't reclaimed until the next GC, that doesn't matter, since the buffer has been freed [and potentially recycled elsewhere] before the unsafe call to perform the last read or write operation into it is made.

There is currently (prior to reachabilityFence) no way I know of in Java to close this race in DBB short of following each unsafe access (e.g. in each put or get) with some carefully crafted (and also expensive and/or optimization-hurting) volatile accesses. E.g. you can add an operation that stores 'this' to an extra volatile field initialized to point refer to 'this'. E.g. I think something like: ... unsafe(…); this.dummy.dummy = this; … might be sufficient to ensure that 'this' is reachable until after the unsafe call if dummy is volatile. But it will make buffer operations dead slow...

> 
> The memory isn't reclaimed by gc until the phantom reference is cleared or becomes reachable.
> 
> The phantom reference queue functionality could be implemented in static methods and fields.  Classes aren't gc'd until all classes in a ClassLoader and the ClassLoader itself becomes reachable.
> 
> Just curious.
> 
> Regards,
> 
> Peter.
> 
> Sent from my Samsung device.
> ---- Original message ----
> From: Doug Lea <dl at cs.oswego.edu>
> Sent: 11/12/2015 10:14:54 am
> To: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] DirectByteBuffers and reachabilityFence
> 
> On 12/10/2015 07:56 AM, Andrew Haley wrote:
> > On 12/10/2015 12:51 PM, Vitaly Davidovich wrote:
> >> I can see a few reasons against extending `this` lifetime at this stage of
> >> java's life, but what were the objections last time(s) this came up?
> >
> > Basically twofold.  Mostly efficiency, but also a reluctance to change
> > long-settled language semantics.  Making changes to something as
> > fundamental as this is always much tricker than people expect.  The
> > great advantage of reachabilityFence is that we can do it without a
> > lot of complex argument and politics.
> >
> 
> Like Andrew and others who have seen periodic protracted
> discussions of this issue over the past decade or so, I'm not
> too optimistic.
> 
> But this is also one reason for considering a @Finalized annotation
> for fields (not classes!), that would give essentially this
> guarantee only in those cases it was requested. Compilers would
> translate methods/blocks accessing @Finalized field r
> (as in .. use(r); ...)  to  the equivalent of:
>    try { ... use(r); ... } finally { reachabilityFence(); }
> 
> In the mean time, users can at least arrange this manually though.
> There is no reason to believe that the performance impact would
> be any different in manual vs automated forms, as long as some of
> us are willing to help hotspot minimize it.
> 
> -Doug
> 
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151211/ba7f26b9/attachment-0001.bin>


More information about the Concurrency-interest mailing list