Correct. The memory of canister smart contracts has gone from 4 GB to 8 GB memory. No need for developers to do anything.
This is the first step of many on the methodical increase 
towards 300 GB.
4 Likes
Motoko does not yet make use of the 64 bit API, e.g., the amount of data stored in stable variables is currently still limited to 4 GiB. But of course we intend to upgrade soon.
(We also have recently implemented a (still experimental) API for accessing stable memory directly. This will also support 64 bit at the time we release it.)
7 Likes
Folks in this thread may be interested in this: Releasing the source of the BigMap PoC demo
3 Likes
I was hoping that canisters would simply have access to more memory through orthogonal persistence. Is there going to be some API that will be required? I think to be of the greatest benefit to developers, the heap of the canister needs to be greatly increased. You should be able to just create data structures and fill them with data, scaling up to the capacity of the subnet.
1 Like
That would require the wasm64 WebAssembly extension, which, as Akhi says further up, isnāt ready for use yet. And even if it was ā Orthogonal Persistence and keeping all data in the heap, while fine for immutable canisters, doesnāt really work well when you want to upgrade your canister. At least not with the programming languages we have at hand.
1 Like
We need to figure this out (upgrading canisters with large Wasm heaps). I think the most exciting long-term goal is an unbounded Wasm heap. Thatās the most ideal solution for developers.
5 Likes
I donāt want to imply anything but you just copied @lastmjs comment on this thread
And you did the same for another 11 posts on this forum.
Are you a bot?
7 Likes
Great catch @coin_master
1 Like
Interesting 
lol
I thought folks here would appreciate this update: Two questions about canister storage - #18 by akhilesh.singhania
6 Likes
any news on this? can motoko delveopers make use of the increased stable storage yet?
1 Like
We actually have had support for 32 bit stable storage silently avialable for a while as library ExperimentalStableMemory.mo. We didnāt advertise this to avoid people taking a dependency on it.
Iām currently revamping this to support 64-bit stable memory (about half way there). However, weāre not convinced this is a great solution for users since it essentially introduces one big global variable (a growable byte array) and has the potential to be a big footgun if used improperly, as well as getting in the way of future, more abstract uses of stable memory including maintaining stable variables in IC stable memory throughout computation, rather than copying out and in on upgrade.
6 Likes
Just to clarify, does that mean that Motoko stable variables are still currently limited to holding only 4 GB worth of data? (Due to stable memory addresses still being 32-bit, i.e. 2^32 ~ 4 GB?)
Yes, and thatās unlikely to change any time soon. It would have rather big implications for our 32-bit tagged value representation.
Gotcha. Hopefully we can unify the APIs for <4 GB stable memory via stable variables and for >4 GB ExperimentalStableStorage at some pointā¦
More importantly, it would require moving our (stable) heap from internal Wasm memory to external IC memory, which would have substantial performance/cycle implications. So, before the IC adopts the memory-64 and multi-memory extensions proposed for Wasm, this isnāt really practical.
Do you have a timeframe when 64bit support will be available? We have been testing the API with 32bit support and are interesting in using this feature.
2 Likes
Why do stable variables involve the wasm linear memory (which Iām guessing is the heap youāre referring to)? Does Motoko load every stable variable from stable memory into wasm linear memory on canister start, and store them back into stable memory on canister termination/upgrade?
1 Like
Yes, Motoko temporarily serialises the heap to stable memory for upgrades (using the pre/post upgrade hooks). Keeping stable vars in stable memory would be vastly more expensive, because every variable access would involve API calls and de/serialising (arbitrarily large) data structures. And having to do GC on the stable memory.
Eventually, we would like to improve this, but that requires Wasm multi-memory support on the IC at a minimum.
4 Likes
I challenge that assumption (posting mostly for the record, we have discussed it elsewhere already): even a vastly more cycle expensive solution would likely serve some use cases better than what we have right now, and some possible implementations (e.g. a page-sized cache in main memory for stable memory accesses) might be less vast, and would allow us to build the system we envision now, and improve the cycle consumption later.
4 Likes