Per thread arenas

[Qinfan Wu]

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
> <javascript:_e(%7B%7D,'cvml','wuqinfan at gmail.com');>> wrote:
>
>>
>>
>> On Tue, Apr 28, 2015 at 10:30 PM, SNL <snl20465 at gmail.com
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','jemalloc-discuss at canonware.com');>
>>> http://www.canonware.com/mailman/listinfo/jemalloc-discuss
>>>
>>>
>>
>
>
> --
>
> Cheers,
> Sunny.
>


-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20150429/535cbb43/attachment.html>