JDK-8280544 : tier9 JCK tests failing after JDK-8268081
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 19
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • CPU: generic
  • Submitted: 2022-01-25
  • Updated: 2022-06-20
  • Resolved: 2022-01-25
Related Reports
Relates :  
Comments
These failures are expected, as the JCK has not been upgraded to Unicode 14. It will be tracked with https://bugs.openjdk.java.net/browse/JCK-7317155 Closing it as a dup to that issue.
25-01-2022

[~shade] I did a clean build, and it still fails, even with -Xint, so I'm thinking the tests may need to be updated after the unicode update.
25-01-2022

The tests are also failing with -Xint, so this doesn't appear to be a compiler issue.
25-01-2022

I see this is now blamed as JDK-8268081 regression. I now remember hitting local java/lang/Character jtreg test failures around the time that change was committed, and clean reconfigure/rebuild helped -- I reasoned back then some build-generated files had to update, and moved on. Maybe a similar thing happens here?
25-01-2022

Sorry, false alarm on JDK-8279676. I was looking at the list of changes for the build that ran the JCK, not the cumulative list of changes since the last JCK run. I'm not done bisecting yet, and I don't have a minimum reproducer yet. Thanks for the short list of interesting candidates.
25-01-2022

Were you able to bisect the failure exactly to JDK-8279676? I find it unlikely that JDK-8279676 is a culprit, to be honest; we have pretty extensive test coverage for arraycopy itself, so it that was broken, it would have failed arraycopy stress tests? I agree it is strange the failure is only on x86_64. I also see JDK-8279676 is recorded as resolved in b05, yet the synopsis for this issue suggests the failure started with b06? Does b05 work? Is there a minimal reproducer? FWIW, this passes well for me in mainline (although it must have less coverage than JCK): $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/Character TEST_VM_OPTS="-Xcomp" I see other interesting String/character-related changesets around jdk-19+4..jdk-19+6: JDK-8268081: Upgrade Unicode Data Files to 14.0.0 JDK-8278831: Use table lookup for the last two bytes in Integer.getChars JDK-8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes JDK-8279833: Loop optimization issue in String.encodeUTF8_UTF16
25-01-2022

Most of the failures are in java.lang.Character JCK tests, when run with -Xcomp.
25-01-2022

The failures seems to be on x64 only, so I'm wondering if the cause is this change: 8279676 Dubious YMM register clearing in x86_64 arraycopy stubs [~shade] and [~kvn], what do you think?
25-01-2022