Enable CMake as the default build system for JDK11

[dnakamura]

Given that the last of the perf regressions have been fixed up. We can now begin moving to making cmake the default build and deprecating the uma build system.

Given that it has the least baggage in terms of internal builds, I'm proposing starting with osx. Once that is done, following up with the linuxes (x, p, then z), then aix, and finally windows. With each platform, use the following general template to migrate over:

• Enable jenkins build for the platform.
• Ensure the full set of extended testing is passing.
• Announce "beta" cmake build, ask for testing and bug reports, add bugs to list below.
• Resolve issues relevant to platform from the list below.
• After suitable buffer period to ensure that all builds are stable, and any bug reports that are going to be filed are, update the jdk extensions repo so that the configure script defaults to a CMake build on osx (old behaviour remains as a fallback by passing --without-cmake on the configure line, and my current draft of this functionality also informs the user of this if autoconf is unable to find cmake). Initially this would just be for jdk11 (as it is the most tested with respect to the cmake changes), but after waiting a suitable time to ensure nothing goes horribly wrong, it would be rolled out to the other jdks.

Platforms:

• OSX (Default to CMake builds on osx ibmruntimes/openj9-openjdk-jdk11#308)
• Linux on x86 (CMake: Default to cmake enabled for x86 linux ibmruntimes/openj9-openjdk-jdk11#314)
• Linux on Power (Enable cmake by default on p and zlinux ibmruntimes/openj9-openjdk-jdk11#323)
• Linux on Z (Enable cmake by default on p and zlinux ibmruntimes/openj9-openjdk-jdk11#323)
• Linux on ARM
• AIX
• Windows
• z/OS

Known Problems:

• Jit is not build with split debug info, causing the jdk to be unnecessarily large
• Currently the cmake builds are run with warnings as errors disabled (CMake builds with -Werror disabled #9455)
• Intermitent failure while building ddr 'cannot find symbol generated.OmrBuildFlags' (Failure to build OMR error: cannot find symbol generated.OmrBuildFlags #9126)
• xlinux cmake builds hang on jsigjnitest (xlinux cmake builds hang on jsigjnitest #9430)
• Osx build failure on jdk8 (JDK8 Mac build ABORTED : FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL #9425)

[keithc-ca]

I suggest that #8418 (or rather the OMR equivalent) be done before making cmake the default: as things stand, JDKs will balloon to about twice their current size (a (space-)performance regression in my mind).

[dnakamura]

yes that is the intention. the extra size also causes startup/footprint regression on some platforms (I think AIX)

[mpirvu]

the extra size also causes startup/footprint regression on some platforms (I think AIX)

@dnakamura What is the magnitude of the regressions on AIX due to cmake? Thanks

[DanHeidinga]

Updated the title to clarify that this is a jdk11 statement. Once cmake is the default for jdk11, we'll roll it out to jdk.next (15?) and jdk8 as well

[dnakamura]

What is the magnitude of the regressions on AIX due to cmake? Thanks

I don't recall the numbers, but I should clarify. Its not CMake directly where there is a regression. The regression is from having the debug symbols present in the shared libs ( which is what you currently get in cmake without the above mentioned pr).

I suggest that #8418 (or rather the OMR equivalent) be done before making cmake the default:

I was thinking about it this shouldn't block osx or windows, as the toolchain semantics there give you split debug info by default

[andrewcraik]

It is currently very common for some JIT developers to build the compiler component against a previously built JVM - this is done when you want to fix the base JVM you are using for performance work and then build a new JIT to drop in to that JVM for experimental purposes. This is also the way many JIT developers avoid having to do a full rebuild of the whole JVM (which is slow).

Will the CMake system support this mode of building? If not how is it proposed to allow development compiler branches to be built against a known fixed VM level? Certainly happy to change processes, but a best practice for doing this would be necessary to maintain productivity of those doing performance work IMO.

[keithc-ca]

The build instructions need to be updated to specify that cmake is needed and explain how to get it.

[dnakamura]

@keithc-ca - #9304
@andrewcraik - There are a couple ways depends on on the exact situation. From an existing build tree, all the dependencies are tracked well enough that a plain incremental make should suffice. Starting from a clean state it is possible to build the vm outside of openjdk extensions, and since the jit has minimal dependencies, running make j9jit aught to do what you want. You end up re-building/running tracegen et al, but the overhead from that is really minimal. Note using cmake to build the vm without openjdk is currently undocumented, as its more of an "advanced" task, and pretty easy to shoot yourself in the foot, although I can write something up.

[andrewcraik]

@dnakamura thanks for the info - if you could try to document the steps we might need to take to try and make a JIT out of tree build against an already built OpenJDK with openj9 that would be great - I (and likely a few others) can try it out to see how it works since that kind of build is the default way of doing performance work right now. If that procedure doesn't end up working then happy to try and brainstorm some workflow that a) fits the build system and b) achieves what the perf analysis folks want to do.

[DanHeidinga]

@andrewcraik I'd be interested in your experience trying cmake with the incremental make as well. You may find that the better dependency tracking means the rebuild of the JDK isn't a limiting factor

[AdamBrousseau]

interested in your experience trying cmake with the incremental make

+1
Something I'm interested in for the Jenkins compiles.

[DanHeidinga]

Issues that need to be resolved before enabling cmake:

• Failure to build OMR error: cannot find symbol generated.OmrBuildFlags #9126

(Please edit this comment to add items and mark them as resolved when appropriate)

[keithc-ca]

I suggest we also make any necessary changes so compile warnings in OMR are not ignored; see https://github.com/eclipse/openj9/blob/master/buildenv/jenkins/variables/defaults.yml#L117 and https://github.com/eclipse/openj9/blob/master/buildenv/travis/build-on-travis.sh#L98.

[DanHeidinga]

From community call:

• Add a cmake build to the nightly build runs and run tests on the cmake platforms
• Pick a target date for the rollout

[hzongaro]

@dnakamura thanks for the info - if you could try to document the steps we might need to take to try and make a JIT out of tree build against an already built OpenJDK with openj9 that would be great - I (and likely a few others) can try it out to see how it works since that kind of build is the default way of doing performance work right now. If that procedure doesn't end up working then happy to try and brainstorm some workflow that a) fits the build system and b) achieves what the perf analysis folks want to do.

Andrew @andrewcraik, FYI: I tried out Devin's instructions from pull request #9376 without any difficulty.

[dnakamura]

Currently hitting an issue with the assembler on z/OS. Anybody happen to know what this means?

FSUM3112 Could not write //DD:SYSIN when copying from //DD:SYSIN2: EDC5003I Truncation of a record occurred during an I/O operation.
FSUM3018 Could not assemble /home/jenkins/devinn/openj9-openjdk-jdk11-zos/raw_build/runtime/codert_vm/znathelp.s. Correct the errors and try again.

Edit: nvm, appears that is z/OS's cryptic way of telling you that assembly lines are > 80 chars.

[jjohnst-us]

@dnakamura
Was looking at enabling cmake for z/TPF platform for OpenJDK 11. Two questions for you.

1. Is there a 'verbose' command which actually echoes out each of the compilation and link commands to be captured by the build.log? The without-cmake has a 'make all LOG=cmdlines' option which enables that.
2. We are a cross-compiled platform. We use standard gcc compiler our 'offline' tools that run on the build machine and we use a tpf-gcc compiler used to build OpenJ9/JCL programs which run on our z/TPF system (target). I was wondering what we set CMAKE_C_COMPILER and CMAKE_C_COMPILER_TARGET too (if at all)? Also, how do you toggle between the two toolchains during the build (is it the CMakeLists.txt?). I guess ideally we want to default to our target and toggle when we are building offline tools such as constgen.

tia

[keithc-ca]

I have changes that are intended to propagate the LOG choice through to cmake; see https://github.com/keithc-ca/openj9-openjdk11/blob/makeflags/closed/OpenJ9.gmk#L59. I've been meaning to update that branch and repeat for all jdk versions.

[dnakamura]

@jjohnst-us At present there isnt a good cross compile story for openj9. There is something there for omr. Basically you run the build twice once with just the native compiler to build native tooling. (tracegen, hookgen etc). On the second pass you use the cross compiler and point cmake to the previously built tools. However I'm not sure how well this will work with openj9/openjdk. I know llvm does allow cross compiling with a single pass using cmake, but I'm not sure if they are relying on compiling with clang, where the single binary can target all the supported platforms.

Edit: for an example of a cross compile for omr, see https://github.com/eclipse/omr/blob/master/buildenv/jenkins/jobs/builds/Build-linux_riscv64_cross

[dnakamura]

cmake is currently the default against all platforms