Port JITServer to Power

[dchopra001]

As part of the work being tracked in eclipse-openj9/openj9#6991, there are some changes that need to be made in the OMR project.

PRs using the comp->isOutOfProcessCompilation() query are opened as draft PRs since this is not a valid query in OMR. While doing the implementation I wasn't sure which front end query to use, so I proceeded with using comp->isOutOfProcessCompilation() in order to first achieve functional correctness. We can discuss and finalize in each of the PRs what the final queries should look like. Where possible, I used an appropriate front end query that is already available instead of the above check.

Where it made sense, I have also divided each PR into separate commits and additional comments so as to provide more context about the changes being made.

The list of PRs is below:

• Remove isAOT check in order to enable relo logging for JITServer: Remove isAOT check in order to enable relo logging for JITServer #4445
• Add isRelocatable boolean to power's loadAddressConstant API: Add isRelocatable boolean to power's loadAddressConstant API #4441
• Rework MemoryReference::accessStaticItem in Power for JITServer: Rework MemoryReference::accessStaticItem in Power for JITServer #4442
• Rename disableTOCForConsts option and disable TOC when the opti…: Rename disableTOCForConsts option and disable TOC when the opti… #4443
• Make relocations in the Power Codegen more flexible for downstr…: Make relocations in the Power Codegen more flexible for downstr… #4444
• Redefine CG queries to return correct answer: Redefine CG queries to return correct answer #4650

@mpirvu @ymanton @gita-omr FYI

[dchopra001]

@Leonardo2718 FYI

[Leonardo2718]

@dchopra001

Would it be possible for you to list what queries are needed to support JITServer in OpenJ9? I'm trying to understand what parts of OMR need to configured/customized to work with JITServer. If existing queries don't satisfy the JITServer use case, I'd like to understand why that is. I think having a clear definition of what customization points are needed will help ensure we come up with the right solutions to the problem.

Taking #4441 as an example, compileRelocatableCode() seems like it should work for JITServer. In my mind, that query should return true anytime relocatable code is needed. The caller shouldn't need to know whether a compilation is AOT, out-of-process, or some other scheme; it just needs to know that relocatable code is needed. So, if compileRelocatableCode() is returning false when relocatable code is desired (which I'm assuming is the case, given the change in #4441), then it sounds like there is a problem with the query. I am given to understand that compileRelocatableCode() has a few distinct meanings conflated together, based on how it's used in other parts of the code. If this is true then maybe now is a good time to fix this?

[ymanton]

The short answer is as you suspect, compileRelocatableCode() guards a lot of AOT-specific behaviour (some of it unrelated to relocations, others related to relocations that JITServer doesn't use) that JITServer doesn't need/want.

There are seemingly about half a dozen different ways of checking for AOT in different contexts, some relating to relocations, others not, strewn across OMR and OpenJ9, that need untangling, but I don't think this should be tackled here and now. It needs to be someone's primary mission for a good period of time because its probably going to take a fair bit of coordination between OpenJ9 and OMR to see it done.

[dchopra001]

Would it be possible for you to list what queries are needed to support JITServer in OpenJ9?

I don't know if there's a concrete list of queries available. There are some examples in the appropriate FrontEnd. Many of these were already available from before. Here's a few queries that we override for remote JIT compiles:
https://github.com/eclipse/openj9/blob/b9a11ca8fe1daf964a0d37cf3425da53143a6333/runtime/compiler/env/VMJ9Server.hpp#L48-L55

And here's a few for remote AOT compiles:
https://github.com/eclipse/openj9/blob/b9a11ca8fe1daf964a0d37cf3425da53143a6333/runtime/compiler/env/VMJ9Server.hpp#L211-L232

Eventually all the changes that go into OMR will replace the comp->isOutOfProcessCompilation() query with a newly create or pre-existing query. Once we have a complete list, I can document the list of any newly added queries in this issue.

Taking #4441 as an example, compileRelocatableCode() seems like it should work for JITServer. In my mind, that query should return true anytime relocatable code is needed. The caller shouldn't need to know whether a compilation is AOT, out-of-process, or some other scheme; it just needs to know that relocatable code is needed. So, if compileRelocatableCode() is returning false when relocatable code is desired (which I'm assuming is the case, given the change in #4441), then it sounds like there is a problem with the query

Adding on to @ymanton's comment, whether we should use a single query to answer such a question is a broader discussion. For example in the regular AOT front-end in OpenJ9 we are deliberately trying to deprecate a general isAOT? query in order to replace it with queries that better explain why relocatable code is needed:
https://github.com/eclipse/openj9/blob/b9a11ca8fe1daf964a0d37cf3425da53143a6333/runtime/compiler/env/VMJ9.h#L1113-L1138

There are queries here that check whether we need to generate relocatableCode as well as if we are in an AOT compile.

I recall @dsouzai mentioning a while ago to me that this new approach was taken to try and provide more context as to why relocatable code is necessary on a per-situation basis. I suppose a similar argument could be made for the compileRelocatableCode() query.

Given that context I do see the advantage of using such queries. Obviously one of the drawbacks is that in some situations these queries end up leaking into OMRCodeGenerator :P). So I'm not really sure what the best long term solution is here.

[dsouzai]

Heh, I think compileRelocatableCode originally started off as a way of not doing self()->fe()->isAOT(). But it might as well have been left as isAOT; the effort to not have one global query for "is AOT" essentially failed since compileRelocatableCode became that global query.