Having been involved with jemalloc 3/4/5 work as well, I agree with Mike's conclusions.
-e On Mon, May 15, 2017 at 6:19 PM, Nicholas Nethercote <n.netherc...@gmail.com > wrote: > Just to add some context: glandium is deeply familiar with jemalloc4's > internals, having submitted numerous patches and fixes to it. And he has > spent *significant* time and effort on multiple occasions, on multiple > versions of jemalloc4, trying to avoid the performance regressions, without > success. If he can't get it into a state suitable for our use, I have > trouble imagining who else could. > > In other words, this is not a hasty or premature decision, but one made > reluctantly based on experience. > > Nick > > On Tue, May 16, 2017 at 10:14 AM, Mike Hommey <m...@glandium.org> wrote: > > > 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 > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
