<div dir="ltr"><div><br></div><div>Another query:</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>Any pointers will be helpful.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 30, 2015 at 1:17 AM, Qinfan Wu <span dir="ltr"><<a href="mailto:wuqinfan@gmail.com" target="_blank">wuqinfan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The arenas would still be there until the whole process dies.<div class="HOEnZb"><div class="h5"><br><br>On Wednesday, April 29, 2015, SNL <<a href="mailto:snl20465@gmail.com" target="_blank">snl20465@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>Right. What happens to arenas when thread dies ? </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 29, 2015 at 9:17 PM, Qinfan Wu <span dir="ltr"><<a>wuqinfan@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Apr 28, 2015 at 10:30 PM, SNL <span dir="ltr"><<a>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></span><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"><span><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></span>_______________________________________________<br>
jemalloc-discuss mailing list<br>
<a>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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br>Cheers,<br>Sunny. <br></div>
</div>
</blockquote><br><br></div></div><span class="HOEnZb"><font color="#888888">-- <br>Sent from Gmail Mobile<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><br>Cheers,<br>Sunny. <br></div>
</div>