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

[Paul Sandoz]

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

This looks promising, and we get to leverage more of what we have built, so we can further test and improve it. We need to get reflectable lambdas working and it passing all tests before its ready.

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.

src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/OpBuilder.java line 216:

> 214:     }
> 215: 
> 216:     public static List<FuncOp> createSupportFunctions(JavaType currentClass) {

Ideally we could declare a reflectable methods and let the compiler build the models for us, not sure that is possible at this stage. Placing the corresponding Java code in a comment would be the next best thing.

src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java line 388:

> 386:     }
> 387: 
> 388:     private Type synthClassDecl(String className, List<CoreOp.FuncOp> funcs) {

Interesting, you cleverly side-step the restriction we could not work out how to overcome, by generating a "synthetic" nested static class.

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.

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

PR Review: https://git.openjdk.org/babylon/pull/679#pullrequestreview-3454892581
PR Review Comment: https://git.openjdk.org/babylon/pull/679#discussion_r2519449414
PR Review Comment: https://git.openjdk.org/babylon/pull/679#discussion_r2519374640
PR Review Comment: https://git.openjdk.org/babylon/pull/679#discussion_r2519392950
PR Review Comment: https://git.openjdk.org/babylon/pull/679#discussion_r2519396253