# UX implications of PVF executor environment versioning

**URL:** <https://forum.polkadot.network/t/ux-implications-of-pvf-executor-environment-versioning/2519>\
**Category:** Tech Talk\
**Created:** [April 5, 2023, 11:07pm UTC](https://forum.polkadot.network/t/ux-implications-of-pvf-executor-environment-versioning/2519 "2023-04-05T23:07:36Z")\
**Posts on this page:** 1\
**Showing post:** 31

<div class="post-metadata">

**Author:** ![m-cat](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/m-cat/32/3680_2.png) [@m-cat](https://forum.polkadot.network/u/m-cat)\
**Post date:** [April 17, 2023, 4:19pm UTC](https://forum.polkadot.network/t/ux-implications-of-pvf-executor-environment-versioning/2519/31 "2023-04-17T16:19:41Z")

</div>

Perhaps related:

> <https://github.com/paritytech/substrate/issues/9298>
>
> Currently for PVF execution we are using a rather naive algorithm for stack mete…ring.
> 
> See:
> 
> \- https://github.com/paritytech/wasm-utils/blob/master/src/stack\_height/mod.rs
> \- https://github.com/paritytech/substrate/blob/3cd75117765c4a63d40c00aa41e1bf12135c237b/client/executor/wasmtime/src/runtime.rs#L262-L304
> \- https://github.com/paritytech/substrate/blob/3cd75117765c4a63d40c00aa41e1bf12135c237b/client/executor/wasmtime/src/runtime.rs#L322-L331
> 
> However this simple model does not actually represent the underlying behavior of an optimizing compiler. Right now we try to overcome this by generously allocating the stack space for a relative small number of logical items. What I've missed is that the regalloc will generate spill slots based on the number of active live ranges. 
> 
> See this discussion https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/deterministic.20stack.20usage
> 
> Introducing the additional parameters into the mix is rather annoying and provides a very rough upper bound which I am not sure if useful. 
> 
> As an alternative, Chris F. has suggested to look into having a virtually unlimited native stack and throw a stack overflow trap based on logical consumption. It's not trivial to implement though. There are certain considerations, i.e. how exactly provide such a stretchable native stack. If done naively we could introduce performance cliffs (such as what segmented stacks in Go had).

---

_[View the full topic](https://forum.polkadot.network/t/ux-implications-of-pvf-executor-environment-versioning/2519)._