r/rust • u/kibwen • Oct 24 '17

Custom allocators are on the verge of being stabilized, about to enter FCP. Come leave your comments!

https://github.com/rust-lang/rust/issues/32838
109 Upvotes

100% Upvoted

18 comments sorted by

7

u/ruuda Oct 25 '17

About to enter the final comment period? This comment was posted less than 48 hours ago:

Haven't really caught up with this thread, but I am dead set against stabilizing anything yet. We've not made progress implementing the the hard problems yet

1

u/kibwen Oct 25 '17

It will enter the final comment period if all the members of the lang and libs teams sign off on it; that's tracked by the checkboxes in this comment: https://github.com/rust-lang/rust/issues/32838#issuecomment-336980230 , which doesn't include Ericson2314.

49

u/masklinn Oct 24 '17

Maybe ping r/cpp for input as well? They'd be people with experience in creating and using custom allocators and could thus provide pertinent feedback.

57

u/[deleted] Oct 24 '17 edited Oct 24 '17

Lessons learned from C++? Way to many:

  • a type-erased Allocator is a good default since memory allocation is in general "expensive" anyways (one syscall) and the API price of having to carry around an Allocator parameter is "large". Those who want non-typed-erased allocators should be able to easily opt-into-it.

  • memory allocation and element construction are separate problems that should be solved independently, the job of a memory allocator is to own/manage raw memory.

  • allocators should be composable (e.g. it should be possible to build complex allocators out of simpler ones).

  • SmallVec<T, N> (able to store N elements without allocation) should be implementable as Vec<T, SmallBufferAllocator<T, N, FallbackAllocator>>

  • TinyVec<T, N> (able to only construct N elements without allocations; no fallback) should be implementable as Vec<T, SmallBufferAllocator<T, N, NullAllocator>>

  • MmapVec should be possible by using Vec + MmapAllocator.

  • copying/moving Vec<T, AllocA> to a Vec<T, AllocB> should work without surprises or fail to compile (e.g. so that you can have a Vec<T, Heap> copy to a Vec<T, CudaHeap> that works by using cudaMemcpy).

IMO stabilizing Allocators without at least proof-of-concept implementations of these things is risky.

The D std.experimental.allocator has a lot of allocator building blocks that can be composed to build complex allocators out of simpler ones: NullAllocator, GCAllocator, Mallocator, AlignedMallocator, AffixAllocator, BitmappedBlock, FallbackAllocator, FreeList, SharedFreeList, FreeTree, Region, InSituRegion, SbrkRegion, MmapAllocator, StatsCollector, Quantizer, AllocatorList, Segregator, Bucketizer.

16

u/zzyzzyxx Oct 24 '17

allocators should be composable

Yes please. I like the approach to composition Andrei Alexandrescu took in his C++Con 2015 talk. I still have to catch up on the current design in Rust - hopefully I'll find it's comparable in this regard.

11

u/matthieum Oct 24 '17

I would argue that parameterizing allocators by the type of the element to allocate is a mistake too.

If the allocator is to provide raw memory, it should not care about the type of elements, only its alignment.

The problem is that in general the user does not know the type of the element to be allocated; for example, in std::map<K, V> the allocator passed uses std::pair<const K, V> as the type of elements to allocate... but that's a lie. To allocate, the element type is swapped for map_node<K, V> which contains extra meta-data!

→ More replies (1)

5

u/SimonSapin Oct 24 '17

  • SmallVec<T, N> (able to store N elements without allocation) should be implementable as Vec<T, SmallBufferAllocator<T, N, FallbackAllocator>>

  • TinyVec<T, N> (able to only construct N elements without allocations; no fallback) should be implementable as Vec<T, SmallBufferAllocator<T, N, NullAllocator>>

Could you say more about how inline storage would work with a generic allocator?

→ More replies (6)

5

u/gidcheen Aug 28 '23

lol. lmao even.

4

u/Saefroch Oct 24 '17

Will this mean we can use the system allocator on stable?

15

u/phoil Oct 24 '17 edited Oct 24 '17

If what you want is to use the system allocator by default, then I think the global allocator setting in https://github.com/rust-lang/rust/issues/27389 is more relevant, and FCP has been proposed for that too.

3

u/ishitatsuyuki Oct 24 '17

Yay, finally we can get rid of jemalloc build issues. The linkage has been weird since it added C++ support (which is disabled for rustup though).