Flexible constructors and switch pattern incompatibility

[Archie Cobbs]

Thanks Jan!

On Mon, May 13, 2024 at 9:39 AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> 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
>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240513/7e3ffc8c/attachment-0001.htm>