[lworld] RFR: 8334484: [lworld] new translation strategy for instance field initializers

Dan Smith dlsmith at openjdk.org
Fri Mar 28 16:55:32 UTC 2025


On Wed, 19 Mar 2025 19:26:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Proxy locals are added as a new compiler phase which is executed just before code generation.
> 
> Q - what it does?
> A - basically for code like:
> 
> abstract value class Super {
>     Super(String s) {}
> }
> 
> value class V extends Super {
>     int i;
>     V(String s) {
>         if (s != null) {
>             i = 100;
>         } else {
>             i = 200;
>         }
>         super("100" + s);
>     }
> }
> 
> javac will generate for V's constructor something in the lines of:
> 
>     V(String s) {
>         /*synthetic*/ int local$i;
>         if (s != null) {
>             local$i = 100;
>         } else {
>             local$i = 200;
>         }
>         {
>             /*synthetic*/ final String local$0 = "100" + s;
>             i = local$i;
>             super(local$0);
>         }
>     }
> 
> so given a constructor for which any strict field is assigned to in a block that is not at the same level as the super constructor invocation, javac will generate synthetic local variables that will correspond to every strict field and any read or write done to a given strict field will be done on the synthetic local variable.
> 
> Javac will also generate additional synthetic local variables to hold the arguments, if any, of the super constructor invocation and will assign the strict fields with the current value of the corresponding synthetic local just before invoking the super constructor.
> 
> Q - does it interacts with other valhalla features?
> A - yes it has a direct interaction with the new stackmap table as the new assert_unset_fields entry is not generated now
> Q- is it on by default?
> A- yes but there is a hidden option to tell javac not to generate local proxy variables: `noLocalProxyVars` this will allow us to continue using javac for test cases that check for the generation of the assert_unset_fields entry in the stackmap table attribute until we have time to migrate those tests
> 
> TIA for any comments

Based on the description, looks like the trigger for this treatment is being a strict field assigned to with nontrivial control flow.

That's not an issue—we've got StackMapTable entries to manage those fields (and we _want_ to be exercising those StackMapTable entries, to ensure they're working properly).

Where we need a proxy local is when a field is _read_ somewhere in the early construction phase. In that case, the generated `getfield` would always trigger a verifier error, and javac needs to translate to a local variable read instead.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1403#issuecomment-2761911720


More information about the valhalla-dev mailing list