D2 weak references

[Sean Kelly]

== Quote from Jason House (jason.james.house at gmail.com)'s article
> Sean Kelly 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.
> I was hoping for a lock-free query that would return garbage (without crashing) in the rare case that
a race occurred. If I get garbage (and says the object is marked) then the finalizer has run when I
recheck the weak ref.  Do all druntime queries acquire the GC lock? I'm hoping to do about 100_000+ of
these operations per second per core (and do other work too).

They all acquire the lock.  And even with per-thread GCs, any
operation against the shared GC will acquire its lock as well.
I'm not terribly inclined to try and make a lock-free GC to
avoid this for even simple queries.

> As long as memory blocks are not released to the OS while all threads are unpaused, lock-free
operations should be possible.

Blocks may be released to the OS at this time, but currently
they will only be for pools that are completely empty.  In
practice this generally only happens for a pool allocated
specifically for a single big allocation.  As for lock-free GC
stuff in general, there's too much state information involved
to make me terribly inclined to give it a shot without some
serious motivation.

> As a side note, does druntime use multiple threads for the garbage collector? Scalability with Tango
and a memory intensive application was horrible last time I tried renting an 8 core system. It may have
been my fault, but the garbage collector is a convenient scape goat.

Currently, no.  The Druntime GC is nearly identical to the
Tango GC but for a few tweaks here and there.  I'm eventually
going to make a GC with per-thread heaps as an alternative,
but I haven't found the time yet.

The current GC is a convenient scapegoat, but it's also a valid
one if the threads in this app churn through memory continuously.
If nothing else the threads are almost definitely convoying on the
GC mutex, not to mention the cost of "stop the world" collections.
You might want to look into judicious use of GC.reserve() to help
with this some.  In apps that grow memory rather than just churn
through it, you can see a pretty solid benefit from GC.reserve().