Re: [RFC] Calling realloc vs. mallo/memcpy/free and _IO_vasprintf.

["Carlos O'Donell" <carlos at redhat dot com>]

On 11/27/2015 10:45 AM, Rich Felker wrote:
> On Thu, Nov 26, 2015 at 09:34:29PM -0500, Carlos O'Donell wrote:
>> While answering a question on libc-help about asprintf I happened
>> to look at _IO_vasprintf and noticed some code which tries to
>> decide if it should do a realloc vs. malloc/memcpy/free.
>>
>> In this particular case we should always be shrinking the buffer.
>> For example _IO_vfprintf may have expanded the stream buffer but
>> now no longer needs the extra space. If we are growing the buffer
>> then something is very very wrong since that means _IO_vpfrintf
>> will have failed due to lack of memory, and we handled that case
>> earlier in _IO_vasprintf.
>>
>> So again, if we are only shrinking the buffer, then realloc has
>> to be the most optimal operation in all cases. It would seem to
>> me that an allocation shrink like this would almost never result
>> in an allocation move, but rather malloc would just split the
>> allocation and reuse the remainder for other malloc calls.
>>
>> So why the micro-optimization?
>>
>> Is my assumption of always shrinking the buffer wrong?
> 
> I suspect the aim is not optimization but rather to prevent
> fragmentation from leaving a small allocation behind in an area carved
> out of large free space. Whether the code is effective at doing this,
> I'm not sure.

As I mention here in the final patch:
https://www.sourceware.org/ml/libc-alpha/2015-11/msg00607.html

My preference is for realloc to be doing this kind of work by making
a decision to split or move based on some kind of fragmentation
estimate (which it carries as part of the arena information perhaps).

I don't know that the caller is really the best place to put this
heuristic.

Thoughts?

Cheers,
Carlos.