[jdk21u-dev] Integrated: 8341715: PPC64: ObjectMonitor::_owner should be reset unconditionally in nmethod unlocking

Richard Reingruber rrich at openjdk.org
Mon Dec 9 07:40:48 UTC 2024


On Mon, 2 Dec 2024 16:45:46 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/f9208fadde8141e18a025ddb6ce28423861ba391
> 
> The change removes instructions that check if an ObjectMonitor is owned by the current thread before unlocking it in a c1/c2 compiled nmethod.
> 
> The check is imprecise. It can fail if the lock was inflated into an ObjectMonitor by another thread.
> It is also redundant since only bytecode with symmetric locking operations is compiled.
> See JBS-Issue for details.
> 
> Note that there existed a special diagnostic locking mode to do the same check also on x86. Purpose was to protect against missbehaving JNI code. It got removed though with [JDK-8210381](https://bugs.openjdk.org/browse/JDK-8210381) in jdk12. On ppc64le it was not removed as the check was done in default mode as well (unclear why).
> 
> The fix didn't apply because in jdk21 there is still just one method to handle LM_LEGACY and LM_LIGHTWEIGHT and LM_LIGHTWEIGHT requires the owner check to handle ANONYMOUS owner. Also RTM is still supported in jdk21.
> 
> I'd consider the risk low. Aside from the assertions, the change is very small and it just brings ppc64 in line with how unlocking is done on other platforms.
> 
> The fix passed our CI testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. JCK, SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
> Testing was done with fastdebug builds on the main platforms and also on Linux/PPC64le and AIX.

This pull request has now been integrated.

Changeset: a0ed69d5
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.org/jdk21u-dev/commit/a0ed69d5a380c41546d6e0c9dbaa235adfe7f237
Stats:     37 lines in 1 file changed: 31 ins; 1 del; 5 mod

8341715: PPC64: ObjectMonitor::_owner should be reset unconditionally in nmethod unlocking

Reviewed-by: mdoerr
Backport-of: f9208fadde8141e18a025ddb6ce28423861ba391

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

PR: https://git.openjdk.org/jdk21u-dev/pull/1191


More information about the jdk-updates-dev mailing list