RFR: 8310513: [s390x] Intrinsify recursive ObjectMonitor locking

[Lutz Schmidt]

On Wed, 6 Mar 2024 04:02:42 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> s390 implementation of [JDK-8277180](https://bugs.openjdk.org/browse/JDK-8277180). PPC implementation for the same: https://github.com/openjdk/jdk/pull/7305
>> 
>> I had tested `tier1` on `fastdebug`, `release` vm. 
>> 
>> 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 patch: 
>> ===== DaCapo 9.12-MR1 h2 PASSED in 223023 msec =====
>> ===== DaCapo 9.12-MR1 h2 PASSED in 225686 msec =====
>> ===== DaCapo 9.12-MR1 h2 PASSED in 219824 msec =====
>> ===== DaCapo 9.12-MR1 h2 PASSED in 226719 msec =====
>> 
>> 
>> 
>> with patch: 
>> ===== DaCapo 9.12-MR1 h2 PASSED in 167816 msec =====
>> ===== DaCapo 9.12-MR1 h2 PASSED in 174368 msec =====
>> ===== DaCapo 9.12-MR1 h2 PASSED in 170517 msec =====
>> ===== DaCapo 9.12-MR1 h2 PASSED in 169349 msec =====
>
> src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3207:
> 
>> 3205: 
>> 3206:   if (DiagnoseSyncOnValueBasedClasses != 0) {
>> 3207:     load_klass(Z_R1_scratch, oop);
> 
> @RealLucy if we use `temp` here instead of Z_R1, do you think there will be issues ? It seems temp is free at this point.

Using temp here actually is a good idea. As you know, using the scratch registers (Z_R0 and Z_R1) across calls is risky. You need to know exactly if they are used as scratch further down the call hierarchy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17975#discussion_r1514804098