Tracking issue for changing the global, default allocator (RFC 1974)

[alexcrichton]

Tracking issue for rust-lang/rfcs#1183 rust-lang/rfcs#1974

Known bugs:

• The #[global_allocator] attribute doesn't work in modules global_allocator can not not be defined inside module #44113

Current status:

• Implemented in rustc: Implement the #[global_allocator] attribute #42727
• Stabilization checklist
  • Remove docs from the unstable book
  • Add docs to the real book
• Add jemalloc as a crates on crates.io (jemallocator)
• Once stable, link binaries to the system allocator by default Switch the default global allocator to System, remove alloc_jemalloc, use jemallocator in rustc #36963
  • known issues Switch the default global allocator to System, remove alloc_jemalloc, use jemallocator in rustc #36963 (comment)
  • valgrind doesn't work on jemalloc Valgrind doesn't report allocations with jemalloc on nightly #28224
  • crates are gone Tracking issue for alloc_system/alloc_jemalloc #33082

A quick summary of the current state of this feature is that you can change the default global allocator via:

// Change this program's global allocator. At most one `#[global_allocator]` 
// allowed in any crate graph.
#[global_allocator]
static ALLOCATOR: MyAlloc = MyAlloc;


// When defining a global allocator, the `Alloc` trait must be defined
// for `&'a T` instead of `T`
use std::heap::Alloc;

struct MyAlloc;

impl<'a> Alloc for &'a MyAlloc {
    // ...
}

[cuviper]

Depending on how we handle its link visibility, the overhead may even be less than calling malloc, if __rust_alloc can avoid the PLT.

[alexcrichton]

@SimonSapin note that the cost is also reduced to zero in cases of LTO.

[SimonSapin]

Alright, if people are confident that this is not an issue please carry on :)

[RalfJung]

However, at least for non-LTO the missing inlining does incur some cost, e.g. the MIN_ALIGN optimization in https://github.com/rust-lang/rust/blob/master/src/liballoc_jemalloc/lib.rs would be more effective if the alignment would be known at compile-time, which it typically is if inlining happens.

[alercah]

Drive-by-comment: Currently, the Alloc trait docs say "Note that as of the time of this writing allocators not intending to be global allocators can still panic in their implementation without violating memory safety."

Should there be a separate GlobalAllocator trait not for the reasons discussed in the RFC, but just to let an allocator author indicate that their allocator meets this additional guarantee and therefore is safe to use as a global allocator?

[SimonSapin]

#49669 adds a new GlobalAlloc trait for use with this attribute instead of Alloc. Tracking issue: #49668.

[pythonesque]

I am certainly not very happy that we're making performance worse in the normal case. LTO is nice, but it's very expensive, so most programs are not compiled with LTO--it's a huge hammer for attacking this problem, and isn't actually necessary today. Moreover, relying excessively on LTO for performance runs counter to the goal of improving Rust's compilation speed for optimized builds. Allocation is a huge hotspot for many programs, and I don't think we should reduce allocation performance in a way that can only be recovered with compiler magic that people rarely enable.

[SimonSapin]

@pythonesque Worse than what? As far as I can tell this indirection has existed since at least #27400 in Rust 1.4.0, released in 2015.

[johnthagen]

I don't think we should reduce allocation performance in a way that can only be recovered with compiler magic that people rarely enable

I think what would help is if cargo had another build flag other than just --debug and --release, something like that --publish that you do when you are actually going to publish and distribute a binary to a larger audience than simply your development machine. In those cases, the extra build time for the final set up optimizations that should be turned on for this case like LTO (and I think I read somewhere the number of code gen units that is default also hurts optimizations a little?). If a build server is what publishes the binary, the extra time waiting for these optimizations for a published release is even less of a problem.

The way it is now, if you want LTO you have to enable it for all release builds, included "development" release builds you are just building and running to test our some performance intensive piece of the software.

[Mazwak]

The way it is now, if you want LTO you have to enable it for all release builds, included "development" release builds you are just building and running to test our some performance intensive piece of the software.

No. You can add a [profile.release] in your cargo.toml. And it will apply to release builds only.

On topic, it would be nice if one could choose the system allocator the same way. Something simple for the end user. Like "allocator = system" in the [target].

[SimonSapin]

@Mazwak Right now the incantation is:

#[global_allocator] static A: std::alloc::System = std::alloc::System;

But the plan is to eventually make System the default (and the only one provided in the standard library), so adding a Cargo.toml config doesn’t seem useful.

[SimonSapin]

Stabilization PR: #51241 (finally!)

[Ericson2314]

Oh I forgot to mention my ~ month-old RFC rust-lang/rfcs#2492 that would subsume #![global_allocator]. Thankfully, #![global_allocator] can be desguared into it, but at the same time if the RFC was accepted it would be a bit silly to stabilize #![global_allocator] only to deprecate it soon after.

[SimonSapin]

@Ericson2314 The #[global_allocator] attribute has already gone through the RFC process with an FCP to merge the RFC, then implementation in Nightly, then FCP in this tracking issue to stablize the feature, then a stabilization PR landed. It is now stable in Rust 1.28 which is currently in Beta and reaches the Stable channel next week.

At this point the existence of an alternative design proposal is not enough to justify an emergency revert in my opinion.

[Ericson2314]

That's fine. I just wanted to not this in the proper place.