mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Siddhesh Poyarekar <siddhesh@redhat.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Rich Felker <dalias@libc.org>, baiyang <baiyang@gmail.com>,
	musl <musl@lists.openwall.com>
Subject: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1)
Date: Tue, 20 Sep 2022 09:54:43 -0400	[thread overview]
Message-ID: <CAAmeS-ZVAc-rPxTGnDo1ycemGE7NZ-HGv_wc+84Z7etQ=0OekQ@mail.gmail.com> (raw)
In-Reply-To: <874jx2phqm.fsf@oldenburg.str.redhat.com>

On Tue, Sep 20, 2022 at 4:34 AM Florian Weimer <fweimer@redhat.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


  reply	other threads:[~2022-09-20 13:58 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-19  7:53 baiyang
2022-09-19 11:08 ` Szabolcs Nagy
2022-09-19 12:36   ` Florian Weimer
2022-09-19 13:46     ` Rich Felker
2022-09-19 13:53       ` James Y Knight
2022-09-19 17:40         ` baiyang
2022-09-19 18:14           ` Szabolcs Nagy
2022-09-19 18:40             ` baiyang
2022-09-19 19:07             ` Gabriel Ravier
2022-09-19 19:21               ` Rich Felker
2022-09-19 21:02                 ` Gabriel Ravier
2022-09-19 21:47                   ` Rich Felker
2022-09-19 22:31                     ` Gabriel Ravier
2022-09-19 22:46                       ` baiyang
2022-09-19 20:46             ` Nat!
2022-09-20  8:51               ` Szabolcs Nagy
2022-09-20  0:13           ` James Y Knight
2022-09-20  0:25             ` baiyang
2022-09-20  0:38               ` Rich Felker
2022-09-20  0:47                 ` baiyang
2022-09-20  1:00                   ` Rich Felker
2022-09-20  1:18                     ` baiyang
2022-09-20  2:15                       ` Rich Felker
2022-09-20  2:35                         ` baiyang
2022-09-20  3:28                           ` Rich Felker
2022-09-20  3:53                             ` baiyang
2022-09-20  5:41                               ` Rich Felker
2022-09-20  5:56                                 ` baiyang
2022-09-20 12:16                                   ` Rich Felker
2022-09-20 17:21                                     ` baiyang
2022-09-20  8:33       ` Florian Weimer
2022-09-20 13:54         ` Siddhesh Poyarekar [this message]
2022-09-20 16:59           ` James Y Knight
2022-09-20 17:34             ` Szabolcs Nagy
2022-09-20 19:53               ` James Y Knight
2022-09-24  8:55               ` Fangrui Song
2022-09-20 17:39             ` baiyang
2022-09-20 18:12               ` Quentin Rameau
2022-09-20 18:19                 ` Rich Felker
2022-09-20 18:26                   ` Alexander Monakov
2022-09-20 18:35                     ` baiyang
2022-09-20 20:33                       ` Gabriel Ravier
2022-09-20 20:45                         ` baiyang
2022-09-21  8:42                           ` NRK
2022-09-20 18:37                     ` Quentin Rameau
2022-09-21 10:15                   ` [musl] " 王志强
2022-09-21 16:11                     ` [musl] " 王志强
2022-09-21 17:15                     ` [musl] " Rich Felker
2022-09-21 17:58                       ` Rich Felker
2022-09-22  3:34                         ` [musl] " 王志强
2022-09-22  9:10                           ` [musl] " 王志强
2022-09-22  9:39                             ` [musl] " 王志强
2022-09-20 17:28           ` baiyang
2022-09-20 17:44             ` Siddhesh Poyarekar
2022-10-10 14:13           ` Florian Weimer
2022-09-19 13:43 ` Rich Felker
2022-09-19 17:32   ` baiyang
2022-09-19 18:15     ` Rich Felker
2022-09-19 18:44       ` baiyang
2022-09-19 19:18         ` Rich Felker
2022-09-19 19:45           ` baiyang
2022-09-19 20:07             ` Rich Felker
2022-09-19 20:17               ` baiyang
2022-09-19 20:28                 ` Rich Felker
2022-09-19 20:38                   ` baiyang
2022-09-19 22:02                 ` Quentin Rameau
2022-09-19 20:17             ` Joakim Sindholt
2022-09-19 20:33               ` baiyang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAmeS-ZVAc-rPxTGnDo1ycemGE7NZ-HGv_wc+84Z7etQ=0OekQ@mail.gmail.com' \
    --to=siddhesh@redhat.com \
    --cc=baiyang@gmail.com \
    --cc=dalias@libc.org \
    --cc=fweimer@redhat.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).