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
src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java
line 77:
> 75: private static final int CLASSFILE_VERSION =
> ClassFileFormatVersion.latest().major();
> 76:
> 77: private static final ClassDesc CD_Arena = desc(Arena.class);
I love that we're able to describe what we need to use at a higher-level of
abstraction than just strings.
src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java
line 940:
> 938: }
> 939:
> 940: private void emitInvokeStatic(Class<?> owner, String methodName,
> String descriptor) {
It is great to see these ad-hoc routines (most of which exist in one form or
another in all our JDK code generators) go away!
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1154357570
PR Review Comment: https://git.openjdk.org/jdk/pull/13247#discussion_r1154357053
