[Gc] Thread Local Storage?

The Devils Jester thedevilsjester at gmail.com
Fri Oct 18 11:42:02 PDT 2013


Since a GC can happen at any arbitrary time, what happens if I use
GC_add_roots on my TLS at the start of the thread, and then GC_remove_roots
right before the thread exits, but the GC has not collected the data yet?
 Will the resources continue to pile up until the thread has had its
resources released?



On Fri, Oct 18, 2013 at 1:35 PM, Bruce Hoult <bruce at hoult.org> wrote:

> 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/20131018/5fc6914a/attachment.htm


More information about the Gc mailing list