Per thread arenas

[SNL]

Another query:

I read that enabling tache interferes with arena related assertions. I
quickly tried a out small test case to check for double free(). I see that
the assertions get hit only when tache is disabled.

My question is, if tcache is enabled, will arena specific assertions ever
get hit ? I am okay if this happens in a deferred manner but it is an issue
if the assertions never get hit if tache is enabled.

Any pointers will be helpful.

On Thu, Apr 30, 2015 at 1:17 AM, Qinfan Wu <wuqinfan at gmail.com> wrote:

> The arenas would still be there until the whole process dies.
>
>
> On Wednesday, April 29, 2015, SNL <snl20465 at gmail.com> wrote:
>
>>
>> Right. What happens to arenas when thread dies ?
>>
>> On Wed, Apr 29, 2015 at 9:17 PM, Qinfan Wu <wuqinfan at gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Apr 28, 2015 at 10:30 PM, SNL <snl20465 at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> I am planning to assign each thread its own arena, as per my
>>>> understanding this is akin to having a per thread heap since arena
>>>> management is completely independent of each other.
>>>>
>>>> How this is know to affect performance and memory overheads ? I am sure
>>>> this would depend a lot on application allocation patterns but are any
>>>> generic numbers/data from past ?
>>>>
>>> If you have a lot of threads, having an arena for each thread could
>>> potentially increasing memory usage and fragmentation. Usually the default
>>> setting (4 arenas per cpu) is enough to reduce lock contention, since not
>>> every allocation needs to acquire the arena lock.
>>>
>>>>
>>>> In cases where allocation done by thread T1 is freed by thread T2, how
>>>> does jemalloc handles it ? Is there any basic garbage collection or
>>>> remote-free ( request to free by remote thread which owns the allocation )
>>>> implementation ? I see that this could lead to memory build up.
>>>>
>>>> Any inputs will be appreciated.
>>>>
>>>>
>>>> _______________________________________________
>>>> jemalloc-discuss mailing list
>>>> jemalloc-discuss at canonware.com
>>>> http://www.canonware.com/mailman/listinfo/jemalloc-discuss
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Cheers,
>> Sunny.
>>
>
>
> --
> Sent from Gmail Mobile
>



-- 

Cheers,
Sunny.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20150502/7419f14c/attachment.html>