[WIP] Goodbye jemalloc #38820
[WIP] Goodbye jemalloc #38820
Conversation
See rust-lang#36963 for rationale closes rust-lang#36963 fixes rust-lang#36488 (indirectly) closes rust-lang#37975
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eddyb (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
| @@ -44,7 +44,7 @@ pub fn opts() -> TargetOptions { | |||
| dll_suffix: ".dylib".to_string(), | |||
| archive_format: "bsd".to_string(), | |||
| pre_link_args: Vec::new(), | |||
| exe_allocation_crate: super::maybe_jemalloc(), | |||
| exe_allocation_crate: "alloc_system".to_owned(), | |||
There was a problem hiding this comment.
Hmm, I wonder if we can remove this now.
There was a problem hiding this comment.
(the exe_allocation_crate field and logic related to it)
|
cc @Mark-Simulacrum @nikomatsakis @nnethercote on rustc perf |
|
I had asked @alexcrichton and @brson about this the other day; they said we couldn't do this before we made the interface stable. Maybe this will change their minds? |
|
The interface stabilization issue is still there: https://github.com/japaric/alloc-jemalloc/blob/master/src/lib.rs#L13 |
|
Thanks for the PR @japaric! I definitely sympathize with how much of a maintenance burden jemalloc is at this time. Unfortunately though I don't think we're in a position to accept this PR at this time. As you've found out it's technically quite easy to remove jemalloc, but as a stable feature of Rust today this would be a breaking change with an unacceptable path forward I think. We've had jemalloc as the default allocator since 1.0, and it objectively performs better than any other allocator in a variety of workloads. Programs may or may not be relying on this performance. I know that the compiler, at least, has historically performed better under jemalloc than the system allocator. If we were to remove jemalloc from in tree then there is no transition path for stable users using jemalloc. They'd all be forced to switch to nightly to regain perf losses, which would be an unacceptable transition in my opinion. Dealing with jemalloc is a very high priority amongst the libs team. It's slated to be the next point of discussion after we've sorted through the stories of scenarios and SIMD. |
👍 |
|
@alexcrichton Fair enough. Closing until the libs team gets to talk about it. |
Out of free version (for testing purposes): https://github.com/japaric/alloc-jemalloc
Minimally tested on x86_64 Linux. Still haven't fixed/updated the in-tree tests
cc @alexcrichton @brson