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

[Aleksey Shipilev]

On Wed, 17 Sep 2025 23:38:39 GMT, Dean Long <dlong at openjdk.org> wrote:

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

Interpreter and C1 do profiling data offsets a bit differently.

Interpreter tracks MDP as BCI changes.  It has to, because it does not really know statically where it is. Take a look at `InterpreterMacroAssembler::update_mdp_*` family of methods, and one of its uses:


void InterpreterMacroAssembler::profile_taken_branch(Register mdp) {
  if (ProfileInterpreter) {
    Label profile_continue;

    // If no method data exists, go to profile_continue.
    test_method_data_pointer(mdp, profile_continue);

    // We are taking a branch.  Increment the taken count.
    increment_mdp_data_at(mdp, in_bytes(JumpData::taken_offset()));

    // The method data pointer needs to be updated to reflect the new target.
    update_mdp_by_offset(mdp, in_bytes(JumpData::displacement_offset()));
    bind(profile_continue);
  }
}


It is fairly confusing in interpreter code that `mdp` is not pointing to `MethodData*` head, but  actually is the _interior_ pointer somewhere in MDP. Profiling code is weaved in in such a way that MDP at current point is pointing at area that belongs to current BCI.

Compilers are able to compute the mapping from BCI to MDP to data slot directly, since they have a good view on the whole method and can ask VM questions about the slot addresses. C1 commonly does this:


  ciProfileData* data = md->bci_to_data(bci);
  md->byte_offset_of_slot(data, <interior-offset>);


Anyhow, I did most of the interface changes mechanically, so the `0` slot offset naturally appeared in these places through refactoring. Which gives me additional confidence about its correctness.

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

Same answer as above.

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

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