669877 - Consider defining MALLOC_DECOMMIT on all jemalloc platforms

Status: RESOLVED WONTFIX

(Core :: Memory Allocator, defect)

Description

[Justin Lebar (not reading bugmail)]

Right now, MALLOC_DECOMMIT in jemalloc.c is defined only on Windows.  I still need to do some testing, but from reading the source, it appears that if it's a win on Windows, it should also be good on Linux, Mac, and Android.

Comment 1

[Justin Lebar (not reading bugmail)]

Stuart or Paul, do you have any idea why we don't define MALLOC_DECOMMIT on non-Windows platforms?

Comment 2

[Justin Lebar (not reading bugmail)]

Well, defining MALLOC_COMMIT definitely decreases the amount of memory jemalloc reports as committed, although it doesn't appear to affect RSS.

heap-committed was 100mb lower with MALLOC_DECOMMIT after I loaded a few tabs (gmail, google calendar, bugzilla) closed them, and gc/cc/memory-pressure'd, but RSS was about the same.  Since I don't really believe that FF was using 100mb of swap without DECOMMIT, I'm inclined to believe that the heap-committed number is bogus...

Comment 3

[Paul Biggar]

I havent looked at DECOMMIT, and all I know is "the DECOMMIT feature is critical to Windows support." (see https://bugzilla.mozilla.org/show_bug.cgi?id=580408#c6)

Comment 4

[Justin Lebar (not reading bugmail)]

Jason, if you're reading bugmail, would you mind providing some guidance here?

Comment 5

[Paul Biggar]

jemalloc now has a mailing list, so we might ask there if Jason doesn't read bugmail:

http://www.canonware.com/mailman/listinfo/jemalloc-discuss

Comment 6

[Justin Lebar (not reading bugmail)]

With Paul's help in bug 670492, I think I understand:

Ideally, jemalloc calls madvise(MADV_FREE) on pages it doesn't need.  This lets the OS decommit those pages whenever it wants.  The pages remain in the program's virtual address space.

I presume MADV_FREE is used instead of mmap(PROT_NONE), which removes the mapping from the process's address space altogether, as an optimization.  If we decide very soon after MADV_FREE'ing memory that we want to use it again, the OS probably didn't get around to decommitting it, so the only work we wasted was the madvise system call.

Similarly, mmap(PROT_NONE) has to remove entries from the process's page table, which is expensive on x86/x64, while MADV just sets a flag in the page table entries whenever the OS gets around to it.

I imagine DECOMMIT is "critical" for Windows support either because Windows doesn't have the equivalent of MADV_FREE, or because address space is usually more limited on Windows, so we need to get our commits out of the way asap.  Maybe both.

Either way, it sounds like leaving DECOMMIT off is best, where we can.  Resolved WONTFIX.

Comment 7

[Paul Biggar]

Note that the current solution I have for bug 414946 is to turn on MALLOC_DECOMMIT :)