In most cases, the canister is stopped before an upgrade takes place, so there should not be any race conditions. However, if an upgrade is performed without stopping the canister first, the race is indeed possible.
Ignoring the limit when upgrading might be a good idea regardless of the potential for race conditions. Because it is probably more convenient for developers to not worry about the heap limit when upgrading.
Also, this seems like it could be implemented entirely in user-space, if desired.
Indeed, but the main problem is that many users are not aware of the out-of-memory problem. It can also be difficult to use the user-land feature without support in canister settings.
Can you give some insight into feasibility and timeline for switching to Wasm64 for the heap?
@abk is working towards supporting Wasm64 for stable memory in Proposal: Wasm-Native Stable Memory
Once that’s done, we will follow up with support of Wasm64 for the heap. We expect that the performance will be slower due to the need for heap bounds checks in load/store instructions (Wasm32 avoids bounds check using a trick with guard pages).
I’d like to not to commit to a concrete timeline at this point, as there are still many unknowns. The rough estimate is this year. The timeline will become clearer once Proposal: Wasm-Native Stable Memory is done.