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

[Daniel D. Daugherty]

On Thu, 11 Apr 2024 22:37:42 GMT, Coleen Phillimore <coleenp 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.
>
> 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.

I got this mechanism from a C1 targeted compiler test, but I'll double check what I've done here.

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

I like the typography of `LockingMode` because a grep will find it so...
I changed all uses of the `LockingMode` flag variable to `flagLockingMode`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18664#discussion_r1571418067
PR Review Comment: https://git.openjdk.org/jdk/pull/18664#discussion_r1571414444