Rework memory allocator in order to increase contract size or call stack depth #6761
Description
Currently, the memory allocator lives in the client. It is pretty simple. For this reason we need to be very conservative how much memory we can use. This means that contract sizes and call stack depths are limited.
We should move the allocator into the runtime. This allows us to use a more sophisticated allocator.
cc @koute AFAIK you have an allocator in mind we should use for the runtime?
- Refactor the host <-> runtime interface machinery #7375
- Remove unnecessary host functions allocator usage polkadot-fellows/RFCs#4
- Choose an allocator with better worst case properties so that we can reduce
MEMORY_ALLOCATOR_INEFFICENCY_DEVIDERas much as possible - Make
MEMORY_ALLOCATOR_INEFFICENCY_DEVIDERconfigurable since it is now depending on the runtime - Assume a certain devider and retune our contract limits to allow for deeper stacks or more code.
- Migrate the AssetHub runtimes to the newly chosen allocator.
Alternative: Wait for the JIT
Once we move PolkaVM into the client (for the JIT) we no longer need to hold all code and memory of the current call stack in runtime memory. It will all be inside client memory and the runtime just holds a handle to it. This will likely remove the need for more memory.
My stance on this is: It will take too long to block on the JIT. We need more memory sooner to allow deeper call stacks. The linked RFC is a bit outdated (there might be new host functions it does not cover) but in good shape. It is not blocked by anything. If we get somebody to work in it, it can happen in parallel with the JIT work.