RFR: 8301703: java.base jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]

[Maurizio Cimadamore]

On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee <jvernee at 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