RFR: 8329351: add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing

[Coleen Phillimore]

On Fri, 5 Apr 2024 19:23:52 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> The first stress test to be added is:
> 
> runtime/Monitor/TestRecursiveLocking.java
> 
> It has been tested with a couple of 12 hour runs on my MBP13:
>   - 3 build configs: release, fastdebug, slowdebug, 4 hours each, total 12 hours
>   - 18 test configs, 800 seconds each, total 4 hours
> 
> The default configuration has been tested in Mach5 Tier2 and the
> StressWrapper_TestRecursiveLocking_36M.java version has been
> tested in Mach5 Tier3.

I haven't figured this test out yet, but I have some initial comments that might help.

test/hotspot/jtreg/runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java line 56:

> 54: 
> 55: /*
> 56:  * @test id=Xint_alternate_AB

I have a question to Misha (@ can't find name) to ask if these are in different files, will the tests run in parallel?  Or does the separate @ test's do that.

test/hotspot/jtreg/runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java line 119:

> 117:  * @test id=C1_alternate_AB
> 118:  * @requires vm.flagless
> 119:  * @requires vm.compiler1.enabled

Is this the same as giving option -Xcomp and -XX:TieredStopAtLevel=1 ? to make sure it only runs c1?  Same question below for c2.

test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 212:

> 210: public class TestRecursiveLocking {
> 211:     static final WhiteBox WB = WhiteBox.getWhiteBox();
> 212:     static final int LockingMode = WB.getIntVMFlag("LockingMode").intValue();

Variables in Java are supposed to start with lower case letters and be camel case so it's sort of clear that you've read this into the Java code. ie. it's the Java version of the variable not the VM version.

test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 255:

> 253:             }
> 254:             if (LockingMode != LM_LEGACY) {
> 255:                 assertInflated();

Legacy isn't inflated because it's recursive?  Can you add a comment why? It would help if something changes and the test starts failing to help whoever breaks this.

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

PR Review: https://git.openjdk.org/jdk/pull/18664#pullrequestreview-1995589802
PR Review Comment: https://git.openjdk.org/jdk/pull/18664#discussion_r1561839863
PR Review Comment: https://git.openjdk.org/jdk/pull/18664#discussion_r1561824343
PR Review Comment: https://git.openjdk.org/jdk/pull/18664#discussion_r1561829865
PR Review Comment: https://git.openjdk.org/jdk/pull/18664#discussion_r1561841421