Runtime storage initialization

[savant2212]

Summary

I need an advice how properly implement runtime initialized storage.

Motivation

Now I use ugly hack to make wee_alloc work with my unikernel wrapper around solo5. In compile time i don't know anything about available heap address and size, I only can get it in runtime from specific structure.

So I add imp_ptr_array with specific alloc_pages implementation and call something like fn init(start: usize, size: usize), but that's very bad thing usable only for initial testing.

As i can see I need some trait or function which can change internal state of alloc_pages implementation

How does this further wee_alloc's goal of being the best allocator for wasm32-unknown-unknown, with a very small .wasm code size footprint?

It doesn't make wee_alloc any bigger in wasm code size, but makes it more usable as general purpose no_std allocator

Details

What bits of code would need to change? Which modules?

As I see it will be additional specific implementation similar to static_array without significant impact on other parts.

What are the trade offs?

Additional trait to be implemented on WeeAlloc structure

Are you willing to implement this yourself? If you had a mentor? Are you willing to mentor someone else?

I'm ready to implement it.

[fitzgen]

So you're thinking that we make each imp module export a Backend trait (or whatever name) that provides the current "duck typed" module interface, but has access to &self?

trait Backend {
    fn alloc_pages(&self, pages: Pages) -> Result<NonNull<Opaque>, AllocErr>;
}

Then, you would generalize the static array backend to allow providing a slice of memory at runtime?

This would require threading T: Backend type parameters and members through everything, but that isn't too terrible, just write-once boilerplate.

The hard part would be if we tried to put Exclusive<T> as an associated type within the Backend trait. That would require generic associated types, unless I'm missing some trick. I guess we could leave that out of the trait, as it is now.

I'm a soft +1 to this proposal in general. What do other team folks think? cc @pepyakin @DrGoldfire @ZackPierce

[DrGoldfire]

+1 from me. I like the idea of serving the general-purpose no_std allocator case better; I know there's demand in the embedded sphere for this sort of thing. As long as we're not regressing the wasm target, which it doesn't sound to me as if this would do.

[ZackPierce]

I generally like the idea of transforming the backend implementations to traits, though there are a few design details to work out. Off the top of my head,

• Should fn alloc_pages have access to &self or &mut self? [My guess: &mut self]
• How does this interact with the Exclusive code (as @fitzgen pointed out)?
• Does the ability to select backend by trait rather than compile-time-configuration-flags mean we should adjust our feature flagging strategy?