[lworld] RFR: [DRAFT] [lworld] Test scalarization and call conventions for different value class shapes

[Galder Zamarreño]

On Mon, 18 Aug 2025 13:42:10 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> This is a **very early draft** for a template-based test (temporarily called `TestOne`) that addresses some of the requirements of JDK-8364421.
>> 
>> **NOTE**: the PR also includes the commits to add template-based testing framework since that's not yet in `lworld`, and also adds https://github.com/openjdk/valhalla/commit/68e4a60c1ff62f4d0b8b31cb0bd729f1d67748e2 so that Boolean types are supported in `checkEQ`.
>> 
>> This test has surfaced [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590) bug, and as I focus on that bug, I thought it'd be a good moment to share what I've done so far with the test and get some feedback.
>> 
>> The test is very simple so far, creating value classes that contain a single field, testing for each of the primitive types. I also started testing having this field be a primitive array type and that's when I encountered [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590).
>> 
>> I've tried to create value classes that had multiple fields, but I've hit some obstacles here so I've just added a very basic test:
>> 
>> First, I tried to use data names to create value classes that would have N fields, and have these fields initialized via a constructor, but I couldn't get it to work. So the example present in the test uses external data structures to keep track of these fields, their types, their initial values...etc. I have discussed these issues in more detail with @chhagedorn and bounced some ideas of how to improve data names, but these need to be discussed in more detail.
>> 
>> The second obstacle I found is related to nuances on when value classes with multiple fields will be scalarized, when these classes are part of another value classes. Depending on the combination of fields, they can be considered that they can be flattened or not, so handling this in a test like this would need to track the sizes of each fields, add them up, and decide whether the test should be positive on scalarization or negative. I traced this logic to `FieldLayoutBuilder::compute_inline_class_layout` and the way `_nullable_layout_size_in_bytes` is then used to decide whether to flatten or not. I've been using `PrintFieldLayout` option to see what nullable flat layout values each of these box instances would have.
>> 
>> So, given these complexities of multiple fields, I'm might keep `TestOne` (note: name is temporary) focused on value classes with a single field. And then have another test with multiple fields.
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 223:
> 
>> 221:             """
>> 222:         )).asToken(field);
>> 223:     }
> 
> Looks like you don't actually need any arguments in the Template here. You are already capturing `field` in the lambda.

True.

When to use arguments vs when to just capture variables...etc has been something I've been struggling with.

Initially I didn't think too much about it, but when I started trying to use `dataNames` lambdas and started giving failures, then I tried to move towards arguments and as you can see there are places where things are mixed up.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2286918618