Re: [omr-dev] Callback based IL generation

[Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx>]

Hi Mark,

On 4 June 2018 at 14:55, Mark Stoodley <mstoodle@xxxxxxxxxx> wrote:
> So, rather than creating a MethodBuilder object and passing that to
> compileMethodBuilder which will call that object's buildIL() function, you
> would prefer to build the IL yourself and then call compile() on it?
>

Not exactly. Once I have MethodBuilder I was expecting to be able to
use it to add IL instructions; As MethodBuilder is a derived class of
ILBuilder. I added a couple of instructions and then called compile
but nothing happened. Then I realized that this is not how it works.
>
> There are some other important factors here as well. Since the IL changes
> throughout the compilation, having the JIT be in control of the IL
> allocations allows it to be more efficient at managing memory (using pools,
> regions, or even just bulk de-allocate at the end of the compilation). If
> the IL is pre-allocated (i.e. provided as input), then managing memory makes
> an already complicated subject that much more complicated.
>
> The first step of compilation is considered "generate IL for the thing you
> want to compile". So the most natural fit is a callback based approach. In
> many dynamic languages, since the input conditions change over time as
> "classes" are loaded/changed/unloaded, generating the IL on demand when you
> want to compile the method probably allows you to generate better IL which
> means better code.
>

I am new to the codebase so I could be mistaken in my understanding of
the issues. But I still think the current approach is flawed.

In my view there are three different concerns:

1. The Source Method which presumably contains some form of Source
Code - may be bytecode or some other form
2. The IL Generator/JIT Compiler are there to generate IL / machine
code from the Method's Source Code. For my purpose I am treating these
two as one component but in reality are need not be. These components
need not be stateful at all as they take input and produce output.
3. The hosting application / framework that decides when a method
should be compiled, with what optimisation options, whether the code
should be cached, how memory is managed etc.

I would like the JIT engine to just do 2) above. Unfortunately in OMR
right now it seems that these separate concerns are somewhat meshed
together - which is not surprising given the JVM heritage.

The callback approach requires the MethodBuilder / ILBuilder to hold
on to the Method's Source code (or some state) - as the engine may
call it again in future, right? The client has no control over when
the callback will be invoked. This is bad in my view as the concerns
are getting mixed up. The hosting application should be free to hold
on to the Method definition (in the Java case this is the classfile I
guess) - and recompile when necessary. But to retain the builder
object and expect to regenerate IL seems wrong.

I feel that all that you are saying could be achieved without using a
callback approach.

Hope this makes sense.

Regards