The _map_store, _set_store, and _decimal_store dicts in vera/codegen/api.py are append-only — entries are never deleted during execution. Long-running programs that create many transient Maps/Sets/Decimals will accumulate unbounded Python-side memory.
Impact
Each map_new(), set_new(), decimal_from_int() etc. allocates a new handle that persists for the entire execute() call. Functional operations like map_insert() create new handles without releasing old ones.
Current behaviour
Handles are local variables inside execute() and are freed by Python GC when execute() returns. No cross-call leakage. But within a single execution, memory grows monotonically.
Possible fix
A handle-refcounting or handle-finalizer scheme that frees host-side data when the WASM GC collects the ADT containing the handle. This would require coordination between the WASM mark-sweep collector and the host stores.
Affects: Map, Set, Decimal, and any future opaque handle types (Json).
The
_map_store,_set_store, and_decimal_storedicts invera/codegen/api.pyare append-only — entries are never deleted during execution. Long-running programs that create many transient Maps/Sets/Decimals will accumulate unbounded Python-side memory.Impact
Each
map_new(),set_new(),decimal_from_int()etc. allocates a new handle that persists for the entireexecute()call. Functional operations likemap_insert()create new handles without releasing old ones.Current behaviour
Handles are local variables inside
execute()and are freed by Python GC whenexecute()returns. No cross-call leakage. But within a single execution, memory grows monotonically.Possible fix
A handle-refcounting or handle-finalizer scheme that frees host-side data when the WASM GC collects the ADT containing the handle. This would require coordination between the WASM mark-sweep collector and the host stores.
Affects: Map, Set, Decimal, and any future opaque handle types (Json).