[concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor?

Gregg Wonderly gergg at cox.net
Wed Oct 21 19:12:11 EDT 2015


Yes David, but the object holding a strong reference can not guarantee that itself is strongly referenced.  So, the reference graph could result in the reference never being queued if any part of the graph is not strongly referenced.  We’ve gone through this before on this list with a use of PhantomReference that had exactly this problem.  I had to establish a complete strong reference graph to make the class work in production and that made it impossible to create a “utility” class because the use had to have very explicit reference semantics.

Gregg

> On Oct 21, 2015, at 5:54 PM, David Holmes <davidcholmes at aapt.net.au> wrote:
> 
> All fields hold strong references, not just static fields. It is only locals/stack-variables that don’t guarantee reachability.
>  
> David
>  
> From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Gregg Wonderly
> Sent: Thursday, October 22, 2015 8:10 AM
> To: Vitaly Davidovich
> Cc: thurstonn; concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor?
>  
>  
>> On Oct 21, 2015, at 4:44 PM, Vitaly Davidovich <vitalyd at gmail.com <mailto:vitalyd at gmail.com>> wrote:
>>  
>>> But the referent arg is on the stack (since the constructor is)
>>> Aren't all variables on the stack strongly reachable?
>>  
>> No.  The stacks are scanned and oopmaps are inspected to find live objects, which then serve as the root of a reachability graph, but mere presence of an object on the stack does not mean it's reachable for GC purposes.
>  
> That seems highly problematic for WeakReference and company to be usable.  How can any object using those APIs guarantee that the object itself is strongly reachable?  Doesn’t seem like they can.  Strong references can only ever be guaranteed by using a static reference, which makes for non-static environments to be really difficult to “develop” in.
>  
> Gregg Wonderly
> 
> 
>  
> On Wed, Oct 21, 2015 at 4:29 PM, thurstonn <thurston at nomagicsoftware.com <mailto:thurston at nomagicsoftware.com>> wrote:
> But the referent arg is on the stack (since the constructor is)
> Aren't all variables on the stack strongly reachable?
> 
> 
> 
> --
> View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/Is-Reference-reachabilityFence-needed-in-Reference-constructor-tp12819p12824.html <http://jsr166-concurrency.10961.n7.nabble.com/Is-Reference-reachabilityFence-needed-in-Reference-constructor-tp12819p12824.html>
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com <http://nabble.com/>.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>  
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151021/4bd7544d/attachment.html>


More information about the Concurrency-interest mailing list