Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [omr-dev] ResolvedMethod question

Hi Mark,

On 17 June 2018 at 16:32, Mark Stoodley <mstoodle@xxxxxxxxxx> wrote:
>
>
> Our goal for OMR (as a whole, but also for the compiler) is to make it a toolkit where you can pick and choose the pieces you want. The goal, again, should be to simplify the integration API of each tool in the kit to make it easy to tie into something from outside OMR, but for the integration to be "ready made" if you take more than one tool and use them together.


Sure - no issues with that. I just wanted to be sure that all the
future planning takes into account cases like mine, where there is no
VM, no GC, etc. I felt after watching some of the videos that there is
a tendency to think about the language runtime / VM - whatever that
may be - a lot (not surprising as OpenJ9 is the biggest user) . With
the whole of OMR being considered a single product it can also become
difficult to maintain the longer term re-usability of the compiler
component as something standalone.

> To be honest, JitBuilder isn't really all that strongly integrated with the rest of the OMR componentry. So, if anything, it's less attached to that "big VM" model you're talking about, but I still know what you mean :) .
>
> That higher degree of separation has made it possible to use JitBuilder to create JITs for several (I think you'll agree) lighter-weight VM scenarios, e.g.:
>         - Lua 5.3 (https://github.com/Leonardo2718/lua-vermelha/)
>         - SOM++ Smalltalk runtime (https://github.com/charliegracie/SOMpp/tree/jitbuilder_vmstate)
>         - the lpeg pattern engine inside the Rosie Pattern Language (https://github.com/mstoodle/rosie-lpeg/tree/experimental_omrjit)
>         - WebAssembly's wabt interpreter (https://github.com/wasmjit-omr/wasmjit-omr)
>

That is great - and yes I agree. I guess I would like the OMR
evolution to be such that it remains easy for use in unconventional
language implementations - i.e. not too much assumptions are being
made about the kinds of use cases for OMR.

Regards
Dibyendu


Back to the top