https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Bernd Paysan from comment #9) > (In reply to Jonathan Wakely from comment #2) > > "I dropped in jemalloc and ran the test. CPU usage dropped but otherwise > > this had no effect." > > > > i.e. jemalloc was not proposed as a solution. > > That's the first attempt, before he discovered that there is another > allocator (likely mt_alloc) lurking inside, There is nothing "lurking inside", the author is deeply mistaken that anything sits between operator new and the C library. The history of operator new can be seen at https://gcc.gnu.org/git/?p=gcc.git;a=history;f=libstdc%2B%2B-v3/libsupc%2B%2B/new_op.cc;h=1c19d4477668242eea1803b76e2638fbd699fe92;hb=HEAD and has been largely unchanged since October 6, 2000. > which he need to disable first > (after a coworker had enabled it somewhere in the source code): Where did you get that information? The blog post says nothing about a coworker enabling mt_allocator, it strongly implies that the mt allocator pooling is on by default and is why libstdc++ is "broken". > "It turns out that there is a somewhat convoluted way to disable it > globally: set the environment variable "GLIBCPP_FORCE_NEW". After doing > this, CPU use increased slightly but memory use stabilized. Recalling > jemalloc I now once again tried sticking it under the controller in place of > glibc's malloc and both CPU load and memory use dropped to substantially > less than either stock configuration. More importantly everything became > stable once again." Yes I was too busy facepalming by the time I got to the end to notice the second reference to jemalloc. > If the "GLIBCPP_FORCE_NEW" is not a typo, we can nail down the version he > used to somewhere at least 14 years old (because the environment variable is > now called GLIBCXX_FORCE_NEW). Right, so unsupported and unmaintained. We're not interested in bug reports for GCC 3.x or 4.x releases.