JDK-8277180 : Intrinsify recursive ObjectMonitor locking for C2 x64 and A64
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 16,17,18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-11-16
  • Updated: 2023-10-05
  • Resolved: 2021-11-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17 JDK 18
17.0.3Fixed 18 b25Fixed
Related Reports
Cloners :  
JDK-8281043 - Intrinsify recursive ObjectMonitor locking for PPC64
Cloners :  
JDK-8310513 - [s390x] Intrinsify recursive ObjectMonitor locking
Duplicate :  
JDK-8263864 - ~17% regression for DaCapo h2 after JDK-8253064
Relates :  
JDK-8277431 - riscv: Intrinsify recursive ObjectMonitor locking for C2
Relates :  
JDK-8317575 - AArch64: C2_MacroAssembler::fast_lock uses rscratch1 for cmpxchg result
Relates :  
JDK-8253064 - monitor list simplifications and getting rid of TSM
Description
The C2 fast_lock and fast_unlock intrinsics don't support recursive ObjectMonitor locking. Some workload can significantly benefit from this.
Comments
Fix Request (17u): This change for 2 ISAs fixes the performance regression seen between 11 and 17. Numbers in the issue (x86 I guess) mention 17% in Dacapo h2. AArch64 results for 17u in that benchmark are slightly different but still impressive: 17u now is ~3% worse than 11u, this patch improves the score by 10%. Original patch applies cleanly. It is rather small, compact and touches frequently used code, so the risk is low. Testing: jtreg tier1, tier2 in dev environment, pre-submit checks.
27-01-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk17u-dev/pull/126 Date: 2022-01-27 15:08:08 +0000
27-01-2022
Changeset: d93b238f Author: Erik Österlund <eosterlund@openjdk.org> Date: 2021-11-18 14:44:58 +0000 URL: https://git.openjdk.java.net/jdk/commit/d93b238f9725727ae1e2e9f203943b5ddf778f35
18-11-2021
Can JDK-8263864 then be closed as a dup of this if it fixes the regression mentioned?
16-11-2021
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 regressions we have seen, and makes a few more benchmarks happy.
16-11-2021
That makes sense. Then we should leave JDK-8263864 open and probably update it after this RFE goes in. Thanks for the update!
16-11-2021
This fixes the problem on x86_64 and AArch64. There is further work to be done for Oracle unsupported platforms like x86_32, S390, PPC and 32 bit ARM, if anyone wants to deal with that. So it seems like the scope of that bug is wider than my fix here.
16-11-2021