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

2023-03-31 Thread Jorn Vernee
On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee 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::tr

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

2023-03-31 Thread Adam Sotona
On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee 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::tr

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

2023-03-31 Thread Adam Sotona
On Fri, 31 Mar 2023 12:20:49 GMT, Adam Sotona wrote: >> I believe that, in order to generate the actual bytecodes, the classfile API >> does a full verification pass (as it needs to infer the stackmap >> information). This leads me to believe that, yes, most (but probably all) >> errors would

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

2023-03-31 Thread Adam Sotona
On Fri, 31 Mar 2023 11:22:46 GMT, Maurizio Cimadamore wrote: >> I'm not really looking for anything specific. I'm just trying to figure out >> if it's worth it to keep the `PERFORM_VERIFICATION` flag, and change it to >> call the verifier in the new impl. i.e. does it catch more errors than ju

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

2023-03-31 Thread Maurizio Cimadamore
On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee 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::tr

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

2023-03-31 Thread Maurizio Cimadamore
On Fri, 31 Mar 2023 03:24:22 GMT, Jorn Vernee wrote: >> Classfile API does have some sort of error reporting mechanism in >> verification; at least it tracks the error context. >> https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/src/java.base/share/classes/jdk/interna

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

2023-03-31 Thread Maurizio Cimadamore
On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee 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::tr

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

2023-03-30 Thread Jorn Vernee
On Fri, 31 Mar 2023 02:34:26 GMT, Chen Liang wrote: >> Just to clarify: I'm looking for the kind of errors that don't get caught by >> just generating the class, but are also more informative than the default >> VerifyError you would get from loading an invalid class. > > Classfile API does hav

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

2023-03-30 Thread Chen Liang
On Thu, 30 Mar 2023 22:09:24 GMT, Jorn Vernee wrote: >> This seems to be caught without running the verifier as well: >> >> >> Caused by: java.lang.IllegalStateException: Operand stack underflow at >> bytecode offset 79 of method >> invoke(SegmentAllocator,MemorySegment,MemorySegment) >> ..

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

2023-03-30 Thread Jorn Vernee
On Thu, 30 Mar 2023 20:11:30 GMT, Jorn Vernee wrote: >> Yes, for instance, the class generation doesn't check operand stack >> underflow, that you can generate code with invalid pops. The classfile >> verifier catches this: >> https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c97524

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

2023-03-30 Thread Jorn Vernee
On Thu, 30 Mar 2023 20:01:57 GMT, Chen Liang wrote: >> Does this provide additional verification over what is already done just by >> generating the class? >> >> For instance, IIRC the ASM verifier could catch e.g. stack underflow, but >> that seems to be caught already by the new implementati

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

2023-03-30 Thread Chen Liang
On Thu, 30 Mar 2023 19:50:47 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java >> line 216: >> >>> 214: if (PERFORM_VERIFICATION) { >>> 215: boolean printResults = false; // only print in case of >>> exception >>> 216:

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

2023-03-30 Thread Jorn Vernee
On Thu, 30 Mar 2023 18:43:42 GMT, Chen Liang wrote: >> 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 21

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

2023-03-30 Thread Jorn Vernee
> 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 builder