RFR: 8365189: Remove LockingMode related code from arm32
Fredrik Bredberg
fbredberg at openjdk.org
Wed Aug 20 13:36:41 UTC 2025
On Tue, 19 Aug 2025 07:30:57 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>>
>> This PR removes `LockingMode` related code from the **arm32** platform.
>>
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>
> Looks good.
>
> You unified some comment styles within a file, but kept them different across the files.
> Not sure the Fall through comments do much now when the ifs are gone.
> A bunch of `[un]lock_done` lables are now only used with bind and are never jumped to.
>
> Not sure any of these require fixing.
@xmas92
> You unified some comment styles within a file, but kept them different across the files. Not sure the Fall through comments do much now when the ifs are gone. A bunch of `[un]lock_done` lables are now only used with bind and are never jumped to.
It's hard not to unify comments within a file when you are changing the code, but didn't find it important enough to unify in all files.
I agree, the `Fall through` comments are not that useful. Looking at Aarch64 I see that they far more informative as they read `Slow path will re-enter here`. I also think you are wrong about the bunch of `[un]lock_done` lables being used only with bind. As far a I can tell they are all jumped to, but far later in the code.
> Not sure any of these require fixing.
I'll fix it if something else that needs fixing turns up, otherwise I'll let it pass.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26795#issuecomment-3206365654
More information about the hotspot-runtime-dev
mailing list