besu/evmtool at d45f3ffac4b4f39b2e9f7f93385a8a476c127e8c - besu

An enterprise-grade Java-based, Apache 2.0 licensed Ethereum client https://wiki.hyperledger.org/display/besu

History

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>	4 years ago
..
src/main	Flatten EVM Loop (#1192 )	4 years ago
build.gradle	Support rocks DBs in EVMTool (#933 )	5 years ago

Danno Ferrin 1961b5d143

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>

4 years ago

src/main

Flatten EVM Loop (#1192 )

4 years ago

build.gradle

Support rocks DBs in EVMTool (#933 )

5 years ago