Currently, all contracts compiled by the JIT are stored in a disk cache and this cache is loaded into memory completely. We might add dropping some unused items or make it smarter in some other way. We could also remove items which are not according to the current schedule (frontier / homestead / ...)

Moved from ethereum/webthree-umbrella#174

There are issues with using C abi with languages (eg. Rust) with different memory allocators (jemalloc). Structures being used by C++ code must be allocated by C++ memory allocator. eg. RuntimeData.

Here is an example of fixed C abi which is succesfully being used with Rust ethereum implementation.

https://github.com/ethcore/evmjit/blob/develop/include/evmjit/JIT-c.h

Instead of jumping to Stop block. It can lead to memory leak.

Tag with a version number and push current version to master branch.

With regard to @chfast's Cross-team EVM Benchmark Suite proposal (#47), I think that is a project which we absolutely should be doing, but that is just one part of something broader which we should be addressing, which is to provide a neutral dashboard showing all aspects of particular EVM's protocol compliance, performance and any other valuable metrics or statistics which can be automated.

I think that the onus is on us as the Ethereum Foundation to maintain and host publicly visible automated dashboard instances of such metrics and tests for all EVM implementations.

See https://html5test.com, for example, or https://arewefastyet.com/, for browsers.

Some examples:

• http://github.com/ethereum/tests
  • We have these, and I believe they are being run, generally, by the various client teams, but the results for those aren't aggregated anywhere to the best of my knowledge)
• https://github.com/ethereum/rpc-tests
  • I believe that these were abandoned at some point, but we should definitely have such tests, whether the are these ones, or a new suite. @tinybike tells me that there is a suite they have at Augur.
