<div dir="ltr"><div style>Thank you for the comments, John and Richard.</div><div><br></div>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.<br>
<div><br></div><div style>1) Capture allocated types of as most objects as possible.</div><div style>2) No need to change almost all the existing code. Just adding some code.</div><div style>3) Capture objects allocated by both global and in-class operator new. (Many projects naturally have many in-class operator new.)</div>
<div style>4) Capture objects allocated by placement new. (Placement new is used for malloc() memory allocation in some projects.)</div><div style>5) Actually, capturing object deallocation is less required for our purpose. (But, it's more required in general.)</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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).</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">2013/1/31 Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">On Wed, Jan 30, 2013 at 10:27 AM, John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:<br>
> On Jan 30, 2013, at 2:42 AM, Dai MIKURUBE <<a href="mailto:dmikurube@acm.org">dmikurube@acm.org</a>> wrote:<br>
>> Hello, what do you think about it, John and Richard?<br>
><br>
> 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.<br>
><br></div></div></blockquote><div style>I agree that it's complex. (It's the reason why we still welcome other ideas.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">
> 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?<br>
<br></div></div></blockquote><div style>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.</div>
<div style><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
</div></div>My biggest concern here is that this extension won't do what you want,<br>
and won't be helpful for anyone else either. That's because it assumes<br>
that new and delete expressions are paired, which is simply false<br>
(even for a leak-free program), because it instruments placement new<br>
and class-specific operator new/delete. For instance:<br>
<br>
{<br>
char buffer[4];<br>
new (&buffer) int;<br>
// no corresponding operator delete call<br>
}<br>
<br>
This will be overwhelmingly common within containers.<br>
<br></blockquote><div style>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.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>Since the intercepting functions can be implemented for each project, developers can use it as a piece of their own profiling.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If you were suggesting a mechanism to implicitly pass a type_info<br>
object to a global operator new, and to prefer that operator new in<br>
overload resolution, I think I would find that simple and useful<br>
enough to support. But the proposed approach does not seem generally<br>
useful.<br>
</blockquote></div>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.)<br><br>-- <br>Dai MIKURUBE<br> <a href="mailto:dmikurube@acm.org" target="_blank">dmikurube@acm.org</a><br>
</div></div>