Increased Canister Smart Contract Memory

Update: We are on track to Submit the proposal to vote on at 15:00 UTC on Wednesday Sep 1st as scheduled :wink:


The proposal is live : Internet Computer Content Validation Bootstrap


Check out the new Dashboard page for NNS proposals:

great work by @Dylan !


The proposal for the design passed!

Next steps:

  • @ulan will submit NNS proposals with code upgrades that follow the design proposal community agreed on.
1 Like

hi everyone, ICP perfect go to moon

Hello, I want to know:
the canister stable memory is used by all canister replicas or just one replica?


Hello everyone:
I am confusing that we can only use 2G wasm memory in normal times, but we have 8G stable memory now, how can we use the 8G stable memory ? Can we read or write data in stable memory outside upgrade? @claudio

canister has both “heap memory” and “stable memory”. Max heap memory is 4GB, and max stable memory has been increased to 300GB. If you use Rust, there are APIs accessing stable memory directly.

But if you use Motoko, there is no API to directly access stable memory, so you are limited to 4GB heap memory. Further more, Motoko uses a copying GC (garbage collector), which means only 2GB memory is usable for your motoko program at the moment. This is subject to change I believe. Please correct me if I’m wrong @claudio


Thank you , perfect answer !

1 Like

Quick update: the implementation of the API will be included in the next version that is expected to roll out to subnets next week (subject to change if there are unexpected blockers).


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.