Consolidate openjdk tests for openj9 and hotspot

[LongyuZhang]

• Set paramaters in mk file for j9 and hotspot
• Related Issue: Consolidate openjdk test targets #2194

Signed-off-by: Longyu Zhang longyu.zhang@ibm.com

[LongyuZhang]

Test Links:

jdk16:
-j9: xliinux: 13415 zlinux: 13425 aix: 13422 mac: 13423 win: 13424
(Only failed with know issue: SealedClassesReflectionTest )
-hotspot: xlinux: 13418

jdk11:
-j9: xliinux: 13414
-hotspot: xlinux: 13417

jdk8:
-j9: xlinux: 13413
-hotspot: xlinux: 13416

[llxia]

LGTM

[sophia-guo]

LGTM, the change should also work in AdoptOpenJDK. I would prefer to have some grinders in AdoptOpenJDK so the reviewer can take a look at.

[smlambert]

Thanks @LongyuZhang and @llxia - I am very happy these are re-consolidated! We should make sure to announce broadly on OpenJ9 channels, in case people have grown accustomed to the _j9 target names.

[sophia-guo]

I actually have one more question. Targets like jdk_lang against hotspot is running with Mode150 (-XX:+UseCompressedOops ), which looks no harm with this specific option. However as a strategy if later we need use a different mode Mode***, which is specific to openj9). What would it happen? Actually I will launch a grinder with arm32, will this work? it may work if Mode150 is "no" to 32. Faied with Mode1000, not sure.

https://ci.adoptopenjdk.net/view/work-in-progress/job/grinder_sandbox/243/console

Mode*** is kind of openj9 options adding to hotspot may or may not work.

[llxia]

Openj9 specific modes should not be used against hotspot. If we need to add an additional openj9 specific mode, then we need to create a separate target for it. Similar to tests in special.system. The purpose of this PR is to consolidate the targets if it is possible. At this point, Mode150, Mode650, Mode1000, and NoOptions are common modes that can be used for both openj9 and hotspot.

[sophia-guo]

Ok, I forgot Mode150 and Mode 650 are introduced on purpose by #2146

[smlambert]

For the time being there is no plan to repeat this set of tests with variations that are not common to all.

In the event that someone wants to add <variation>someVendorSpecific options</variation> our PR testing would tank, and the PR would have to be reworked... to either return to the duplication of targets with <vendor> tags or put the options in the openjdk.mk file as done with some j9 specifics in this PR.

Noting the behaviour of the different implementations are different. If you run with an option that hotspot does not recognize, it will hard stop and not run. On the reverse, if openj9 encounters an unrecognized option it warns about it and continues to run.

[sophia-guo]

Not a blocker for merging this PR. Just throw out some thoughts for discussion.

If we need to add an additional openj9 specific mode, then we need to create a separate target for it.

That means it will depends on developer's knowledge to judge if the Mode*** is vendor specific. And based no that or based on the PR build results to decide if separate target need to be added. There is no extra documents to tell other developers or testers or triagers this information. I think it might be helpful if we can document this information( Mode*** ---> vendor).

If we will continue to use Mode story I think https://github.com/AdoptOpenJDK/TKG/blob/master/resources/modes.xml could help. All modes defined here are actually define key-value <envVar name="OPENJ9_JAVA_OPTIONS" value="****"/> https://github.com/AdoptOpenJDK/TKG/blob/master/resources/modes.xml.

Mode150:

	<mode number="150">
		<description>compressed references</description>
		<settings>
			<setting type="either">
				<clArg>-XX:+UseCompressedOops</clArg>
				<envVar name="OPENJ9_JAVA_OPTIONS" value="-XX:+UseCompressedOops"/>
			</setting>
		</settings>
	</mode>

Is it possible we use envVar to discriminate different Vendor/impl's JAVA_OPTIONS? or adding an element |< vendor> to define which the Mode works with which impl | vendor? Similar to the use of |< vendor> in playlist.xml. This way we will not need to separate targets based on if Mode works or not. Though there will be extra jobs for TKG. Just my two cents.

[smlambert]

Good notes - I had thought about vendor specific variants (and leveraging the modes.xml / ottawa.csv mechanism that already skips for platforms to have TKG skip for impls, strip out modes that can't be used for a particular impl). We can watch to see if we have a use case for having to solve for this problem or not... it could be something lurking in the future.

Employing that approach would allow us to utilize more of the functional suite against the hotspot impl, which would be in itself a worthy reason (some functional tests would still be tagged as only openj9/ibm because they use internals, etc, but many are just tagged that way because of the modes in use).

[smlambert]

I believe we are all good on this change, with the follow-up task of announcing it in Slack channels (for awareness of people who may be affected by the reunification of target names).

[LongyuZhang]

@smlambert Thanks for merging this PR.
BTW, the Adopt grinder also passed as @sophia-guo suggested:
jdk16:
-j9: xliinux: 6074 zlinux: 6076 aix: 6077 mac: 6078 win: 6079
-hotspot: xlinux: 6069

jdk11:
-j9: xliinux: 6075
-hotspot: xlinux: 6068

jdk8:
-j9: xlinux: 6065
-hotspot: xlinux: 6080

[smlambert]

thanks @LongyuZhang !