Jan Kratochvil <jan.kratoch...@redhat.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org/message/Y4SE4ODPMRGSZRSEXHE3QBZIXARPICL2/

Reply via email to