Re: Removing Jemalloc 4

2017-05-18 Thread jasone
This is a disappointing outcome. You put a huge amount of work into porting and testing jemalloc, and more recently I've done a lot of work to improve reliability especially on Windows, primarily with Firefox in mind. Over the past few months we've fixed some long-standing performance issues

Re: Removing Jemalloc 4

2017-05-16 Thread Mike Hommey
On Tue, May 16, 2017 at 11:28:02AM -0700, Steve Fink wrote: > 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. As Nick mentions, Jason Evans, the main developer on jemalloc (guess where "je"

Re: Removing Jemalloc 4

2017-05-16 Thread Nicholas Nethercote
On Wed, May 17, 2017 at 4:28 AM, Steve Fink wrote: > > 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. As far as I know the short answer is "whatever Facebook needs",

Re: Removing Jemalloc 4

2017-05-16 Thread Steve Fink
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

Re: Removing Jemalloc 4

2017-05-16 Thread Tom Ritter
On Tue, May 16, 2017 at 1:48 AM, Mike Hommey wrote: > 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

Re: Removing Jemalloc 4

2017-05-16 Thread Mike Hommey
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

Re: Removing Jemalloc 4

2017-05-16 Thread Tom Ritter
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

Re: Removing Jemalloc 4

2017-05-15 Thread Eric Rahm
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 wrote: > Just to add some context: glandium is deeply familiar with jemalloc4's > internals, having submitted numerous

Re: Removing Jemalloc 4

2017-05-15 Thread Nicholas Nethercote
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

Removing Jemalloc 4

2017-05-15 Thread Mike Hommey
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