RFR: 8336421: ciMethod() constructor should use ConditionalMutexLocker(Compile_lock)

[Vladimir Kozlov]

On Tue, 16 Jul 2024 01:01:17 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> During Leyden testing with `-XX:+LogCompilation` flag I hit assert because `ciMethod()` could be called from `ciEnv::register_method()` which already holds `Compile_lock` lock. See call stack in JBS report.
> Use `ConditionalMutexLocker` in `ciMethod()`.
> This is normal code pattern used in other places where we can have nested locking: [compileBroker.cpp#L2847](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L2847).
> 
> Tested tier1.

I don't think `compiler/interpreter/Test6833129.java` test failure in GHA is related to changes:

[0.552s][error][gc,verify] Object 0xa1a00010 has a null klass
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xead2b887, pid=12006, tid=12028
#
 # JRE version: OpenJDK Runtime Environment (24.0) (fastdebug build 24-internal-vnkozlov)
# Java VM: OpenJDK Server VM (fastdebug 24-internal-vnkozlov, mixed mode, sharing, tiered, g1 gc, linux-x86)
# Problematic frame:
# V  [libjvm.so+0x52b887]  oopDesc::size_given_klass(Klass*)+0x17

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

PR Comment: https://git.openjdk.org/jdk/pull/20187#issuecomment-2230003639