Yes, and there are a few libraries that already do this (i.e. CanDB) that require you to set scaling limits beforehand and has builtin checks to then safeguard the canister’s heap, but otherwise using the lower level APIs requires developers to insert this check into every update call, or add a recurring timer check to their canister. I’ve reviewed a lot of canister code from other projects, and most canisters do not have these checks in place. memory_allocation is a fixed amount of memory that the canister allocates (not flexible), and the current solution of using Prim is in my opinion lower-level abstraction than it needs to be.
Ideally the 2 higher level (monitoring and programmatic) abstractions of heap memory being added to canister_status and the canister_on_low_heap_memory Lifecycle Hook are implemented.
I also wanted to bring this up since the canister heap limit previously was something Motoko developers did not have to worry about, but now they do. They may not have even been thinking about this problem, as I have seen numerous examples (I provided one above) of large projects that previously may have had code that guarded against this differently.
It’s a backwards compatibility thing. Projects that are using older versions of dfx (pre incremental GC) would have hit the instruction limit, which is easier to recover from than hitting the heap limit.
It’s a pretty easy lift to just add the heap memory size?