Re: Thread Local Storage?

There seems to be some confusion about what a GC is.

The GC will collect and reuse *everything* unless it can see that it is
still wanted because it found a pointer to it.

The reason to use GC_add_roots() is so that the GC can see your pointers
and won't reuse memory you allocated using the GC. If you don't call
GC_add_roots(),
or after you call GC_remove_roots(), the GC is free to reuse GC memory
pointed to from your TLS. That would be bad if you were still using it.


On Sat, Oct 19, 2013 at 7:42 AM, The Devils Jester <
[email protected]> wrote:

> 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 <[email protected]> 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 <
>> [email protected]> 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 <[email protected]> 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 <
>>>> [email protected]> 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 <[email protected]> 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 <
>>>>>> [email protected]> 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* <http://www.mailscanner.info/>,
>>>>>>> and is
>>>>>>> believed to be clean.
>>>>>>> _______________________________________________
>>>>>>> Gc mailing list
>>>>>>> Gc-V9/[email protected]
>>>>>>> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> This message has been scanned for viruses and
>>>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>>>>> and is
>>>>> believed to be clean.
>>>>>
>>>>> _______________________________________________
>>>>> Gc mailing list
>>>>> Gc-V9/[email protected]
>>>>> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>>>>
>>>>
>>>>
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
>>> is
>>> believed to be clean.
>>>
>>
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> _______________________________________________
> Gc mailing list
> Gc-V9/[email protected]
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>

_______________________________________________
Gc mailing list
Gc-V9/[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/