Research on moving to a compiler and a vm

[SupunS]

Issue to be solved

Explore the possibility of replacing the existing interpreter-based run-time with a compiler and a VM.

There are several key questions that need to be answered about the implementation approach.
e.g:

• A custom VM or Using an existing bytecode/vm
  • Performance?
  • Interoperability? (e.g: The host environment, ie.: fvm, the storage interactions like atree are implemented in Go. How easy/hard would it be to interact with these from the existing VM?)
  • How to extend existing VMs to support Cadence specifics. e.g: runtime type checking, defensive checks, etc.
• If a custom vm: stack-based Vs register-based.
  • Performance?
  • How easy to validate?

[dreamsmasher]

during execution, how often do we call into the FVM? I think that's probably the biggest factor in determining our approach - i.e. minimizing FFI overhead. If FVM calls are rare compared to interpreter overhead, then we could even look into an IPC implementation that completely separates the two runtimes

[SupunS]

That's a good thought indeed!

We did explore this path sometime back and came to the realization that the Cadence <-> FVM interactions are quite high and heavy. For example, the program cache is maintained at FVM (because it needs to be fork-aware), and Cadence constantly accesses this cache at runtime. Serializing a program (elaboration in particular) or a part of it through an IPC is a big overhead.

More details on: https://github.com/dapperlabs/cadence-private-issues/issues/21

[j1010001]

Related to #3612