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

[Adam Sotona]

On Wed, 12 Nov 2025 18:58:31 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   nit fixes
>
> src/jdk.incubator.code/share/classes/jdk/incubator/code/Op.java line 560:
> 
>> 558:         try {
>> 559:             // @@@ Use method handle with full power mode
>> 560:             var cls = Stream.of(method.getDeclaringClass().getDeclaredClasses()).filter(c -> c.getName().endsWith("$$CM")).findFirst();
> 
> I realize you are trying to avoid generating any code using the tree API but i think it still may be best to keep generating the synthetic method that produces the code model. That synthetic method hides the details without having to change the runtime code allowing us to experiment with various encodings e.g., we could decide to generate one nested class per reflectable.

This generates the synthetic methods, just into an internal class.
BytecodeGenerator produces full class (with constant pool) and it does not mix match with ASTs.
I've tried also an experiment to inject Code attribute into the synth method, however complexity of interoperation between existing bytecode and ASTs is horrible.

> test/jdk/java/lang/reflect/code/writer/TestCodeBuilder.java line 47:
> 
>> 45:  * @modules jdk.incubator.code/jdk.incubator.code.internal
>> 46:  * @run junit TestCodeBuilder
>> 47:  * @ignore
> 
> Is this a temporary restriction? Until you get to part 2.

It is because I didn't pack all the FuncOps into a ModuleOp, so they could call each other. 
Yes, it is expected as a part 2.

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

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