D2 weak references

[Jason House]

Leandro Lucarella Wrote:

> Jason House, el 22 de abril a las 11:32 me escribiste:
> > Leandro Lucarella Wrote:
> > 
> > > Jason House, el 21 de abril a las 21:11 me escribiste:
> > > > Another alternative I came up with is notification when the GC clears or sets 
> > > > a mark on an object.  That would allow the weak ref to know that its 
> > > > information is suspect.  That approach would only required that the mark 
> > > > phase is done with all threads stopped.
> > > 
> > > I think instead of a notification mechanism access to the mark bit can be
> > > provided.
> > > 
> > > The mark phase is ran with all thread paused, so you don't need any
> > > notifications in that phase because nobody can ask the weak ref object for
> > > the underlaying pointer then.
> > > 
> > > When threads are resumed, the mark phase is complete, so the invariant of
> > > all live objects having the mark bit set and all the garbage having the
> > > bit unset should hold. If the GC guarantee that the mark bit is set
> > > *always* when a object is live (the mark bit clearing should be done with
> > > all threads stopped and that should be it), except only when the mark
> > > phase is running, then, a weak ref implementation can look at the mark bit
> > > to safely see if the reference is garbage or not (even before the sweep
> > > phase find it and call the finalizer).
> > > 
> > > I think this approach is both simple and efficient, it doesn't have races
> > > at all (unless I'm missing something, of course). The only problem is it's
> > > too tied to the current GC implementation. But I think any weak ref
> > > implementation will, so it looks like weak ref really belong to the GC.
> > 
> > Unfortunately, that is not efficient. The state used by the GC is in
> > flux during the sweep phase, so there is no easy lockless way to access
> > that data. Having to acquire a lock on every weakref dereference
> > absolutely kills performance.
> 
> The sweep phase don't touch mark bits. I can't possible understand why
> you should synchronize access to a (temporarily) read-only variable.

I'm mostly regurgitating what Sean Kelly said. I know that if the sweep deallocates at an object, the bits marking it become invalid. I don't disagree that reading the bits without a lock should be possible, but I also trust Sean's statement that it isn't easy. I'm trying to find something that doesn't require reworking or rewriting large parts of a garbage collector. 

> Mark bits are only written when:
> 1) Clearing all the mark bits before marking (this is done with all
>    threads running now, and this is what it should be changed to be done
>    when all threads are suspended)
> 2) Marking (threads are suspended in the current implementation)

Is that what it does? I realized recently that one could simple toggle a mark bit and avoid a clearing phase altogether.

 
> > I'm definitely open to hearing more ideas on how to efficiently
> > implement.
> 
> The only performance penalty of my proposal would be incrementing the time
> the world is stooped a bit (adding the marks cleaning phase there).
> I think is a fair price to pay (being that mark bits are implemented using
> bitmaps, it should be pretty fast resetting all bits to 0) for an easy and
> safe weak references implementations.
> 
> -- 
> Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
> ----------------------------------------------------------------------------
> GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
> ----------------------------------------------------------------------------
> ELLA FUE INFIEL, PERO EX POLOLO PAGÓ
> 	-- TV CHILE