haven’t tried --rts-stack-pages also haven’t tested v7. I’ve shared the repo, you can check it out. Or I will a bit later
@claudio I just implemented your singleton suggestion for v8 map
Here is the branch GitHub - ZhenyaUsenko/motoko-hash-map at stack-overflow-fix-attempt
Still fails to upgrade. Increasing --rts-stack-pages <n> doesn’t help either
1 Like
Sorry, didn’t see this and will try to take a look tomorrow.
The flag only affects one of the stacks used by the compiled code. The hard limit is determined by the Wasm stack which we can’t configure but is set by the IC. So it can help, but only so much.
So the introduction of [var _] as you did should improve sharing, but I think if its failing with a stack overflow then it might be the use of deeply nested recursive value (of type Entry) that might be the other problem. Reading the code and this, Map v8.0.0, it's finally here, I wonder if it’s the support for the previous and next pointers,preserving insertion order, that (I guess) are linking all entries in a long list.
Just a hunch, I’m afraid. Could you record the hashes of previous and next entries instead and link them that way?
That’s an interesting idea. Could definitely be a temporary solution until we have a better serialization/deserialization algorithm on upgrades. One problem I see immediately is
current structure (..., links: [var Entry<K, V>]) will be replaced with
double array (..., branches: [var Entry<K, V>], prevNext: [var Nat32])
which as far as I understand will increase space per entry by 12 bytes
That sounds about right. It will be another 4 bytes larger in the incremental gc (as all objects are).
Still might be worth the experiment to see if it fixes the issue (or just take out support for pre and next to determine that).
It is just a hunch though. Sorry if it wastes your time in the end.