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

[Vitaly Davidovich]

>
> queue is marked volatile, so a simple reordering of the lines should be
> just as effective:
>      Reference(T referent, ReferenceQueue<? super T> queue) {
>          this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
>          this.referent = referent;
>      }


Won't mean much since the plain referent store can move above the queue
store.

On Wed, Oct 21, 2015 at 1:10 PM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com
> wrote:

> >> Might the following be needed or not:
> >>
> >>     Reference(T referent, ReferenceQueue<? super T> queue) {
> >>         this.referent = referent;
> >>         this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
> >>         reachabilityFence(referent);
> >>     }
> >
>
> queue is marked volatile, so a simple reordering of the lines should be
> just as effective:
>
>      Reference(T referent, ReferenceQueue<? super T> queue) {
>          this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
>          this.referent = referent;
>      }
>
> A simplistic interpretation of GC (as for example seen here:
> http://stackoverflow.com/questions/10795505/how-do-garbage-collectors-know-about-references-on-the-stack-frame
> ) might lead one to believe that referent is reachable until the end of the
> constructor because it's in the stack frame. The point at which
> reachability analysis kicks in, in the middle of such a simple two liner
> and removes the referent from the stack (or other variations such as
> inlining) is presumably highly implementation dependent and should not be
> relied on, but I'm guessing that's the reason you're not able to reproduce
> an early GC.
>
> Thanks
> Moh
>