1. The approach used in the old libtock-rs: Allow apps to specify a heap size at compile time, reserve that much space for the heap using brk() while initializing the runtime, and then use an allocator that assumes a backing store of a fixed size (such as linked_list_allocator).

2. An approach similar to that originally suggested by Johnathan when the old libtock-rs allocator was first implemented: a heap that only takes memory from the kernel as needed, and return memory to the kernel when no longer needed. The idea is generally an allocator that works on a backing store it was given, but will grow the size of this contiguous backing store as needed. One advantage of this approach is that if an app wants to allocate a bunch of memory, then return it before calling any syscalls that lead to grant allocation, that app can use more memory than would otherwise be possible given the size of a grant allocation. This approach can also just be useful toward maximizing the memory available to the app -- rather than having to specify a constant heap size that is known to be smaller than (app memory - allocated grant size), the app can just use everything that is not taken by grants, and then allocations will start to fail once that point is reached.

The second approach is more challenging to integrate with existing open source embedded Rust allocators, because in practice I have not found any that provide APIs for returning memory given to the allocator back to the kernel, without having to add an OS port to the allocator itself. IMO this approach seems more likely to require us to write our own allocator, or to modify an existing open source allocator with a port to Tock specifically. Interested to hear what others think.