8343506: [s390x] multiple test failures with ubsan

[offamitkumar]

This is trivial patch which fixes the error I am seeing on s390x, while running tier1 with ubsan enabled. Please see JBS for more details.

---

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-8343506: [s390x] multiple test failures with ubsan (Bug - P4)

Reviewers

• Martin Doerr (@TheRealMDoerr - Reviewer)
• Lutz Schmidt (@RealLucy - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 21864

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back amitkumar! 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]

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

8343506: [s390x] multiple test failures with ubsan

Reviewed-by: mdoerr, lucy

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

• 4244682: 8339190: Parameter arrays that are capped during annotation processing report incorrect length
• 7620b12: 8323803: ConstantOopReadValue::print_on should print 'null' instead of 'nullptr'
• 592a48b: 8321997: Increase upper limit of LoopOptsCount flag
• c3df050: 8343726: [BACKOUT] NMT should not use ThreadCritical
• 0e1c1b7: 8343452: Incorrect WINDOWS build variable is used in macroAssembler_x86.cpp
• 619b4d5: 8334107: Specification for MemorySegment::get/setString could use some clarification
• a6c85da: 8342945: Replace predicate walking code in get_assertion_predicates() used for Loop Unswitching and cleaning useless Template Assertion Predicates with a predicate visitor
• 97b681e: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles
• f2316f6: 8343505: Problemlist java/lang/Thread/jni/AttachCurrentThread/AttachTest.java
• 9e31e78: 8342647: [macosx] Clean up the NSInvocation based call to NSProcessInfo.operatingSystemVersion
• ... and 64 more: https://git.openjdk.org/jdk/compare/c125178065664fdf96c42dfc6dcfa2431e6011a4...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]

@offamitkumar 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.

[mlbridge]

Webrevs

• 00: Full (b16352a7)

[TheRealMDoerr]

I think the is_uimm* checks should take an uint64_t. See assembler_riscv.inline.hpp.

[offamitkumar]

I think the is_uimm* checks should take an uint64_t. See assembler_riscv.inline.hpp.

But aren't julong same as uint64_t ?
I saw this in globalDefinitions.hpp

// Additional Java basic types

typedef uint8_t  jubyte;
typedef uint16_t jushort;
typedef uint32_t juint;
typedef uint64_t julong;

[TheRealMDoerr]

My point is that I think that the riscv solution is better. See assembler_riscv.inline.hpp.

[TheRealMDoerr]

Your cast is correct, though.

[offamitkumar]

Oh, got it. I will add that change in the PR and ran tests again.

[offamitkumar]

My point is that I think that the riscv solution is better. See assembler_riscv.inline.hpp.

@TheRealMDoerr can we do it with another RFE ?

[TheRealMDoerr]

Looks correct. Additional improvements could be done separately.

[RealLucy]

LGTM.

[offamitkumar]

/integrate

[openjdk]

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

• 96eed7f: 8343306: javac is failing to determine if a class and a sealed interface are disjoint
• 0c281ac: 8343754: Problemlist jdk/jfr/event/oldobject/TestShenandoah.java after JDK-8279016
• 2e58ede: 8341399: Add since checker tests to the langtools modules
• c7f071c: 8343189: [REDO] JDK-8295269 G1: Improve slow startup due to predictor initialization
• a9e53bb: 8343783: Improve asserts in concurrentHashTable.inline.hpp
• bf5c3ce: 8272780: ServerNotifForwarder.removeNotificationListener() incorrect exception handling
• a10b1cc: 8340532: C2: assert(is_OuterStripMinedLoop()) failed: invalid node class: IfTrue
• d0077ee: 8343771: Some FFM benchmarks are broken
• 068f4ce: 8343293: Remove the check for /jre/lib/libjava.dylib from the launcher's java_md_macosx.m
• f621f26: 8343724: [PPC64] Disallow OptoScheduling
• ... and 86 more: https://git.openjdk.org/jdk/compare/c125178065664fdf96c42dfc6dcfa2431e6011a4...master

Your commit was automatically rebased without conflicts.

[openjdk]

@offamitkumar Pushed as commit f6edfe5.

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