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

[Paul Sandoz]

On Wed, 12 Nov 2025 22:31:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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...

If we can represent the building of the model purely as a model it gives us flexibility to translate and test e.g., testing using the interpreter *or* bytecode generator.

The modest set of models we build by hand, and fit into the larger model, could in theory eventually be built by the compiler itself. Let's try not to short circuit this and keep pushing. The key abstraction is the translation of a body with one block in some context, we already support it for one func op in the context of a `JCMethodDecl` that has one block node , we can extend for more than one func op in a module op, and then extend to support `ConditionalExpressionOp` that has three bodies, in the context of `JCConditional` that has three expression nodes.

I am glad as we have explored this area we have found limitations, that's valuable and we should find solutions for those regardless. So even if cannot use `BytecodeGenerator` in this case it will almost certain be used in other cases.

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

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