Calling all DFINITY engineers!
Just in case you weren’t aware, wasmtime has just implemented memory64: wasm64 support · Issue #572 · bytecodealliance/wasmtime · GitHub
Seems like one of the biggest blockers for increasing the canister memory limit has just been removed.
Please give us canisters with terabytes of memory!
Hey Jordan. This is great news indeed. As you are aware, the team is currently actively working on 64 bit stable memory which will already enable developers to use tons of memory. Looking at Implement the memory64 proposal in Wasmtime by alexcrichton · Pull Request #3153 · bytecodealliance/wasmtime · GitHub in more detail, in particular the section:
In terms of the actual underlying implementation, no one should expect
memory64 to be all that fast. Right now it’s implemented with
“dynamic” heaps which have a few consequences:
All memory accesses are bounds-checked. I’m not sure how aggressively
Cranelift tries to optimize out bounds checks, but I suspect not a ton
since we haven’t stressed this much historically.
Heaps are always precisely sized. This means that every call to
memory.grow will incur a memcpy of memory from the old heap to the
new. We probably want to at least look into mremap on Linux and
otherwise try to implement schemes where dynamic heaps have some
reserved pages to grow into to help amortize the cost of
memory.grow.
Seems to suggest that the current implementation may not be quite production ready yet. I have already raised a feature request internally to figure out how to best move forward here.