Hard-to-reproduce GC bug

[dsimcha]

== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> Oh!  You're using the built-in thread-local storage.  I don't think that's fully
> implemented yet (Walter, please correct me if I'm wrong).  You might want to
> use the thread-local storage feature in the Thread class for now.  Depending
> on your memory / performance requirements:
> import core.thread;
> void main()
> {
>     auto t = new ThreadLocal!(int);
>     t.val = 5;
>     writefln( t.val );
> }
> -or-
> import core.thread;
> void main()
> {
>     auto key = Thread.createLocal();
>     Thread.setLocal( key, cast(void*) 5 );
>     writefln( cast(int) Thread.getLocal( key ) );
> }
> the second approach is closer to how C/C++ TLS works and saves
> the allocation of a wrapper struct, but is clearly more complicated
> in exchange.  your best bet is probably to simply use ThreadLocal
> for now, since it will be easier to change later when built-in TLS
> works properly.
> Sean

Thanks, though I'm way ahead of you in that I already did this.  Works great,
except it's a little bit slow.

I'm actually working on an implementation of the SuperStack proposed by Andrei
about a month ago, which was why I needed good TLS.  It seems like with the
current implementation (using the faster explicit key solution instead of the
slower class-based solution), about 1/3 of my time is being spent on retrieving
TLS.  I got this number by caching the stuff from TLS on the stack of the calling
function and passing it in as a parameter.  This may become a semi-hidden feature
for wringing out that last bit of performance from SuperStack.  Is TLS inherently
slow, or is the druntime implementation relatively quick and dirty and likely to
improve in the future?