Danno Ferrin 1961b5d143 Flatten EVM Loop (#1192) ...

Our current EVM loop splits out cost, execution and halt evaluation. Flattening these three into one method results in a significant speedup in reference tests, which are EVM heavy.

Mostly the cost, exceptionalHaltCondition, and execute are merged into one method, sharing calculations between the three.

In fixed cost operations the merger is very simple AddOperation is a representative fixed cost operation.

Check the gas, check other exceptional halts, do the work, return the result.

In variable cost operations there is some value reads to be done before the cost is calculated. This is where a lot of the de-duplication occurs. CodeCopyOperation is a representative variable cost operation.

JumpIOperation shows where this merger pays off. If the condition is zero then some exceptional halts don't need to be considered. But with the three way split each step couldn't consider such optimizations because the local data was lost between each call.

Some cleanup was enabled by this. The old exceptional halt predicates were deleted and moved into each operation. Gas costs must be checked by the operation instead of globally, or we would lose state if we had to split into two methods and do the gas check shared.

The OperandStack was flattened into a single class instead of an interface plus a single implementation. stack underflow and overflow are signaled via named exceptions and handled via catches instead of pre-checking the stack height. Since overflow/underflow is exceedingly rare in mainnet transactions java exceptions are the more performant means.

Some of the APIs had lingering impacts on how some tests were run and the EVMTool (we cache operation cost in the message frame now.)

Signed-off-by: Danno Ferrin <danno.ferrin@gmail.com>

2020-07-07 19:17:50 -06:00

..

src/main

Flatten EVM Loop (#1192)

2020-07-07 19:17:50 -06:00

build.gradle

Fix Gradle 7.0 compatibility issues and build warnings (#288)

2020-01-13 08:28:50 -07:00