The Ethereum Virtual machine stands out as somewhat unique compared to the majority of other Virtual Machines available. In my earlier article I elaborated on its usage and highlighted several of its features.
The Ethereum Virtual Machine (EVM) is a basic yet potent, Turing complete 256-bit Virtual Machine that permits anyone to run arbitrary EVM Byte Code.
The go-ethereum initiative includes two versions of the EVM. A straightforward and uncomplicated byte-code VM and a more advanced JIT-VM. In this article, I will clarify some distinctions between these two versions while discussing certain attributes of the JIT EVM and the reasons it can be significantly faster than the byte-code EVM.
Byte Code Virtual Machine of Go-ethereum
The internal workings of the EVM are rather straightforward; it consists of a singular run loop that endeavors to carry out the instruction located at the current Program Counter (PC for short). Within this loop, the Gas is computed for each instruction, memory is augmented if needed, and the instruction is executed if the preliminary conditions are met. This process continues until the VM either concludes successfully or returns an error by triggering an exception (e.g. out-of-gas).
for op = contract[pc] {if !sufficientGas(op) {return error("not enough gas for op:", or)}switch op {case ...:/* execute */case RETURN:return memory[stack[-1], stack[-2]]}pc++}
Upon the completion of the execution cycle, the program-counter is incremented to proceed to the subsequent instruction and it continues this process until it has concluded.
The EVM possesses an additional method to alter the program-counter via what is referred to as jump-instructions (JUMP & JUMPI). Rather than allowing the program-counter to increment (pc++), the EVM has the capability to leap to arbitrary locations within the contract code. There are two jump instructions known to the EVM: a standard jump that is interpreted as “jump to position X” and a conditional jump which is interpreted as “jump to position X if condition Y is satisfied”. Whenever such a jump takes place, it must consistently land on a jump-destination. If the execution lands on an instruction that is not a jump destination, the program fails — in essence, for a jump to be valid, it must invariably be succeeded by a jump-destination instruction if the conditionyielded true.
Before executing any Ethereum application, the EVM traverses through the code to identify all potential jump-targets, subsequently cataloging them in a map that can be referenced by the program-counter for retrieval. Each time the EVM comes across a jump-instruction, the validity of the jump is verified.
As you may notice, the executing code is fairly straightforward and effortlessly interpreted by the byte-code VM, leading us to the conclusion that despite its simplicity, it is fundamentally quite primitive.
Introducing JIT VM
The JIT-EVM adopts a distinct method for executing EVM byte-code and is, by nature, initially less efficient than the byte-code VM. Before the VM can execute any code, it must first transform the byte-code into segments that the JIT VM can comprehend.
The setup and execution process is carried out in three phases:
- We verify if there exists a JIT program ready for execution using the code’s hash — H(C) serves as an identifier for the program;
- if a program is located, we execute it and return the output;
- if no program is found, we execute the byte-code and compile a JIT program in the background.
Initially, I attempted to check if the JIT program had completed compilation and to transfer the execution to the JIT — this all transpired during runtime in the same loop using Go’s atomic package — however, it was unfortunately slower than allowing the byte-code VM to execute and subsequently utilizing the JIT program for every sequential invocation post-program compilation completion.
By segmenting the byte-code into logical components, the JIT gains the capability to examine the code more accurately and to optimize whenever necessary.
For instance, an exceedingly simple optimization I implemented was consolidating several push operations into a single command. Consider the CALL instruction; it necessitates 7 push commands — i.e. gas, address, value, input-offset, input-size, return-offset, and return-size — before execution, and instead of iterating through these 7 commands one by one, I’ve streamlined the process by gathering the 7 commands and appending the 7 values into a single slice. Now, whenever the beginning of the 7 push commands is executed, it performs the optimized instruction by instantly appending the static slice to the VM stack. Of course, this is only applicable for static values (i.e. push 0x10), which frequently occur in the code.
Additionally, I enhanced the static jump commands. Static jumps are those that consistently redirect to the same location (i.e. push 0x1, jump) and remain unchanged under any conditions. By identifying which jumps are static, we can pre-validate whether a jump is legitimate and falls within the contract’s limits, and if so, we generate new instructions that replace both the push and jumpinstructions, marking it as valid. This alleviates the VM from executing two instructions and eliminates the need to confirm the legitimacy of the jump, thus avoiding the costly hash-map lookup for valid jump locations.
Subsequent Steps
Comprehensive stack and memory evaluation would also integrate seamlessly into this architecture, allowing substantial blocks of code to consolidate into single commands. Furthermore, I aspire to incorporate symbolic-execution and transform the JIT into a fully functional JIT-VM. I believe this would be a logical progression once the programs grow large enough to leverage these optimizations.
Final Thoughts
Our JIT-VM is significantly more intelligent than the byte-code VM yet remains far from completed (if ever). There are numerous additional clever techniques we could implement within this framework, but they simply aren’t feasible at present. The execution time is within the parameters of being “reasonably” swift. Should the necessity arise to further optimize the VM, we possess the resources to achieve that.
Additional Code Review
Cross posted from – https://medium.com/@jeff.ethereum/go-ethereums-jit-evm-27ef88277520#.1ed9lj7dz
