Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Sep 2022 22:33:32 +0200
From: Gabriel Ravier <>
To:, baiyang <>
Cc: Quentin Rameau <>, Florian Weimer <>
Subject: Re: The heap memory performance (malloc/free/realloc) is
 significantly degraded in musl 1.2 (compared to 1.1)

On 9/20/22 20:35, baiyang wrote:
> > So what you're actually trying to do is more clear now.
> > And this is something that you should do on the “application layer”,
> > not expect the libc to magically taking care of this.
> Yes, we just do this at the application layer with the help of APIs 
> such as malloc_usable_size. You can look at the previous emails, isn't 
> that what we're discussing?
> > They want to know if realloc will resize the allocation in-place so
> > the internal memcpy will not happen.
> > AIUI, what they really need is not "usable_size", but "cost estimation
> > for resizing allocation at pointer P to size S". Which I believe they
> > try to deduce from malloc_usable_size.
> Yes, from malloc_usable_size, the size that the application layer 
> actually needs to copy, and other parameters like the OS, allocator, etc.
At this point it feels more and more like malloc basically can't fulfill 
your needs unless every implementation out there starts adding 
specialized methods for your application. In other words, it might be 
more productive for you to simply bring in a more agreeable allocator, 
instead of trying to get every single allocator out there to bow down to 
your needs.

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.