8377670: [lworld] RO adapter signature should not scalarize inline receiver in CompiledEntrySignature::initialize_from_fingerprint()

[dafedafe]

CompiledEntrySignature::initialize_from_fingerprint() was building _sig_cc and _sig_cc_ro the same way, but for virtual methods with an inline‑type receiver they must differ: _sig_cc should include the receiver’s scalarized fields, while _sig_cc_ro should represent the receiver as a single T_OBJECT.
This change fixes _sig_cc_ro construction so that when the receiver is an inline type, its fields are skipped and a single object entry is emitted instead.
It also adds asserts for _sig_cc_ro as a regression test proved to be hard to isolate and the asserts trigger immediately with any test if the RO signature is wrong.

Tests:

• Tier 1-3+
• Assert makes even build crash without fix

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (1 review required, with at least 1 Committer)

Issue

• JDK-8377670: [lworld] RO adapter signature should not scalarize inline receiver in CompiledEntrySignature::initialize_from_fingerprint() (Bug - P2)

Reviewers

• Marc Chevalier (@marc-chevalier - Committer)
• Tobias Hartmann (@TobiHartmann - Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/valhalla.git pull/2185/head:pull/2185
$ git checkout pull/2185

Update a local copy of the PR:
$ git checkout pull/2185
$ git pull https://git.openjdk.org/valhalla.git pull/2185/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2185

View PR using the GUI difftool:
$ git pr show -t 2185

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/valhalla/pull/2185.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back dfenacci! A progress list of the required criteria for merging this PR into lworld will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@dafedafe This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8377670: [lworld] RO adapter signature should not scalarize inline receiver in CompiledEntrySignature::initialize_from_fingerprint()

Reviewed-by: mchevalier, thartmann

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 113 new commits pushed to the lworld branch:

• 2bb7e72: 8380197: [lworld] [REDO] OptimizePtrCompare is too conservative
• ee48773: 8380802: [lworld] Remove larval bit from markWord
• 7c952e2: Merge
• ... and 110 more: https://git.openjdk.org/valhalla/compare/738e0cb821dc9fd0d80bdc4d7589be3328c70cfc...lworld

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the lworld branch, type /integrate in a new comment.

[mlbridge]

Webrevs

• 01: Full - Incremental (266e1040)
• 00: Full (dde1cce0)

[marc-chevalier]

There is something I don't understand, but I'm not sure what, so I'll throw things, and you tell me when I stop making sense:

• _sig_cc has all the value types exploded, each starting with T_METADATA and ending in T_VOID
• _sig_cc_ro is basically the same, but if the receiver is a value type, it must be T_OBJECT, but the other arguments
• value_object_count is the current nesting depth inside scalarized arguments
• skipping_inline_recv is whether we are currently inside the receiver, it is set when we meet its T_METADATA and cleared at the T_VOID, once value_object_count == 0, that is we closed all the nested inline types.

Given this, I don't understand how the code under the case T_METADATA: ensures we are adding as T_OBJECT only the receiver, and not every scalarized argument when _has_inline_recv is true.

---

Should we rename the PR/issue to be more descriptive?

[dafedafe]

Given this, I don't understand how the code under the case T_METADATA: ensures we are adding as T_OBJECT only the receiver, and not every scalarized argument when _has_inline_recv is true

If I get your question right, I think the missing point is that the receiver is the first argument (for non‑static methods), and the fingerprint should preserve that order, so the first T_METADATA encountered while value_object_count == 0 is the receiver’s inline‑type start. That’s why it emits a single T_OBJECT there and sets skipping_inline_recv. It then "ignores" all receiver fields until the matching T_VOID brings value_object_count back to 0 and clears the skipping_inline_recv flag. Any later inline‑type arguments should occur after this point, with skipping_inline_recv already false, so they are handled normally and are not "collapsed" to T_OBJECT.

I hope this makes sense somehow...

Should we rename the PR/issue to be more descriptive?

Good idea! Renaming...

[marc-chevalier]

skipping_inline_recv is initially false. We set it to ŧrue if

        if (!skipping_inline_recv) {
          if (_has_inline_recv && value_object_count == 0) {

so, at the beginning of the receiver scalarized type. At the end in

          if (!skipping_inline_recv) {
            SigEntry::add_entry(_sig_cc_ro, T_VOID, nullptr, offset);
          } else if (value_object_count == 0) {
            skipping_inline_recv = false;
          }

We set it back to false. But then, if I now see another T_METADATA, I have skipping_inline_recv == false, value_object_count == 0 and _has_inline_recv didn't change value. So why aren't we setting skipping_inline_recv to true again if we see a T_METADATA then?

[dafedafe]

We set it back to false. But then, if I now see another T_METADATA, I have skipping_inline_recv == false, value_object_count == 0 and _has_inline_recv didn't change value. So why aren't we setting skipping_inline_recv to true again if we see a T_METADATA then?

Of course! Well spotted @marc-chevalier! Thanks! (and I've checked it so many times 😆)
I've added a flag to take care of that.

[marc-chevalier]

It's interesting tests weren't failing with that. Maybe one can add asserts... But I don't see which wouldn't be quite expensive. We could check that after the first argument, if it's a receiver, both the cc and cc_ro are the same? But I fear I'm a bit overspecializing an assert for this exact mistake that will probably never happen again.

But thanks for fixing anyway. And happy to see I'm not crazy.

[dafedafe]

We could check that after the first argument, if it's a receiver, both the cc and cc_ro are the same

Maybe something like this could work

assert((!_has_inline_recv || (receiver_handled && !skipping_inline_recv)) && (_sig_cc->last()._bt == _sig_cc_ro->last()._bt),
        "_sig_cc and _sig_cc_ro differ for non-receiver arguments");

but, as you say, it looks a bit specific (and relies on the just introduced flag as well).

[marc-chevalier]

That's an idea. I'm not sure it's very useful. Also the _sig_cc->last()._bt == _sig_cc_ro->last()._bt part doesn't hold if the receiver is the only argument, does it? But overall, I'm not sure it's worth doing anything. Without this mistake in the first place, nobody would have asked for such a check. There is no reason to believe it could be reintroduced in the future.

[TobiHartmann]

Looks good to me too.

[dafedafe]

Thanks for your reviews @marc-chevalier @TobiHartmann.

[dafedafe]

/integrate

[openjdk]

Going to push as commit 357956b.
Since your change was applied there have been 113 commits pushed to the lworld branch:

• 2bb7e72: 8380197: [lworld] [REDO] OptimizePtrCompare is too conservative
• ee48773: 8380802: [lworld] Remove larval bit from markWord
• 7c952e2: Merge
• ... and 110 more: https://git.openjdk.org/valhalla/compare/738e0cb821dc9fd0d80bdc4d7589be3328c70cfc...lworld

Your commit was automatically rebased without conflicts.

[openjdk]

@dafedafe Pushed as commit 357956b.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.