RFR: 8330849: Add test to verify memory usage with recursive locking [v4]

[Aleksey Shipilev]

On Tue, 23 Apr 2024 16:19:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Before recursive support has been added to lightweight locking, using recursive locking patterns would inflate lightweight locks to full monitors. In some scenarios (when churning lots of recursively locked objects), this could lead to excessive native memory usage. I'd like to add a test that verifies that this does not happen.
>> 
>> I verified that the new test fails reliably with an earlier commit that did not have LW recursive locking, yet, and passes with latest LW recursive locking.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Let the monitor object escape to prevent it from getting optimized away

Looks fine with minor nits.

test/hotspot/jtreg/runtime/locking/TestRecursiveMonitorChurn.java line 49:

> 47:     }
> 48: 
> 49:     public static Monitor monitor;

I'll probably make it `static volatile` to be extra confusing to the compiler. As it stands now, compiler is open to only do the last store in the loop.

test/hotspot/jtreg/runtime/locking/TestRecursiveMonitorChurn.java line 61:

> 59:             ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(
> 60:                     "-XX:+UnlockDiagnosticVMOptions",
> 61:                     "-Xmx100M", "-XX:AsyncDeflationInterval=0",

I'd also add `-XX:GuaranteedAsyncDeflationInterval=0`. The test does not run as long to trigger the guaranteed interval, but in case we would tune down the interval in future, better be safe.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18899#pullrequestreview-2019107874
PR Review Comment: https://git.openjdk.org/jdk/pull/18899#discussion_r1577428941
PR Review Comment: https://git.openjdk.org/jdk/pull/18899#discussion_r1577430309