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

[Paul Sandoz]

On Wed, 12 Nov 2025 23:15:53 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

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

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

I would prefer this approach if feasible. That would allow us cleanly to exercise all the layers.

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

It's in the same package as ReflectMethods (at one point it might have been external, don't recall exactly).

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

Yes, that's a possibility to collapse the layers, although maybe a little harder to test independently.

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

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