-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for changing the global, default allocator (RFC 1974) #27389
Comments
Depending on how we handle its link visibility, the overhead may even be less than calling |
@SimonSapin note that the cost is also reduced to zero in cases of LTO. |
Alright, if people are confident that this is not an issue please carry on :) |
However, at least for non-LTO the missing inlining does incur some cost, e.g. the |
Drive-by-comment: Currently, the Should there be a separate |
Add GlobalAlloc trait + tweaks for initial stabilization This is the outcome of discussion at the Rust All Hands in Berlin. The high-level goal is stabilizing sooner rather than later the ability to [change the global allocator](#27389), as well as allocating memory without abusing `Vec::with_capacity` + `mem::forget`. Since we’re not ready to settle every detail of the `Alloc` trait for the purpose of collections that are generic over the allocator type (for example the possibility of a separate trait for deallocation only, and what that would look like exactly), we propose introducing separately **a new `GlobalAlloc` trait**, for use with the `#[global_allocator]` attribute. We also propose a number of changes to existing APIs. They are batched in this one PR in order to minimize disruption to Nightly users. The plan for initial stabilization is detailed in the tracking issue #49668. CC @rust-lang/libs, @glandium ## Immediate breaking changes to unstable features * For pointers to allocated memory, change the pointed type from `u8` to `Opaque`, a new public [extern type](#43467). Since extern types are not `Sized`, `<*mut _>::offset` cannot be used without first casting to another pointer type. (We hope that extern types can also be stabilized soon.) * In the `Alloc` trait, change these pointers to `ptr::NonNull` and change the `AllocErr` type to a zero-size struct. This makes return types `Result<ptr::NonNull<Opaque>, AllocErr>` be pointer-sized. * Instead of a new `Layout`, `realloc` takes only a new size (in addition to the pointer and old `Layout`). Changing the alignment is not supported with `realloc`. * Change the return type of `Layout::from_size_align` from `Option<Self>` to `Result<Self, LayoutErr>`, with `LayoutErr` a new opaque struct. * A `static` item registered as the global allocator with the `#[global_allocator]` **must now implement the new `GlobalAlloc` trait** instead of `Alloc`. ## Eventually-breaking changes to unstable features, with a deprecation period * Rename the respective `heap` modules to `alloc` in the `core`, `alloc`, and `std` crates. (Yes, this does mean that `::alloc::alloc::Alloc::alloc` is a valid path to a trait method if you have `exetrn crate alloc;`) * Rename the the `Heap` type to `Global`, since it is the entry point for what’s registered with `#[global_allocator]`. Old names remain available for now, as deprecated `pub use` reexports. ## Backward-compatible changes * Add a new [extern type](#43467) `Opaque`, for use in pointers to allocated memory. * Add a new `GlobalAlloc` trait shown below. Unlike `Alloc`, it uses bare `*mut Opaque` without `NonNull` or `Result`. NULL in return values indicates an error (of unspecified nature). This is easier to implement on top of `malloc`-like APIs. * Add impls of `GlobalAlloc` for both the `Global` and `System` types, in addition to existing impls of `Alloc`. This enables calling `GlobalAlloc` methods on the stable channel before `Alloc` is stable. Implementing two traits with identical method names can make some calls ambiguous, but most code is expected to have no more than one of the two traits in scope. Erroneous code like `use std::alloc::Global; #[global_allocator] static A: Global = Global;` (where `Global` is defined to call itself, causing infinite recursion) is not statically prevented by the type system, but we count on it being hard enough to do accidentally and easy enough to diagnose. ```rust extern { pub type Opaque; } pub unsafe trait GlobalAlloc { unsafe fn alloc(&self, layout: Layout) -> *mut Opaque; unsafe fn dealloc(&self, ptr: *mut Opaque, layout: Layout); unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut Opaque { // Default impl: self.alloc() and ptr::write_bytes() } unsafe fn realloc(&self, ptr: *mut Opaque, old_layout: Layout, new_size: usize) -> *mut Opaque { // Default impl: self.alloc() and ptr::copy_nonoverlapping() and self.dealloc() } fn oom(&self) -> ! { // intrinsics::abort } // More methods with default impls may be added in the future } ``` ## Bikeshed The tracking issue #49668 lists some open questions. If consensus is reached before this PR is merged, changes can be integrated.
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. |
@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. |
I think what would help is if 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]. |
@Mazwak Right now the incantation is: #[global_allocator] static A: std::alloc::System = std::alloc::System; But the plan is to eventually make |
…lexcrichton Ensure every unstable language feature has a tracking issue. Filled in the missing numbers: * `abi_ptx` → #38788 * `generators` → #43122 * `global_allocator` → #27389 Reused existing tracking issues because they were decomposed from a larger feature * `*_target_feature` → #44839 (reusing the old `target_feature` number) * `proc_macros_*` → #38356 (reusing the to-be-stabilized `proc_macros` number) Filed new issues * `exhaustive_patterns` → #51085 * `pattern_parentheses` → #51087 * `wasm_custom_section` and `wasm_import_module` → #51088
Stabilization PR: #51241 (finally!) |
Stabilize GlobalAlloc and #[global_allocator] This PR implements the changes discussed in #49668 (comment) Fixes #49668 Fixes #27389 This does not change the default global allocator: #36963
Oh I forgot to mention my ~ month-old RFC rust-lang/rfcs#2492 that would subsume |
@Ericson2314 The At this point the existence of an alternative design proposal is not enough to justify an emergency revert in my opinion. |
That's fine. I just wanted to not this in the proper place. |
Tracking issue for
rust-lang/rfcs#1183rust-lang/rfcs#1974Known bugs:
#[global_allocator]
attribute doesn't work in modules global_allocator can not not be defined inside module #44113Current status:
A quick summary of the current state of this feature is that you can change the default global allocator via:
The text was updated successfully, but these errors were encountered: