Am Thu, 30 May 2013 01:19:10 +0200
schrieb "Iain Buclaw" <ibuc...@ubuntu.com>:
> OK, from today till the end of the week I'm going to be sitting
> down and thinking through this, as I'd really like the emitting
> of _tlsstart and _tlsend out of the compiler by hook or by crook.
>
>
> Phase one - start:
>
> We have rt/tls.S. Have added this to the libdruntime builds, and
> I see no immediate problems running this through the testsuite
> (though - that is never really a good indicator of anything).
> Drawbacks, this is only available for linux at the moment. But
> that's fine if we keep this temporary for the week.
Do you know what that comment in that file "Sadly, this does not work
because ld orders [...]" is about?
> Phase two - plan:
>
> The GC has a hook gc_addRoot used for the purpose of tracking GC
> allocated memory in C-land. The idea I've got turning over in my
> head at the moment is that any thread local decls that are
> 'new-able' (classes, pointers, d arrays) are added as a root upon
> 'new' declaration, this is safe-guarded by a thread-local static
> to prevent multiple calls to gc_addRoot.
>
The good part part is that this will work with non-contiguous TLS, i.e
GCC emulated TLS. The bad part is that it'll be very slow so it should
really only be a fallback. And what about non-newable types?
Why don't we register all thread local variables in a module
constructor instead (in the C one or in the D one)?
static int a;
static void* b;
static this()
{
gc_addRoot(&a);
gc_addRoot(&b);
}
Then unload in the module destructor. We could try to optimize that,
although we have to be careful:
static this() //pseudo code
{
void*[2] roots;
roots[0] = &a;
roots[1] = &b;
if(isContiguous(roots[])) //Sort. need to allow alignment though
gc_addRange(roots[0], roots[$] + size) //probably need to keep a
size array as well
else
foreach(ptr; roots)
gc_addRoot(ptr);
}
This can detect if the TLS memory is contiguous and then only add one
range per module. Maybe it's not worth the effort as long as it's only
a slow fallback (and even with the optimization it'll still be slow)
> Though this should not be required if we have a proper TLS GC in
> place.
Do you mean Martin Nowak's shared library/TLS work? That indeed sounds
like the proper solution.
(And maybe the D community should develop a sane standard interface to
the runtime linker to access sections. Then go lobbying all major libcs
out there...)
