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

Igor Veresov iveresov at openjdk.org
Wed Jan 14 23:04:21 UTC 2026


On Wed, 14 Jan 2026 21:40:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> 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.

The main user of the cached lookups is `MethodTrainingData* mtd = MethodTrainingData::find_fast(mh);` in `compilationPolicy.cpp:1024`. It's going to be called on every tiered event if `have_data() == true`. That's likely the main source of the MC pollution he's trying to avoid.

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

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


More information about the hotspot-dev mailing list