[LLVMdev] [RFC] [PATCH] Fix for sys::Process::GetMallocUsage() when using ptmalloc2 allocator in glibc

[Reid Kleckner]

On Mon, Apr 28, 2014 at 3:40 PM, Dan Liew <dan at su-root.co.uk> wrote:

> Thanks for the reply.
>
> On 28 April 2014 20:01, Reid Kleckner <rnk at google.com> wrote:
> > The problem with tcmalloc seems like a real problem.  I can't think of
> any
> > good workarounds.  My best worst idea is to try to figure out if malloc
> is
> > coming from libc with dlsym and dlopen, and then use that to decide
> whether
> > we add these two numbers together.
>
> I'm not sure we can always assume libc is a dynamic library. A user
> can statically link to libc if they really want to. For the static
> case something like libbfd could help provided the symbol table was
> still around.
>
> It seems to me whatever we do is going to incur some overhead. Calling
> dlsym() sounds a little bit expensive so we might be best off doing
> the test on the first call to sys::Process::GetMallocUsage() and
> storing a static variable that indicates the result of the test so we
> don't need to do it again on subsequent calls to GetMallocUsage().
> This would mean if an application decided to change its allocator
> during execution GetMallocUsage() might break but changing the
> allocator during execution sounds insane anyway, so hopefully no one
> does that.


I think the static libc case breaks the dlsym trick.  The sanitizers, for
example, provide a statically linked malloc implementation.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140428/22b3a944/attachment.html>