My interest in jemalloc3/4 has always been with taking advantage of it's partitioning capabilities to segment things like javascript arrays for increased security against heap grooming and UAF exploitation.
Is there a path forward with this in mozjemalloc? Plans, or would-take changes, or just thoughts on what to do here? -tom On Mon, May 15, 2017 at 7:14 PM, 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
