On Tue, Feb 26, 2013 at 8:33 AM, Richard Yao <[email protected]> wrote: > Unless a significant issue is found in jemalloc itself, I do not see any > reason to continue using glibc's ptmalloc over jemalloc. As far as I > know, FreeBSD, NetBSD, Facebook and others are using jemalloc, so I > expect that no significant issues will be found. jemalloc will still > needs testing before we can consider it. Doing good tests is hard, so I > would like to crowd source ideas on the appropriate way to test a malloc > implementation from the list. My expectation is that people on the list > will collectively think of better ideas than I could on my own. > > With that said, what do people think? >
Just want to point out a problem I have personally encountered with another alternate malloc (tcmalloc). Essentially, when you combine libGL.so from nvidia-drivers with tcmalloc, the Google Chrome web browser fails to properly close its worker processes. https://bugs.gentoo.org/show_bug.cgi?id=413637 This thread on the Chromium developer list goes into more detail: https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/uLf5l669dCk/MXXfJfIvDF0J The main concern I would have is that upstream developers (like nvidia) are unlikely to test their software with an alternate malloc implementation, so we could end up running into some very subtle bugs. Are the saved cycles really worth it?
