[code-reflection] RFR: OpBuilder optimizations - part 1. [v2]
Paul Sandoz
psandoz at openjdk.org
Wed Nov 12 20:42:49 UTC 2025
On Wed, 12 Nov 2025 20:29:21 GMT, Adam Sotona <asotona at openjdk.org> wrote:
>> 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.
All i am saying here is the details about the nested class can be embedded in the synthetic method that invokes the static method of the same name on the nested class. Thereby we hide those details from the runtime.
-------------
PR Review Comment: https://git.openjdk.org/babylon/pull/679#discussion_r2519753124
More information about the babylon-dev
mailing list