Re: [omr-dev] ResolvedMethod question

[Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx>]

Hi Mark,

On 15 June 2018 at 18:17, Mark Stoodley <mstoodle@xxxxxxxxxx> wrote:
>
> > But if ResolvedMethods are cached in MethodBuilder - how are
> externally defined functions resolved?
>
> I'm not quite sure what you mean by "resolved" in this question. JitBuilder requires the client to call DefineFunction in order to associate an instruction address and ABI (parameters, return type) with a function name. That's the "caching" (your term) that MethodBuilder does. Calling "DefineFunction" to define the entry points and ABI for which methods is up to the client. And that leads into the second question you asked...

Okay. I had assumed that DefineFunction() is only for the function
being defined by MethodBuilder - if I understand you correctly then
one can call DefineFunction() for any function that is to be called,
including external ones (e.g. some library function).

>
> > I don't understand why a RequestFunction is a callback. Who is calling whom?
>
> In the dynamic JIT world, the runtime process (or "client", as I tend to call it from the JitBuilder perspective) tends to have data structures recording all the possible methods or functions, usually organized around a (large) set of code units (classes, prototypes, modules, whatever you want to call them). I'm usually thinking from the perspective of a dynamic language runtime, which may not match the scenario you're working with, but please bear with me.
>
> I was trying to avoid JitBuilder requiring clients to maintain a second persistent copy of *all* that knowledge (in the Context, as you described) *solely* so that the JIT can look up that information when it does compilations. It feels wasteful and also error prone. Such a context object also opens the door to data races and stale information because it exists for a "long time" and there is no guarantee it could not be accessed by multiple threads. I suppose MethodBuilder objects are similarly vulnerable, but my original mental model was to keep the duplication more localized: only for that MethodBuilder's method, and only actually needed while compiling it.

Maybe I still don't understand the issue. The JIT (global instance)
knows about already compiled functions - so it could provide an API
such as lookupFunction() that can be called by the client? The only
reason I am doing this in the Context is because I am simulating what
I would have liked the JIT instance to do ... and maybe in future I
will enhance it to do so. What remains then are functions not known to
the JIT - e.g. some existing C library functions.


>
> Initially, I created the "DefineFunction" API so that the client could tell the JIT about other functions it thought were relevant to compiling a MethodBuilder and I typically imagined DefineFunction being called in the MethodBuilder's constructor (as in all the code samples). But it's not always easy to make all those DefineFunction calls in the constructor without actually simulating the bytecode execution (for a language runtime, anyway), and how many times should one be required to do that? In buildIL(), sure, but also during the constructor?
>
> I also did not want to have to predict which functions the JIT's inliner might want to look at / inline before calling compileMethodBuilder(), though the more I think about it, maybe this one isn't such a strong concern if the inliner is taught to properly interact with MethodBuilders (which it will need to learn about anyway ... so much to do ! ).
>
> In any case, that was the motivation behind introducing the RequestFunction callback: so that the JIT could easily ask the runtime, while traipsing through a method anywhere in the call graph, about any function call it encountered that had not yet been defined to it.
>

So if I undesrtand correctly - this happens inside the buildIL()
callback? So as the client is generating IL, the JIT engine can ask it
about a function? As I was saying - either the JIT already knows or
the client already knows the function - so in either case, this
callback should not be necessary?

> The use of RequestFunction is an optional thing: if you call DefineFunction on every target before you Call it, then RequestFunction will never be called because the JIT already knows everything it needs to know. By default, I believe RequestFunction does nothing, which means any previously undefined function you Call should assert.

Okay.

Thank you for the explanations - they will also be helpful to other
folks wanting to use JitBuilder api.

Regards
Dibyendu