D2 weak references

[Leandro Lucarella]

Jason House, el 23 de abril a las 12:51 me escribiste:
> > >     T opCall(){
> > >         T tmp = t; // force future conservative GC scan to find the pointer
> > >         if ( (tmp is null) || (pool.mark[index] == false) ){
> > 
> > pool.mark.test(index) is used in the GC code, I don't know if the array
> > syntax works. And to use the mark bit trick, I think something in the
> > lines of my patch is needed to ensure the mark bit is set for all live
> > objects.
> > 
> > >             t = null;
> > >             return null;
> > >         }
> > >         tmp = t; // avoid race where t was replaced with new data
> > 
> > I don't understand exactly what kind of race are you trying to avoid with
> > this (and how this assignation can avoid any race if there is one).
> 
> Consider this sequence:
> 1. GC runs mark phase and leaves object unmarked.
> 2. Weakref starts dereferencing and reads its hidden pointer.

Ok, I see now that this can happen because you first store the reference
into the stack so it can be seen in future collections.

What I'm not sure is if it's really necessary to do that step. What can go
wrong with this simple approach?

     T opCall() {
         if (!pool.mark.test(index))
             t = null;
         return t;
     }

Weakref only reads the reference *if* the mark bit is set, in which case
is safe to assume that the object is live.

If the object is garbage, the mark bit is unset and in that case the
reference is only *written* (the only race it could happen is the sweep()
can be called but in that case the reference is written to null too, so
there should be no problem with that, I guess...

As long as the test are successful (t is not overwritten to null), the GC
should be able to find the reference in the stack when the function
returns.

I'm probably missing something else...

> 3. Sweep calls finalizer and deallocates
> 4. A new object is allocated in the old location
> 5. Query for GC mark says we're ok
> 6. Weakref returns its old copy of the pointer
> 7. Pointer is used
> 8. Random behavior

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------