Re: [omr-dev] ResolvedMethod question

["Mark Stoodley" <mstoodle@xxxxxxxxxx>]

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

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

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.

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.

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