It makes more sense to have platforms such as Java and the JVM be open as opposed to proprietary.
J9 was largely used for IBM products which means it wasn't exposed to or tuned for workloads outside. Opening it up is a very good thing.
OMR is the foundation for J9, and it tackles the issues that come up again and again in dynamic runtimes:
1. Having a good threading, networking library, etc...
2. Having a battle tested industrial strength GC.
3. Having a JIT with easy to use optimizations out-of-the-box.
4. Having solid tooling for debugging and performance introspection.
Other runtimes such as Ruby, Python are at various stages of improving their GC or adding a JIT. The goal with OMR is to turn the battle tested components of J9 into pluggable components for these other runtimes. If tomorrow somebody wants to make a new Ruby or Python they shouldn't have to write their own GC or JIT, the same way nobody writes their own filesystem these days.
Oracle and IBM both see this and Truffle/Graal are different ways of attacking the same problem.
J9 was largely used for IBM products which means it wasn't exposed to or tuned for workloads outside. Opening it up is a very good thing.
OMR is the foundation for J9, and it tackles the issues that come up again and again in dynamic runtimes:
1. Having a good threading, networking library, etc...
2. Having a battle tested industrial strength GC.
3. Having a JIT with easy to use optimizations out-of-the-box.
4. Having solid tooling for debugging and performance introspection.
Other runtimes such as Ruby, Python are at various stages of improving their GC or adding a JIT. The goal with OMR is to turn the battle tested components of J9 into pluggable components for these other runtimes. If tomorrow somebody wants to make a new Ruby or Python they shouldn't have to write their own GC or JIT, the same way nobody writes their own filesystem these days.
Oracle and IBM both see this and Truffle/Graal are different ways of attacking the same problem.