[Gc] Thread Local Storage?
The Devils Jester
thedevilsjester at gmail.com
Fri Oct 18 05:11:51 PDT 2013
The number of threads created is not a known value, but I suspect it will
often be very low with longer life spans. My question is more about
accumulation. If I create thousands (or hundreds of thousands) of threads
over the lifetime of the program, even if this is days, weeks, or months,
will the performance be impacted by all of the registered areas? Would it
be safe to 'unregister' an area when the thread is ended, even if GC has
On Fri, Oct 18, 2013 at 12:42 AM, Bruce Hoult <bruce at hoult.org> wrote:
> That all depends on how often you are creating and deleting threads.
> If you are creating and deleting thousands of threads between each GC then
> 2) will be lower impact. If threads live for many seconds or minutes then
> 1) will be lower impact.
> If you only have a few dozen threads then performance in this area is
> probably irrelevant.
> On Fri, Oct 18, 2013 at 6:29 PM, The Devils Jester <
> thedevilsjester at gmail.com> wrote:
>> The platform that I am currently experiencing the issue on is Ubuntu
>> Linux 64bit 13.04, using GCC 4.8.
>> If I just have a few pointers to some containers, would it be safe to
>> simply add those pointers to the 'roots'?
>> You say that there might be performance problems with approach 1? I only
>> have a few TLS pointers, do you think this would have any kind of
>> performance impact? Since I (re)instantiate these pointers for every
>> thread, I would assume that I would have to "mark" every instance of these
>> pointers? Would the performance hit start to grow, then, as new threads
>> are created and points are marked?
>> On a slightly related note, your approach 2 has me wondering if there is
>> some other generic call back (not specific to roots) that I can set for
>> before (and maybe after) a GC occurs. (It would help debug things that
>> happen specifically at a GC).
>> On Fri, Oct 18, 2013 at 12:09 AM, Bruce Hoult <bruce at hoult.org> wrote:
>>> Fundamentally, someone needs to make sure that the thread local storage
>>> is added to the root areas the GC scans pointers from.
>>> Ideally, the standard GC would do that. I don't know what your system is
>>> and therefore whether it is practical for the GC to locate the TLS global
>>> But you can do it yourself.
>>> There are two approaches:
>>> 1) for fixed size areas (or even individual pointer variables) you can
>>> call GC_add_roots(low_address, high_address) on as many areas as necessary.
>>> You can also remove these areas if necessary. Or remove and re-add if they
>>> change size. See gc.h
>>> 2) for things that change often during execution, it can be better to
>>> point GC_push_other_roots at your own function, which will be called near
>>> the start of every GC. Your function should call e.g. GC_push_all(bottom,
>>> top) on each appropriate area you want the GC to scan from. Make sure you
>>> save the old value of GC_push_other_roots before installing your function,
>>> and call it too. This is all defined in include/private/gc_priv.h
>>> Unless you see performance problems, it's safer to stick to approach 1).
>>> On Fri, Oct 18, 2013 at 5:20 PM, The Devils Jester <
>>> thedevilsjester at gmail.com> wrote:
>>>> I have a couple of stl containers that hold pointers to classes which
>>>> inherit from gc. The containers are created via a template that includes
>>>> the gc_allocator. This has worked great for quite awhile, however I have
>>>> recently made a couple of the containers thread local using __thread. When
>>>> I do this, however, (while still in my main thread and never having created
>>>> a new thread), at some arbitrary point (maybe when GC kicks in?) my
>>>> container size goes from whatever it was, to zero.
>>>> I can remove the __thread from the containers and everything works as
>>>> desired, for an indefinite period of time, but adding __thread back in,
>>>> always causes the same issue. Is there some special initialization I need
>>>> to do to allow for __thread (and similar) to work correctly in the GC?
>>>> This message has been scanned for viruses and
>>>> dangerous content by *MailScanner* <https://www.mailscanner.info/>, and
>>>> believed to be clean.
>>>> Gc mailing list
>>>> Gc at linux.hpl.hp.com
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <https://www.mailscanner.info/>, and
>> believed to be clean.
>> Gc mailing list
>> Gc at linux.hpl.hp.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gc