[omr-dev] JitBuilder updates

["Mark Stoodley" <mstoodle@xxxxxxxxxx>]

Hi,

This mailing list doesn't get much action
since most of our project's activities are tracked in the GitHub issues,
so I thought I'd interrupt the "silence" to briefly make some
shout-outs on progress we've been making with the JitBuilder library, representing
about a couple of months or so worth of "stuff".

For starters, @samolisov helped the
project get JitBuilder up and running on Windows, which was a major achievement.
JitBuilder is now built and runs tests on Windows with every pull request!
He also resolved a tricky memory allocator construction/destruction issue
by encapsulating our memory allocators in a struct so their lifetimes could
be properly controlled. Great stuff, Pavel ! Very nice to see your work
at the project!

I made an API change around the use
of the VirtualMachine* hierarchy of classes: these classes used to only
exist in the OMR namespace and could not be extended, but have now been
made more extensible and therefore are now properly referenced as TR::VirtualMachine*
classes. Sorry for the pain, but hopefully it's a fairly easy update for
clients: s/OMR::VirtualMachine/TR::VirtualMachine/ .

@charliegracie made a change to VirtualMachineOperandStack
and VirtualMachineOperandArray to enable multiple stacks/arrays to be modelled
in a single method, which was previously impossible because a single name
was used by each of these classes to store their base address in a local
variable. More flexibility is good, right?

We very recently merged what I think
is an exciting addition to the JitBuilder API: a Call service where you
provide the target as a MethodBuilder object, which can (currently *will*
but that isn't promised by the API) be inlined into the caller: https://github.com/eclipse/omr/pull/2758. This is a prototype but it seems to be working reasonably well. It comes
along with a code sample that can inline recursive Fibonacci calls to "any"
desired depth (I've tried it up to 11 levels (yes, that's 2048 inlined
function bodies!) but compile times are intolerable :) ). I haven't looked
at the resulting code in much detail, so there are almost surely improvements
to be made here (analysis and pull requests welcome!) . The great thing
about this new API is that it lets people play around with inlining themselves,
so that when we get to bolstering our OMR compiler inliner optimization,
people may already have some concrete ideas on how best to influence what
that inliner does.

@Leonardo2718 has taken my prototype
client API generator branch and come up with a JSON description of the
JitBuilder API and is now working towards a generator written in Python
to be able to automatically generate the JitBuilder client API. Once we
have a C API generated as a base, we'll be offering the JitBuilder API
to other languages like Rust, Java, and Python. I'm sure Leonardo would
be willing to share what he's got so far to anyone willing to provide constructive
feedback. Another goal, once we have a decent generator up and running,
will be to start semantically versioning the JitBuilder API. It will likely
remain at major version 0 for a while yet, but we'd like to get into the
habit of maintaining the version numbering.

As part of that process, Leonardo has
been making some improvements to the JitBuilder API for some of our "varargs"
services like Switch (https://github.com/eclipse/omr/pull/2821)
and there should be another one coming shortly for IfAnd() and IfOr().
Sorry again for the impact to anyone currently using these services, but
we feel these changes measureably improve these APIs.

Another pull request on deck is a new
service called VectorLoopBuilder that helps you write vectorized loops.
It builds the vector loop and residue loop and takes care of all the control
for you: all you need to do is to provide the vector loop code and it automatically
copies scalarized code into the residue loop for you. You can even embed
an inner scalar for loop. Two new code samples: one which just multiplies
two 1D vectors together, and another that vectorizes the middle loop of
matrix multiply. The current pull request is here: https://github.com/eclipse/omr/pull/2820. I wish the OMR compiler had better coverage on vector instructions, but
it can only get better :) (help wanted!)

There is also prototype implementation
for a NOPGuard() service in my private fork that I'd love to get people's
feedback on. To see how it could be used, check out https://github.com/mstoodle/omr/blob/jb_guard/jitbuilder/release/src/Guards.cppwhich shows a very simple function that generates a NOPped guard it later
invalidates. This pull request borrows some code from Eclipse OpenJ9 project
that still needs a fair amount of cleanup so it won't land immediately,
but I don't think that should affect the example of how you would use the
NOPGuard service. Feedback welcome!

Finally, I'll point out that several
OMR project members (including myself) will be at SPLASH
2018 in Boston Nov 4-9 this year.
Among other acivities, OMR project members Daryl Maier, Xiaoli Liang along
with University of New Brunswick professors Kenneth Kent and Gerhard Dueck
will be running the "TURBO" workshop on building runtimes with
Eclipse OMR which will feature some presentations and labs that include
projects that use the JitBuilder library. See https://2018.splashcon.org/track/turbo-2018-tutorialif you'd like more details.

That's all for now, thanks for making
it to the end :) !

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