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

[Maurizio Cimadamore]

On Tue, 18 Nov 2025 09:48:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This PR include following changes:
>> 
>> - op-building methods isolated from the original code and moved to a synthetic inner class
>> - fixed boxing in `OpBuilder`
>> - op-building methods are generated by `BytecodeGenerator` and support wide range of ops
>> - `CodeModelTranslator` is deleted
>> - synthetic op-building method overrides significantly reduce overhead (by 60% on `TestBytecode`)
>> 
>> Remaining tasks:
>> 
>> - implement part 2. type-building helper method(s) to reduce the overhead even more
>> - refactor `OpBuilder` to build `ModuleOp` instead of individual `FuncOp`s (and re-enable `TestCodeBuilder`)
>> - cleanup `BytecodeGenerator` API
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - re-enabled TestCodeBuilder
>    
>  - renamed OpBuilder::createBuilderFunction to createBuilderFunctions

To summarize the strategy that I think would be the path of least resistance to integrate with javac more properly (doesn't have to be done in this PR):
* ReflectMethods should create "shim" *inner* JCClassDef nodes for the synthetic classes and append them to the `defs` field of the toplevel class being visited;
* Those classes should contain no nested "defs" AST nodes, but should instead have a moduleOp field (this is a new field we can add to JCClassDef);
* We need to teach Lower to leave these synthetic inner classes alone -- e.g. Lower will (correctly) translate them as toplevel classes (which we want), but we don't want any other treatment -- perhaps this already is the case if the class is nested static and has no members, but we should make sure;
* Then, when in JavaCompiler we generate code, we can look at the JCClassDef: if it has no moduleOp, we send it through Gen/ClassWriter. If it does have a moduleOp, we use BytecodeGenerator instead.

This should allow us to retain flexibility to update the definitions of the synthetic classes w/o touching javac, while at the same time making sure that bytecode is generated in the right javac phase.

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

PR Comment: https://git.openjdk.org/babylon/pull/679#issuecomment-3546631346