Re: [omr-dev] Callback based IL generation

["Mark Stoodley" <mstoodle@xxxxxxxxxx>]

Hi Dibyendu,

> 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.

I think we're saying the same thing
just differently :) . You're treating the input to the compiler as "IL".
But "IL", in our system, is actually an internal data structure
of the compiler.

There are (currently) only two callbacks
from the JIT to user code: buildIL() and RequestFunction(). Both of these
are called from within compileMethodBuilder(). None of the JitBuilder objects
are cached by the JIT compiler at all. The compiled native code is stored
into a code cache by the JIT compiler, of course, but otherwise none of
those things you have listed in #1 or #3 are performed by JitBuilder.

JitBuilder implements no heuristics
to compile/recompile: that's all up to you. You call compileMethodBuilder()
and it compiles that method for you. It doesn't care if you delete that
MethodBuilder object once compileMethodBuilder comes back.

Over time, I would like to implement
hooks for JitBuilder to receive profile information and for TypeDictionary
to be able to represent more kinds of relationships between the types it
represents (actually, I'm unhappy with TypeDictionary right now because
it's technically a combination of a TypeDictionary and a ShapeDictionary
and I don't really want to conflate shape and type together, but that's
a whole 'nother topic).

One way to provide the kind of API you're
looking for would be to have the C API always use a recorder. Then the
compileMethodBuilder() call would simply call the replay capability to
actually generate IL. This is a less direct approach, because it creates
one data representation in order to later create the real IL, and it makes
the C API work rather differently than the C++ API. 

Going forward, one way we could choose
to evolve JitBuilder would be to just switch the entire client API to the
model Dibyendu is suggesting (i.e. the MethodBuilder can "receive"
service calls any time up until the call to compileMethodBuilder). The
original "buildIL() as callback" design seemed like a good fit
for object oriented languages and works well enough in C++ and Java but,
I confess, isn't very clean in a procedural language like C.

Anyone else on the list have an opinion
on changing the client form of the API?

Opinions are, of course, welcome on
the mailing list; I will also try to capture this discussion in https://github.com/eclipse/omr/issues/2397to collect the info together.

Mark Stoodley		8200 Warden Avenue
Senior Software Developer		Markham, L6G 1C7
IBM Runtime Technologies		Canada
Phone:	+1-905-413-5831
e-mail:	mstoodle@xxxxxxxxxx
We cannot solve our problems with the same thinking we used when we created them - Albert Einstein

From:      
 Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx>
To:      
 omr developer discussions
<omr-dev@xxxxxxxxxxx>
Date:      
 2018/06/04 05:38 PM
Subject:    
   Re: [omr-dev]
Callback based IL generation
Sent by:    
   omr-dev-bounces@xxxxxxxxxxx

---

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
_______________________________________________
omr-dev mailing list
omr-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/omr-dev