[PATCH] Intercept allocation to skim allocated types

[Dai MIKURUBE]

Thank you for the comments, John and Richard.

At first, I don't stick to this design and implementation (I'm saying not
to make misunderstanding).  I'd just like to solve the following problem.

1) Capture allocated types of as most objects as possible.
2) No need to change almost all the existing code.  Just adding some code.
3) Capture objects allocated by both global and in-class operator new.
 (Many projects naturally have many in-class operator new.)
4) Capture objects allocated by placement new.  (Placement new is used for
malloc() memory allocation in some projects.)
5) Actually, capturing object deallocation is less required for our
purpose.  (But, it's more required in general.)

If we can solve this problem in another better way, I'm so positive to
switch to the way.  Do you have any ideas?  It's useless without (3) and
(4) as I discussed in the previous comment and the document.

I guess it's a kind of "impossible" problem (please tell me if not!), but
we can make a progress to approximately good profiling.  Many developers
are in trouble with memory usage especially in big C++ projects (like
WebKit).  We can't ignore memory usage problems, and we need some
compiler's help to solve this problem.  Approximate analysis is much better
than nothing.  This method is proposed to be a good piece to profile each
project in its customized way (but better ways are welcome).


2013/1/31 Richard Smith <richard at metafoo.co.uk>

> On Wed, Jan 30, 2013 at 10:27 AM, John McCall <rjmccall at apple.com> wrote:
> > On Jan 30, 2013, at 2:42 AM, Dai MIKURUBE <dmikurube at acm.org> wrote:
> >>  Hello, what do you think about it, John and Richard?
> >
> > To be frank, the more I look at it, the more this seems like a very
> questionable language extension.  It adds a lot of linguistic and
> implementation complexity to some already-quite-complex parts of the
> language and implementation, all to benefit the approximately 0% of users
> that will know about and enable the feature.
> >
>
I agree that it's complex.  (It's the reason why we still welcome other
ideas.)

 > My understanding is that you'd just like to be able to track what types
> are being allocated.  Perhaps it would be better to replace operator new,
> record return addresses, and then somehow map those back to source code?
>
> I may not understand your idea well, but does it apply for in-class
operator new effectively?  ( == Don't we need to add another operator new
for *every* in-class operator new?)  I think it's the way we've already
tried.  In-class new is the main reason why we chose intercepting as
discussed in the doc.


My biggest concern here is that this extension won't do what you want,
> and won't be helpful for anyone else either. That's because it assumes
> that new and delete expressions are paired, which is simply false
> (even for a leak-free program), because it instruments placement new
> and class-specific operator new/delete. For instance:
>
>   {
>     char buffer[4];
>     new (&buffer) int;
>     // no corresponding operator delete call
>   }
>
> This will be overwhelmingly common within containers.
>
> Yeah, that's a problem.  That's the point that I said "to be a good piece
to profile each project in its customized way" above.

For example in Chromium and WebKit, we chose to get together with malloc's
memory profiling.  We count only intercepted objects whose addresses are
allocated by malloc.

Since the intercepting functions can be implemented for each project,
developers can use it as a piece of their own profiling.

If you were suggesting a mechanism to implicitly pass a type_info
> object to a global operator new, and to prefer that operator new in
> overload resolution, I think I would find that simple and useful
> enough to support. But the proposed approach does not seem generally
> useful.
>
I guess it has the same issue as above.  Does it apply for in-class
operator new?  (If I understand your idea correctly, we've already tried
it.)

-- 
Dai MIKURUBE
   dmikurube at acm.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130201/8eb75407/attachment.html>