Stream: t-libs/wg-allocators

Topic: Allocator lifetime

HeroicKatora (Jan 24 2020 at 20:33, on Zulip):

None of the allocator traits mention lifetimes. However, some allocators may be local in the sense that their own lifetime and that of the allocated memory is limited. For example, a stack allocator or an instance of bumpalo that is not in a static. How is and how should this be handled?

Erich Gubler (Jan 24 2020 at 21:46, on Zulip):

The type implementing AllocRef is expected to encapsulate the lifetime if necessary -- so, implementing it for a reference to a bumpalo memory pool is what you would do, not implement it directly on a pool instance. Does that make sense?

Tim Diekmann (Jan 25 2020 at 00:42, on Zulip):

We rename Alloc to AllocRef because types that implement Alloc are a reference, smart pointer, or ZSTs. This question is another reason, why this rename is a good idea.

It is not possible to have an allocator like MyAlloc([u8; N]), that owns the memory and also implements Alloc. That would mean, that moving a Vec<T, MyAlloc> would need to correct the internal pointer, which is not possible. You have to encapsule the lifetime yourself by impl AllocRef for &(mut) MyAllocator, or pass the lifetime to the allocator directly. The former is prefered IMO.

Lokathor (Jan 25 2020 at 00:47, on Zulip):

Would the same "trick" be necessary to make types using not-thread-safe allocation?

In other words, a Vec you can't Send because the allocator only lets you dealloc in the same thread that made the allocation in to start?

Lokathor (Jan 25 2020 at 00:47, on Zulip):

Or would those take even further type hackery?

Tim Diekmann (Jan 25 2020 at 00:48, on Zulip):

I havn't tried this out, but my first guess is, that's possible.

Lokathor (Jan 25 2020 at 00:49, on Zulip):

that certainly seems like a very important case to support

Lokathor (Jan 25 2020 at 00:50, on Zulip):

eg, the windows process heap is thread safe, so slow, but you can make thread local heaps if you want to go faster

Tim Diekmann (Jan 25 2020 at 01:03, on Zulip):

Can't you just implement !Send for your allocator?

Tim Diekmann (Jan 25 2020 at 01:03, on Zulip):

Something like in this playground?

Lokathor (Jan 25 2020 at 01:19, on Zulip):

Probably, I mostly wasn't sure if it'd work out like that with allocref too

Tim Diekmann (Jan 25 2020 at 01:28, on Zulip):

I just tried it out with impl ... for MyAlloc, impl ... for &MyAlloc, and impl ... for &mut MyAlloc. Everything works :)

HeroicKatora (Jan 25 2020 at 02:05, on Zulip):

That is a very interesting way of inheriting properties of the allocator to the allocations.

Tim Diekmann (Jan 25 2020 at 02:40, on Zulip):

This way is only suited for very few traits, as calling those traits is ugly. We don't expect users to call allocators directly in most cases. Mostly they will be used behind a generic type, which abstracts away this.

Lokathor (Jan 25 2020 at 02:54, on Zulip):

sounds like a red flag to me

Lokathor (Jan 25 2020 at 02:55, on Zulip):

directly using the allocator shouldn't give the user a hard time.

HeroicKatora (Jan 25 2020 at 03:08, on Zulip):

To me as well, Box was being specified to be equivalent to allocating the layout exactly so that one can manually allocate and initialize it for example.

Tim Diekmann (Jan 25 2020 at 11:38, on Zulip):

I have tried out this a bit more. When implementing AllocRef on MyAlloc, everything works as before. When implementing it on &MyAlloc, the methods has to be called on a reference. This means either, you need

let my_ref = &my_alloc;


HeroicKatora (Jan 28 2020 at 18:12, on Zulip):

I'm slightly confused what it means to implement AllocRef for a &mut MyAllocator. How long would the returned memory need to be valid and can be assumed unique? Is it the lifetime of the BuildAllocRef that returned this mutable reference? Or the lifetime of the mutable reference itself? That is important if I have a bump allocator with reset.

HeroicKatora (Jan 28 2020 at 18:18, on Zulip):

I'm asking about the mutable reference in particular since the BuildAllocRef can not return the original reference with its full lifetime. For a BuildAllocRef that returns &_ this is possible by cloning some original reference which it contains.

Last update: Feb 25 2020 at 03:55UTC