Use PLATFORM value from TKG if available in top.xml

[Mesbah-Alam]

We would like to use the PLATFORM value from TKG when available in STF (top.xml). When it's not available, e.g., when we are running system tests using the make layer locally, we can then use logic in top.xml to figure out PLATFORM values from java properties.

Note that, we need to update the existing logic in top.xml and ensure that in case it's figuring out PLATFORM values, that it is generating the PLATFORM values of the same format as generated by TKG.

[Mesbah-Alam]

FYI @llxia

[lumpfish]

The code is the way it is at the moment to detect PLATFORM by interrogating the system properties of the java running the build.
If you go ahead and remove this capability, make sure that the system fails if those arguments are not set. Remember a user may want to execute the tests without going though openjdk-tests testkitgen.

[llxia]

The plan is not to remove the existing capability. The script should be updated to allow the value to be passed in. If the value is passed in, proceed with the value. There is no need to detect/construct it again.

[Mesbah-Alam]

My two cents on this:

1. The format used by the set-platform-properties macrodef in STF's top.xml to form the java_platform value is:

${@{osname.property}}_${@{arch.property}}-${@{bits.property}}

This results in values such as zos_390-64. Note: this format is different than the PLATFORM env var e.g. s390x_zos. However, It is a bit closer to values we get for SPEC, e.g. zos_390-64_cmprssptrs.

2. Platform values generated in top.xml are referenced (hardcoded) in 3 system test makefile scripts (e.g., modularity, sharedclasses.jvmti and jck).

Given the above, if we are to use the SPEC values for java_platform property in system tests, instead of the values produced by the set-platform-properties of top.xml, and still keep the set-platform-properties macro to be used for the case of running system test locally without TKG, we'd have to do the following:

1. Update the format used for platform.property in set-platform-properties macro and make it generate valuers in the same format as TKG.

2. Add logic in top.xml to use SPEC when it's available (e.g. during Jenkins runs, or local runs that use TKG). If it's not available, we'd depend on set-platform-properties.

3. Update the hardcoded references of platform values in the 3 makefile scripts (mentioned above) according to the new / changed / common format.

FYI.. @llxia @lumpfish

[llxia]

Maybe we should pause this issue for now. Once we switch entirely to mixedref SDK, there will not be *_mixed or *_xl in PLATFORM. Also, we may want to remove SPEC.

[Mesbah-Alam]

Hi @llxia ,

While cleaning up the system test native makefiles (e.g. , this), I did a cross check between the platforms they have support for and the platforms for which we run builds (checked internal Jenkins only), plus also the list of platforms we display in grinder. This reveals that we are not running any builds for the following platforms:

• s390 31 bit z/OS
• s390 32 bit zLinux
• ppc32 bit AIX
• ppc32 bit linux

However, these platforms do exist in the list in platform map.

My question is, are we ever going to have any SDK for these above platforms to test? If not, I'll go ahead and clean up the test make scripts and remove them from there.

[llxia]

We have these build for IBM Java 8 internally. For example, Test_openjdk8_ibm_sanity.system_ppc32_aix_Nightly
These builds were stopped running, but I think we will eventually re-enable them. Hence, I do not think we can remove them in the makefiles.

[Mesbah-Alam]

Actually, This issue has been resolved by #413. Modularity natives, SCC native tests, and JCK native compilation scripts now no longer depend on PLATFORM value as an input. So, we do not need to bother about which platform value to use anyway.