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

[Aleksey Shipilev]

On Mon, 1 Dec 2025 23:25:42 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Simplify third case: no need to loop, just restart the search
>>  - Actually have a second "fast" case: receiver is not found in the table, and the table is full
>>  - Pushing/popping for rare CAS path is counter-productive
>
> 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.

The path I saw 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>

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

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