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

[Rich Felker <dalias at libc dot org>]

On Fri, Nov 27, 2015 at 11:07:12AM -0500, Carlos O'Donell wrote:
> 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?

I'm not clear on which is best. The caller has more knowledge that the
allocator implementation fundamentally cannot have, like knowing
whether it will pass the object to realloc again to enlarge it again,
etc. and there's also the issue that even if glibc's realloc is smart
about this, replacement allocator implementations (which glibc allows)
may not be. Personally, I try to avoid using realloc for any purposes
except enlarging existing allocations either to their now-known final
size or as part of an exponential growth strategy that bounds the
number of memcpy operations that might be needed.

Rich