8364296: Set IntelJccErratumMitigation flag ergonomically

[olivergillespie]

We should update the flag if we are using a computed value. Nobody else reads IntelJccErratumMitigation specifically, but we want it to be correctly shown in PrintFlagsFinal and anywhere else these flags are inspected.

Intel(R) Xeon(R) Platinum 8259CL
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc
Before:
     bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {default}
After:
     bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {ergonomic}

Even worse when it's actually false, but shows as true:

AMD EPYC 7R13
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep IntelJcc
Before:
     bool IntelJccErratumMitigation  = true   {ARCH diagnostic} {default}
After:
     bool IntelJccErratumMitigation  = false  {ARCH diagnostic} {ergonomic}

---

Progress

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

Issue

• JDK-8364296: Set IntelJccErratumMitigation flag ergonomically (Enhancement - P4)

Reviewers

• Aleksey Shipilev (@shipilev - Reviewer)
• Jatin Bhateja (@jatin-bhateja - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26560

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back ogillespie! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@olivergillespie 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:

8364296: Set IntelJccErratumMitigation flag ergonomically

Reviewed-by: shade, jbhateja

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 31 new commits pushed to the master branch:

• 7fbeede: 4938801: The popup does not go when the component is removed
• d80b5c8: 8361316: javadoc tool fails with an exception for an inheritdoc on throws clause of a constructor
• 7d63c9f: 8294074: Make other specs more discoverable from the API docs
• ... and 28 more: https://git.openjdk.org/jdk/compare/57d02d9ac5e45dde6a32b02868b578f03e47c974...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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@shipilev, @jatin-bhateja) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[openjdk]

⚠️ @olivergillespie a branch with the same name as the source branch for this pull request (master) is present in the target repository. If you eventually integrate this pull request then the branch master in your personal fork will diverge once you sync your personal fork with the upstream repository.

To avoid this situation, create a new branch for your changes and reset the master branch. You can do this by running the following commands in a local repository for your personal fork. Note: you do not have to name the new branch NEW-BRANCH-NAME.

$ git checkout -b NEW-BRANCH-NAME
$ git branch -f master 57d02d9ac5e45dde6a32b02868b578f03e47c974
$ git push -f origin master

Then proceed to create a new pull request with NEW-BRANCH-NAME as the source branch and close this one.

[openjdk]

@olivergillespie The following label will be automatically applied to this pull request:

• hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (7f4f5deb)

[shipilev]

This looks fine to me as the solution to the UX problem.

Thinking out loud:

I don't know VM_Version::_has_intel_jcc_erratum field bears any reasonable weight at this point. That said, I think the guidance I heard from @vnkozlov once is that checking the flag directly instead of calling into VM_Version is frowned upon. This would be somewhat important in Leyden.

But maybe we should go and redefine VM_Version::has_intel_jcc_erratum to return the IntelJccErratumMitigation value as well. That would require JVMCI folks to poll the JVM flag directly instead of going via VMStructs. Also somewhat busy-work-ish.

So I am approving this as an MVP that solves the UX problem and does not prompt any additional work.

/reviewers 2

[openjdk]

@shipilev
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

[jatin-bhateja]

Hi @olivergillespie , This change looks good to me, what about other flags in vm_version_x86.cpp
https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L1198

JVM flag which is enabled through feature detection should have ERGONOMIC origin.

[olivergillespie]

Hi @olivergillespie , This change looks good to me, what about other flags in vm_version_x86.cpp https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L1198

JVM flag which is enabled through feature detection should have ERGONOMIC origin.

Thanks, good point, there are many more cases there. Looks like this is the only one where the actual value is out of sync with the flag, though, which is the most egregious part. The others all use FLAG_SET_DEFAULT or equivalent, so it's just the source of the updated value which is wrong. It actually seems like that's a pattern across the codebase - this one literally points out that it's an ergonomic setting while using FLAG_SET_DEFAULT.

[shipilev]

It actually seems like that's a pattern across the codebase

Yeah, we have not been consistent about this. I believe it would be busy work to change FLAG_SET_DEFAULT -> FLAG_SET_ERGO everywhere. But the new code should go FLAG_SET_ERGO, see for example just a few lines below:

  assert(supports_clflush(), "Always present");
  if (X86ICacheSync == -1) {
    // Auto-detect, choosing the best performant one that still flushes
    // the cache. We could switch to CPUID/SERIALIZE ("4"/"5") going forward.
    if (supports_clwb()) {
      FLAG_SET_ERGO(X86ICacheSync, 3);
    } else if (supports_clflushopt()) {
      FLAG_SET_ERGO(X86ICacheSync, 2);
    } else {
      FLAG_SET_ERGO(X86ICacheSync, 1);
    }

Plus, we have this macro that does the similar thing:

#define FLAG_SET_ERGO_IF_DEFAULT(name, value) \
  do {                                        \
    if (FLAG_IS_DEFAULT(name)) {              \
      FLAG_SET_ERGO(name, value);             \
    }                                         \
  } while (0)

[olivergillespie]

/integrate

[openjdk]

@olivergillespie
Your change (at version 7f4f5de) is now ready to be sponsored by a Committer.

[shipilev]

/sponsor

[openjdk]

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

• 812bd8e: 8364199: Enhance list of environment variables printed in hserr/hsinfo file
• 7fbeede: 4938801: The popup does not go when the component is removed
• d80b5c8: 8361316: javadoc tool fails with an exception for an inheritdoc on throws clause of a constructor
• ... and 29 more: https://git.openjdk.org/jdk/compare/57d02d9ac5e45dde6a32b02868b578f03e47c974...master

Your commit was automatically rebased without conflicts.

[openjdk]

@shipilev @olivergillespie Pushed as commit 6c58047.

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