This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] libio/vasprintf.c: Always use realloc.


On 11/27/2015 10:03 AM, Carlos O'Donell wrote:
> The asprintf/vasprintf implementations calls into _IO_vasprintf
> to carry out operations on a string-based FILE* object. When
> the work is complete and the buffer filled with the result the
> implementation null-terminates and returns the string which is
> passed back to the caller of asprintf.
> 
> During underflow the string-based buffer might have grown, and
> conversely the buffer might be exactly the right size, but short
> by 1-byte for the NULL terminator. Therefore the implementation
> chooses to realloc the buffer to return back any excess memory
> or get 1-byte more for the NULL terminator.
> 
> In 2000 the implementation was changed by Ulrich Drpper to
> make a local deicsion to use realloc vs. malloc/memcpy/free
> based on a heuristic and in order to reduce memory fragmentation.
> The idea is that if the buffer is only just bigger than what the
> user needs the realloc will split the chunk and increase
> fragmentation. While this is true, this decision should not be
> made at the _IO_vasprintf level. The allocator should be making
> this decision based on known fragmentation estimates and a tunable
> fragmentation parameter which could be used to control when realloc
> splits a chunk and when it decides to malloc/memcpy/free.
> 
> Therefore we remove the local heuristic. This should increase
> performance slightly at the cost of fragmentation. Future malloc
> work to handle fragmentation should be pursued. If someone measures
> fragmentation and tracks it back down to _IO_vasprintf, we add a
> comment to guide the reader to what we consider is best practice:
> enhance realloc to handle fragmentation decisions.
> 
> OK to checkin?
> 
> No regressions on x86_64.

I'm going to drop this until I can get a benchtest to show this
is better than before.

c.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]