Skip to content
This repository has been archived by the owner. It is now read-only.

8269580: assert(is_valid()) failed: invalid register (-1) #172

Closed
wants to merge 1 commit into from

Conversation

@jatin-bhateja
Copy link
Member

@jatin-bhateja jatin-bhateja commented Jun 29, 2021

  • Assertion fails during emit phase of rep_stos instruction pattern on targets not supporting AVX512BW feature.
  • Pattern is selected under following predication logic.
    predicate(!((ClearArrayNode*)n)->is_large() &&
    (UseAVX <= 2 || !VM_Version::supports_avx512vlbw()));
  • Encoding block of this pattern passes a knoreg opmask register having a default encoding of -1, this later causes an assertion failure while assembling instruction operating over this register.
  • Existing pattern rep_stos_evex should be able to handle case for AVX512 targets as instructions operating of opmask registers are anyways guarded by target feature checks.

Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8269580: assert(is_valid()) failed: invalid register (-1)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk17 pull/172/head:pull/172
$ git checkout pull/172

Update a local copy of the PR:
$ git checkout pull/172
$ git pull https://git.openjdk.java.net/jdk17 pull/172/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 172

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk17/pull/172.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Jun 29, 2021

👋 Welcome back jbhateja! 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 openjdk bot added the rfr label Jun 29, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jun 29, 2021

@jatin-bhateja The following label will be automatically applied to this pull request:

  • hotspot-compiler

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.

@jatin-bhateja
Copy link
Member Author

@jatin-bhateja jatin-bhateja commented Jun 29, 2021

/label hotspot-compiler-dev

@openjdk
Copy link

@openjdk openjdk bot commented Jun 29, 2021

@jatin-bhateja The hotspot-compiler label was already applied.

@mlbridge
Copy link

@mlbridge mlbridge bot commented Jun 29, 2021

Webrevs

Copy link
Contributor

@vnkozlov vnkozlov left a comment

Good.
What testing you did?

@openjdk
Copy link

@openjdk openjdk bot commented Jun 29, 2021

@jatin-bhateja 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:

8269580: assert(is_valid()) failed: invalid register (-1)

Reviewed-by: kvn, dlong

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

  • ad27d9b: 8269088: C2 fails with assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect
  • c67a7b0: 8269230: C2: main loop in micro benchmark never executed
  • 962f1c1: 8262886: javadoc generates broken links with {@inheritdoc}
  • f7ffd58: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog
  • 4930ae9: 8268592: JDK-8262891 causes an NPE in Lint.augment
  • 9ac63a6: 8262841: Clarify the behavior of PhantomReference::refersTo
  • aba6c55: 8269703: ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on Windows-X64 with -Xcomp
  • 3e02224: 8269513: Clarify the spec wrt useOldISOCodes system property
  • 0dc65d3: 8268897: [TESTBUG] compiler/compilercontrol/mixed/RandomCommandsTest.java must not fail on Command.quiet
  • 3826012: 8268557: Module page uses unstyled table class
  • ... and 24 more: https://git.openjdk.java.net/jdk17/compare/d9cb068f4ba85e2be2ebc14e89e739b0a2d90409...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.

@openjdk openjdk bot added the ready label Jun 29, 2021
@jatin-bhateja
Copy link
Member Author

@jatin-bhateja jatin-bhateja commented Jun 29, 2021

Good.
What testing you did?

No explicit test added since the code flow involves post allocation system initialization pattern which is very frequently exercised by almost all jtreg tests on KNL

@vnkozlov
Copy link
Contributor

@vnkozlov vnkozlov commented Jun 29, 2021

I have to test it in our system before you push. I will let you know results.

@vnkozlov
Copy link
Contributor

@vnkozlov vnkozlov commented Jun 29, 2021

tier1-3 testing passed.

predicate(!((ClearArrayNode*)n)->is_large() &&
UseAVX > 2 && VM_Version::supports_avx512vlbw() &&
UseAVX > 2 &&
Copy link
Contributor

@sviswa7 sviswa7 Jun 30, 2021

VM_Version::supports_avx512vlbw() check is required otherwise MacroAssembler::clear_mem will assert. See the code snippet below. The assert is generated because the emovdqu with smaller than 512 bit vector width is not supported unless avx512vl() is available on the platform.
// Clearing constant sized memory using YMM/ZMM registers.
void MacroAssembler::clear_mem(Register base, int cnt, Register rtmp, XMMRegister xtmp, KRegister mask) {
assert(UseAVX > 2 && VM_Version::supports_avx512vlbw(), "");

Copy link
Member

@dean-long dean-long left a comment

I can't convince myself that this fix is correct. The logic that controls when the mask register is used seems much more complicated that the predicate that guards it.

@jatin-bhateja
Copy link
Member Author

@jatin-bhateja jatin-bhateja commented Jul 1, 2021

Hi @sviswa7 , in all the following code paths originating from rep_stos and rep_stos_evex instruction pattern EVEX encoded instructions are guarded by compile time checks, thus it should be safe to remove AVX512BW check from rep_stos and just enable it for UseAVX <= 2.

  • fill64_avx: Emits 64 byte mode if AVXThreshold=0 and UseAVX > 2 else it disintegrates to two 32 byte vex encoded moves.
  • fill64_masked_avx : Is again guarded by AVX3Threshold = 0 and UseAVX > 2
  • fill32_masked_avx : Guarded by UseAVX > 2 and AVX512VL == true.

This bug is related to clear operation over small non-constant length.

@dean-long
Copy link
Member

@dean-long dean-long commented Jul 1, 2021

@jatin-bhateja I see your point. With your change, the predicates are enough to prevent the assert. But I noticed an existing issue for both the small and large cases. The predicates do not prevent some cases where a mask register will be reserved when it isn't really needed. For example when UseFastStosb is TRUE or UseXMMForObjInit is FALSE. It seems like a good followup RFE.

@jatin-bhateja
Copy link
Member Author

@jatin-bhateja jatin-bhateja commented Jul 1, 2021

Hi @dean-long , yes extra opmask allocation will exist for non default control path, but its not a bug, and that's the penalty of packing mutiple flows in one pattern. We can do more cleanup in this flow as suggested.

@jatin-bhateja
Copy link
Member Author

@jatin-bhateja jatin-bhateja commented Jul 1, 2021

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented Jul 1, 2021

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

  • 54dd510: 8269704: Typo in j.t.Normalizer.normalize()
  • a8385fe: 8269354: javac crashes when processing parenthesized pattern in instanceof
  • c16d1fc: 8269285: Crash/miscompile in CallGenerator::for_method_handle_inline after JDK-8191998
  • ad27d9b: 8269088: C2 fails with assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect
  • c67a7b0: 8269230: C2: main loop in micro benchmark never executed
  • 962f1c1: 8262886: javadoc generates broken links with {@inheritdoc}
  • f7ffd58: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog
  • 4930ae9: 8268592: JDK-8262891 causes an NPE in Lint.augment
  • 9ac63a6: 8262841: Clarify the behavior of PhantomReference::refersTo
  • aba6c55: 8269703: ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on Windows-X64 with -Xcomp
  • ... and 27 more: https://git.openjdk.java.net/jdk17/compare/d9cb068f4ba85e2be2ebc14e89e739b0a2d90409...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Jul 1, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Jul 1, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jul 1, 2021

@jatin-bhateja Pushed as commit 4bbf11d.

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

@jatin-bhateja jatin-bhateja deleted the JDK-8269580 branch Jul 7, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
4 participants