On Mon, 2 Mar 2026 13:38:22 GMT, Damon Fenacci <[email protected]> wrote:
> `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 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? ------------- PR Review: https://git.openjdk.org/valhalla/pull/2185#pullrequestreview-3966699877
