<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 28, 2014 at 3:40 PM, Dan Liew <span dir="ltr"><<a href="mailto:dan@su-root.co.uk" target="_blank">dan@su-root.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Thanks for the reply.<br>
<div class=""><br>
On 28 April 2014 20:01, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
> The problem with tcmalloc seems like a real problem.  I can't think of any<br>
> good workarounds.  My best worst idea is to try to figure out if malloc is<br>
> coming from libc with dlsym and dlopen, and then use that to decide whether<br>
> we add these two numbers together.<br>
<br>
</div>I'm not sure we can always assume libc is a dynamic library. A user<br>
can statically link to libc if they really want to. For the static<br>
case something like libbfd could help provided the symbol table was<br>
still around.<br>
<br>
It seems to me whatever we do is going to incur some overhead. Calling<br>
dlsym() sounds a little bit expensive so we might be best off doing<br>
the test on the first call to sys::Process::GetMallocUsage() and<br>
storing a static variable that indicates the result of the test so we<br>
don't need to do it again on subsequent calls to GetMallocUsage().<br>
This would mean if an application decided to change its allocator<br>
during execution GetMallocUsage() might break but changing the<br>
allocator during execution sounds insane anyway, so hopefully no one<br>
does that.</blockquote><div><br></div><div>I think the static libc case breaks the dlsym trick.  The sanitizers, for example, provide a statically linked malloc implementation.<br></div><div><br></div><div>It's probably OK to have one-time startup overhead.  We only use this for -time-passes.  So... allocate 10mb and see how the counters update?  =D</div>
</div></div></div>