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