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

[Xiaohong Gong]

On Thu, 7 Sep 2023 08:58:05 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Couldn't you just check that there is no oop load for that particular field, i.e., no indirection to load the fields from a heap buffer?
>
> 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!

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

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