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

[Emanuel Peter]

On Thu, 22 Jan 2026 01:54:16 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> @hgqxjj Hmm I see. I'm not a fan of using `@requires vm.debug`, because it means that your test is not run in product, and sometimes bugs only show up in product.
>> 
>> It's also not great that we have to run a whole JVM startup with `-Xcomp`, compiling EVERYTHING, and blocking for every compilation. We should only use `-Xcomp` in combination with a fairly restricted `compileonly`. Otherwise, we just waste a lot of compute resources.
>> 
>> @iwanowww What is your opinion on this?
>
> @eme64 Thanks for the feedback.
> 
> On @requires vm.debug: I’d like to keep it for this reproducer. ProfileTraps is the key knob here: the failure requires ProfileTraps=false (create_if_missing = ProfileTraps, so get_method_data(..., false) may return NULL). Since ProfileTraps is a develop_pd flag and not settable on product builds, this reproducer has to run on a non-product VM (i.e., a debug VM).
> 
> On -Xcomp: agreed. I’ll keep it but restrict it with -XX:CompileCommand=compileonly,... so we only compile the relevant method(s).
> 
> If that sounds reasonable, I’ll proceed with just the compileonly tightening.

Generally, it would also be nicer to extract a reproducer into a `test` method, and only compile that one. That way, the code shape leading to the crash is preserved. Would that be possible? Otherwise, we risk that someone changes the code shape (maybe in the core libs), and the test would not reproduce any more.

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

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