On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> Rewrite BindingSpecializer to use the new class file API.
>>
>> Note: There is a big try/catch/finally block generated in the `specialize`
>> method that currently uses labels. I looked at replacing this with a call to
>> `CodeBuilder::trying` but it would require threading the nested code
>> builders through all the `emit*` methods, which currently access the
>> 'global' CodeBuilder instance attached to the BindingSpecializer instance.
>> Since there didn't really seem to be a big benefit to this, I've kept that
>> try/catch/finally block as is, using labels.
>>
>> The current implementation could also use `CheckClassAdapter` to do
>> additional verification on the generated bytecode (ahead of the VM's
>> verifier). I'm not sure if the new API has a replacement for that?
>
> Jorn Vernee has updated the pull request incrementally with one additional
> commit since the last revision:
>
> use existing MTD_void constant
Thanks for the reviews. I've now re-implemented the `PERFORM_VERIFICATION` flag
as well, using `ClassModel::verify`. I tested this out by changing around some
of the parameter types for certain calls, and it works as expected:
java.lang.VerifyError: Bad type on operand stack at
jdk/internal/foreign/abi/DowncallStub.invoke(Ljava/lang/foreign/SegmentAllocator;Ljava/lang/foreign/MemorySegment;Ljava/lang/foreign/MemorySegment;)V
@66 (java/lang/System is not assignable from long2_type)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13247#issuecomment-1492299163
