8330849: Add test to verify memory usage with recursive locking

[elifaslan1]

Clean backport to add test to verify memory usage with recursive locking.
This pull request contains a backport of commit 7b2560b4 from the openjdk/jdk repository.

---

Progress

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

Issue

• JDK-8330849: Add test to verify memory usage with recursive locking (Enhancement - P4 - Approved)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 747

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper]

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

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

8330849: Add test to verify memory usage with recursive locking

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

• c3693c2: 8327840: Automate javax/swing/border/Test4129681.java
• 6a67861: 8318605: Enable parallelism in vmTestbase/nsk/stress/stack tests
• a79db00: 8309685: Fix -Wconversion warnings in assembler and register code
• 7e12de9: 8334332: TestIOException.java fails if run by root
• 5c1282b: 8332936: Test vmTestbase/metaspace/gc/watermark_70_80/TestDescription.java fails with no GC's recorded
• c0eb17c: 8331063: Some HttpClient tests don't report leaks
• c959207: 8331999: BasicDirectoryModel/LoaderThreadCount.java frequently fails on Windows in CI
• 4bb85fc: 8325083: jdk/incubator/vector/Double512VectorTests.java crashes in Assembler::vex_prefix_and_encode
• 568bd67: 8330133: libj2pkcs11.so crashes on some pkcs#11 v3.0 libraries
• 8148675: 8330819: C2 SuperWord: bad dominance after pre-loop limit adjustment with base that has CastLL after pre-loop
• ... and 26 more: https://git.openjdk.org/jdk21u-dev/compare/df030542eb11bb3482e2a8c7c8a477a333a409c8...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.

➡️ 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.

[openjdk]

⚠️ @elifaslan1 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.

[mlbridge]

Webrevs

• 00: Full (cbf86f8d)

[elifaslan1]

/approval JDK-8330849 request Clean backport to add test to verify memory usage with recursive locking. GHA tested

[openjdk]

@elifaslan1
JDK-8330849: The approval request has been created successfully.

[elifaslan1]

/integrate

[openjdk]

@elifaslan1
Your change (at version cbf86f8) is now ready to be sponsored by a Committer.

[shipilev]

Hold on a sec, without JDK-8319796 in JDK 21, should the test actually fail in jdk21u-dev?

[TheRealMDoerr]

I guess the test passes because LockingMode is 1 ("LM_LEGACY") by default in JDK 21. Does it fail with LockingMode = 2? I think it should.

[phohensee]

/sponsor

[openjdk]

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

• 99b50b3: 8332248: (fc) java/nio/channels/FileChannel/BlockDeviceSize.java failed with RuntimeException
• 8c6ad58: 8317372: Refactor some NumberFormat tests to use JUnit
• 98cfde4: 8222884: ConcurrentClassDescLookup.java times out intermittently
• 2c3a40b: 8328647: TestGarbageCollectorMXBean.java fails with C1-only and -Xcomp
• c0050ca: 8322062: com/sun/jdi/JdwpAllowTest.java does not performs negative testing with prefix length
• 4be1a02: 8328697: SubMenuShowTest and SwallowKeyEvents tests stabilization
• 17e271d: 8310906: Fix -Wconversion warnings in runtime, oops and some code header files.
• 487b29d: 8325520: Vector loads and stores with indices and masks incorrectly compiled
• 5c3dbbf: 8325494: C2: Broken graph after not skipping CastII node anymore for Assertion Predicates after JDK-8309902
• 7328df4: 8332920: C2: Partial Peeling is wrongly applied for CmpU with negative limit
• ... and 61 more: https://git.openjdk.org/jdk21u-dev/compare/df030542eb11bb3482e2a8c7c8a477a333a409c8...master

Your commit was automatically rebased without conflicts.

[openjdk]

@phohensee @elifaslan1 Pushed as commit 153accc.

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

[TheRealMDoerr]

@phohensee @elifaslan1: This PR should not have been integrated. The test fails when running with the LockingMode it is written for because JDK-8319796 is not in 21u as pointed out by @shipilev above.
make run-test TEST="test/hotspot/jtreg/runtime/locking/TestRecursiveMonitorChurn.java" JTREG="VM_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:LockingMode=2" runs into RuntimeException: Allocated too many monitors.

[shipilev]

I agree we should have talked a bit more about this. But honestly, we can keep the test since it works with the default locking modes. There is no breakage at this point, AFAICS. So we can still revert it at our leisure?

Yes, there is a downside that we cannot run this test cleanly with LockingMode=2, which is experimental in JDK 21. This is likely a problem for lightweight locking backports. Then again, I wonder if the only person in the world who cares is @rkennke when maintaining lilliput-jdk21u, where JDK-8319796 is backported.