[lworld] RFR: 8359370: [lworld] allow instance fields of identity classes to be readable in the prologue phase [v15]

[Maurizio Cimadamore]

On Thu, 28 Aug 2025 20:27:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing unnecessary imports

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1449:

> 1447:                              * not allowed in the prologue
> 1448:                              */
> 1449:                             if (insideLambdaOrClassDef ||

I'm not entirely convinced about these checks. They seem to lead to very strange asymmetries:


import java.util.function.*;

class Test3 {

    int x = 4;
    int y;

    Test3() {
        System.out.println(x); //error
        Supplier<Integer> s1 = () -> x; // error
        y = 2;
        System.out.println(y); // ok
        Supplier<Integer> s2 = () -> y; // error
        super();
    }
}


I understand that references to `x` are invalid here -- `x` is not a strict field, so it will be initialized _after_ the prologue. So the first couple of references are errors, fine.

But in the last couple, we have that `print(x)` is good, but the reference from the lambda is flagged as an error. I'm not sure what's the rationale here? After all the lambda is defined _after_ `y` has been assigned, so what are we trying to protect against?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309840429