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 t
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" com
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", because
jemalloc's auth
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
plau
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 security against heap
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 for
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 tho
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 patches and fixes to it. And he
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
success.
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 ea
10 matches
Mail list logo
