This will be the initial release of the Eclipse OMR project.
The Eclipse OMR project is a set of open source C and C++ components that can be used to build robust language runtimes that support many different hardware and operating system platforms.
For this initial release, all of the components are functionally stable, but a few of them have not finalized an API yet. The list of components with stable APIs will grow with future releases. The table below summarizes the current status:
A platform porting library
A cross platform pthread-like threading library
General utilities useful for building cross platform runtimes
Components for building compilers, particularly JIT compilers
A diagnostic tooling library
Garbage collection framework for managed heaps
A simple high-level abstraction on top of the compiler technology
APIs to manage per-interpreter and per-thread contexts
While several components (port library, threading library, etc.) have very stable APIs, there remain components (like the GC glue definition, the compiler component, etc.) that are still under flux. The JitBuilder API is on its way to stability, but is still changing so we do not consider it stable at the moment. The compiler component, in particular, still contains a lot of code from the Eclipse OpenJ9 project, and while this code is not active in OMR and does not impact OMR builds, the presence of this code relfects an ongoing coupling between these two projects that we continue to work to reduce. Most of this coupling pain is felt by the Eclipse OpenJ9 project, but fixing it requires more work that spans both OMR and OpenJ9.
This release includes fixes for two CVEs reported:
CVE-2019-11773 (AIX only)
AIX builds of Eclipse OMR contain unused RPATHs which may facilitate code injection and privilege elevation by local users. We addressed this vulnerability by adding '-bnolibpath' to DLL link flags so that only the default library paths are added to the loader section of those shared libraries being built.
Builds of Eclipse OMR contain a bug where the loop versioner may fail to privatize a value that is pulled out of the loop by versioning - for example if there is a condition that is moved out of the loop that reads a field we may not privatize the value of that field in the modified copy of the loop allowing the test to see one value of the field and subsequently the loop to see a modified field value without retesting the condition moved out of the loop. This can lead to a variety of different issues but read out of array bounds is one major consequence of these problems. To prevent any such issues, loop versioner has been first modified to conservatively treat thse values as non invariant so that incorrect versioning will not occur. A more refined fix will be delivered in a subsequent release.
Conforms To UI/UX Guidelines:
The Eclipse OMR project primarily operates via its GitHub issues as well as communicating with our community via our Slack instance often providing hands-on help with issues as they arise. We have produced a number of tutorials and conducted workshops at e.g. CASCON 2018, SPLASH 2018 and others to give developers a feel for how to use different parts of the OMR project. Blogs have been written to help explan the JitBuilder library and its use.