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

[Maurizio Cimadamore]

On Wed, 12 Nov 2025 17:42:02 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 one additional commit since the last revision:
> 
>   nit fixes

The overall approach seems solid. You generate a separate class that contains some helper methods to build lists/maps and ops. Presumably, these methods have a very high chance to be reused across different synthetic op methods.

I wonder if these "helper" functions could be turned into bootstrap methods. That way, we can implement them once and for all in the incubator module. And we could even add more, such as the ability to turn a Java type string into a type element w/o building the tree structurally. 

Re. helper method names, perhaps would be better to start with `$` instead of `::`, as that is a more common symbol to indicate "synthetic method" in javac-land.

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

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