8310513: [s390x] Intrinsify recursive ObjectMonitor locking

[offamitkumar]

Hi all,

This pull request contains a backport of commit 47df1459 from the openjdk/jdk repository.

The commit being backported was authored by Amit Kumar on 10 Apr 2024 and was reviewed by Lutz Schmidt and Martin Doerr.

Thanks!

Benchmarking:

./build/linux-s390x-server-release/jdk/bin/java -Xms4g -Xmx4g -jar dacapo-9.12-MR1-bach.jar h2 -s huge -t 1 -n 1

Without the patch:

===== DaCapo 9.12-MR1 h2 PASSED in 209768 msec ===== 
===== DaCapo 9.12-MR1 h2 PASSED in 197472 msec =====
===== DaCapo 9.12-MR1 h2 PASSED in 222872 msec =====
===== DaCapo 9.12-MR1 h2 PASSED in 215725 msec =====


with patch: 
===== DaCapo 9.12-MR1 h2 PASSED in 171055 msec =====
===== DaCapo 9.12-MR1 h2 PASSED in 169696 msec =====
===== DaCapo 9.12-MR1 h2 PASSED in 174032 msec =====
===== DaCapo 9.12-MR1 h2 PASSED in 167271 msec =====

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8310513 needs maintainer approval

Issue

• JDK-8310513: [s390x] Intrinsify recursive ObjectMonitor locking (Enhancement - P4 - Approved)

Reviewers

• Lutz Schmidt (@RealLucy - Reviewer) ⚠️ Review applies to 50b25633

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk21u-dev.git pull/537/head:pull/537
$ git checkout pull/537

Update a local copy of the PR:
$ git checkout pull/537
$ git pull https://git.openjdk.org/jdk21u-dev.git pull/537/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 537

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk21u-dev/pull/537.diff

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:

8310513: [s390x] Intrinsify recursive ObjectMonitor locking

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

• 3bb8eee: 8317809: Insertion of free code blobs into code cache can be very slow during class unloading
• a4d8d06: 8328744: Parallel: Parallel GC throws OOM before heap is fully expanded
• 87d5da4: 8328822: C2: "negative trip count?" assert failure in profile predicate code
• 3892078: 8324121: SIGFPE in PhaseIdealLoop::extract_long_range_checks
• 3ab3f52: 8326974: ODR violation in macroAssembler_aarch64.cpp
• 5d5c678: 8319713: Parallel: Remove PSAdaptiveSizePolicy::should_full_GC
• 56a9090: 8312014: [s390x] TestSigInfoInHsErrFile.java Failure
• c922c50: 8322962: Upcall stub might go undetected when freezing frames
• cbd30c9: 8325095: C2: bailout message broken: ResourceArea allocated string used after free
• 75ac9e8: 8328168: Epsilon: Premature OOM when allocating object larger than uncommitted heap size
• ... and 6 more: https://git.openjdk.org/jdk21u-dev/compare/262cacb2385af4e0e2ee3a4e1f763b68e3101f28...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 (@RealLucy) 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]

This backport pull request has now been updated with issue from the original commit.

[mlbridge]

Webrevs

• 01: Full - Incremental (6d3ea211)
• 00: Full (50b25633)

[offamitkumar]

I have done tier1 testing and no new failure appeared in JDK-21 as well.

one of the failing test case TestSigInfoInHsErrFile.java will be fixed by #541

[offamitkumar]

@RealLucy would you please review this backport as well. Testing & Benchmark result I have already added.

[RealLucy]

Looks good.
I would have expected this to be a clean backport. Which parts did you have to adapt manually?

[openjdk]

⚠️ @offamitkumar This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[offamitkumar]

There were conflicts in the copyright header.

diff --cc src/hotspot/cpu/s390/macroAssembler_s390.cpp
index 8a56f3e4c2b,fd04a66a843..00000000000
--- a/src/hotspot/cpu/s390/macroAssembler_s390.cpp
+++ b/src/hotspot/cpu/s390/macroAssembler_s390.cpp
@@@ -1,6 -1,6 +1,11 @@@
  /*
++<<<<<<< HEAD
 + * Copyright (c) 2016, 2023, Oracle and/or its affiliates. All rights reserved.
 + * Copyright (c) 2016, 2023 SAP SE. All rights reserved.
++=======
+  * Copyright (c) 2016, 2024, Oracle and/or its affiliates. All rights reserved.
+  * Copyright (c) 2016, 2024 SAP SE. All rights reserved.
++>>>>>>> 47df14590c0 (8310513: [s390x] Intrinsify recursive ObjectMonitor locking)
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it

[offamitkumar]

/approval request backport is required to JDK-21 as other archs have added this change in JDK-21, but on s390x we ported it in JDK-23.

[openjdk]

@offamitkumar
8310513: The approval request has been created successfully.

[RealLucy]

There were conflicts in the copyright header.

Ahh,
Copyright header conflicts are considered negligible if only the years don't resolve. In that case, you can force the state to "clean" by adding the "/clean" tag. But only then.

[offamitkumar]

you can force the state to "clean" by adding the "/clean" tag.

ohh, thanks, I didn't know that it is possible to mark PR forcefully clean. I had missed it while looking at bot-commands.

[GoeLin]

Hi @offamitkumar, you changed the Oracle Copyright. This is not part of the original change. Please revert that and the change will be clean.

[GoeLin]

The copyright dates must be the max of the date in the 21u repo and the date in the patch backported. No other changes to the copyright should be made.

[GoeLin]

Also, please enable the GHA tests on your repo. You can restart the tests either in the actions tab or by merging head into your PR branch.

[offamitkumar]

Hi @offamitkumar, you changed the Oracle Copyright. This is not part of the original change. Please revert that and the change will be clean.

Nice, Thank you, Goetz

[offamitkumar]

Initially I thought that patch will be considered "clean" only if there are no merge-conflicts.

[offamitkumar]

Thanks @GoeLin @RealLucy for advice & review.

/integrate

[openjdk]

@offamitkumar
Your change (at version 6d3ea21) is now ready to be sponsored by a Committer.

[shipilev]

/sponsor

[openjdk]

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

• 3ff5359: 8330011: [s390x] update block-comments to make code consistent
• abbad92: 8326201: [S390] Need to bailout cleanly if creation of stubs fails when code cache is out of space
• 3770c28: 8331331: :tier1 target explanation in doc/testing.md is incorrect
• 021372c: 8328703: Illegal accesses in Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_ioctl0
• d459ae9: 8329850: [AIX] Allow loading of different members of same shared library archive
• 835d016: 8330094: RISC-V: Save and restore FRM in the call stub
• 3bb8eee: 8317809: Insertion of free code blobs into code cache can be very slow during class unloading
• a4d8d06: 8328744: Parallel: Parallel GC throws OOM before heap is fully expanded
• 87d5da4: 8328822: C2: "negative trip count?" assert failure in profile predicate code
• 3892078: 8324121: SIGFPE in PhaseIdealLoop::extract_long_range_checks
• ... and 12 more: https://git.openjdk.org/jdk21u-dev/compare/262cacb2385af4e0e2ee3a4e1f763b68e3101f28...master

Your commit was automatically rebased without conflicts.

[openjdk]

@shipilev @offamitkumar Pushed as commit 9159882.

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