Skip to content

Commit

Permalink
Evm tool readme update (hyperledger#7274)
Browse files Browse the repository at this point in the history
* update paths to binary. update docker build to use java 21
* updated suggested jdk

---------

Signed-off-by: Justin Florentine <justin+github@florentine.us>
Signed-off-by: Daniel Lehrner <daniel.lehrner@consensys.net>
  • Loading branch information
jflo authored and daniellehrner committed Jul 16, 2024
1 parent 7ab7eed commit e5e5068
Show file tree
Hide file tree
Showing 3 changed files with 20 additions and 94 deletions.
71 changes: 19 additions & 52 deletions ethereum/evmtool/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,13 +8,9 @@ and enclosing data structures.
Using EVM Tool in execution-specification-tests
-----------------------------------------------

To use EVM Tool in Execution Spec tests it is recommended that you use
the GraalVM build, as the framework incurs significant startup penalties
for each invocation when run via the Java runtime.

### Building Execution Tests on macOS

Current as of 24 Jun 2023.
Current as of 26 Jun 2024.

MacOS users will typically encounter two problems,one relating to the
version of Python used and one relating to zsh.
Expand All @@ -35,93 +31,64 @@ install python packages needs to escape the brackets
pip install -e .\[docs,lint,test\]
```

An all-in-one script, including homebrew, would look like
An all-in-one script, using homebrew, would look like

```zsh
brew install ethereum solidity
git clone https://github.com/ethereum/execution-spec-tests
cd execution-spec-tests
python3 -m venv ./venv/
source ./venv/bin/activate
pip install -e .[docs,lint,test]
pip install -e .\[docs,lint,test\]
```

### Building EvmTool with GraalVM on macOS
### Building EvmTool on macOS

First you need a GraalVM JDK installed, if not already installed.
First you need a Java 21+ JDK installed, if not already installed.

It is recommended you install [SDKMAN](https://sdkman.io/install) to
manage the graalVM install, homebrew has issues with native attributes
and code signing.
manage the jvm install.

```zsh
sdk install java 22.3.r17-grl
sdk use java 22.3.r17-grl
sdk install java 21.0.3-tem
sdk use java 21.0.3-tem
```

You can also manually install GraalVM from
the [GraalVM website](https://www.graalvm.org/downloads)..

Once GraalVM is installed you use the `nativeCompile` target.
Once a JVM is installed you use the gradle target:

```zsh
./gradlew nativeCompile
./gradlew installDist -x test
```

The resulting binary
is `./ethereum/evmtool/build/native/nativeCompile/evmtool`
is `build/install/besu/bin/evmtool`

If the testing repository and besu are installed in the same parent
directory, the command to run the execution tests is

```zsh
fill -v tests --evm-bin ../besu/ethereum/evmtool/build/install/evmtool/bin/evm
fill -v tests --evm-bin ../besu/build/install/besu/bin/evmtool
```

Assuming homebrew and SDKMan are both installed, the complete script is

```zsh
sdk install java 22.3.r17-grl
sdk use java 22.3.r17-grl
sdk install java 21.0.3-tem
sdk use java 21.0.3-tem
git clone https://github.com/hyperledger/besu
cd besu
./gradlew nativeCompile
./gradlew installDist -x test
cd ..

brew install ethereum solidity
solc-select install latest
solc-select use latest
git clone https://github.com/ethereum/execution-spec-tests
cd execution-spec-tests
python3 -m venv ./venv/
source ./venv/bin/activate
pip install -e .[docs,lint,test]
pip install -e .\[docs,lint,test\]

fill -v tests --evm-bin ../besu/ethereum/evmtool/build/install/evmtool/bin/evm
fill -v tests --evm-bin ../besu/build/install/besu/bin/evmtool
```

If you don't want to use the GraalVM tool the binary that is compatible
is generated by the `ethereum:evmtool:installdist` target and is located
at `./ethereum/evmtool/build/install/evmtool/bin/evm`

Why not GraalVM for everything?
-------------------------------

Using GraalVM in execution-spec-tests results in over 20x performance
increase in execution. It will be faster to build GraalVM from scratch
and run the execution-spec-tests than to run just the Java version.

It is demonstrably faster to run the Java version for a node.
All the test execution gains are the result of reduced startup
penalties. Larger benchmarks will show that performance intensive EVM
code will be slower in GraalVM than the Java version due to the adaptive
compiler.

For contracts that execute 30 million gas in small operations it is
often faster to run the Java EVMTool than the GraalVM EVMTool, including
startup penalty. The execution tests focus on smaller VM tests that
demonstrate specification conformance.

We would also need to reconsider some library choices. GraalVM does not
work with Log4J, and we would have to ban that library across Besu and
all dependents. Libraries such as Netty also have some problematic entry
points that interact poorly with how SLF4J needs to initialize.

41 changes: 0 additions & 41 deletions ethereum/evmtool/build.gradle
Original file line number Diff line number Diff line change
Expand Up @@ -72,16 +72,6 @@ dependencies {

mainClassName = 'org.hyperledger.besu.evmtool.EvmTool'

startScripts {
applicationName = 'evm'
defaultJvmOpts = [
"-Dsecp256k1.randomize=false"
]
doLast {
unixScript.text = unixScript.text.replace('BESU_HOME', '\$APP_HOME')
windowsScript.text = windowsScript.text.replace('BESU_HOME', '%~dp0..')
}
}

// rename the top level dir from besu-<version> to besu and this makes it really
// simple for use in docker
Expand Down Expand Up @@ -148,34 +138,3 @@ tasks.register('dockerUpload', Exec) {
executable "sh"
args "-c", cmd
}

graalvmNative {
binaries {
main {
sharedLibrary = false
buildArgs.addAll(
"-H:ReflectionConfigurationFiles=${projectDir}/src/main/graal/reflection-config.json",
"-H:AdditionalSecurityProviders=org.bouncycastle.jce.provider.BouncyCastleProvider",
'-H:+TraceSecurityServices'
)


// Netty drags in older versions of bouncy castle, exclude it so there are no conflicts
excludeConfig.put("io.netty:netty-buffer", [".*"])
}
}
}


configurations.nativeImageClasspath {
// netty statically allocates some problematic classes
exclude group: 'io.netty', module: 'netty-buffer'
exclude group: 'io.netty', module: 'netty-common'
exclude group: 'io.netty', module: 'netty-transport'

// keep log4j from sneaking in. GraalVM has an aleric reaction if it sees even one class
exclude group: 'org.slf4j', module: 'log4j-over-slf4j:1.7.36'
exclude group: "log4j", module: "log4j"
exclude group: "org.apache.logging.log4j"
exclude group: 'org.bouncycastle', module: 'bcprov-jdk18on'
}
2 changes: 1 addition & 1 deletion ethereum/evmtool/src/main/docker/Dockerfile
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ RUN apt-get update $NO_PROXY_CACHE && \
apt-get -o Acquire::BrokenProxy=true -o Acquire::http::No-Cache=true -o Acquire::http::Pipeline-Depth=0 \
--no-install-recommends -q --assume-yes install ca-certificates-java=20190909* && \
apt-get -o Acquire::BrokenProxy=true -o Acquire::http::No-Cache=true -o Acquire::http::Pipeline-Depth=0 \
--no-install-recommends -q --assume-yes install openjdk-17-jre-headless=17* && \
--no-install-recommends -q --assume-yes install openjdk-21-jre-headless=21* && \
# Clean apt cache \
apt-get clean && \
rm -rf /var/cache/apt/archives/* /var/cache/apt/archives/partial/* && \
Expand Down

0 comments on commit e5e5068

Please sign in to comment.