# Wasmtime just implemented memory64

**URL:** <https://forum.dfinity.org/t/wasmtime-just-implemented-memory64/6434>\
**Category:** Developers\
**Created:** [August 12, 2021, 6:41pm UTC](https://forum.dfinity.org/t/wasmtime-just-implemented-memory64/6434 "2021-08-12T18:41:24Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\
**Post date:** [August 12, 2021, 6:41pm UTC](https://forum.dfinity.org/t/wasmtime-just-implemented-memory64/6434/1 "2021-08-12T18:41:24Z")

</div>

Calling all DFINITY engineers!

Just in case you weren’t aware, wasmtime has just implemented memory64: [wasm64 support · Issue #572 · bytecodealliance/wasmtime · GitHub](https://github.com/bytecodealliance/wasmtime/issues/572#event-5149904094)

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!

---

<div class="post-metadata">

**Author:** ![akhilesh.singhania](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/akhilesh.singhania/32/487_2.png) [@akhilesh.singhania](https://forum.dfinity.org/u/akhilesh.singhania)\
**Post date:** [August 13, 2021, 11:51am UTC](https://forum.dfinity.org/t/wasmtime-just-implemented-memory64/6434/2 "2021-08-13T11:51:31Z")

</div>

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](https://github.com/bytecodealliance/wasmtime/pull/3153) 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.