You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following program, taken from HVM's example on lambda arithmetic, converted to kdl (as done here) and run on KVM leaks space (does not properly clear all the stored data that wasnt used), which then stores unecessary data on the chain. The bigger the numeric operation, the bigger the leak.
This seems to be related with lambda encoded data (in this case, Scott encoded) being passed around, more specifically when multiple erased arguments are applied to other erased arguments (or something like this?). This error seems to be related with this problem on HVM, where the possible fix seems to make the runtime not lazy on some cases, and thus more investigation is needed to draw further conclusions.
The text was updated successfully, but these errors were encountered:
Very small example that shows this behaviour (using Scott encoded pairs) :
run {
let new = @a @b @f ((f a) b);
let first = @p (p @a @~ a);
let secnd = @p (p @~ @b b);
dup new1 new2 = new;
dup p1 p2 = ((new1 #1) #2);
(Done ((new2 (first p1)) (secnd p2)))
}
On current KVM, this run has size = 24 (instead of 0).
I'm 99% sure this has to do with when a lambda that has an erased argument is cloned and then applied to another term.
Scott encoding is not that useful inside KVM, since constructors are primitive, but continuation passing style is very much useful in this context (monads!), and will envolve a lot of erased-argument lambdas, which will probably cause some unexpected large memory leaks in some cases. I will try to find an example like this.
The following program, taken from HVM's example on lambda arithmetic, converted to kdl (as done here) and run on KVM leaks space (does not properly clear all the stored data that wasnt used), which then stores unecessary data on the chain. The bigger the numeric operation, the bigger the leak.
This seems to be related with lambda encoded data (in this case, Scott encoded) being passed around, more specifically when multiple erased arguments are applied to other erased arguments (or something like this?). This error seems to be related with this problem on HVM, where the possible fix seems to make the runtime not lazy on some cases, and thus more investigation is needed to draw further conclusions.
The text was updated successfully, but these errors were encountered: