Revisit the choice of memory allocator?

[SimonSapin]

Historically, Rust has shipped a copy of jemalloc as part of the standard library on most platforms (but notably not Windows) and used it as the default memory allocator for Rust code.

These days with the #[global_allocator] attribute, Servo can and does override the allocator used by the standard library. But we’ve kept the same config (jemalloc, now through https://crates.io/crates/jemalloc-sys, on all platforms except Windows) just because that used to be the default. Now that we control this choice, we can reconsider it.

Should we prefer jemalloc on Windows? Should we prefer not building and shipping and using our own copy of jemalloc on some other platforms, and use the system’s allocator?

For example, the system allocator appears to be jemalloc on recent Android versions. Using it would mean one less piece of code that we need to cross-compile (see #20645), and a smaller binary (though we probably have some low hanging fruit to pick there before this difference becomes significant: #18625).

CC @jdm, @pcwalton

[emilio]

It'd be nice to try out bmalloc and see if it makes a difference on performance / memory use. It's one of the things I'd like to try in Gecko as well. Also maybe worth checking Gecko's malloc as well?

[SimonSapin]

Gecko has a modified/tuned fork of an older version of jemalloc and gave up trying to rejoin upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1363992. Trying it in Servo would involve writing a standalone build system for it (perhaps similar to generate_build_data.py + build.rs in https://github.com/servo/mozangle).

[froydnj]

@glandium is experimenting with porting Gecko's fork of jemalloc to Rust; perhaps that would be a more suitable base to build from.

[SimonSapin]

Porting as in a rewrite, or FFI bindings?

[froydnj]

Pure Rust.