This is a leaner version of the Eclipse OMR project focussing just on the compiler / JIT backend.
Here is what is included:
compiler: Components for building compiler technology, such as JIT compilers.jitbuilder: An easy to use high level abstraction on top of the compiler technology.tool: Code generation tools for the build system (only required parts)fvtest: Tests for the compiler/JitBuilder (includes tril)
Following OMR components have been removed:
gc: Garbage collection framework for managed heapsport: Platform porting librarythread: A cross platform pthread-like threading libraryutil: general utilities useful for building cross platform runtimesomrsigcompat: Signal handling compatibility libraryomrtrace: Tracing library for communication with IBM Health Center monitoring toolsvm: APIs to manage per-interpreter and per-thread contextsexample: Demonstration code to show how a language runtime might consume some Eclipse OMR components
- Builds successfully on Linux, Mac OSX and Windows 10
- Some tests fail on Windows 10
- A C API is implemented to allow easy use of the JIT engine in projects; note this is a low level api, not the same as the JITBuilder api provided by Eclipse OMR. A user guide for this api will be available at a future date.
- An easy way to get started is to use the C front end dmr_C, which enables you to generate code from C code taking away a lot of the complexities of working with the JIT api.
- Or you can use the JITBuilder api from OMR which is included and installed by default.
- Immediate focus is on trying to use the JIT engine behind a C front end dmr_C and with the help of that, as a backend JIT engine for Ravi, a Lua 5.3 derived language.
- I would like to further trim the library to make it even leaner and focussed - especially enable a build option that is minimal in size
- The OMR technology originated for Java. In Java, stack values cannot be referenced through pointers. Hence stack values cannot be modified indirectly via pointers, nor can they be aliased by function calls. OMR's optimizer (mainly the alias analysis framework in the optimizer) does not handle these scenarios, hence resulting in incorrect optimization. Therefore, OMR at present cannot be successfully used as the JIT for a language such as C. The approach I am taking in dmr_C for now is to not allow constructs that are not supported.
I have submitted a pull request to Eclipse OMR for the C api as it stands. However that does not do away with the need to maintain this project as I disagree with one aspect of the Eclipse OMR strategy which is to make the compiler depend on the port and thread libraries.
Initially I wanted to merge the commits from Eclipse OMR using git's am facility. But I got hopelessly lost and some of the
merges did not succeed. So sadly I am taking the easy way and am doing periodic manual merges from the OMR tree using BeyondCompare tool. The downside is that the upstream commit history is not maintained.
You can build the libraries and install the header files plus library. On Windows a static library is built. On Mac OSX and Linux a shared library will be built (JITBuilder library will be static however).
Note - the only builds I have done so far as X86-64 versions. I have no means of testing other architectures.
Note that due to the way the OMR code is structured the code is compiled several times, once for each target. You can reduce the time taken to build by commenting out some of the targets you do not require in the top-level CMakeLists.txt file.
- You will need CMake, Perl, Python, bison and flex installed
- I follow steps below from the location of source directory.
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$HOME/Software/nj -DCMAKE_BUILD_TYPE=MinSizeRel ..
make install
- You will need Visual Studio 2017, Python, Perl, Win flex-bison, and CMake installed
- Follow these steps from the source directory
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/Software/nj -G "Visual Studio 15 2017 Win64" ..
cmake --build . --target INSTALL --config MinSizeRel