RFR: 8361952: Double-checked locking MethodData::extra_data_lock() misses synchronization on reader side

[Aleksey Shipilev]

On Fri, 11 Jul 2025 09:47:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that fixes some recently introduced double-checked locking missing the memory barrier (`load_acquire`) on the reader side. Without it the reader might get a valid pointer to the `Mutex` created on the fly, without it being initialized properly.
> 
> Found during code inspection for https://bugs.openjdk.org/browse/JDK-8361706 ; due to some suspicious hangs in the `MutexLocker` while cleaning klasses during class unloading in parallel (multiple threads hanging in `MethodData::clean_method_data`), executing the `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java` test.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks reasonable. 

Two nits:
  - This is not technically double-checked locking, this is just an atomic installation. So the RFE synopsis is not that accurate.
  - Maybe `Atomic::cmpxchg` should use a more relaxed memory ordering as well, to micro-optimize and offset the costs of now-proper acquire a bit. There is no need for default `memory_order_conservative` here. I think `memory_order_seq_cst` would do: gives acquire of `old` and release of new in the same package.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26262#pullrequestreview-3009726736