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

[Dan Liew]

> 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

That is an option but that itself has problems...

- The test would be dependent on the threshold used by the allocator
to decided whether or not to use mmap(). If we pick a too large amount
of memory to allocate users might get annoyed. If we pick too small
amount of memory to allocate then changes to the allocator might break
the test.

- Thread safety. In a multi-threaded application there is a small
chance that additional mallocs (other than our own) may happen between
the first read from mallinfo() and the second read. If those
additional mallocs internally use mmap() there's no problem
(mallinfo.uordblks won't increase) but if they use sbrk()
mallinfo.uordblks will increase and possibly invalidate the test.
Maybe this isn't worth worrying about...

Attached is a rough draft of what you are suggesting. 10MiB wasn't
enough on my system to trigger mmap() usage but 20MiB was (the flaws
in our approach are already showing!). I wouldn't suggest you commit
this but feel free to try out the patch to see how it performs. It
"works fine for me" but I have no idea about other systems.

We probably ought to get the glibc devs to try and fix this...

-- 
Dan Liew
PhD Student - Imperial College London
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Try-to-fix-llvm-sys-Process-GetMallocUsage-under-all.patch
Type: text/x-patch
Size: 3864 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140429/24f8c1cb/attachment.bin>