[lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize" cannot work well [v4]

[Jatin Bhateja]

On Fri, 8 Sep 2023 02:31:14 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> If a primitive class field is flattened, then compiler will not be creating an InlineTypeNode for field access, sub-field will be part of container, isn't that sufficient to make the check, e.g.
>> 
>> 
>> primitive class ABC {
>>    int f1;
>>    long f2;
>>    ABC (int f1, long f2) {
>>       this.f1 = f1;
>>       this.f2 = f2;
>>    }
>> }
>> 
>> 
>> public class flatten {
>>    public final ABC field;
>> 
>>    public flatten(int val) {
>>      this.field = new ABC(val, (long)val);
>>    }
>> 
>>    public static long micro(int val) {
>>       flatten obj =  new flatten(val);
>>       return obj.field.f1 + obj.field.f2;
>>    }
>> 
>>    public static void main(String [] args) {
>>       long res = 0;
>>       for (int i = 0; i < 10000; i++) {
>>           res += micro(i);
>>       }
>>       System.out.println(res);
>>    }
>> }
>> 
>> 
>> 
>> We see no InlineTypeNode in post parse IR with following command line:-
>> 
>> -XX:CompileCommand=compileonly,flatten::micro -XX:+EnablePrimitiveClasses -cp . flatten
>> 
>> But, field access does generate InlineTypeNode if flatten size explicitly set as 0 with following options.
>> 
>> -XX:InlineFieldMaxFlatSize=0  -XX:CompileCommand=compileonly,flatten::micro -XX:+EnablePrimitiveClasses -cp . flatten
>> 
>> EA will anyways remove non-escapable allocation, but post parse IR verification should be good enough to test your changes ?
>
> Hi @jatin-bhateja @TobiHartmann , I'v added the IR tests which check the oop load number for non-flattened inline type fields. Please help to take a look whether it's fine. Thanks in advance!

Thanks @XiaohongGong, LGTM!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/888#discussion_r1319351799