Incremental Garbage Collector Beta Release: Motoko Update Part 12

Motoko Biweekly Update Part 12!

Hey Motoko Developers! :wave:

Welcome back to the latest Motoko update post!

If you happened to miss our previous update, you can catch up here. We discussed a new Bitcoin hackathon for the IC and the VSCode candid features.

Today, we’re excited to discuss a beta test for the new incremental GC! If you want to test out the full usage of the Motoko heap then keep reading!

Incremental Garbage Collector: Beta Release!

A new, powerful garbage collector, the incremental GC, has been released for beta-testing with version 0.9.0 of Motoko!

The biggest impact of the incremental GC is that it enables heap usage in Motoko up to the full 4GB limit. While the existing GCs are unable to collect the whole heap due to the instruction limit per message, the new GC distributes its work across multiple messages when needed. Using evacuation-compaction based on forwarding pointers, the GC guarantees limited short pauses in all phases and is comparable to the most modern and advanced GCs used in other languages (e.g. Java). The GC’s scalability would also be a key enabler when moving Motoko to a 64-bit heap space in the future.

Based on our GC benchmark, the incremental GC allows allocating up to 3x more heap space while consuming around 3-16% less cycles on average compared to the other GCs available in Motoko.

For the moment, the incremental GC is only intended for beta testing and can be explicitly activated by the —incremental-gc compiler flag. You can enable the feature in dfx.json like so:

  "canisters": {
    “my_dapp”: {
       "main": "src/",
       "type": "motoko",
       "args" : "--incremental-gc"

Please let us know of any feedback and special shoutout to @luc-blaeser for leading and building out this large and complex feature!

More information on the incremental GC can be found here.

Till next time!

Keep building, and stay tuned for more updates!

– DFINITY Languages team


Also feel free to consult the release notes!


I was curious to get an update from @luc-blaeser about how this feature is working out. We have not enabled it for any production canisters, but would love the speed/efficiency bump when it is out of ‘beta.’

Hi Austin,

The incremental GC seems rather stable and there were no relevant issues or bugs encountered so far since the release of the beta version.

There are two important aspects to consider when using the GC:

  • The GC allows using the full 4GB memory space (with some minimum reserve), such that a canister may run out of 32-bit memory space. Therefore, for critical canisters, it is good to monitor its memory space and limit memory allocations in application code.
  • The current upgrade mechanism by serialization (stable variables) does not scale. Sometimes, it only supports a few 100 MB depending on the stable object graph topology. Therefore, it is important to thoroughly test the upgrade mechanism and also limit the allocations according to the tested scenarios.

I will see that we may officially change its status to “stable” and whether we could make this GC the default GC.

Moreover, with the latest aim to improve scalability of upgrade mechanism (, the incremental GC could become the default and the above mentioned limitations could be relaxed. However, this is currently only in a prototype phase, and there are several IC dependencies and aspects to be resolved before this could be supported.

Thank you very much for the interest in the GC.

1 Like