But 4 is bigger than 3, and much bigger than 0.9, so it must be way
better, right? ;-)
For the record, I have no reason to object to this plan, and
conceptually it seems like allocators always have to tune for something.
If mozjemalloc is at this time tuned to our workload, it seems very
plausible that jemalloc has over time optimized for something somewhat
different.
But I'm curious if you know anything about the intended future
directions of jemalloc, if there are any, and whether they align with
anything we need. Also, how much of the difficulty in maintaining
jemalloc perf across upgrades is specific to ARM?
Again, I am not challenging the decision. I agree that you're the best
person to make this call. I just like to know about the sweet spots of
different memory allocators.
On 05/15/2017 05:14 PM, Mike Hommey 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
