RFR: 8373114: Redundant MethodCounters in the preimage generated by training run [v3]

Vladimir Kozlov kvn at openjdk.org
Wed Jan 14 21:44:29 UTC 2026


On Wed, 14 Jan 2026 20:56:55 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> src/hotspot/share/oops/trainingData.cpp line 122:
>> 
>>> 120: MethodTrainingData* MethodTrainingData::make(const methodHandle& method, bool null_if_not_found, bool use_cache) {
>>> 121:   MethodTrainingData* mtd = nullptr;
>>> 122:   if ((!have_data() && !need_data()) || (assembling_data() && !CDSConfig::is_at_aot_safepoint())) {
>> 
>> @ashu-mehra  and @veresov  from what I see `MethodTrainingData::make()` should be called only during training run when CTD is set: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileBroker.cpp#L356C21-L356C30
>> 
>> Am I missing path where it is called in assembly phase or production?
>> 
>> `need_data()` is true only during training:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/trainingData.hpp#L290
>
> During assembly we have `have_data()` return true, and since we're running some java code this will make us cache MTDs in MCs. That's what I think this code is trying to avoid.
> 
> But I have a question though. Why do we treat the presence of the cache MTD value in MC as a proof that MTD refers to a MC?

I am referencing `need_data()` in `compileBroker.cpp` code which set CTD:

  if (TrainingData::need_data() && !CDSConfig::is_dumping_final_static_archive()) {
    CompileTrainingData* ctd = CompileTrainingData::make(task);
    if (ctd != nullptr) {
      task->set_training_data(ctd);


I see we check CTD in places where we call `MethodTrainingData::make()`. That is why I assumed that it is called only during training run.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28670#discussion_r2692151846


More information about the hotspot-dev mailing list