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

[Dean Long]

On Mon, 15 Sep 2025 14:27:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for discussion what issues current machinery has. 
>> 
>> This PR executes the plan outlined in the bug:
>>  1. Common the receiver type profiling code in interpreter and C1
>>  2. Rewrite receiver type profiling code to only do atomic receiver slot installations
>>  3. Trim `C1OptimizeVirtualCallProfiling` to only claim slots when receiver is installed 
>> 
>> This PR does _not_ do atomic counter updates themselves, as it may have much wider performance implications, including regressions. This PR should be at least performance neutral.
>> 
>> Additional testing:
>>   - [x] Linux x86_64 server fastdebug, `compiler/`
>>   - [ ] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8357258-x86-c1-optimize-virt-calls
>  - Drop atomic counters
>  - Initial version

src/hotspot/cpu/x86/interp_masm_x86.cpp line 1342:

> 1340: 
> 1341:     // Record the receiver type.
> 1342:     type_profile(receiver, mdp, 0);

Why is 0 the correct offset?  The C1 helper uses md->byte_offset_of_slot().

src/hotspot/cpu/x86/interp_masm_x86.cpp line 1553:

> 1551: 
> 1552:       // Record the object type.
> 1553:       record_klass_in_profile(klass, mdp, reg2, false);

Same question as above about the 0 offset.  Is this because `mdp` has already been adjusted?

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

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