This is more of a thought at this point. Right now, it looks like NativeInvokerBytecodeGenerator is used to implement the dynamic compilation of LambdaForms. LambdaForms in Java are much like Expressions in .NET: a symbolic record of a potential method execution.

OpenJDK uses InvokerBytecodeGenerator to implement this in Java. It is Java code which builds Java bytecode, which is then loaded using the standard defineClass semantics at runtime.

IKVM however has a map to replace the compileToBytecode method with a call to NativeInvokerBytecodeGenerator. This method assembles the semantic form directly into IL. Then generating a delegate to that, and setting it up on MemberName.

This seems like it was a good potential optimization: instead of having IKVM compile the code to byte code, only to have it then recompile it on the fly to IL, the middle step is skipped.

It is however about 1000 lines of IL generation code, which has to take into account most of the same security and mapping guarantees as the rest of the dynamic compilation. And it's a rather large significant deviation from OpenJDK code. It's going to make upgrading the JDK all that much harder.

I'm hard pressed to imagine the optimization is still worth it at this point. The end result is still cached.

I think it would be better to let the existing OpenJDK code proceed as is, resulting in a defineClass call. Optimizations can be focused on the speed of JIT and other things.