Hi, We've tried to get off mozjemalloc for, apparently, close to 5 years (date of the filing of bug 762449). We've had memory usage regressions (like bug 1219914), and we've had perf regressions as per talos numbers (things like bug 1138999), and those have never gone away (with variations with each update of jemalloc >= 3).
My best bet at this point is that it's "just" a consequence of the difference in memory layout due to the differences in how the allocators work. That doesn't make it more okay. Many updates to recent versions of jemalloc have been painful (usually breaking everything except linux), and the current tip of the jemalloc dev branch is not making things any better (see bug 1357301). Furthermore, bug 1361258 has started to modify mozjemalloc with new features for stylo, further deepening the API surface between both allocators. While what was added in bug 1361258 is possible to implement for jemalloc 4, the burden of continuing to maintain both allocators is not really appealing considering the perspective of ever switching. As much as it pains me, it's time to admit that switching to jemalloc >= 3 is not going to happen, and pull the plug once and for all. This decision has taken way too long to be made, and I apologize for that. This will happen with the landing of bug 1363992 in a few hours. As for the things we were hoping jemalloc >= 3 would allow us to do (essentially, heap partitioning), we'll be working on getting that on mozjemalloc shortly (bug 1361258 and followups will actually get us close on the necessary infrastructure), as well as cleaning up its code (I have a local patch queue that removes 15% of jemalloc.c), and probably converting it to C++ (at least for some RAII benefits, and converting some of the gory macros to templates) Mike. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
