<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 7:40 PM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.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 class="">On Wed, May 11, 2016 at 6:56 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@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 Wed, May 11, 2016 at 12:25 AM, Rong Xu <span dir="ltr"><<a href="mailto:xur@google.com" target="_blank">xur@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">xur added a comment.<br>
<br>
This avoids calloc in lprofCreateBufferIO() which is not used at all if there is not value profiles.<br>
<br>
But how about the malloc calls from  setFilenamePossiblyWithPid() and truncateCurrentFile(). They are not from value profiling, but they also call dynamic memory allocation.<br></blockquote><div><br></div></span><div>I suspect some combination of luck and that we officially expose only a limited API to users means we haven't hit those. This issue has only recently reached our priority list and we'll be looking more deeply at the issues and our requirements.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Maybe we should convert all these into alloca or using pre-allocated memory.<br></blockquote><div><br></div></span><div>I would prefer pre-allocated, but I suppose alloca is fine and avoids a fixed limit. The downside of alloca is that in the worst case circumstances, we can overflow the stack and trigger an issue that is difficult to debug; at least for a fixed buffer we can return an error code.</div></div></div></div></blockquote><div><br></div></span><div>I have same concern on using alloca, thus prefer fixed allocation. This presents some challenge when serializing VP data, but it is doable.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
David and I are working on to get the profile runtime malloc free (or at least avoiding re-entrance to malloc) in the past few days. Hopefully we can have some discussion on this soon.<br></blockquote><div><br></div></span><div>Great! Glad we are working in the same direction.</div></div></div></div></blockquote><div><br></div></span><div>yes -- I am in the process of getting rid of dynamic allocations one by one. The first couple of ones are in profile dumper.</div></div></div></div></blockquote><div><br></div><div>This should make this patch unnecessary, right? I think I'll just help your effort to remove allocations from the dumper (if you haven't already gotten to them first).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> The last/major one is in the instrumenter.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>What do you mean "avoiding re-entrace to malloc"? Are you making calls into the runtime lib from malloc? (for value profiling presumably? I would not have guessed that malloc libs were using indirect calls)</div></div></div></div></blockquote><div><br></div></span><div>It is the tcmalloc implementation (with source) -- it is feature rich that also invokes various user define hooks .</div></div></div></div></blockquote><div><br></div><div>Ah, I was not considering hooks.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div><br></div><div>David<br></div></font></span><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><font color="#888888"><div><br></div><div>-- Sean Silva</div></font></span><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="http://reviews.llvm.org/D20148" rel="noreferrer" target="_blank">http://reviews.llvm.org/D20148</a><br>
<br>
<br>
<br>
</div></div></blockquote></span></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>