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

[Dai Mikurube]

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