This pattern sounds really interesting to me because we’re able to break all those constraints about JIT/AOT on a blockchain. Basically we have:
- A main thread that handle normal block/transaction processing. It uses already compiled blob when available, or interpreter as fallback.
- An optimization thread in the background that gradually optimizes contracts in the state.
We can imagine that the optimization thread would first try a simple (inefficient) one-pass AOT, and when time permits, try an advanced LLVM AOT with aggressive optimization.
I would say this feels like when we first used GC for memory management. It will be a complicated beast, but whoever managed to implement it gains great advantages because then we’re not constrained by single-pass and all optimizations become possible.
I would even argue that if we ever find a proper algorithm (so that we efficiently select the next contract, skip JIT bomb contracts and do reasonable gas metering for all situations), then this will even make PolkaVM obsolete, because now we can use a more complex non-single-pass-optimized instruction set for better storage efficiency.
But the open question is still whether such algorithm is actually possible…