[PATCH] Intercept allocation to skim allocated types

[Dai MIKURUBE]

Thank you, Douglas!

I'll talk to Eric.

2013/3/26 Douglas Gregor <dgregor at apple.com>:
> Hello Dai,
>
> Eric Christopher has a ton of knowledge about this area of the compiler. I
> think he'll be able to help more than I.
>
> - Doug
>
> On Mar 18, 2013, at 2:30 AM, Dai MIKURUBE <dmikurube at acm.org> wrote:
>
> Hi John and Douglas,
>
> Sorry for my mails a lot of times, but I found that just the first
> part of your suggestion would work enough for our purpose!
>
> It works for our purpose only with the association of 1) the type of a
> particular "new" expression and 2) the address at which the call to
> operator new occurs (DWARF does this sort of thing) as you suggested.
> It's because we already have a malloc profiler, and we focus on
> malloc'ed memory blocks.  A result of the malloc profiler should have
> the address at which the call to operator new occurs.
>
>
> Could you introduce the expected reviewer for that?  I think I'll be
> starting to implement your suggestion soon, but I'd like to discuss
> the rough design and how to implement it before starting.
>
> # I wonder if I could attend the next LLVM devmtg, and talk about it
> with him or her face-to-face quickly.
>
> 2013/2/27 Dai MIKURUBE <dmikurube at acm.org>:
>
> Hi John,
>
> Thank you for your reply.
>
>
> 2013/2/27 John McCall <rjmccall at apple.com>
>
>
> On Feb 24, 2013, at 12:38 AM, Dai MIKURUBE <dmikurube at acm.org> wrote:
>
> Hi Douglas and John,
>
> I started to try your approach, but I'm still not sure what it does, and
> still a little doubtful that it's easy to catch allocation by non-global
> (in-class) operator news.  When a project has 100 in-class operator news,
> doesn't it need to prepare 101 replacement functions?  If it needs, I think
> it's so unrealistic.  We cannot track all changes in a big project (e.g.
> WebKit).  If a developer adds a new class with its local operator new, it's
> impossible to track all such local operator news.
>
> Could you tell me make sure 1) what should happen in the compiler and 2)
> what replacement functions should be added, in the simple example below?
>
> (Also, I'd like to know where is the DWARF code in Clang you mentioned.)
>
>
> Okay, here's the deal.
>
> I don't think we're really interested in taking your original language
> extension into mainline clang.  It's invasive, it's complicated, it's novel,
> and it doesn't seem to have broad applicability.
>
> Yes and yes, your point on my original extension is right at all.  I also
> think it's complicated.  (So, I asked about it at cfe-dev@ weeks ago, before
> I started implementing for upstream since I was worried about its
> complicacy.)
>
> I don't want to stick on my original proposal, and I don't want to
> contradict your suggestion.  I *just* wanted hints to understand Douglas's
> suggestion (maybe just simple answers to my questions) since I didn't
> well-understand how his suggestion should be implemented and how the
> implementation should work.  If it's not enough for our purpose, I'll think
> out another idea.  Or, any other suggestions are also welcome.
>
> What do you think, Douglas?
>
>
>
> Doug and I were suggesting adding infrastructure to LLVM under which
> arbitrary calls could be annotated with metadata which would potentially
> survive into DWARF.  This would be a broadly-applicable feature that could
> be used by potentially many projects.  This would be a lot of work on your
> part, but as a carrot, we would be open to an extension which merely
> annotates an operator new call using this new LLVM feature.  It may not,
> however, actually achieve your purposes that well;  I don't know them well
> enough to speculate.
>
> Ultimately, however, this is an open-source project, and you are welcome
> to maintain your patch out-of-tree.
>
> John.
>
>
>
>
>
> --
> Dai MIKURUBE
>   dmikurube at acm.org
>
>
>
>
> --
> Dai MIKURUBE
>   dmikurube at acm.org
>
>



-- 
Dai MIKURUBE
   dmikurube at acm.org