>
> 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.rez...@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
>
