Increased Canister Smart Contract Memory

Actually, we are about to ship a library that gives you (almost) raw access to 32-bit IC stable memory while letting you also continue to use stable variables when convenient.

We intend to extend that to allow access to the proposed, larger stable memory.

Motoko acquired a second, compacting GC, a while ago. This lets you use much more of the 4GB heap. You need to select the GC with a compiler flag.


What are these flags? Does dfx use the automatically?

–compacting-gc should enable it.

Dfx supports this via the optional “args” field in the dfx.json record for Motoko projects.


How to choose the GC Algorithm? Is there any advice?

I don’t think we’ve written up any advice (@osa1 ?), but there’s some interesting stats and discussion here.

I think the basic take home is that the compacting gc costs more in terms of cycles, because of the number of passes over the heap it needs to do, but uses less pages (and provides more user space) than the copying gc, which requires twice the live heap size to do a collection.


Wow, thank you for your explanation :D

1 Like

dfx 0.8.1:
in dfx.json

   "args" : "--compacting-gc",

Update: the implementation of the 64-bit stable memory is part of the new replica release (version e86ac9553a8eddbeffaa29267a216c9554d3a0c6) that will roll out to subnets soon.


I may have missed this, but is this fully rolled out?

Is it supported natively using the stable variable qualifier in Motoko? If not, are there stopgap tools we can use to access memory addresses directly in Motoko?


1 Like

@jzxchiang: you’re right. The new version e86ac9553a8eddbeffaa29267a216c9554d3a0c6 with 64-bit stable memory has been rolled out to all subnets as of today.

I will defer the question about Motoko support for @claudio.


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 :roller_coaster: towards 300 GB.


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.)


Folks in this thread may be interested in this: Releasing the source of the BigMap PoC demo


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.


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?


Great catch @coin_master

1 Like

Interesting :rofl: lol

I thought folks here would appreciate this update: Two questions about canister storage - #18 by akhilesh.singhania