Some GC and emulated TLS questions (GDC related)

[Iain Buclaw via Digitalmars-d]

On 16 July 2017 at 14:37, Johannes Pfau via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> Am Sat, 15 Jul 2017 10:49:39 +0000
> schrieb Joakim <dlang at joakim.fea.st>:
>
>> On Friday, 14 July 2017 at 09:13:26 UTC, Johannes Pfau wrote:
>> > Another solution could be to enhance libgcc emutls to allow
>> > custom allocators, then have a special allocation function in
>> > druntime for all D emutls variables. As far as I know there is
>> > no GC heap that is scanned, but not automatically collected?
>>
>> I believe that's what's done with the TLS ranges now, they're
>> scanned but not collected, though they're not part of the GC heap.
>
> Indeed. We used to use GC.addRange for this and this was said to be
> slow when using many ranges. So I'm basically asking whether the scan
> delegate has got the same problem or whether it can cope with thousands
> of small ranges.
> A scanned but not collected heap is slightly different, as the GC can
> internally treat the allocator memory as one huge memory range. When
> allocating using C malloc, every single allocation needs to be scanned
> individually. A scan+/do not collect allocator can probably be built
> using the std.experimental.allocator primitives but that code is not in
> druntime.
>
>>
>> > I'd need a way to completely manually manage GC.malloc/GC.free
>> > memory without the GC collecting this memory, but still
>> > scanning this memory for pointers. Does something like this
>> > exist?
>>
>> It doesn't have to be GC.malloc/GC.free, right?  The current
>> DMD-style emutls simply mallocs and frees the TLS data itself and
>> only expects the GC to scan it.
>
> The problem here again is whether this scales properly when using
> thousands of non contiguous memory ranges. DMD style TLS can allocate
> one memory block per thread for all variables. GCC style will allocate
> one block per thread and variable.
>
>>
>> > Another option is simply using the DMD-style emutls. But as far
>> > as I can see the DMD implementation never supported dynamic
>> > loading of shared libraries? This is something the GCC emutls
>> > support is quite good at: It doesn't have any platform
>> > dependencies (apart from mutexes and some way to store one
>> > thread specific pointer+destructor) and should work with all
>> > kinds of shared library combinations. DMD style emutls also
>> > does not allow sharing TLS variables between D and other
>> > languages.
>>
>> Yes, DMD's emutls was never made to work with loading multiple
>> shared libraries.  As for sharing with other languages without
>> copying the TLS data over, that seems a rare scenario.
>
> Yes, probably the best solution for now is to reimplement GCC style
> emutls with shared library support in druntime for all compilers and
> forget about C/C++ TLS compatibility. Even if we could get patches into
> libgcc it'd take years till all relevant systems have been updated to
> new libgcc versions.
>

I sense a revert coming on...

https://github.com/D-Programming-GDC/GDC/commit/cf5e9e323b26d21a652bc2933dd886faba90281c

Iain.