Flexible constructors and switch pattern incompatibility

[Archie Cobbs]

Looking at this a little further, I think I remember we already dealt with
this, and the JVM restriction referred to below is no longer a problem.

In JDK 22, the JVMS was changed to say:

The rule for *invokespecial* of an <init> method is the sole motivation for
> passing back a distinct exception stack frame. The concern is that when
> initializing an object, the *invokespecial* invocation could fail,
> leaving the object in a partially initialized, permanently unusable state.
> To prevent repeated initialization attempts after an object fails to
> initialize the first time, an exception handler must consider any
> references to the object stored in local variables to have type top
> rather than uninitializedThis or uninitialized(Offset).


So then maybe this is just a regular bug, i.e., we need to make an
adjustment to how stack maps are generated for code in early initialization
contexts. Any confirmation on that appreciated & sorry for the false alarm.

-Archie

On Sat, May 11, 2024 at 11:01 AM Archie Cobbs <archie.cobbs at gmail.com>
wrote:

> There is an issue with flexible constructors and certain
> synthetically-generated try/catch code, for example, when using switch
> patterns (where a try/catch for MatchException is sprinkled in).
>
> Please see https://bugs.openjdk.org/browse/JDK-8332106 for an example.
>
> As I understand it, this is due to the same verifier 'uninitializedThis'
> restriction that prevents bytecode rewriters from building a synthetic
> try/catch around super() calls, even if the catch clause always rethrows.
>
> I may have this muddled, but I believe this restriction disallows an
> 'uninitializedThis' in a catch clause stack map even if the
> 'uninitializedThis' is never actually touched. In which case a seemingly
> obvious fix for this is to relax the restriction, but that's a JVMS change.
>
> Are there other options?
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240511/71649d69/attachment.htm>