RFR: 8357258: x86: Improve receiver type profiling reliability [v6]

[Aleksey Shipilev]

On Tue, 2 Dec 2025 08:44:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4826:
>> 
>>> 4824:   // and never duplicate the receivers in the list.
>>> 4825:   //
>>> 4826:   // It is tempting to combine these cases into a single loop, and claim the first
>> 
>> Can you elaborate, please, why it is the case? Is it a result of class unloading or something else?
>
> Yes, we are clearing MDOs for unloaded classes. 
> 
> I initially thought this kind of cleanup happens only during `ciReceiverTypeData::translate_receiver_data_from` translation to `ciReceiverTypeData`. If that was the only path, we would probably not care about this; although I would, for defensive programming reasons. *But* it looks like the cleanup happens during "normal" GC class unloading, which also makes sense: you do not want to have unloaded classes referenced from any runtime datastructure, including MDO. So this forces our hand to deal with empty slots. Old code also did this, AFAICS: it scanned everything at least once.
> 
> The path to receiver cleanup I saw in the code was:
> 
> 
> ReceiverTypeData::clear_row
> ReceiverTypeData::clean_weak_klass_links
> MethodData::clean_method_data
> InstanceKlass::clean_method_data
> InstanceKlass::clean_weak_instanceklass_links
> Klass::clean_weak_instanceklass_links
> KlassCleaningTask::work 
> <this is GC class unloading work>

I tightened up the comments a bit to mention that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25305#discussion_r2580384110