<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 28, 2015 at 10:30 PM, SNL <span dir="ltr"><<a href="mailto:snl20465@gmail.com" target="_blank">snl20465@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div>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.</div><div><br></div><div>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 ?</div></div></blockquote><div>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.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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. </div><div><br></div><div>Any inputs will be appreciated.</div><div><br></div>
</div>
<br>_______________________________________________<br>
jemalloc-discuss mailing list<br>
<a href="mailto:jemalloc-discuss@canonware.com">jemalloc-discuss@canonware.com</a><br>
<a href="http://www.canonware.com/mailman/listinfo/jemalloc-discuss" target="_blank">http://www.canonware.com/mailman/listinfo/jemalloc-discuss</a><br>
<br></blockquote></div><br></div></div>