• EVM benchmarking (as per #47), or perhaps there are other performance suites at ETHCORE, ConsenSys and elsewhere. We should certainly have a single set of tests which we all run. If our current suite is "wrong" then we should fix that.

This is now a bug. EVMJIT passes arguments as int64, but does not check if the value is not greater.

The optimizer should use less registers for values where it can infer that they need less than 256 bits. We should potentially also revisit the code that is generated for e.g. 256 bit multiplication such that it is efficient for small values and that branch prediction is correct.

evmjit should have its own tests, especially to avoid regressions of the optimizer

Check constant gas, stack and memory requirements and the beginning of the block.

JIT instance

handle create();

void destroy(handle);

context exec(handle, ...);

In normal solidity code, loops should always jump to a position that has the same stack height. This means that the stack underflow check should not be done in every iteration of the loop.

I am having cpp-jit fail with memory leak on
https://github.com/ethereum/tests/blob/develop/StateTests/RandomTests/st201505272131CPPJIT.json

somewhere in function
void Compiler::createBasicBlocks(code_iterator _codeBegin, code_iterator _codeEnd)

We should have a standalone test infrastructure for EVMJIT, so that we can run automated tests with only the single repository, and so that developers can run the tests based purely on cloning this single repository.

make test, test.sh or whatever.

We should create a stand-alone VM benchmarking tool using input in reusable format (like the vm tests, for example).
The ethvm binary already is a stand-alone tool and should especially be used to test the performance of the interpreter in comparison.

evmjit/libevmjit/Utils.cpp:16: warning: Redundant code: Found a statement that begins with numeric constant.

Will be used to memory and dynamic stack

If the bytecode of a call target is compiled, the jit should directly invoke it without first going through the runtime. This of course requires information like the current call stack depth to be available to the jited module.

Hello! I'm working on compiling the webthree-umbrella source tree (WU) on FreeBSD 10.3-RELEASE. WU uses libethereum as a Git submodule, which of course - in turn - uses evmjit as a submodule.

Personally, I'd like to be able to develop a complete port and some documentation about the WU build on FreeBSD - perhaps towards developing a manner of a FreeBSD edition specifically for Ethereum nodes? and of course it would include geth. Presently, I'm trying to - so to speak - to "Hash out" the dependencies for the build, onto the FreeBSD ports tree.

I noticed that libevmjit/support/Path.h defines a small number of preprocessor macros, such that are applied in the corresponding Path.cpp file as with regards to the definitions of the dev::path::user_home_directory() and dev::path::user_cache_directory() functions. Rather than trying to globally define -D__linux to pull in those macros' respective Linux definitions on FreeBSD, I've patched Path.h such as to allow for the macros to be declared in CXXFLAGS. The macros affected with this patch include:

• UTILS_OS_LINUX
• UTILS_OS_MAC
• UTILS_OS_POSIX
• UTILS_OS_WINDOWS

The applications of the bold annotated macros, of course, may be in some ways apropos to the FreeBSD build.

In reference to how these macros are applied in Path.cpp I've added a note to my own albeit ad-hoc notebook - towards adding a note to the documentation - that the UTILS_OS_LINUX definition is apropos to an environment variable named XDS_CACHE_HOME applied in Path.cpp. I'm not sure of whether or how that may pertain to XDG_CACHE_HOME as in reference to the XDG Base Directory spec. It seems that the XDS... environment variable's name does find some applications, however I'm not sure if it's quite as common as the XDG_CACHE_HOME form? Perhaps that could be addressed in a separate patch, but I wouldn't want to propose a change to it without being certain as with regards to applications of the XDS form viz a viz XDG_CACHE_HOME

The present patch will address only the definitions in Path.h

patch_evmjit_path.diff.txt

Homestead support is already done by chriseth in https://github.com/ethereum/libethereum/tree/develop/evmjit. This library needs to be merged with it.

• Question and discussion: https://groups.google.com/forum/#!topic/llvm-dev/WJd0nRr0yxs.
• Test passing i256 as {i64,i64,i64,i64}.
• Test returning i256 as {i64,i64,i64,i64}.

During @programonauta work on getting cpp-ethereum building on Debian 8 (Jesse), he's seeing the following build break:

CMake Error at libethereum/evmjit/CMakeLists.txt:5 (cmake_policy):
  Policy "CMP0054" is not known to this version of CMake.

Google tells me that CMP0054 was introduced in CMake 3.1.

https://cmake.org/cmake/help/v3.1/policy/CMP0054.html

In various parts of our documentation, I have seen our minimum version for CMake listed as 3.0.

Now we could obviously say "Our minimum CMake version is 3.1", but I think this one place is probably the only use we have of a > 3.0 feature, so maybe we can weaken it off, or do something conditional so that we just work out of the box on Debian.

What do you guys think? @chfast, @chriseth?

• Auto generate doxygen docs and push to GitHub Pages.
• evm_get_info should return NULL if the key is not found (by @axic).
• Drop evm_get_info(). (#84)
• Consider extending evm_result with custom error codes and messages. (#81 and #83)
• Support multiple VMs by providing vtable in evm_instance.
• Replace evmjit_is_code_ready() by evm_get_code_status().
• Replace evmjit_compile() by evm_prepare_code().
• Consider not using bool.
• Replace #define EVM_EXCEPTION with const int64_t EVM_EXCEPTION (will help Python CFFI).
• Add API version to evm_interface.
• Reuse evm_result/evm_result_code in evm_call_fn. (moved to #86)
• Add support for VM tracing. (moved to #85)

• Pull changes from libethereum/evmjit to develop branch (last pull 045f421).
• Remove libethereum/evmjit, ethereum/libethereum#232
• Reconfigure webthree-umbrella, ethereum/webthree-umbrella#459
• Test build.

Spent a while trying to compile this against llvm35 as per the OS X instructions, when it turns out cmake will fail if the version < 3.7. It's (as of 8/1) unreleased so git repo for source download is in a branch here: https://github.com/llvm-mirror/llvm/tree/master Hopefully this saves someone some time.

Keep internal ABI version used to detect incompatible cached objects as an internal number. Usage of the project version declared in cmake file is bad idea.

It might be considered to create a separate execution context / process for evmjit to limit the effects of possible breakouts.

Moved from ethereum/webthree-umbrella#175

Pull changes done recently to evmjit in libethereum and replace evmjit in libethereum with a git submodule.

Allow DIV instruction to be replaced by shift by LLVM. To do that, DIV must be replaced with function call AFTER the IR optimizations applied.

In a loop of the form

for (uint i = 0; i < 100; i++) {
...
}

the jit should generate code that uses a regular register for i.

• Any working build server that just builds the code. CircleCI has been configured to build every git push (including PRs).
• Configure Jenkins to build (and test if tests included) on multiple platforms. This requires LLVM being available for those platforms. Suggested solution is to use Jenkins Pipeline plugin and Jenkinsfile.
• Optional. Configure build and test of dependent projects (e.g. libethereum) to be used as integration tests. This is optional because alternatively we can postpone integration tests to the moment when evmjit upgrade is proposed to dependent projects in form of a PR.

If a loop iteration consumes constant gas (g) and the number of iterations is "known" (n) in advance, the optimizer should convert the out-of-gas checks into a single if (gas <= n * g) throw before entering the loop.

evmjit/libevmjit/Stack.h:27: style: Unused private function: 'Stack::getPopFunc'
evmjit/libevmjit/Stack.h:28: style: Unused private function: 'Stack::getPushFunc'
evmjit/libevmjit/Stack.h:30: style: Unused private function: 'Stack::getSetFunc'

The notion of "undefined behaviour" is a big opportunity for optimizers to do their work.
For example the content of memory in case of an out-of-gas exception should be undefined and so the optimizer might remove some memory writes if it can already anticipate that we will run out of gas in a later instruction.

Evmjit often crashes when it's used from multiple processes, because of cache race conditions.

Static llvm libraries in Fedora 23, installed from packages such as llvm-static.x86_64, are in /usr/lib64/llvm/, but the current Makefile looks for them in /usr/lib/.

[giacecco@giaceccos-linux evmjit]$ mkdir build
[giacecco@giaceccos-linux evmjit]$ cd build/
[giacecco@giaceccos-linux build]$ cmake ..
-- The CXX compiler identification is GNU 5.3.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- EVM JIT 0.9.0
-- Using LLVM 3.7.0 (/usr/share/llvm/cmake)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/giacecco/Documents/Dico.im/GitHub-projects/evmjit/build
[giacecco@giaceccos-linux build]$ make 
Scanning dependencies of target evmjit
[  5%] Building CXX object libevmjit/CMakeFiles/evmjit.dir/JIT.cpp.o
(...)
[ 95%] Building CXX object libevmjit/CMakeFiles/evmjit.dir/support/Path.cpp.o
make[2]: *** No rule to make target '/usr/lib/libLLVMCore.a', needed by 'libevmjit/libevmjit.so.0.9.0.2'.  Stop.
CMakeFiles/Makefile2:85: recipe for target 'libevmjit/CMakeFiles/evmjit.dir/all' failed
make[1]: *** [libevmjit/CMakeFiles/evmjit.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
[giacecco@giaceccos-linux build]$

See also ethereum/webthree-umbrella#524 .

Thanks!

We need to load runtime data elements only once.
Also useful for Stack/Memory.
GVN optimization pass can be a good candidate.

I want to describe an idea of creating a small project that will allow benchmarking different implementations of Ethereum VM. We can move the discussion if you know better place to have it.

EVM Benchmark Suite

EVM Benchmark Suite is responsible of benchmarking individual Ethereum VM implementations and collecting results in form of reports. Each EVM implementation needs to provide a small executable that is capable of running a benchmark or a series of benchmarks (to speed up testing). The executable should inform the Suite about benchmark timings - they can be divided into implementation specific partitions.

What do we need?

1. The Suite itself. It should take a set of benchmarks, run executables, collect results and generate a report. I would suggest using Python for that.
2. EVM executables. Mamy projects have them already (C++ ethvm, Go evm). They should show timings as the result. The same interface would be nice, but is not must-have. We can handle different interfaces in Python in the begging.
3. Benchmark format spec. We can take a look at VMTests and/or StateTests (https://github.com/ethereum/tests/tree/develop).
4. Benchmarks. A lots of people started investigating VM performance using their own code snippets. We should start collecting the tests.