[PATCH] Intercept allocation to skim allocated types

[Dai MIKURUBE]

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