8304888: Add dedicated VMProps for linker and fallback linker

[JornVernee]

This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).

Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses vm.flavor != "zero" which is not always correct, since the fallback linker can also be used on other platforms which are not zero.

To initialize the property, VMProps directly reads jdk.internal.foreig.CABI::current(). Since this class is in an internal package, --add-exports flags are added as javac flags and VM flags for the extra prop definitions class.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8304888: Add dedicated VMProps for linker and fallback linker

Reviewers

• Alan Bateman (@AlanBateman - Reviewer) ⚠️ Review applies to 272478b6
• Maurizio Cimadamore (@mcimadamore - Reviewer) ⚠️ Review applies to 272478b6

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13429/head:pull/13429
$ git checkout pull/13429

Update a local copy of the PR:
$ git checkout pull/13429
$ git pull https://git.openjdk.org/jdk.git pull/13429/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 13429

View PR using the GUI difftool:
$ git pr show -t 13429

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13429.diff

Webrev

Link to Webrev Comment

[mlbridge]

Webrevs

• 04: Full - Incremental (a3947c55)
• 03: Full (272478b6)
• 02: Full (8a6df30e)
• 01: Full (aa90690c)
• 00: Full (aa90690c)

[openjdk-notifier]

The parent pull request that this pull request depends on has now been integrated and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:

git checkout VMProps
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

[openjdk]

@JornVernee this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout VMProps
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

[openjdk]

⚠️ @JornVernee This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

[openjdk]

@JornVernee This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8304888: Add dedicated VMProps for linker and fallback linker

Reviewed-by: alanb, mcimadamore

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 15 new commits pushed to the master branch:

• 75a4edc: 8301223: Replace NULL with nullptr in share/gc/g1/
• 544bd26: 8305505: NPE in javazic compiler
• ea9201f: 8306510: Print number of threads and stack sizes in error reports
• a8d16de: 8300197: Freeze/thaw an interpreter frame using a single copy_to_chunk() call
• 1532a1b: 8307164: TestSegmentCopy times out (mainline)
• 860bf9b: 8307104: [AIX] VM crashes with UseRTMLocking on Power10
• 86f97fe: 8305919: java/lang/Thread/virtual/HoldsLock.java#id0 failed, ThreadInfo.getLockInfo() return null
• 2179a8f: 8298087: XML Schema Validation reports an required attribute twice via ErrorHandler
• 1227a27: 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions
• 35e75c1: 8301455: comments in TestTypeAnnotations still refer to resolved JDK-8068737
• ... and 5 more: https://git.openjdk.org/jdk/compare/7d07d19523658cb8034121af6569fbbe92c9afd1...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[JornVernee]

Thanks for the reveiw. I've added a comment that explains the property.

During testing after the merge I noticed that the @requires tags were checking against "UNKNOWN" while they should have been checking against "UNSUPPORTED". (I thought I tested this already, but maybe something went wrong when shifting things between repos on my local machine)

I've fixed this and re-tested on the following configurations:

• Windows/x64, tests full port
• Windows/x86, tests UNSUPPORTED (I also needed to fix an unrelated issues in one of the native test libraries for this to work. That is not included in this patch)
• Linux/x64 with CABI set to FALLBACK
• Linux/x64/zero (also FALLBACK)

For the latter two to pass, I had to fix an issue in TestLinker as well, where some test cases brought in by the merge with master were failing on the fallback linker, since it doesn't support by-value unions. The fix conditionally adds those test cases only when we are not running on the fallback linker.

[AlanBateman]

I looked at the update (comment on VMProps. cabi, update to TestLinker, and s/UNKNOWN/UnSUPPORTED). Looks okay to me.

[mcimadamore]

what about the name jdk.native.abi ?

[JornVernee]

Not so sure. The CABI is really the linker kind, not the underlying ABI ('CABI' is probably a misnomer at this point, since we no longer use it for anything else besides selecting the linker implementation). It can also be FALLBACK which is not an ABI.

If CABI is bad, I think jdk.foreign.linker would be better as a property name

[mcimadamore]

Looks good - I'm not too much of a fan of "CABI" as a property name - but that's a minor nit. I think the improvements in the jtreg test headers are very nice.

[JornVernee]

I went with the jdk.CABI -> jdk.foreign.linker name change. Re-tested. Will integrate soon.

[mcimadamore]

I went with the jdk.CABI -> jdk.foreign.linker name change. Re-tested. Will integrate soon.

Looks good (if we wanted to be 100% explicit, then it would have been jdk.foreign.system.linker/jdk.foreign.native.linker - but what you picked is better than what it replaces).

[JornVernee]

/integrate

[openjdk]

Going to push as commit a8bf2ac.
Since your change was applied there have been 15 commits pushed to the master branch:

• 75a4edc: 8301223: Replace NULL with nullptr in share/gc/g1/
• 544bd26: 8305505: NPE in javazic compiler
• ea9201f: 8306510: Print number of threads and stack sizes in error reports
• a8d16de: 8300197: Freeze/thaw an interpreter frame using a single copy_to_chunk() call
• 1532a1b: 8307164: TestSegmentCopy times out (mainline)
• 860bf9b: 8307104: [AIX] VM crashes with UseRTMLocking on Power10
• 86f97fe: 8305919: java/lang/Thread/virtual/HoldsLock.java#id0 failed, ThreadInfo.getLockInfo() return null
• 2179a8f: 8298087: XML Schema Validation reports an required attribute twice via ErrorHandler
• 1227a27: 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions
• 35e75c1: 8301455: comments in TestTypeAnnotations still refer to resolved JDK-8068737
• ... and 5 more: https://git.openjdk.org/jdk/compare/7d07d19523658cb8034121af6569fbbe92c9afd1...master

Your commit was automatically rebased without conflicts.

[openjdk]

@JornVernee Pushed as commit a8bf2ac.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.