D2 weak references

[Jason House]

Sean Kelly wrote:

> == Quote from Jason House (jason.james.house at gmail.com)'s article
>> Jarrett Billingsley Wrote:
>> > On Mon, Apr 20, 2009 at 5:03 PM, Sean Kelly <sean at invisibleduck.org>
>> > wrote:
>> >
>> > > The horrible thing about all this is it makes using a multithreaded
>> > > WeakRef horribly slow. �Even if the GC facility were provided for
>> > > what you want to do you're talking about acquiring a mutex in
>> > > the GC for every deref operation. �What a mess.
>> >
>> > Then take a hint from D2 and make them thread-local by default ;)  But
>> > provide a SharedWeakRef for the cases where you need it.
>> I'm pretty sure the GC can bypass thread locality for mark and sweep, so
>> thread local won't help.
> Anything that stops the sweep from occurring in parallel with a thread
> using the data bypasses this issue.
> 
> Yeah.  The unfortunate tradeoff is that finalizers are run while all these
> app threads are suspended, and if these finalizers enter a synchronized
> block they're likely to deadlock.  This happened enough with the Phobos
> GC that I was motivated to make the change in the first place.  It's
> unfortunate, but at least WeakRef is the only victim of the current
> approach that I'm aware of.

Is it possible for druntime to expose an option as to whether or not the 
sweep phase / finalizers should run while all threads are suspended?

It'd really suck to implement some kind of mark and sweep garbage collection 
just to compensate for how the standard mark and sweep garbage collector is 
implemented.

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.

If you like either of these ideas, I could attempt a patch to add the 
functionality.