Flexible constructors and switch pattern incompatibility

[Jan Lahoda]

Hi Archie,


I think this is just a bug. My fix proposal:
https://github.com/openjdk/jdk/pull/19217


Thanks,

      Jan


On 11. 05. 24 22:15, Archie Cobbs wrote:
> 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/20240513/2f714486/attachment.htm>