Move setmemoryEvaluator() from OMR to Openj9

[midronij]

Use OMR_GC_SPARSE_HEAP_ALLOCATION instead of J9VM_GC_ENABLE_SPARSE_HEAP_ALLOCATION in setmemoryEvaluator().

The current implementation of OMR::Power::setmemoryEvaluator() has some OpenJ9 dependencies (namely when getting the classDepthAndFlags from the object's J9Class to generate the runtime array check), and is only ever used by OpenJ9 to generate assembly code for Unsafe.setMemory(). Thus, to avoid having to re-implement setmemoryEvaluator() to eliminate these OpenJ9 dependencies, we will move it over to OpenJ9 instead.

Depends on eclipse-openj9/openj9#20578

[midronij]

@amicic @0xdaryl @rmnattas I've separated the offheap macro fix into this PR. The change is very simple so hopefully we can merge it soon

[0xdaryl]

Jenkins build plinux,aix

[0xdaryl]

@midronij : please see the CI build failures

[0xdaryl]

Jenkins build plinux,aix

[midronij]

I believe the CI failures are happening because my change is dependent on this PR: eclipse-openj9/openj9#20461. I've updated the title/description accordingly

[amicic]

I believe the CI failures are happening because my change is dependent on this PR: eclipse-openj9/openj9#20461. I've updated the title/description accordingly

There should not ever be dependancy from OMR code on J9 (or potentially any other downstream project). OMR should be able to compile standalone. You might be missing some 'empty' methods in OMR that J9 fully implement

[amicic]

for the failures of missing compressObjectReferences, follow an example of contiguousArrayHeaderSizeInBytes()

[midronij]

@0xdaryl I rebased my branch and I'm now able to build sucessfully. When you have a moment can you please run the CI tests again?

[0xdaryl]

Jenkins build plinux,aix

[0xdaryl]

There are still failures in the CI builds. When you said that your build was successful, was that an OpenJ9 build?

The compilers these CI builds are building and testing are either "compilertest" builds or "jitbuilder" builds. These are not connected to OpenJ9 at all.

To reproduce this locally, if you look at your failed AIX job you can see the "cmake" command that was used to prepare the build (near the beginning of the console output). Further CMake info is here -> https://github.com/eclipse-omr/omr/blob/master/doc/BuildingWithCMake.md

[midronij]

As it turns out, OMR::Power::setmemoryEvaluator() (which is where these OpenJ9 dependencies that are causing the CI build to fail are coming from) is only ever used for Unsafe.setmemory() in OpenJ9, and is not called anywhere else or in any other downstream projects. However, eliminating these dependencies entirely would be difficult, since in order to perform the runtime array check when offheap is enabled, we need to get the classDepthAndFlags from the object's J9Class.

After discussing the situation with @0xdaryl, we decided that the best solution may be to simply move setmemoryEvaluator() from OMR over to OpenJ9. That being the case, this contribution has been modified to reflect that change, and a matching OpenJ9 PR has been opened here: eclipse-openj9/openj9#20578

[0xdaryl]

Depends on eclipse-openj9/openj9#20578

Just FYI that no PR in OMR should ever depend on another in a downstream project such as OpenJ9 (they are independent open source projects). A downstream PR, however, may depend on an OMR PR. In your case, it is correct to say in OpenJ9 PR 20578 that it depends on OMR 7513, and the burden of enforcing that dependency falls on the OpenJ9 project (i.e., via a coordinated merge).

I know what you mean though :-).