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

Adam Sotona asotona at openjdk.org
Fri Nov 14 13:48:08 UTC 2025


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

Based on the discussions above (and offline) I propose to refactor this solution a bit:
- Model-building `FuncOp`s + helpers `FuncOp`s will be organized under self-contained `ModuleOp` (forming the full content of the synthetic class). Helper methods will be called as `FuncCallOp`, instead of `InvokeOp`.  This configuration allows interpretation of the of model-building `FuncOp`s and so better testability (re-enabling of the `TestCodeBuilder`). It also eliminates some issues with lookup of the actual class.
- Model-building methods will return to the parent class, however they will just delegate to the same-named methods in the synthetic class.

Related to the `BytecodeGenerator` postpone to the rigth `javac` phase - I'm open to the implementation proposals.
Maybe we can solve it in a follow-up PR.

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

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


More information about the babylon-dev mailing list