Using eclipse/omr to support GC languages to produce WebAssembly

[StEvUgnIn]

Hi dear Wasm community,
I would like to present OMR and its goals. I will also explain how this technology has potential to enable support for GC languages embedding on WebAssembly:

What is OMR?

The Eclipse OMR project consists of a highly integrated set of open source C and C++ components that can be used to build robust language runtimes that run on many different hardware and operating system platforms.

The core technology components include, but are not limited to: a platform porting library, a thread library, diagnostic services, monitoring services, a just-in-time compiler, and a garbage collector.

Other, developer-focused components, include build tools and utilities, a test framework, and demonstration code to show how a language runtime might consume Eclipse OMR components.

Why should I use it?

Despite decades of research and development in building languages and runtimes, almost none of the popular language runtimes share any common components. Many runtimes implement their own interface to the operating system, their own garbage collector, their own asynchronous event handling, their own diagnostic formats and so on. However, by reusing the core facilities provided by Eclipse OMR and extending those facilities to cater for your language, you can cut down on the time and effort needed for development. And of course, sharing implementation technology for language runtimes also fosters enablement and adoption of newer, modern programming languages.

Source: https://www.eclipse.org/omr/starter/whatisomr.html

In summary, with OMR, the eclipse foundation attempts to solve the lack of shared components in the implementation of runtime for modern GC languages. This led to too many differences. The web being open source and cross platform, we should also go in the same direction, to support different languages and technologies on the web through WebAssembly.

Components

Eclipse OMR is made up of shared, reusable, open-source core components for building language runtimes. These components include:

Garbage Collector (GC): a garbage collection framework for managed heaps. Eclipse OMR includes several implementations: mark-and-sweep, generational, and parallel scavenger.
Port Library (port): a platform abstraction (porting) library.
Thread Library (thread): a cross platform threading library.
Utility Library (util): a variety of utility libraries that provide functions for building cross platform runtimes.
Virtual Machine (VM): APIs to manage per-interpreter and per-thread contexts.
Trace Library (omrtrace): a tracing library for communication with IBM Health Center monitoring tools.
Signal Handling Compatibility Library (omrsigcompat): a signal handling compatibility library.
Compiler: for native code generation.
Diagnostic services: (to be contributed) Health Center provides a live view of runtime details, such as GC statistics and method profiling.

Source: https://www.eclipse.org/omr/reference/components.html

We could take some of the components (GC, port, util) to integrate them in the specification for integrating Garbage Collection into WebAssembly. Another solution would be to implement a LLVM toolchain based on the native code (JIT) compiler, they are offering.

Git Hub repository: https://github.com/eclipse/omr
Eclipse OMR: https://www.eclipse.org/omr
Reference: https://www.eclipse.org/omr/reference/architecture.html
Building: https://www.eclipse.org/omr/guide/building.html
Presentations: https://www.eclipse.org/omr/resources/presentations.html
Goals: https://www.eclipse.org/omr/starter/goals.html

[aardappel]

To allow languages to use OMR and also target Wasm, you could try porting the OMR C/C++ libraries to Wasm. This will likely however be difficult, since we don't have facilities for stack inspection yet (though they are being proposed), no way to JIT at a fine-grained level from within Wasm, and threads are only just being standardized / widely implemented.

We are also working on a native way to do GC that is part of the Wasm spec directly. To port OMR to work directly on top of this would likely not be very productive, as in that case Wasm itself replaces most of the work that OMR does. So a language might be better off targeting Wasm GC directly in that case.

If instead of those, you mean to suggest that OMR should be built-in to Wasm as the way to do GC, that may be difficult at this point, as several Wasm specific proposals for GC are already underway. Engines implementing Wasm typically already have a GC implementation (for JS) and would want to keep using it. You are encouraged however to get engaged in the Wasm GC discussions and propose how we can do things better.

[kripken]

I am slightly more optimistic than @aardappel I think 😄 I'd be very interested to see someone port OMR to wasm, and I think it could be done today:

• Stack inspection can be done using Asyncify (for example emscripten has helpers to scan the stack and registers, built on Asyncify). Another possible approach is Binaryen's SpillPointers pass. Each has overhead, but would work for now, and when stack switching arrives it could be fast. This could also help the stack switching discussions.
• JITing is indeed limited as you need to create an entire new Module. But it works, and as long as you avoid JITing a huge number of tiny functions, it should be fine (you could compile in large-enough bundles, for example).