On Tue, 26 May 2026 07:03:33 GMT, Tobias Hartmann <[email protected]> wrote:
>> Quan Anh Mai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rename ConstraintCastNode::ideal_inline_type_node
>
>> it makes the compiler not try expanding a value object subfield, unless the
>> field is loaded
>
> Do you mean "unless the field is **flattened**"?
>
>> It also means that, we have no choice but stopping flattening at this level,
>> because going even 1 level deeper may lead to issues in extreme cases, as a
>> value object can have hundreds of leaf fields
>
> But since we know the layout(s) statically, couldn't we just set a
> limit/threshold on the number of fields that get scalarized or on the depth?
@TobiHartmann Thanks for your review.
> Do you mean "unless the field is flattened"?
Yes, that's right, my mistake.
> But since we know the layout(s) statically, couldn't we just set a
> limit/threshold on the number of fields that get scalarized or on the depth?
I think that's possible, but since it makes the code more complicated and it is
not relevant for JEP401, I think we can leave it to lw401-post, what do you
think?
> src/hotspot/share/opto/castnode.cpp line 225:
>
>> 223: }
>> 224:
>> 225: Node* ConstraintCastNode::ideal_inline_type_node(PhaseGVN* phase) {
>
> The name of this method is a bit misleading.
Renamed it.
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java line 4918:
>
>> 4916: Asserts.assertFalse(test174(x, null));
>> 4917: Asserts.assertFalse(test174(null, x));
>> 4918: // Asserts.assertFalse(test174(x, z));
>
> Why is this needed? (Same below)
Because I changed the field from an `Integer` to an `int`, so there is no
guarantee that `x` and `z` are different values anymore.
-------------
PR Comment: https://git.openjdk.org/valhalla/pull/2474#issuecomment-4542179763
PR Review Comment:
https://git.openjdk.org/valhalla/pull/2474#discussion_r3302369203
PR Review Comment:
https://git.openjdk.org/valhalla/pull/2474#discussion_r3302367678
