Enable DDR support under cmake

[dnakamura]

Running issue to track DDR support under cmake

[keithc-ca]

Some remaining issues with cmake+DDR:

• blob_reader should be built

• Except for expected differences (e.g. J9VM_BUILD_CMAKE, J9VM_BUILD_UMA) constants should be the same. The differences below were from two builds on xLinux from the same SHAs. The reference was built without cmake, the other with cmake (including #6098).

  Type: CacheLifecycleManagerConstants
  constant J9SH_DESTROY_TOP_LAYER_ONLY is missing
  Type: J9BuildFlags
  constant J9VM_ARCH_AARCH64 is missing
  constant J9VM_ARCH_AARCH64_DEFINED is missing
  constant J9VM_BUILD_OPENJ9 is 0; expected 1
  constant J9VM_BUILD_OPENJ9_DEFINED is 0; expected 1
  constant J9VM_GC_STACCATO is missing
  constant J9VM_GC_STACCATO_DEFINED is missing
  constant J9VM_INTERP_ATOMIC_FREE_JNI is 0; expected 1
  constant J9VM_INTERP_ATOMIC_FREE_JNI_DEFINED is 0; expected 1
  constant J9VM_INTERP_ATOMIC_FREE_JNI_USES_FLUSH is missing
  constant J9VM_INTERP_ATOMIC_FREE_JNI_USES_FLUSH_DEFINED is missing
  constant J9VM_INTERP_TWO_PASS_EXCLUSIVE is missing
  constant J9VM_INTERP_TWO_PASS_EXCLUSIVE_DEFINED is missing
  constant J9VM_OPT_USE_OMR_DDR is missing
  constant J9VM_OPT_USE_OMR_DDR_DEFINED is missing
  Type: J9Pool
  constant POOL_ALLOC_TYPE_POOL is missing
  constant POOL_ALLOC_TYPE_PUDDLE is missing
  constant POOL_ALLOC_TYPE_PUDDLE_LIST is missing
  constant POOL_ALWAYS_KEEP_SORTED is missing
  constant POOL_NEVER_FREE_PUDDLES is missing
  constant POOL_NO_ZERO is missing
  constant POOL_ROUND_TO_PAGE_SIZE is missing
  constant POOL_USES_HOLES is missing
  Type: J9PoolPuddle
  constant PUDDLE_ACTIVE is missing
  constant PUDDLE_KILLED is missing
  Type: J9PoolState
  constant POOLSTATE_FOLLOW_NEXT_POINTERS is missing
  Type: J9PortLibrary
  constant J9PORT_CAPABILITY_MASK is missing
  constant J9PORT_CAPABILITY_MASK_CAN_RESERVE is missing
  Type: OmrBuildFlags
  constant HAVE_DWARF_H is missing
  constant HAVE_DWARF_H_DEFINED is missing
  constant HAVE_LIBDWARF_DWARF_H is missing
  constant HAVE_LIBDWARF_DWARF_H_DEFINED is missing
  constant HAVE_LIBDWARF_H is missing
  constant HAVE_LIBDWARF_H_DEFINED is missing
  constant HAVE_LIBDWARF_LIBDWARF_H is missing
  constant HAVE_LIBDWARF_LIBDWARF_H_DEFINED is missing
  constant OMRPORT_OMRSIG_SUPPORT is 0; expected 1
  constant OMRPORT_OMRSIG_SUPPORT_DEFINED is 0; expected 1
  constant OMR_COMPILER is 1; expected 0
  constant OMR_COMPILER_DEFINED is 1; expected 0
  constant OMR_GC_CONCURRENT_SCAVENGER is 0; expected 1
  constant OMR_GC_CONCURRENT_SCAVENGER_DEFINED is 0; expected 1
  constant OMR_GC_DOUBLE_MAP_ARRAYLETS is missing
  constant OMR_GC_DOUBLE_MAP_ARRAYLETS_DEFINED is missing
  constant OMR_GC_HEAP_CARD_TABLE is 0; expected 1
  constant OMR_GC_HEAP_CARD_TABLE_DEFINED is 0; expected 1
  constant OMR_INTERP_COMPRESSED_OBJECT_HEADER is missing
  constant OMR_INTERP_COMPRESSED_OBJECT_HEADER_DEFINED is missing
  constant OMR_OPT_CUDA is 0; expected 1
  constant OMR_OPT_CUDA_DEFINED is 0; expected 1
  constant OMR_VALGRIND_MEMCHECK is missing
  constant OMR_VALGRIND_MEMCHECK_DEFINED is missing
  Type: TRBuildFlags
  constant HOST_ARCH is missing
  constant HOST_COMPILER is missing
  constant HOST_OS is missing
  constant TARGET_ARCH is missing
  constant TR_HOST_64BIT is missing
  constant TR_HOST_X86 is missing

  This may explain differences in the sizes of various types (e.g. MM_EnvironmentBase is 6880 instead of 6904 bytes).

• We should understand why field types are different (or fix things so they're the same).

  Type: _jvmtiEnv
    type of functions is jvmtiNativeInterface*; expected struct JVMTINativeInterface_*
  Type: message
    type of next is qMessage*; expected struct message*
    type of nextSecondary is qMessage*; expected struct message*

[DanHeidinga]

What is the state of this?

[keithc-ca]

I'm not aware of any changes that would significantly affect my previous comment. @dnakamura ?

[dnakamura]

• I believe we are building blob_reader
• I don't believe the differing constants relating to libdwarf are important (they should still exist just under different names under cmake)
• I believe many of the the OMR config flags should be resolved with ~#7827~ #7828
• I believe the remaining discrepencies are really issues with differing configuration on the cmake builds and not with cmakes ddr support

[keithc-ca]

• Yes, blob_reader is in a different place.
• I don't see how #7827 relates to OMR configuration flags; did you mean to reference a different issue?
• I don't think we can claim full DDR support with cmake if it yields a blob with inaccurate constants or offsets.

[dnakamura]

Oops yes I mean #7828

I don't think we can claim full DDR support with cmake if it yields a blob with inaccurate constants or offsets.

I believe the constants are accurate (as in the reflect the settings that the vm was built with), however we are not configuring the vm the same as the UMA builds. ie it's still an issue, just not technically a DDR issue

[keithc-ca]

At least one constant is inaccurate:

constant OMR_OPT_CUDA is 0; expected 1

The build I configured did have CUDA support.