Do we want to keep an instance alive if we call it twice?

[adrien-zinger]

Actually the strategy is too create an instance on call_module. But we could define a cache of instances in order to interact more activelly with internal objects.

1. We could define a call access that specifically create a new instance and another that reuse the previous one if already created.
2. We could also define a MAX_INSTANCE configuration to limit the cache / or we can make pay a big price to keep an instance alive since the end of the 'run'.

@AureliaDolo @damip @gterzian @yvan-sraka

[AureliaDolo]

Do you mean if one SC is calling the same instance multiple times, we should not recreate it each time, or more of keeping a cache of frequently used instances no matter what SC calls it ?

[adrien-zinger]

I suggest only if a smartcontract call a module two times.

I'm open to other possibilities ☺️

[damip]

Does an instance carry a state that can be read&written by the SC ?
If so, isn't there a risk of leaking some non-determinism from one call to the next through caching as different nodes might define different max cache sizes ?

[adrien-zinger]

Yep, caching will keep the instance memory. We can "clean" the instance between each call of cautious bassoon but cleaning is a really heavy operation.

The non-determinism risk happen only if we choose in a non-determinist way who will stay alive. Nevertheless, it's unfear because some instances will have the right to keep an internal state between operations. In addition, a smart contract could be broken if massa choose to don't keep the instance alive anymore because users don't call it frequently.

[damip]

yes, let's keep it safe and simple for this first iteration :)
We'll add optimizations later

[yvan-sraka]

I think it's just a good sandboxing rule of thumbs to not reuse instances at this time. It's not a concern about determinism but more because it will be an more complex mental execution model to deal with this behaviour, for only few case where it is a performance game changer.