Per thread arenas

[SNL]

Jason,

Any inputs will be really helpful.

On Sat, May 2, 2015 at 3:36 PM, SNL <snl20465 at gmail.com> wrote:

>
> 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.
>



-- 

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