Re: Jemalloc 3 is now on by default
On Tue, Jan 13, 2015 at 10:13:34AM +0900, Mike Hommey wrote: > Hi, > > I just landed bug 762449 on inbound, which enables Jemalloc 3 on the > nightly channel. This puts us a step forward to removing mozjemalloc, > our highly patched fork of jemalloc 0.9. More importantly, it will allow > us to more closely work with upstream, by proposing patches that do > apply there (which is not the case every time we do changes to > mozjemalloc), or taking improvements from upstream (which, for some, we > backported to mozjemalloc, with pain). > > For now, the change is such that it won't ride the trains, because there > are a few known "regressions" that need to be addressed first, but I'd > expect them to be fixed by next merge-day. > > From a developer point of view, this shouldn't change anything. > > Thanks to Guilherme Gonçalves, Eric Rahm, and Emanuel Hoogeveen for the > hard work. By now, we're at Jemalloc 4, and I just turned it on again for the third time (not riding the trains yet, like back then). There are known performance regressions, let's see how they turn out in reality (comparing talos results on try is not entirely reliable yet to get the full picture) and see where we go from there. Third try's the charm? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Jemalloc 3 is now on by default
On Tue, Jan 13, 2015 at 12:44:19PM +0900, Mike Hommey wrote: On Tue, Jan 13, 2015 at 10:13:34AM +0900, Mike Hommey wrote: Hi, I just landed bug 762449 on inbound, which enables Jemalloc 3 on the nightly channel. This puts us a step forward to removing mozjemalloc, our highly patched fork of jemalloc 0.9. More importantly, it will allow us to more closely work with upstream, by proposing patches that do apply there (which is not the case every time we do changes to mozjemalloc), or taking improvements from upstream (which, for some, we backported to mozjemalloc, with pain). Aaand as usual with such changes, it didn't stick. I just (finally) relanded this. It incurs a startup regression on Android, but it was decided we'd take it. There will be opportunities to improve things in the future. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Jemalloc 3 is now on by default
Hi, I just landed bug 762449 on inbound, which enables Jemalloc 3 on the nightly channel. This puts us a step forward to removing mozjemalloc, our highly patched fork of jemalloc 0.9. More importantly, it will allow us to more closely work with upstream, by proposing patches that do apply there (which is not the case every time we do changes to mozjemalloc), or taking improvements from upstream (which, for some, we backported to mozjemalloc, with pain). For now, the change is such that it won't ride the trains, because there are a few known regressions that need to be addressed first, but I'd expect them to be fixed by next merge-day. From a developer point of view, this shouldn't change anything. Thanks to Guilherme Gonçalves, Eric Rahm, and Emanuel Hoogeveen for the hard work. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Jemalloc 3 is now on by default
On Tue, Jan 13, 2015 at 10:13:34AM +0900, Mike Hommey wrote: Hi, I just landed bug 762449 on inbound, which enables Jemalloc 3 on the nightly channel. This puts us a step forward to removing mozjemalloc, our highly patched fork of jemalloc 0.9. More importantly, it will allow us to more closely work with upstream, by proposing patches that do apply there (which is not the case every time we do changes to mozjemalloc), or taking improvements from upstream (which, for some, we backported to mozjemalloc, with pain). Aaand as usual with such changes, it didn't stick. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Jemalloc 3 is now on by default
On 1/12/2015 9:44 PM, Mike Hommey wrote: Aaand as usual with such changes, it didn't stick. Does that mean I should assume that whenever someone makes this sort of announcement, I should assume they really mean this will take effect tomorrow or the day after, when I've figured out what went wrong? :-) -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform