Re: [PATCH] Nano-malloc: Fix for unwanted external heap fragmentation
Ola Olsson <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <CABAco3DLhyOe39Bj7wu0FwZxy+Fs0ix+a8yHq37j4+AHB2o_Kg@mail.gmail.com> |
Hi again, I am sorry but I have no idea what picolibc is and I haven't seen any errata/todo or anything in newlib indicating that this issue will be fixed. I am just a simple programmer; I pulled latest and greatest of newlib, used "git log" and inspected the last 7 commits of nano-mallocr.c and then I was back in year 2017...Hence, I pretty much came to the conclusion that this issue won't be fixed unless I fix it myself. Please tell me if there is anything I can do or if something is expected from me regarding the patch before it's getting merged. Btw, there are some cleanup I would like to do in this file as well, mostly regarding comments and tabs->spaces but I guess it's okay to send a new patch for that. On Mon, Apr 26, 2021 at 5:31 PM Keith Packard <[email protected]> wrote: > Ola Olsson <[email protected]> writes: > > > The solution for this problem is to check if the last > > item in the free list is adjacent to sbrk(0). If it is, > > as it is in this case, we can just ask sbrk for the > > remainder of what is needed. In this case 1 byte. > > I've already implemented both of these suggestions in the nano malloc > version included as part of picolibc. This version has some significant > additional work which fixes issues with memalign (does anyone use this > on embedded systems?). > > > https://github.com/picolibc/picolibc/blob/main/newlib/libc/stdlib/nano-mallocr.c > > Growing the chunk adjacent to the brk is useful for both malloc and > realloc as this allows the common pattern of a buffer which grows > incrementally to be realloc'd in place. > > I was hoping to get some time to push this upstream to newlib as you're > quite correct that having these two changes is very useful on limited > memory devices. However, I have been redirected away from this work. > > There are also a couple of tests included with picolibc that uncovered > the issues with the original implementation: > > https://github.com/picolibc/picolibc/blob/main/test/malloc.c > https://github.com/picolibc/picolibc/blob/main/test/malloc_stress.c > > -- > -keith >