New Memory Metrics - Our experience contributing to the Internet Computer protocol

The CycleOps team is excited to announce our first contribution to the core protocol, providing all canisters with more detailed memory metrics. This update equips developers with a clearer understanding of how their canisters utilize memory, allowing for better debugging, resource allocation, and monitoring.

In this post, we’ll outline what’s new, as well as our experience contributing to both the dfinity/ic and dfinity/portal repositories.


What’s New?

We’ve introduced new memory usage fields in CanisterStatus, giving developers a more granular view of memory consumption. These fields include:

  • wasm_memory_size - Tracks memory used by the WebAssembly module.
  • stable_memory_size - Captures memory stored persistently across upgrades.
  • global_memory_size - Monitors memory allocated for global variables.
  • wasm_binary_size - Shows the size of the deployed WebAssembly binary.
  • custom_sections_size - Reports the size of custom sections in the Wasm binary.
  • canister_history_size - Tracks memory used by the canister’s historical data.
  • wasm_chunk_store_size - Measures storage used by Wasm chunking mechanisms.
  • snapshots_size - Monitors memory usage by stored snapshots.

Each of these metrics provides deeper insight into memory distribution, helping teams analyze and optimize their canister deployments.

Our Experience Contributing

In late 2024, CycleOps reached out to the foundation to add more fine-grained memory metrics to canister status, and in January 2025, Dimitris Sarlis invited us to contribute this feature as part of a new initiative opening up the IC monorepo to external contributions.

We were excited and agreed to the opportunity, as this both allowed us an opportunity to contribute both to the official IC codebase, as well as the API interface of the IC Management canister

Initial Call with DFINITY Engineering

A 30-60 minute call with Dimitris covering:

  • New Contributor logistics, such as signing DFINITY’s Contributor License Agreement (CLA),
  • A high level overview of the code changes involved, including implementation and adding tests!
  • The code review process for contributing to the dfinity/ic and dfinity/portal repositories (different processes!)

Making Code Changes

Interface Spec changes

The Interface Spec documentation and Candid lives in the Portal repository, which has been open to contributions for quite a while now. Its maintainers are also very responsive. Contributing to this repository was as simple as making a PR directly to the repository.

In our case, the changes to the spec were fairly straight forward, especially thanks to the helpful feedback and reviews of Dimitris, and Martin Raszyk the DFINITY team.

Since we’re familiar w/ Candid (and our change is backwards compatible by design) our contributions simply required updating the interface to reflect the changes we made in the execution layer.

Adding new metrics to the Management Canister (core protocol changes)

Brief step-by-step summary by @quint:

  1. Repository & Container Setup

    First, I forked and cloned the IC repo, and used the CI test containers to build it. Note that the first time you do build the repo it takes a lot of time! There is a lot to set up and compile, but after the first build, subsequent builds run much quicker.

    From the get go I chose to use a specific build system (VPS x86_64-linux) to remove any possible friction while running the dev docker container. My experience with Bazel was pretty limited before I did the contribution, but bazel build/test worked on the first try, and it was pretty intuitive to use!

    My advice would be to make sure you only run the subset of the tests you need (e.g. bazel test //rs/execution_environment/…), because running them all can take over half an hour (even on a beefy system)!

  2. Making code changes

    Even though @dsarlis gave us a walk through beforehand, finding all the impacted areas of code was not obvious, so having a good text search mechanism or IDE setup is your friend here!

    Since the additional memory metrics we wanted to expose already existed in the codebase, they just needed to be propagated to the correct places and exposed in a backwards compatible way. While the exact code changes were not difficult, the hardest part about this contribution was finding my way around the repository.

  3. Adding tests

    Adding tests was more time-consuming and involved than the implementation of the code itself, since there are some more underlying mechanisms and utilities, such as the ExecutionTestBuilder that I needed to understand in order to set up and trigger the desired test behavior. For example, the memory metric tests added, such as this test measuring stable memory that spins up a “universal canister” and pushes bytes to stable memory in order to verify its functionality.

    Since compilation of changes to the IC repo can take awhile, it will save you time in the long run to take your time with changes during development before re-running tests (compared to project/ code bases of a smaller size).

Interested in Contributing?

Given that this first experiment of an external contribution was successful, DFINITY Foundation is excited to pursue more opportunities of such collaborations. The Interface Spec is fully open to external contributions, so PRs with ideas/feature requests are very welcome. The IC repository is not officially open to contributions yet (internal teams are working to make this happen), so for the time being if you’re interested to make such a contribution, please reach out to Dimitris Sarlis (@dsarlis) on the forum.

A Collaborative Effort

Authored by @quint, this is our first contribution to the IC repo as a team, making CycleOps one of the first teams to commit code to the core protocol outside of Dfinity, and aligning with our mission to help build a world class developer experience on ICP.

We want to give a huge thanks to Dimitris Sarlis (@dsarlis) for his encouragement and mentorship, and code reviews throughout the entire contribution process, and for pushing forward the initiative to open up the IC repo to external developers and teams. We also want to thank Martin Raszyk @mraszyk for his thoughtful review of our update to the interface spec API and documentation, and Michael Weigelt @michael-weigelt for reviewing our protocol update to the management canister.

Contribution References

18 Likes

This is a huge step forward for the IC. Awesome job!

4 Likes

Thanks to @icme and @quint for championing and implementing this change! It’s a big step for the IC community to contribute to the core protocol and I’m personally very happy we got to to do this. Hopefully this is the beginning of many more such contributions!

3 Likes

Great job guys ! :rocket: !