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

[Ola Olsson]

Hi!

>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.
You are right. I missed the padding details. That's nice to get rid of.
And no, I am not using memalign at all. I only use newlib for embedded
systems.

> The generated code is smaller, the allocation overhead is lower and the
> API is more robust against invalid API usage.
Now when I skimmed through the code I couldn't find anything regarding the
API robustness.
Do you think you can point me in the right direction?
But yes, you are right here as well, the code is smaller and allocation
overhead lower so
the nano-malloc in picolibc is most likely an improvement.

>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.

Great, I appreciate it. Tell me when you've hit the merge button and I'll
make a new GCC/Newlib version for my company
to use on our internal automatic integration system.

Finally I'd like to thank you for taking time to teach me about the
internals even though I assume you are busy enough as it is.

Take care

On Wed, Apr 28, 2021 at 11:12 PM Keith Packard <keithp@keithp.com> wrote:

> 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
>