[PATCH] D20148: Idea for avoiding memory allocation calls.

[Sean Silva via llvm-commits]

On Wed, May 11, 2016 at 7:40 PM, Xinliang David Li <davidxl at google.com>
wrote:

>
>
> On Wed, May 11, 2016 at 6:56 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>>
>>
>> On Wed, May 11, 2016 at 12:25 AM, Rong Xu <xur at google.com> wrote:
>>
>>> xur added a comment.
>>>
>>> This avoids calloc in lprofCreateBufferIO() which is not used at all if
>>> there is not value profiles.
>>>
>>> But how about the malloc calls from  setFilenamePossiblyWithPid() and
>>> truncateCurrentFile(). They are not from value profiling, but they also
>>> call dynamic memory allocation.
>>>
>>
>> I suspect some combination of luck and that we officially expose only a
>> limited API to users means we haven't hit those. This issue has only
>> recently reached our priority list and we'll be looking more deeply at the
>> issues and our requirements.
>>
>>
>>>
>>> Maybe we should convert all these into alloca or using pre-allocated
>>> memory.
>>>
>>
>> I would prefer pre-allocated, but I suppose alloca is fine and avoids a
>> fixed limit. The downside of alloca is that in the worst case
>> circumstances, we can overflow the stack and trigger an issue that is
>> difficult to debug; at least for a fixed buffer we can return an error code.
>>
>
> I have same concern on using alloca, thus prefer fixed allocation. This
> presents some challenge when serializing VP data, but it is doable.
>
>
>>
>>> David and I are working on to get the profile runtime malloc free (or at
>>> least avoiding re-entrance to malloc) in the past few days. Hopefully we
>>> can have some discussion on this soon.
>>>
>>
>> Great! Glad we are working in the same direction.
>>
>
> yes -- I am in the process of getting rid of dynamic allocations one by
> one. The first couple of ones are in profile dumper.
>

This should make this patch unnecessary, right? I think I'll just help your
effort to remove allocations from the dumper (if you haven't already gotten
to them first).


> The last/major one is in the instrumenter.
>
>
>>
>> What do you mean "avoiding re-entrace to malloc"? Are you making calls
>> into the runtime lib from malloc? (for value profiling presumably? I would
>> not have guessed that malloc libs were using indirect calls)
>>
>
> It is the tcmalloc implementation (with source) -- it is feature rich that
> also invokes various user define hooks .
>

Ah, I was not considering hooks.

-- Sean Silva


>
> David
>
>
>>
>> -- Sean Silva
>>
>>
>>>
>>>
>>> Repository:
>>>   rL LLVM
>>>
>>> http://reviews.llvm.org/D20148
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160512/3d9ba1e1/attachment.html>