[PATCH] improve performance of std::allocator::deallocate

Jonathan Wakely jwakely@redhat.com
Mon May 20 11:15:00 GMT 2019


On 20/05/19 10:44 +0100, Jonathan Wakely wrote:
>On 20/05/19 09:17 +0000, Pádraig Brady wrote:
>>
>>
>>On 04/02/2019 07:33 PM, Padraig Brady wrote:
>>>On 03/07/2019 03:43 AM, Jonathan Wakely wrote:
>>>>OK, that makes me feel better about it. It's presumably much easier to
>>>>upgrade to 5.2 from 5.0 or 5.1 than it would be from 4.x.
>>>>
>>>>>>How complicated is the fix to prevent the crashes? Would it be
>>>>>>feasible for distros to backport that fix? I see that RHEL8 has
>>>>>>jemalloc 5.0.1 for example, but if the fix could be backported to that
>>>>>>release then it's less of a problem.
>>>>>The patch set is simple enough:
>>>>>https://github.com/jemalloc/jemalloc/pull/1341/commits
>>>>Thanks. That does seem reasonable for distros and other packagers to
>>>>backport, if they want to support 5.0 or 5.1 for their users.
>>>>
>>>>I'm leaning towards accepting the patch for gcc-9 (and if not, we
>>>>should do it early in the gcc-10 cycle).
>>>>
>>>FYI jemalloc 5.2 is released with the fix for zero sized deallocations:
>>>https://github.com/jemalloc/jemalloc/releases/tag/5.2.0
>>>
>>Friendly ping.
>>I can create a bug to track if you prefer.
>
>No thanks, patches belong on these lists.
>
>Now that we're in GCC 10 development stage 1 I'm happy to apply the
>patch. I think by the time GCC 10 is released it will be reasonable to
>expect people to use the fixed version of jemalloc.
>
>I'll do the change today.

Tested powerpc64le-linux (without jemalloc) and committed to trunk.

I also had to fix a latent testcase bug that this change revealed.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 2744 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20190520/02271b02/attachment.bin>


More information about the Libstdc++ mailing list