[PATCH] nano malloc allocator algorithm improvement

Corinna Vinschen vinschen@redhat.com
Mon Aug 24 10:03:45 GMT 2020


On Aug 22 17:12, Keith Packard via Newlib wrote:
> Keith Packard via Newlib <newlib@sourceware.org> writes:
> 
> > Maarten van der Schrieck | Things Connected <maarten@thingsconnected.nl>
> > writes:
> >
> >> The current nano malloc implementation has two issues reducing the amount of memory available and increasing fragmentation.
> >>
> >> The first issue is that sbrk() will be called to allocate a space with
> >> the size of the entire requested alloc_size, even if the last free
> >> chunk borders the edge of currently allocated memory. This means that
> >> in a system with 20 kb of RAM, you will get ENOMEM when performing
> >> this:
> >
> > Oh, that's a great idea. I did the same for realloc when the block was
> > at the end of the heap; doing the same for malloc is a nice
> > addition.
> 
> I've gone ahead and added this. Because this code is shared with
> realloc, the overall impact on the code size is pretty modest. I think
> it's easily worth the increase in code size because it will use ram more
> efficiently now.
> 
> I can back-port this code to newlib if people are interested; certainly
> having people on this list review the could would be great.

The review should take place on the newlib list ;)


Thanks,
Corinna



More information about the Newlib mailing list