Omr: What does a minimal glue directory look like, and how do I hook it up?

[mgaudet]

Regarding PR #293: In the case where I want to use the OMR compiler technology, what does my OMRGLUE directory look like?

See the discussion on #293 for more background.

[mstoodle]

It probably looks a lot like a stripped down version of the jitbuilder directory.

[mstoodle]

What you're proposing sounds like an example/compileronlyglue directory. In there, you could do the same #error handling for defining the genIL() implementation in a basic IL generator.

Does that sound about right?

[charliegracie]

In your scenario @mgaudet are you trying to figure out the minimal OMRGLUE required to use the Eclipse OMR project with only the OMR_JIT build flag enabled?

[mgaudet]

Yep; early experiments suggest that an empty directory may suffice if you explicitly configure with

--enable-OMR_JIT --disable-OMR_GC [--enable-fvtest] 

[charliegracie]

I would expect that to compile but if you link the libomrstatic.a library into your application I would expect that there would be link errors for missing functions if you use and of the non compiler OMR APIs.

The current idea for OMRGLUE is that you copy the omr/glue folder into your runtime (you can choose any location / folder name you like) and provide the implementation for any of the functions required by the components you have ./configure enabled. Required functions have a #error in them so you know what needs to be filled in as a minimum. Currently if you have the GC disabled there will only be 2 functions you need to provide an implementation for and they are related to RAS features that are not properly wrapped in #if blocks. Hopefully if I get some changes finished this week I will remove the requirement to fill in those 2 functions.

There is too much code / required implementation in the current omr/glue folder. The GC is working on moving a lot of the implementations back into the GC proper since they are the same for all languages. This is a work in progress and we are hoping to drastically reduce the number of files and lines of code in this folder. With this there is also the omr/example/glue folder provided so that the FV tests can compile and test the different components of OMR. Having both folders (omr/glue and omr/example/glue) is confusing and cumbersome to keep in sync since the omr/glue folder is not actually used. Our current thinking is that the omr/example/glue folder be morphed into the only "glue" provided. The example/fv implementations will be under an #if defined(OMR_EXAMPLE) or something similar which would only be enabled for the example/FV tests and provide the same #error messages if that build flag is not defined.

I think the compiler test glue should likely move into the omr/example/glue at some point as this would make it more consistent. The JIT Builder code is something that I think we need to spend more time thinking about so I do not have a suggestion about where it belongs / plugs into this model.

[dibyendumajumdar]

Hi - I am also trying to work out the minimal set of glue code I need to use the compiler. I am interested in using the core IL directly - so that I can start to understand the backend.

I have been looking at the compilertest and jitbuilder projects to see how this is done - but I am not sure that this gives me a minimal subset.

I tried compiling the code (not omr but my cutdown compiler/jitbuilder only version) without the glue code and that way found that the backend expected to include ConcreteFE.hpp and ILGeneratorMethodDetails.hpp at least.