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

[Xinliang David Li via llvm-commits]

On Thu, May 12, 2016 at 10:56 PM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
> 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?
>


right once the cleanup is done.



> I think I'll just help your effort to remove allocations from the dumper
> (if you haven't already gotten to them first).
>

Doing this part right now (while doing other cleanups along the way) -- it
will be ready in a day or two.

thanks,

David


>
>
>> 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/1b8b12b1/attachment.html>