Repository navigation
Tracking issue for location of facade crates #27783
Description
Activity
It has been noted that the separation between
allocandcollectionsis seemingly arbitrary. However with a robust allocator API, it could be possible to specify collections without any allocator. So e.g. no_std users could provide their own allocator and still use Vec.Basically I don't think these should be stabilized at all in anything approaching the short term pending the ultimate allocator designs.
Found this through
allocdocuments.Is there any news about this issue?
btw, I just want aRawVecfor custom data-structures.RawVecwould be great. Any way to allocate memory other than Vec::with_capacity + mem::forget would be nice.Reacted by Ilan Godik@chao787 that's the
alloccrate.I've found this issue through compiler error message:
error: use of unstable library feature 'alloc_system': this library is unlikely to be stabilized in its current form or name (see issue #27783)I'm just trying to opt out of jemalloc and get Rust to compile my binary with system default malloc implementation. Is there a way to do it that would not involve unstable language features, like a compiler switch to get jemalloc out of my binaries and off my lawn?
Rationale: jemalloc has abysmal fork performance (80x slowdown) on default kernel configuration of recent Ubuntu. See issue #36705 for more info.
Opting out of jemalloc is also important for fuzzing, e.g. with afl-fuzz; even on jemalloc-friendly configurations using default malloc gets you 20% more fork performance which is significant for fuzzing workloads, and lets you substitute abusive memory allocators at runtime that catch more errors than default allocator or jemalloc but don't incur the performance penalty of DUMA or AddressSanitizer. See AFL's libdislocator as an example.
@Shnatsel yeah I'd love to explore the possibilities of stabilizing the "please give me the system allocator" intent. Right now it's unfortunately not possible to do that in stable Rust.
The tracking issue for global allocators in general is #27389, but it may be worth spawning off a separate thread of discussion for just declaring the intent to use the system allocator.
FWIW I'm not in favor of merging the facade crates. Having std be decomposed into reusable components should be useful for those targeting more exotic systems, particularly if I complete my further ambitions to extract all system-specific components of std into their own crates. Ultimately people should be able to create custom stds for whatever weird systems they want be reusing our small self-contained building blocks.
Decomposed stdlib would be really useful for asm.js target that I will need in the near future and really want to use Rust for.
@brson As a person targeting a mildly exotic system, I agree. For example, I would expect that a significant proportion of bare-metal use cases (like mine) would want
allocandcollectionsbut nothing beyond.The current set of crates considered under this issue are:
- rustc_unicode
- libc
- collections
- alloc
- rand
I surveyed what’s tracked by this issue when writing #39954. Unless I missed something:
libcandrandare now available on crates.io.- All functionality in
collectionsis re-exported as stable instd, is deprecated, or has a more specific tracking issue. - Some non-deprecated functionality in
std_unicode(formerlyrustc_unicode) andallocis re-exported as stable instd. - Functionality not available on stable Rust is:
alloc::heap- When a type
Tcan be written such asmem::align_of::<T>()is the desired alignment,Vec+mem::forgetcan be used to re-implementallocate,deallocate, andreallocate. - As far as I know, no such work-around is possible for
reallocate_inplaceorusable_size. EMPTYis “known” to be1 as *mut (), but keeping a separate definition and assuming it keeps matchingalloc’s seems fragile
- When a type
alloc::oomalloc::raw_vecstd_unicode::derived_propertystd_unicode::propertystd_unicode::str::is_utf16std_unicode::str::utf8_char_widthstd_unicode::str::Utf16Encoder
- Additional functionality not available on stable Rust with
#![no_std]:alloc::arcalloc::boxedalloc::rccollectionsstd_unicode::charstd_unicode::str::UnicodeStr
Some environments might require
#![no_std]because they lack threads for example, but still have a memory allocator available.My subjective opinions:
derived_property,property,utf8_char_width, andraw_vecare public in order to be used in other crates. Arguably they’re not something we ever want to stabilize.Utf16Encoderis almost in this category, but it is usefully more general than the stablestr::encode_utf16method since it works on arbitrarychariterators rather than just&str.is_utf16has never been used in the compiler or standard library since 47e7a05 added it in 2012 “for OS API interop”. It can be replaced with a one-liner:std::char::decode_utf16(s).all(|r| r.is_ok()). I propose removing it: Remove std_unicode::str::is_utf16 #40190
Reacted by Sander MaijersLooking at
Utf16Encoderagain, it’s based onchar::encode_utf16and so fairly easy to reproduce outside ofstd, so never mind. (Mostly, it’s only verbose because defining an iterator is verbose.)I think this leaves two items in need of attention:
- Stabilize raw memory allocation (
alloc::heap, maybe alsoalloc::oom). - Figure out how to provide non-
corefunctionality to#![no_std]crates.
I vaguely recall GC-related concerns about the former, but I think those would also apply to the
Vec+mem::forgettrick that is used on stable today. There’s even a crate for it: https://crates.io/crates/memalloc- Stabilize raw memory allocation (
Stabilize raw memory allocation
This is #27700, not sure how I missed that.
24 remaining items
RFC 2480 proposes stabilizing the
alloccrate, which would close this issue.Related:
- PR Make the public API of the alloc crate a subset of std #51569: Make the public API of the alloc crate a subset of std
- PR Move OOM handling to liballoc and remove the
oomlang item #51607: Move OOM handling to liballoc and remove theoomlang item - PR Update the error message for a missing global allocator #51639: Update the error message for a missing global allocator
There is something questionable with using
allocin ano_stdcontext currently: you automatically get a global allocator without adding a#[global_allocator], and that allocator is jemalloc. I would have expected something similar topanic: a compiler error about the missing panic_implementation (which currently still talks about the lang item, but you get the point).@glandium #36963 should make this disappear, and it only happens for executables. A
staticlibfor example does get an error message: #51639, since the "default lib allocator" is not jemalloc and is defined instd.But yeah it’s a good question whether we should change this in the meantime. Maybe it’s not much of a problem in practice?
- added a commit that references this issue
on Jun 29, 2018 How about adding
getrandomto the OP list? (maybe instead ofrand?) Introduction of a simple (overwritable) function for pulling entropy from system randomness source was previously briefly discussed here. See rust-random/getrandom for the current prototype.- added a commit that references this issue
on Apr 12, 2019
We probably don't want to indefinitely have a large number of facade crates which are all unstable, so we should eventually stabilize these crates, fold them back into the standard library, or find a good middle ground in which they can all reside.
The current set of crates considered under this issue are:
rustc_unicodelibccollectionsallocrandUpdate 2018-04-05:
libcandrandhave moved to crates.iocollectionswas merged intoallocrustc_unicodewas renamed tostd_unicodeand later merged intocoreThis leaves only the
alloccrate still unstable, which with the stablecoreandstdcrates (plus arguablyproc_macro) form the standard library.Update 2018-06-19:
RFC 2480 proposes stabilizing the
alloccrate, which would close this issue.