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

[Dai Mikurube]

Hi cfe-dev,

I wrote a patch to implement it, and uploaded the patch at
http://llvm-reviews.chandlerc.com/D298.

Could anyone tell me a good document about Clang's test?  My patch actually
doesn't have tests yet.  I'm not sure how to add new tests in Clang's
style...  Finally, I'd like to make sure that
https://gist.github.com/4535834 works as its comment.


On Tue, Jan 8, 2013 at 6:21 PM, Dai Mikurube <dmikurube at chromium.org> wrote:

> Hi Sean,
>
> Thanks for your suggestion.  DTrace sounds reasonable.  I may implement
> the general (described) way at first, but will try DTrace as a next step.
>
>
> On Tue, Jan 8, 2013 at 8:50 AM, Sean Silva <silvas at purdue.edu> wrote:
>
>> 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
>> >
>>
>
>
>
> --
> Dai MIKURUBE
>    dmikurube at chromium.org
>



-- 
Dai MIKURUBE
   dmikurube at chromium.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130115/b46e356f/attachment.html>