<div dir="ltr"><div class="gmail_default" style>Hi Sean,</div><div class="gmail_default" style><br></div><div class="gmail_default" style>Thanks for your suggestion.  DTrace sounds reasonable.  I may implement the general (described) way at first, but will try DTrace as a next step.</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 8, 2013 at 8:50 AM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mac, you should hook this into DTrace and let DTrace handle all the<br>
data collection and filtering. This would save you the trouble of<br>
having to relink the browser, and would have basically no slowdown<br>
when disabled (just the overhead of argument shuffling + call + ret<br>
(and even this could be reduced)). That would be really convenient so<br>
that you could e.g. trace the memory allocation patterns of only a<br>
particular webpage, or easily iterate (like, 5 sec. iteration time) an<br>
analysis, filtering/aggregating on type, size, call stack, pid,<br>
thread, or anything else that DTrace can look at + whatever else you<br>
expose to it.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Sean Silva<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, Jan 7, 2013 at 6:01 AM, Dai Mikurube <<a href="mailto:dmikurube@chromium.org">dmikurube@chromium.org</a>> wrote:<br>
> Hello,<br>
><br>
> Does anyone have additional opinions about it?  If none, I think I'll create<br>
> a bug entry and start working on it soon.<br>
><br>
><br>
> On Fri, Dec 7, 2012 at 1:47 AM, Dai Mikurube <<a href="mailto:dmikurube@chromium.org">dmikurube@chromium.org</a>> wrote:<br>
>><br>
>> Thanks for your interest.<br>
>><br>
>> Does "the context information" mean like a call site (__FILE__ and<br>
>> __LINE__)?  If so, yes, preserving them may be useful.  It might be a good<br>
>> idea if it is committed to the Clang tree.  I didn't implement it in the<br>
>> prototype just because I didn't use it -- we're using calling stacks<br>
>> instead.<br>
>><br>
>><br>
>> On Thu, Dec 6, 2012 at 5:24 PM, Onewastedlife <<a href="mailto:onewastedlife@gmail.com">onewastedlife@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Interesting.. Why would you not preserve the context information as well?<br>
>>><br>
>>> Regard,<br>
>>> Ramneek<br>
>>><br>
>>> On Dec 6, 2012, at 11:28 PM, Dai Mikurube <<a href="mailto:dmikurube@chromium.org">dmikurube@chromium.org</a>> wrote:<br>
>>><br>
>>> Hi cfe-dev,<br>
>>><br>
>>> I'd like to propose a way of Type-Aware Memory Profiling in Clang.  It was<br>
>>> one of the lightning talks at the DevMtg by Nico Weber on behalf of me.<br>
>>> Slides and Video were recently published.<br>
>>> * <a href="http://llvm.org/devmtg/2012-11/Weber_TypeAwareMemoryProfiling.pdf" target="_blank">http://llvm.org/devmtg/2012-11/Weber_TypeAwareMemoryProfiling.pdf</a><br>
>>> *<br>
>>> <a href="http://llvm.org/devmtg/2012-11/videos/Weber_TypeAwareMemoryProfiling.mp4" target="_blank">http://llvm.org/devmtg/2012-11/videos/Weber_TypeAwareMemoryProfiling.mp4</a><br>
>>><br>
>>> Object's type information is useful to profile memory usage in a process.<br>
>>> Type info is, however, hard to use in C++ programs.  Our proposal is to make<br>
>>> it easy by compiler's help.  We implemented an early prototype, and the<br>
>>> prototype has been working in Chromium project for a couple of months.<br>
>>><br>
>>><br>
>>> What do you think?  I wonder if I could have your opinions about it.  The<br>
>>> details are discussed in this document.<br>
>>> <a href="https://docs.google.com/document/d/1zyJ3FJhheJ5iSxYaMXARkZcR61tx6r44euMJbWw8jFY/edit" target="_blank">https://docs.google.com/document/d/1zyJ3FJhheJ5iSxYaMXARkZcR61tx6r44euMJbWw8jFY/edit</a><br>
>>><br>
>>> tl;dr, we did it by user-defined intercepting functions for operator new<br>
>>> and delete.  If a developer defines a function __op_new_intercept__ (and if<br>
>>> a compiler option is given!), the function intercepts operator new calls.<br>
>>><br>
>>><br>
>>> An example follows :<br>
>>><br>
>>> $ cat typeaware.cc<br>
>>> #include <stdio.h><br>
>>> #include <typeinfo><br>
>>><br>
>>> struct Klass {<br>
>>>   int x, y, z;<br>
>>> };<br>
>>><br>
>>> void* __op_new_intercept__(<br>
>>>     void* address, std::size_t size, const std::type_info& type) {<br>
>>>   printf("Allocated %lu bytes for %s at %016p.\n",<br>
>>>          size, <a href="http://type.name" target="_blank">type.name</a>(), address);<br>
>>>   return address;<br>
>>> }<br>
>>><br>
>>> void* __op_delete_intercept__(<br>
>>>     void* address, std::size_t size, const std::type_info& type) {<br>
>>>   printf("Deallocated %lu bytes for %s at %016p.\n",<br>
>>>          size, <a href="http://type.name" target="_blank">type.name</a>(), address);<br>
>>>   return address;<br>
>>> }<br>
>>><br>
>>> int main() {<br>
>>>   int *i;<br>
>>>   Klass *k;<br>
>>>   i = new int(3);<br>
>>>   k = new Klass();<br>
>>>   delete k;<br>
>>>   delete i;<br>
>>>   return 0;<br>
>>> }<br>
>>><br>
>>> $ clang++ -fintercept-allocation-functions typeaware.cc<br>
>>><br>
>>> $ ./a.out<br>
>>> Allocated 4 bytes for i at 0x000000022df010.<br>
>>> Allocated 12 bytes for 5Klass at 0x000000022df030.<br>
>>> Deallocated 12 bytes for 5Klass at 0x000000022df030.<br>
>>> Deallocated 4 bytes for i at 0x000000022df010.<br>
>>><br>
>>> --<br>
>>> Dai MIKURUBE<br>
>>>    <a href="mailto:dmikurube@chromium.org">dmikurube@chromium.org</a><br>
>>><br>
>>> _______________________________________________<br>
>>> cfe-dev mailing list<br>
>>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Dai MIKURUBE<br>
>>    <a href="mailto:dmikurube@chromium.org">dmikurube@chromium.org</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Dai MIKURUBE<br>
>    <a href="mailto:dmikurube@chromium.org">dmikurube@chromium.org</a><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Dai MIKURUBE</div><div>   <a href="mailto:dmikurube@chromium.org" target="_blank">dmikurube@chromium.org</a></div>
</div>