[PATCH] Nano-malloc: Fix for unwanted external heap fragmentation

[Keith Packard]

Ola Olsson <ola1olsson@gmail.com> writes:

> Okay, now I follow. Thanks for the explanation. I have only heard about
> newlib and newlib nano since these are the options I get through most
> UI/SDK from MCU manufacturers.

Yeah, picolibc has only been around for a couple of years...

> It's quite a big diff between the current newlib nano-malloc code and the
> nano-malloc in picolibc even though the strategy is the same. The code
> definitely looks okay from my point of view but it feels overkill for me to
> bring in an overwrite merge (or a bigger patch) right now when the only
> thing I need is the small patch I provided. At least since I haven't seen
> any more issues with the newlib nano version of malloc.

The nano malloc in newlib doesn't handle the memalign call correctly,
which I suspect you aren't using. It's also has more overhead than the
picolibc version as it adds variable padding between the header and the
allocation.

> My experience with the newlib nano-malloc is limited though, maybe you are
> aware of more bugs, or maybe the picolibc version is easier to maintain? Or
> what is the rational of bringing in the picolibc version of
> nano-malloc?

The generated code is smaller, the allocation overhead is lower and the
API is more robust against invalid API usage.

> I am of course fine with you bringing in the nano-malloc of picolibc but
> I'd suggest to merge my patch in the meantime. The first reason is that I
> am afraid that it will take time to get the fixes backported from picolibc.
> The other reason is that I want to have a commit that I can use as
> reference for bug checking if I find something fishy in the picolibc
> version of nano-malloc.

If someone wants to work on your patches in newlib, that's fine; they're
definitely an improvement over the current code. My work is focused on
picolibc, and when I have some time, I try to get fixes merged into
newlib.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20210428/fa601f9d/attachment.sig>