[cfe-dev] Proposal: Type-Aware Memory Profiling

[Sean Silva]

On Mac, you should hook this into DTrace and let DTrace handle all the
data collection and filtering. This would save you the trouble of
having to relink the browser, and would have basically no slowdown
when disabled (just the overhead of argument shuffling + call + ret
(and even this could be reduced)). That would be really convenient so
that you could e.g. trace the memory allocation patterns of only a
particular webpage, or easily iterate (like, 5 sec. iteration time) an
analysis, filtering/aggregating on type, size, call stack, pid,
thread, or anything else that DTrace can look at + whatever else you
expose to it.

-- Sean Silva

On Mon, Jan 7, 2013 at 6:01 AM, Dai Mikurube <dmikurube at chromium.org> wrote:
> Hello,
>
> Does anyone have additional opinions about it?  If none, I think I'll create
> a bug entry and start working on it soon.
>
>
> On Fri, Dec 7, 2012 at 1:47 AM, Dai Mikurube <dmikurube at chromium.org> wrote:
>>
>> Thanks for your interest.
>>
>> Does "the context information" mean like a call site (__FILE__ and
>> __LINE__)?  If so, yes, preserving them may be useful.  It might be a good
>> idea if it is committed to the Clang tree.  I didn't implement it in the
>> prototype just because I didn't use it -- we're using calling stacks
>> instead.
>>
>>
>> On Thu, Dec 6, 2012 at 5:24 PM, Onewastedlife <onewastedlife at gmail.com>
>> wrote:
>>>
>>> Interesting.. Why would you not preserve the context information as well?
>>>
>>> Regard,
>>> Ramneek
>>>
>>> On Dec 6, 2012, at 11:28 PM, Dai Mikurube <dmikurube at chromium.org> wrote:
>>>
>>> Hi cfe-dev,
>>>
>>> I'd like to propose a way of Type-Aware Memory Profiling in Clang.  It was
>>> one of the lightning talks at the DevMtg by Nico Weber on behalf of me.
>>> Slides and Video were recently published.
>>> * http://llvm.org/devmtg/2012-11/Weber_TypeAwareMemoryProfiling.pdf
>>> *
>>> http://llvm.org/devmtg/2012-11/videos/Weber_TypeAwareMemoryProfiling.mp4
>>>
>>> Object's type information is useful to profile memory usage in a process.
>>> Type info is, however, hard to use in C++ programs.  Our proposal is to make
>>> it easy by compiler's help.  We implemented an early prototype, and the
>>> prototype has been working in Chromium project for a couple of months.
>>>
>>>
>>> What do you think?  I wonder if I could have your opinions about it.  The
>>> details are discussed in this document.
>>> https://docs.google.com/document/d/1zyJ3FJhheJ5iSxYaMXARkZcR61tx6r44euMJbWw8jFY/edit
>>>
>>> tl;dr, we did it by user-defined intercepting functions for operator new
>>> and delete.  If a developer defines a function __op_new_intercept__ (and if
>>> a compiler option is given!), the function intercepts operator new calls.
>>>
>>>
>>> An example follows :
>>>
>>> $ cat typeaware.cc
>>> #include <stdio.h>
>>> #include <typeinfo>
>>>
>>> struct Klass {
>>>   int x, y, z;
>>> };
>>>
>>> void* __op_new_intercept__(
>>>     void* address, std::size_t size, const std::type_info& type) {
>>>   printf("Allocated %lu bytes for %s at %016p.\n",
>>>          size, type.name(), address);
>>>   return address;
>>> }
>>>
>>> void* __op_delete_intercept__(
>>>     void* address, std::size_t size, const std::type_info& type) {
>>>   printf("Deallocated %lu bytes for %s at %016p.\n",
>>>          size, type.name(), address);
>>>   return address;
>>> }
>>>
>>> int main() {
>>>   int *i;
>>>   Klass *k;
>>>   i = new int(3);
>>>   k = new Klass();
>>>   delete k;
>>>   delete i;
>>>   return 0;
>>> }
>>>
>>> $ clang++ -fintercept-allocation-functions typeaware.cc
>>>
>>> $ ./a.out
>>> Allocated 4 bytes for i at 0x000000022df010.
>>> Allocated 12 bytes for 5Klass at 0x000000022df030.
>>> Deallocated 12 bytes for 5Klass at 0x000000022df030.
>>> Deallocated 4 bytes for i at 0x000000022df010.
>>>
>>> --
>>> Dai MIKURUBE
>>>    dmikurube at chromium.org
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>
>>
>> --
>> Dai MIKURUBE
>>    dmikurube at chromium.org
>>
>
>
>
> --
> Dai MIKURUBE
>    dmikurube at chromium.org
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>