Date: Wed, 21 Sep 2022 01:28:54 +0800 From: baiyang <baiyang@...il.com> To: "Siddhesh Poyarekar" <siddhesh@...hat.com>, "Florian Weimer" <fweimer@...hat.com> Cc: "Rich Felker" <dalias@...c.org>, musl <musl@...ts.openwall.com> Subject: Re: Re: The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) > Is there any other valid reason to use > malloc_usable_size instead of simply using realloc? Yes, we use it as one of the parameters to estimate the memory copy cost when realloc degenerates back to malloc+memcpy+free, refer to the previous mails. -- Best Regards BaiYang baiyang@...il.com http://i.baiy.cn **** < END OF EMAIL > **** From: Siddhesh Poyarekar Date: 2022-09-20 21:54 To: Florian Weimer CC: Rich Felker; baiyang; musl Subject: Re: [musl] 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 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.