Increased Canister Smart Contract Memory

diegop · September 1, 2021, 4:44am

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

diegop · September 1, 2021, 2:56pm

The proposal is live : Internet Computer Content Validation Bootstrap

diegop · September 1, 2021, 3:03pm

Check out the new Dashboard page for NNS proposals: https://dashboard.internetcomputer.org/proposal/18337

great work by @Dylan !

diegop · September 3, 2021, 3:27pm

The proposal for the design passed!

https://dashboard.internetcomputer.org/proposal/18337

Next steps:

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

Soncb · September 3, 2021, 3:46pm

hi everyone, ICP perfect go to moon

C-B-Elite · September 6, 2021, 3:24pm

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

C-B-Elite · September 7, 2021, 12:25pm

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

PaulLiu · September 7, 2021, 5:24pm

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

C-B-Elite · September 8, 2021, 3:17am

Thank you , perfect answer !

ulan · September 8, 2021, 5:43pm

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

claudio · September 9, 2021, 5:40pm

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.

skilesare · September 10, 2021, 1:50am

What are these flags? Does dfx use the automatically?

claudio · September 10, 2021, 12:02pm

–compacting-gc should enable it.

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

C-B-Elite · September 10, 2021, 1:10pm

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

claudio · September 10, 2021, 3:26pm

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

github.com/dfinity/motoko

Collect garbage when the heap is full

opened 02:23PM - 08 Oct 20 UTC

osa1

compiler performance P2

Currently Motoko programs only do GC in these places: - In `canister_init`: f…irst function invoked by the system after installing a canister - In `post_upgrade`: Invoked by the system after upgrading a canister - After responding to a message (but not if a message is a query? I don't understand this part) In particular Motoko doesn't do GC if a single message the program fills the heap. Here's an example (run with `run.sh -d`): ``` import Prim "mo:prim"; actor a { class range(x : Nat, y : Int) { var i = x; public func next() : ?Nat { if (i > y) null else {let j = i; i += 1; ?j} }; }; public func allocate() : async () { // Allocate 4GiB of arrays, 4KiB each. This shouldn't fill up the heap // as the arrays are not used and could be collected. for (i in range(0, 1024 * 1024 * 4)) { let a = Prim.Array_init<Nat>(1024, 0); // 4 KiB } }; }; a.allocate(); //OR-CALL ingress allocate 0x4449444C0000 //SKIP run //SKIP run-low //SKIP run-ir //SKIP ic-ref-run ``` `allocate` allocates 4GiB of 4KiB-large arrays but doesn't keep any of them alive, so ideally this program should not cause heap overflow. (Btw, this program fails with "heap out of bounds", which seems weird. I'd expect it to fail with "heap overflow" or something like that.) To fix this we need to at least do a GC when the heap is full [1], in `alloc_words` [2]. Later we may want to do GC more often, in different places, but we have to do a GC when the heap is full to avoid trapping, so I think it's fine to start with just doing a GC in `alloc_words` when the heap is full for now. Once this is implemented adding more GC points will also be easier. The main difficulty is to pass roots to the GC at the GC site. As far as I understand we currently don't need this because a property of the current GC sites is that they don't have any roots in locals, stack, or globals, so the only roots are those in the `static_roots` array. I think we currently don't store pointers in globals (as far as I can see globals are only used for multi-value returns), so we only need to refactor our use of function locals and the Wasm stack. Because Wasm doesn't provide a way to traverse the stack or function locals we can't use "stack maps" or anything like that that tells the GC locations of pointers in Wasm stack, locals, and globals. I think we have no choice other than maintaining our own stack, for roots. The idea is that at a GC point the stack will have all dynamic objects (other than those pointed by the static_roots array) that the GC needs to retain. I'm not sure how to best implement this stack. Some notes: 1. At a function call, the caller needs to push all its pointers that may be used after the callee returns to the stack. (this can be avoided if callee is known to not allocate, but it's probably a good idea to not make this any more complicated for now and assume every function can potentially allocate). 2. When returning, the function needs to pop its pointers off the stack. 3. Caller, when the callee returns, needs to load locals from the root stack, assuming that the function call did a GC. (would not be necessary in a non-moving GC) 4. We can still use locals and Wasm stack for pointers, but we need to make sure to do (1), (2), (3). Alternatively we could stop using Wasm stack for pointers and only use the root stack. 5. The root stack needs to be extensible, which I think means it'll have to be heap allocated and should allow chaining. 6. Knowing which locals will be potentially used after a function call at a call site requires liveness analysis. Maybe for now we could assume all locals except those that are out of scope are live (I don't know if this will be useful enough in practice, but I suspect it might). For example, in the program above, we shouldn't assume `a` will be live after an iteration and we should pop this off the stack before jumping to the loop header. 7. The liveness analysis will have to insert remove instructions/expressions for variables after their last use in a function. For this I think we'll have to maintain something like stack frames in runtime, and in compile time we need to map locals to their locations in the function's frame. For example, if I have (in a function) ``` let a = ...; let b = ...; let c = ...; use(a); use(b); use(c); ``` We want to convert this to: ``` let a = ...; let b = ...; let c = ...; use(a); kill(a); use(b); kill(b); use(c); kill(c); // alternatively just pop the function frame as this is the end of the function ``` The IR instruction/expression `kill` needs to know location of variables in the current frame. Allocating frame locations for variables is a problem similar to register allocation. We could implement something like "linear scan", but we simply extend the call frame when there isn't an available slot. This is all very complicated, but I don't see any other way.. Maybe others do? Is there an easier way? Do everyone agree that this (doing GC when the heap is full) something we need to implement? Adding GC to Wasm spec makes more sense to me now... CC @nomeata @crusso @rossberg @ggreif [1]: Current GC only uses stack space so it's currently fine to do a GC when we reach the 4GiB limit. [2]: All heap allocations go through `alloc_words`, which is implemented as a RTS function.

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.

C-B-Elite · September 10, 2021, 3:41pm

Wow， thank you for your explanation ：D

C-B-Elite · September 14, 2021, 1:45am

dfx 0.8.1:
in dfx.json

"build":{
   "args" : "--compacting-gc",
    ······
}

ulan · September 16, 2021, 12:57pm

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.

jzxchiang · September 27, 2021, 6:57am

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?

Thanks!

ulan · September 27, 2021, 4:30pm

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

Topic		Replies	Views
Improving the utility of stable memory Roadmap	15	2190	December 10, 2022
Big Map (for scaling canisters across subnets) Roadmap Discussing	16	3858	September 29, 2021
SNS Update: Feb 9, 2024 SNS Project Governance	3	400	March 25, 2024
Memory Allocation Explained Developers	6	1546	December 7, 2021
SNS Update: Feb 1, 2024 Developers sns	0	290	January 31, 2024

Increased Canister Smart Contract Memory

Related Topics