Re: [PATCH] nano malloc allocator algorithm improvement

Corinna Vinschen via Newlib <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
On Aug 22 17:12, Keith Packard via Newlib wrote:
> Keith Packard via Newlib <[email protected]> writes:
> 
> > Maarten van der Schrieck | Things Connected <[email protected]>
> > 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.