Jan Kratochvil <jan.kratochvil@xxxxxxxxxx> writes: > So why glibc greated an N+1 allocator (by DJ Delorie) instead of just > importing/using tcmalloc (which is license-compatible with glibc)? I didn't create an N+1 allocator. We're still using the Doug Lea allocator from ancient times. My recent work added a relatively minor bit of code that improved performance (which makes alternate allocators less of a win, and sometimes worse), and we've been working on security bugs all along, but it's not a "new" allocator by any stretch of the imagination. As for replacing it, I/we are not against that in principle, although that's a glibc topic and not a Fedora topic. However, keep in mind that glibc's allocator has been tested against a HUGE collection of software, compared to other mallocs that might have a much smaller testing breadth. To replace glibc's allocator would require a huge testing effort, and careful consideration of EVERY glibc-specific feature, hack, hook, and historical divot that Fedora apps might rely on (I'm looking at you, Emacs). So if you can prove that some alternate allocator can serve as a *general* purpose *system-wide* default allocator, and has better performance (speed, RSS, VSZ, etc) all the time, for all apps in Fedora (and other Linux distros, and Hurd, etc) that use it, with fewer security bugs and no missing features... yeah, we're listening. Patches welcome :-) I will repeat that this is not really a Fedora topic, and is independent of the "alternate mallocs in Fedora" topic, which exists for a different reason. I'm posting this purely for clarification. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/Y4SE4ODPMRGSZRSEXHE3QBZIXARPICL2/