[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAmeS-ZVAc-rPxTGnDo1ycemGE7NZ-HGv_wc+84Z7etQ=0OekQ@mail.gmail.com>
Date: Tue, 20 Sep 2022 09:54:43 -0400
From: Siddhesh Poyarekar <siddhesh@...hat.com>
To: Florian Weimer <fweimer@...hat.com>
Cc: Rich Felker <dalias@...c.org>, baiyang <baiyang@...il.com>, musl <musl@...ts.openwall.com>
Subject: Re: The heap memory performance (malloc/free/realloc) is
significantly degraded in musl 1.2 (compared to 1.1)
On Tue, Sep 20, 2022 at 4:34 AM Florian Weimer <fweimer@...hat.com> wrote:
> The compiler needs to treat malloc_usable_size similar to realloc and
> just the size information for the buffer based on the return value from
> malloc_usable_size. This is admittedly harder to do than a comparable
> analysis for realloc if the compiler interprets the standard in such a
> way that after a successful realloc, any access to the original pointer
> value is undefined.
>
> malloc_usable_size is not actually *that* useful with allocators that do
> not have strict size classes because they do not over-allocate that
> much. For these allocators, it may be possible to increase the size of
> allocation significantly without moving it, but that is not reflected in
> the return value of malloc_usable_size at all.
So the glibc manual does not document malloc_usable_size semantics
(which is weird since it is, well, a GNU extension!) so the only
reference users have is the man page. The man page already
discourages use of malloc_usable_size to write beyond the allocated
size in the NOTES section:
The value returned by malloc_usable_size() may be greater than
the requested size of the allocation because of alignment and minimum
size constraints. Although the excess bytes can be overwritten by the
application without ill effects, this is not good programming
practice: the number of excess bytes in an allocation depends on the
underlying implementation.
Adding support for something that's already declared as bad
programming practice seems like a step backwards. Instead, I hope we
find a way to discourage active use of malloc_usable_size more
strongly. At least based on the systemd experience, the problem they
try to solve is that of glibc realloc being too slow for paths where
the reallocation should return the same block and that should be easy
to special-case. Is there any other valid reason to use
malloc_usable_size instead of simply using realloc?
Sid
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.
