Openj9: Investigate and improve debug build

[gita-omr]

Based on experience of at least several developers, building debug JVM and JIT is quite non-trivial. See https://blog.openj9.org/2018/06/05/debugging-openj9-in-docker-with-gdb/ as an example.

We need to make sure there is a simple way to get symbols, line number info, and non-optimized code for both VM and JIT.

This should help all the platforms. Please share your experience and ideas.

[charliegracie]

The main issue here is that there are technically 5 different build frameworks used to create an OpenJDK with OpenJ9 build.

1. OpenJDK
2. OpenJ9 (except the JIT)
3. OpenJ9 JIT
4. OMR (except the Compiler)
5. OMR Compiler

The first question that comes to mind is do the developers know when they configure the JVM (ie invoke configure from the OpenJDK build system) that they want a "debug" build? I hope the answer is yes but I just want to be clear. I do not understand why the answer would be no since you have to recompile every file anyway so re-running the configure step does not seem like overkill to me.

The solution, IMHO, is that whatever configure/build option is used to enable a "debug" build of OpenJDK should enable all of the correct options for the other components as part of configuring OpenJ9 and subsequently OMR.

I believe the OpenJDK build framework could be easily modified to pass the appropriate flags for each of the components. Knowing which options are the correct options for a given components build system seems like something an expert from that component should be capable of figuring out and adding to the OpenJDK build framework in the appropriate places. So as a first step if a developer is having an issue with enabling a debug build can they verify that the component they are most familiar with is cooperating with the OpenJDK build system in this area. If it is not they should work to enable "debug" for their component properly.. If they need help please reach out to myself and I will connect them with someone to help them make the changes (ie not do the changes for them but help them make the changes so we share the knowledge of how to do this).

IF all of the components in OpenJ9 and OMR would use the same build system this would probably already be solved since it would be a simple tweak to the OpenJDK build framework to pass the one correct flag to the OpenJ9 build framework which would then pass the exact same option to the OMR framework.

The OMR project has settled on moving to CMake but the process is not complete as there is some difficultly with platform coverage. Also the CMake story is not complete for the Compiler component. These outstanding tasks have open calls for help but the progress is currently slow.

The OpenJ9 project is also investigating a CMake story but it is moving slowly as the implementation is being completed in spare cycles. There is the same platform coverage issues and an incomplete story for the JIT as there is for the OMR project.

[fjeremic]

IF all of the components in OpenJ9 and OMR would use the same build system this would probably already be solved since it would be a simple tweak to the OpenJDK build framework to pass the one correct flag to the OpenJ9 build framework which would then pass the exact same option to the OMR framework.

IMHO we should not be pouring resources into any non-CMake solution at this point. Having played around in OMR and even x86 OpenJ9 the CMake build system is so much easier and more consistent to use. Building a debug build with CMake is trivial as is the addition of extra flags.

@charliegracie do we have a tracking item for all the issues in the CMake domain which need be tackled? I have always been interested in using my space cycles towards helping in this area but could never find any concrete issues or tasks to tackle.

[pdbain-ibm]

Corollary to this: make all does not pick up changes to the port library: a one-line change requires make clean; make all.

[mstoodle]

I have a patch for OpenJDK11 that mostly implements "slowdebug" / "fastdebug" JVM variants by passing in the smorgasborg of options needed to build VM and JIT with debug information. It doesn't quite work yet but I've had little time to dig into the reasons. If anyone wants the patch so they can play with it to get this going, I'd be happy to hand it over as a starting point.

[DanHeidinga]

@mstoodle Can you attach the patch or point to the branch with the patch?

[mstoodle]

@DanHeidinga the patch is primarily for the extensions project rather than for OpenJ9: mostly it just sets up the appropriate environment variables I extracted from, I believe, OpenJ9 slack channel content and maybe an article someone wrote about it?

Unfortunately, that means someone from IBM would need to contribute it because of the way the Extensions projects work. I would prefer not to publish what would be a GPLv2 licensed patch from another project here :) but will happily provide it to anyone via PM.

[fjeremic]

I've had these bookmarked for a while:

export UMA_DO_NOT_OPTIMIZE_CCODE="1"
export VMDEBUG="-g3 -fno-inline -O0"
export VMLINK="-g -O0 -Xlinker —export-dynamic"
export enable_debug=yes
export enable_optimized=no
export enable_optimize=no
export enable_release=no
export CXXFLAGS="-O0 -g3"
export CFLAGS="-O0 -g3"
export BUILD_CONFIG=debug

Hoping once we transition to CMake this whole issue can go away since it's dead simple to get a debug build there.

[DanHeidinga]

@fjeremic re: cmake - give it a try on jdk11. I believe (and @dnakamura please correct me) that the linux platforms should be mostly working