# Ic-stable-memory rust library

**URL:** <https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158>\
**Category:** Developers\
**Created:** [July 5, 2022, 8:55pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158 "2022-07-05T20:55:36Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![senior.joinu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/senior.joinu/32/9240_2.png) [@senior.joinu](https://forum.dfinity.org/u/senior.joinu)\
**Post date:** [July 5, 2022, 8:55pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/1 "2022-07-05T20:55:36Z")

</div>

Hey everyone, I’m here with a new Rust library again.

> **[GitHub - seniorjoinu/ic-stable-memory: Lets you store canister data directly...](https://github.com/seniorjoinu/ic-stable-memory)**
>
> Lets you store canister data directly in stable memory - GitHub - seniorjoinu/ic-stable-memory: Lets you store canister data directly in stable memory

It is called ic-stable-memory and it basically allows you use stable memory as main memory.

With this library you can create stable variables - variables that live directly on stable memory and do not require a common serialization/deserialization routine during canister upgrades. Also, you can use stable collections (there are two of them at the moment: stable `vec` and stable `hashmap`) which also live purely in stable memory and are able to hold as many elements as a subnet will allow your canister to allocate.

Remember - this is still version 0.0.1, so it is a bit limited, a bit unoptimized and a bit buggy. But anyway, I encourage you to give it a shot. Also, this is a pretty complex piece of software (at least for me), so any help is also greatly appreciated: PRs, design proposals, bug reports or any other feedback.

Also, I published some articles (to this new cool purely web3 blogging platform called [papy.rs](https://papy.rs/)) in order to make it easier to understand what this library is and how to use it:

> **[IC Stable Memory Library Introduction](https://suvtk-3iaaa-aaaal-aavfa-cai.raw.ic0.app/d/ic-stable-memory-library-introduction)**
>
> This Rust library finally makes you able to use stable memory as main memory.

> **[IC Stable Memory Library Under The Hood](https://suvtk-3iaaa-aaaal-aavfa-cai.raw.ic0.app/d/ic-stable-memory-library-under-the-hood)**
>
> This article uncovers what's inside the ic-stable-memory rust library - how does it exactly work.

> **[Building A Token Canister With IC Stable Memory Library](https://suvtk-3iaaa-aaaal-aavfa-cai.raw.ic0.app/d/building-a-token-canister-with-ic-stable-memory-library)**
>
> In this tutorial we use ic-stable-collection rust library in order to implement the most common thing - a token canister. This canister is able to take over all the stable memory that a subnet can offer and is very cheap to upgrade.

Hope you’ll like it.  
Have a nice day!

---

<div class="post-metadata">

**Author:** ![Maxfinity](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/maxfinity/32/1484_2.png) [@Maxfinity](https://forum.dfinity.org/u/Maxfinity)\
**Post date:** [July 5, 2022, 11:01pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/2 "2022-07-05T23:01:03Z")

</div>

> [@senior.joinu](#):
>
> Remember - this is still version 0.0.1, so it is a bit limited, a bit unoptimized and a bit buggy. But anyway, I encourage you to give it a shot. Also, this is a pretty complex piece of software (at least for me), so any help is also greatly appreciated: PRs, design proposals, bug reports or any other feedback.

Fantastic work. I will consider using this in our token standard, looks to be exactly what we need.

---

<div class="post-metadata">

**Author:** ![ovictor](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/ovictor/32/5946_2.png) [@ovictor](https://forum.dfinity.org/u/ovictor)\
**Post date:** [July 6, 2022, 3:25am UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/3 "2022-07-06T03:25:33Z")

</div>

Well Done! I was lokking for something like this and ended adapting the BtreeMap implemented by dfinity team to use the stable memory.:[GitHub - victorcastro89/Ic-stable-storage: Rust Stable Storage Implementation](https://github.com/victorcastro89/Ic-stable-storage),  
Original repo: [ic/rs/stable-structures/src at master · dfinity/ic · GitHub](https://github.com/dfinity/ic/tree/master/rs/stable-structures/src)

---

<div class="post-metadata">

**Author:** ![senior.joinu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/senior.joinu/32/9240_2.png) [@senior.joinu](https://forum.dfinity.org/u/senior.joinu)\
**Post date:** [July 6, 2022, 7:56am UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/4 "2022-07-06T07:56:12Z")

</div>

Thanks! Feel free to reach out.

---

<div class="post-metadata">

**Author:** ![senior.joinu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/senior.joinu/32/9240_2.png) [@senior.joinu](https://forum.dfinity.org/u/senior.joinu)\
**Post date:** [July 6, 2022, 8:56am UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/5 "2022-07-06T08:56:12Z")

</div>

Thank you!  
Your work is also looks really good. I tried to implement a BTreeMap, but found it kinda tricky at the moment an gave up.

Do you think it is possible to somehow integrate the code you have into my library?

---

<div class="post-metadata">

**Author:** ![domwoe](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/domwoe/32/5165_2.png) [@domwoe](https://forum.dfinity.org/u/domwoe)\
**Post date:** [July 6, 2022, 12:05pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/6 "2022-07-06T12:05:07Z")

</div>

Thanks a lot for taking the time to write those posts in addition to the implementation. I find this very helpful.

Would it be practical to implement certified data structures on top of this as well?

---

<div class="post-metadata">

**Author:** ![Maxfinity](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/maxfinity/32/1484_2.png) [@Maxfinity](https://forum.dfinity.org/u/Maxfinity)\
**Post date:** [July 6, 2022, 12:11pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/7 "2022-07-06T12:11:40Z")

</div>

> [@ovictor](#):
>
> Well Done! I was lokking for something like this and ended adapting the BtreeMap implemented by dfinity team to use the stable memory.:[GitHub - victorcastro89/Ic-stable-storage: Rust Stable Storage Implementation](https://github.com/victorcastro89/Ic-stable-storage),

B+ tree would be more useful than a Btree IMO.

---

<div class="post-metadata">

**Author:** ![senior.joinu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/senior.joinu/32/9240_2.png) [@senior.joinu](https://forum.dfinity.org/u/senior.joinu)\
**Post date:** [July 6, 2022, 12:36pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/8 "2022-07-06T12:36:56Z")

</div>

Thanks!

> [@domwoe](#):
>
> Would it be practical to implement certified data structures on top of this as well?

This is what I’m thinking of right now. Such a solution could bring a seamless data certification developer experience, but I need to do some more research before trying to implement it.

There is a thing in Ethereum called Verkle trees. I would like to try to implement it, but I don’t know anything about this type of crypto. If someone could assist me with the theory behind it, it would be awesome.

---

<div class="post-metadata">

**Author:** ![ovictor](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/ovictor/32/5946_2.png) [@ovictor](https://forum.dfinity.org/u/ovictor)\
**Post date:** [July 6, 2022, 12:48pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/9 "2022-07-06T12:48:39Z")

</div>

I will take a look, how are you allocating/delocating the memory? It grows as needed or can you set boundaries? If the variable is deleted it creates a fragmentation or you realocate it accondingly?  
One major problem I see is how to allocate and deallocate memory.

---

<div class="post-metadata">

**Author:** ![ovictor](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/ovictor/32/5946_2.png) [@ovictor](https://forum.dfinity.org/u/ovictor)\
**Post date:** [July 6, 2022, 12:49pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/10 "2022-07-06T12:49:33Z")

</div>

And many thanks for sharing this piece of code and the blog posts as well!

---

<div class="post-metadata">

**Author:** ![domwoe](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/domwoe/32/5165_2.png) [@domwoe](https://forum.dfinity.org/u/domwoe)\
**Post date:** [July 6, 2022, 12:56pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/11 "2022-07-06T12:56:30Z")

</div>

> [@senior.joinu](#):
>
> This is what I’m thinking of right now. Such a solution could bring a seamless data certification developer experience, but I need to do some more research before trying to implement it.

Awesome!

> [@senior.joinu](#):
>
> There is a thing in Ethereum called Verkle trees. I would like to try to implement it, but I don’t know anything about this type of crypto. If someone could assist me with the theory behind it, it would be awesome.

yeah, just with regular data structures there’s a large design space of authenticated data structures (That’s the general term for what we’d call certified data structures) with different trade offs. Would be great if someone would have a resource that compares different authenticated data structures. I’m not sure if Verkle trees are the best structure to start with.

---

<div class="post-metadata">

**Author:** ![senior.joinu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/senior.joinu/32/9240_2.png) [@senior.joinu](https://forum.dfinity.org/u/senior.joinu)\
**Post date:** [July 6, 2022, 1:33pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/12 "2022-07-06T13:33:39Z")

</div>

> [@ovictor](#):
>
> how are you allocating/delocating the memory?

There is a segregation free list based memory allocator. When you ask it to allocate a new memory block of some size it will first search it’s free-list, if there is no free block of a requested size, then it will try to find any free-block of bigger size. If there is such a bigger block, it will split it in two. If there is no such bigger block it will try to call `stable_grow(1)`. If the call was successful, it will repeat the previous steps. If the call was unsuccessful, it will return `OutOfMemory` to which you can respond programmatically (e.g. spawn another canister to scale horizontally).

You can’t set artificial grow boundaries rn, but it seems like a good idea to add such feature. Thanks!

> [@ovictor](#):
>
> If the variable is deleted it creates a fragmentation or you realocate it accondingly?

When you delete a variable it frees the memory block. This new free block is added back to the free-list (and possibly joined with it’s free neighbors). So, yes, there is a bit fragmentation, but I need to add some tests in order to understand how much of impact does it provide.

---

<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:** [July 7, 2022, 1:09pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/13 "2022-07-07T13:09:50Z")

</div>

Can someone explain to me and ideally point to documentation explaining the current limits of stable memory?

I was under the impression that stable memory was still limited to 8gb per canister.

I assume this might just be an artificial limit by Motoko? Does the Rust CDK not also impose this limit? And where can I go to see how much stable memory a subnet has available to all canisters?

---

<div class="post-metadata">

**Author:** ![domwoe](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/domwoe/32/5165_2.png) [@domwoe](https://forum.dfinity.org/u/domwoe)\
**Post date:** [July 7, 2022, 1:25pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/14 "2022-07-07T13:25:24Z")

</div>

> [@lastmjs](#):
>
> I was under the impression that stable memory was still limited to 8gb per canister.

You’re correct. I don’t think it’s in the docs, but it is in the [code](https://github.com/dfinity/ic/blob/3bd2d654ae6699d0779da6a1eac27ee4fac9784b/rs/types/types/src/lib.rs#L479).

Same case for the [subnet capacity](https://github.com/dfinity/ic/blob/3bd2d654ae6699d0779da6a1eac27ee4fac9784b/rs/config/src/execution_environment.rs#L23).

---

<div class="post-metadata">

**Author:** ![senior.joinu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/senior.joinu/32/9240_2.png) [@senior.joinu](https://forum.dfinity.org/u/senior.joinu)\
**Post date:** [July 7, 2022, 1:29pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/15 "2022-07-07T13:29:03Z")

</div>

Do you know the purpose of this 8gb limit?  
Now It looks like my title is overpromising.

UPD: updated the title and articles

---

<div class="post-metadata">

**Author:** ![diegop](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/diegop/32/569_2.png) [@diegop](https://forum.dfinity.org/u/diegop)\
**Post date:** [July 7, 2022, 1:49pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/16 "2022-07-07T13:49:03Z")

</div>

> [@domwoe](#):
>
> You’re correct. I don’t think it’s in the docs, but it is in the [code](https://github.com/dfinity/ic/blob/3bd2d654ae6699d0779da6a1eac27ee4fac9784b/rs/types/types/src/lib.rs#L479).

Following up: When I saw this thread yesterday, I realized the 8GB capacity is too hard to find in the docs, so I am making a PR to update the docs.

---

<div class="post-metadata">

**Author:** ![domwoe](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/domwoe/32/5165_2.png) [@domwoe](https://forum.dfinity.org/u/domwoe)\
**Post date:** [July 7, 2022, 3:52pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/17 "2022-07-07T15:52:35Z")

</div>

> [@senior.joinu](#):
>
> Do you know the purpose of this 8gb limit?

We started with having 4GB just to accommodate the use case of upgrading canisters and I think we are just cautious with increasing it too much because it’s always hard to put back a restriction, and thus far no one is close to using the 8GB.

---

<div class="post-metadata">

**Author:** ![diegop](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/diegop/32/569_2.png) [@diegop](https://forum.dfinity.org/u/diegop)\
**Post date:** [July 7, 2022, 4:26pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/18 "2022-07-07T16:26:15Z")

</div>

I think this previous update from the DFINITY team working on execution (Wasm, memory) would help give context:

> [@Increased Canister Smart Contract Memory](https://forum.dfinity.org/t/increased-canister-smart-contract-memory/6148/114):
>
> Hi all, I would like to share the team’s current thinking on the topic of increasing canister smart contract memory. This is a topic we know is important to the community and some people have been reaching out asking for the current status.With this update, we want to manage everyone’s expectations around the timeline of further increasing canister smart contract memory. As we had discussed in our rollout plan when the [original](https://forum.dfinity.org/t/increased-canister-smart-contract-memory/6148/37) proposal had been shared with you, we were going to start with bump…

---

<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:** [July 7, 2022, 5:19pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/19 "2022-07-07T17:19:29Z")

</div>

Can we start lifting the limit? Keeping it artificially low in my case is kind of preventing me from using it in [Sudograph](https://github.com/sudograph/sudograph). I would like to be able to tell people how much storage they can use in Sudograph, that’s a major limitation to people. I also would love to see a schedule to know when we can expect limits to be lifted. If we can really get into the 100s of GB then this might be an all-in solution for Sudograph and any other library that is willing to embrace stable memory data structures.

Keeping it low might be a self-fulfilling prophecy, as people know they can’t use it for much thus perhaps they don’t.

---

<div class="post-metadata">

**Author:** ![senior.joinu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/senior.joinu/32/9240_2.png) [@senior.joinu](https://forum.dfinity.org/u/senior.joinu)\
**Post date:** [July 11, 2022, 10:10pm UTC](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158/20 "2022-07-11T22:10:05Z")

</div>

ic-stable-memory promoted to v0.1.0!

Features:

- new safer & easier stable variables API
- `SHashSet` collection
- `SBinaryHeap` collection
- bug fixes

[Next page](https://forum.dfinity.org/t/ic-stable-memory-rust-library/14158.md?page=2)
