RFR: 8277180: Intrinsify recursive ObjectMonitor locking for C2 x64 and A64

[Erik Österlund]

On Wed, 17 Nov 2021 07:46:15 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> The C2 fast_lock and fast_unlock intrinsics don't support recursive ObjectMonitor locking. Some workloads can significantly benefit from this. Recent ObjectMonitor work has changed heuristics such that ObjectMonitors are deflated less aggressively. Therefore we can expect to see more inflated monitors in workloads where we would usually see more stack locks. That in itself is fine, except that C2 doesn't intrinsify the recursive locking paths for object monitors. Enabling those cases in the C2 code, removes a (~17%) regression we have seen with DaCapo h2 -t 1, and makes a few more benchmarks happy as well.
>
> src/hotspot/cpu/aarch64/aarch64.ad line 3924:
> 
>> 3922: 
>> 3923:     __ cmp(disp_hdr, (u1)0);
>> 3924:     __ br(Assembler::EQ, notRecursive);
> 
> You can replace these two with a single `__ cbz(disp_hdr, notRecursive)` and avoid clobbering the flags.

That is a good idea. BTW note that in the unlocking path for AArch64 there is an ownership check, while in the x86_64 code there is only a comment saying we definitely need one of those, but it doesn't actually check the owner. @dholmes-ora did some digging and it seems like this was previously controlled by some ancient sync flag that isn't around anymore. It would only exist to check for unbalanced JNI locking, and the JNI spec kind of says you shouldn't do that - that's a programmer error. So it seems like just not doing the ownership check is totally fine, and seems to yield 10% better performance in some workloads where there is contended locking. But I don't want to remove that check as part of this change - just something to keep in mind for a future RFE.

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

PR: https://git.openjdk.java.net/jdk/pull/6406