RFR: 8374807: Crash in MethodData::extra_data_lock()+0x0 when running -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp -version [v2]

[Vladimir Ivanov]

On Thu, 15 Jan 2026 09:55:13 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Please review this change. Thanks!
>> 
>> Description:
>> 
>> This change fixes a crash in Deoptimization::uncommon_trap_inner when running with -XX:+TraceDeoptimization -XX:-ProfileTraps -XX:-TieredCompilation -Xcomp.
>> 
>> With -XX:-ProfileTraps, create_if_missing is set to false.
>> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2121-L2122
>> 
>> When create_if_missing is false, new mdo can not be created when m()->method_data() return null, so get_method_data() may return null .
>> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L1911-L1912
>> 
>> and trap_mdo can be null as a result
>> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2134-L2136
>> 
>> The crash happens here because trap_mdo is null
>> https://github.com/openjdk/jdk/blob/74faf033127ab3a5e28be75b91e662c589f81084/src/hotspot/share/runtime/deoptimization.cpp#L2157
>> 
>> Fix:
>> 
>> The fix makes acquisition of extra_data_lock conditional on trap_mdo being non-null, preserving the required lock ordering (extra_data_lock before ttyLocker) when an MDO exists.
>> 
>> Test:
>> 
>> GHA
>
> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - split long line
>  - Merge remote-tracking branch 'upstream/master' into 8374807
>  - fix 8374807

src/hotspot/share/runtime/deoptimization.cpp line 2161:

> 2159:                                 Mutex::_no_safepoint_check_flag);
> 2160: 
> 2161:       ttyLocker ttyl;

Does the code still need `ttyLocker`? 

There's only one usage of `tty` and it prints all accumulated info all at once. `xtty` already annotates output with thread info. So, I'd assume that moving `trap_mdo->extra_data_lock()` locker to  `trap_mdo` accesses  should solve the problem as well. 

(I'm not sure whether a `ttyLocker` is needed or not to avoid interleaving during `tty->print_raw(st.freeze());`, but `ttyLocker` can be placed right before it.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29147#discussion_r2695517458