[Gc] Thread Local Storage?

Bruce Hoult bruce at hoult.org
Fri Oct 18 11:35:19 PDT 2013


Yes, of course, that's the reason GC_remove_roots() exists.

What do you mean "even if GC has not occurred"? That's irrelevant.


On Sat, Oct 19, 2013 at 1:11 AM, The Devils Jester <
thedevilsjester at gmail.com> wrote:

> 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
> not occurred?
>
>
> 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 areas.
>>>>
>>>> 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 is
>>>>> believed to be clean.
>>>>> _______________________________________________
>>>>> Gc mailing list
>>>>> Gc at linux.hpl.hp.com
>>>>> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>>>>
>>>>
>>>>
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by *MailScanner* <https://www.mailscanner.info/>, and
>>> is
>>> believed to be clean.
>>>
>>> _______________________________________________
>>> Gc mailing list
>>> Gc at linux.hpl.hp.com
>>> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>>
>>
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <https://www.mailscanner.info/>, and is
> believed to be clean.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20131019/35d46e46/attachment-0001.htm


More information about the Gc mailing list