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

[Dai Mikurube]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130108/0eaaf022/attachment.html>