https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #5 from Nadav Har'El <nyh at math dot technion.ac.il> --- Some replies to Andrew's comments above: 1. As the number of cores continue to grow, libraries will also fix malloc scalability issues, so concurrent malloc will no longer present a problem. The code which led me to this report (http://www.seastar-project.org/) already replaces malloc() by a lock-free implementation (Seastar has per-thread memory allocation), so malloc() was never a problem there. 2. With the phrase "global lock" I just meant that there is just one lock that all the unrelated threads which try to throw any exception of any type need to take. 3. As far as I can tell, the C++ standard doesn't say anything exceptions necessarily being very slow. Conventional wisdom indeed has it that exceptions are slower than normal function returns. But nothing suggests that C++ exceptions are not scalable, in the sense that throwing unrelated exceptions in unrelated threads at the same time is not possible, or is orders of magnitude slower than just the normal costs of exceptions on one thread. That is nothing more than an implementation bug. It can be argued how urgent fixing this bug is, but as the number of cores continue to grow, and performance of C++ software continues to improve (e.g., http://www.seastar-project.org/), "exception storms" of the type I outlined in my original report will become a very real risk. Fixing this bug completely might require fixes in glibc too (dl_iterate_phdr, and as you said malloc). But I think it definitely needs fixing.
