Refactor NullChk Evaluators to OpenJ9

[dchopra001]

The follow evaluators:
NULLCHKEvaluator
resolveAndNULLCHKEvaluator

should be moved to OpenJ9. Currently, the x86 implementations are the only ones defined in OpenJ9. The ARM, Power, and Z codegen implementations are in OMR. For example, the OMR implementation for Z is here (ARM and Power implementations can be found in their respective directories):
https://github.com/eclipse/omr/blob/a733f7fc302de366bdc87bca57fdb6d4a8537f4b/compiler/z/codegen/ControlFlowEvaluator.cpp#L2549-L2553

And here:
https://github.com/eclipse/omr/blob/a733f7fc302de366bdc87bca57fdb6d4a8537f4b/compiler/z/codegen/ControlFlowEvaluator.cpp#L2478-L2482

On the other hand, the x86 implementations can be found in the OpenJ9 repository:
https://github.com/eclipse/openj9/blob/071bae0a8b4de6b9ef94da70dd8cc888f0c1eafd/runtime/compiler/x/codegen/J9TreeEvaluator.cpp#L2126-L2135

The ARM, Power and Z implementations should also be moved to OpenJ9.

While making this change, we should move the TR::TreeEvaluator::evaluateNULLCHKWithPossibleResolve routine to OpenJ9 as well.

[mhaque5]

Working on this. If anyone has any suggestions, please share.

[aarongraham9]

Any thoughts on this one @0xdaryl?

[Leonardo2718]

Thinking on this a bit, I'm wondering whether moving these evaluators to OpenJ9 is the right thing to do.

The definition of these opcodes is in OMR so keeping their evaluators in OMR seems appropriate. More generally, I think it makes sense to keep evaluators and opcode definitions in the same project (I know this is not always the case currently because of historic reasons).

That said, I can see arguments for why NULLCHK and resolveAndNULLCHK could be considered "Java opcodes" and should, therefore, be moved to OpenJ9. Moving the opcodes themselves though will require more discussion.

In the case of NULLCHK, the current implementation may be Java-focused, but the general concept of a null-check is applicable to other languages. So, it could be possible to use the NULLCHK opcode in other languages with some OMR-side refactoring. For resolveAndNULLCHK, I find it a little harder to see how it could be used outside of a Java context as not many other languages have the concept of unresolved symbols.

In any case, I think a little more thought is needed as to whether moving the evaluators for these opcodes to OpenJ9 without the opcodes themselves the right thing to do.

[mhaque5]

Necessary changes have been made according to the instructions. Please, review it. Thanks in advance.

[0xdaryl]

The semantics of the entire family of "check" opcodes all need to be properly specified from an OMR point-of-view. The semantics of what "thing" is being checked, how that check is accomplished, and what the course of action is when the check passes or fails need to be worked out in a project-neutral way. I'm not convinced (yet) that it is possible, but I do believe that some progress can be made. However, I don't think OMR will have answers to those questions in the short term.

For the NULLCHK case specifically, the code generator evaluators are largely unchanged from when OMR was distilled from OpenJ9. In effect, they are the OpenJ9 implementations and executing that implementation can only occur exclusively in an OpenJ9 VM. They shouldn't need to exist in OMR simply to provide inspiration for when the opcode semantics are properly specified, as we can simply look at OpenJ9 for such information.

This issue, I believe, is about relocating something highly OpenJ9-specific to the OpenJ9 project. Yes, check opcodes need a proper specification and perhaps a default implementation but I don't think there's a strong reason to keep this code around in OMR until that happens.