On Tue, May 16, 2017 at 01:33:13AM -0500, Tom Ritter wrote: > 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?
See last paragraph of the email you quoted ;) > On Mon, May 15, 2017 at 7:14 PM, Mike Hommey <[email protected]> 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 > > [email protected] > > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
