[code-reflection] RFR: OpBuilder optimizations - part 1. [v2]

[Maurizio Cimadamore]

On Wed, 12 Nov 2025 21:09:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> If that were the goal then I agree it would certainly be a non-trivial amount of work. We have a more modest goal - ensuring that a code model for a reasonably large reflectable method/lambda can be encoded using our current mechanism without breaking class file limits. We need to be good enough, and this unlikely to be the final solution as to how we store the code model.
>> 
>> Looking at the `OpBuilder` changes in `createSupportFunctions` I suspect that the enhancements required to  `CodeModelTranslator` are manageable e.g., support for multiple methods, and the ? : operator. @mabbay wrote `CodeModelTranslator` and he may have a sense of how easy it would be to enhance with support for additional ops.
>
> It is an option.
> I just don't see much of added value when we manually hard-code proprietary code models and then translate them with proprietary translator to ASTs. BytecodeGenerator here revealed bugs in the models, and on the other side it revealed blind spots in the BytecodeGenerator itself.
> It would make more sense to hard-code it in the ASTs then. 
> For example the `tableswitch` instruction I would like to look at it in the BytecodeGenerator have the same problem in the CodeModelTranslator.

Another option we discussed offline, in case we want to keep things more fluid, would be to make this trick more official. That is, during `ReflectMethods`, we generate some ops, we save them on the AST, then, when the time comes to generate bytecode (`JavaCompiler::generate`) we pick these up again, and we run them through the `BytecodeGenerator`. This will at least respect the order in which things should occur.

One thing that is related is what is the role of `OpBuilder` going forward, because it's looking now like a very specialized piece of code that probably belongs more near to `ReflectMethods` than as a standalone API?

And, if that's true, perhaps once the op method format settles, we can do a pass on the code and just generate the AST we want directly, w/o going through code models...

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/679#discussion_r2520013783