From asotona at openjdk.org Mon Dec 1 08:17:53 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 1 Dec 2025 08:17:53 GMT Subject: [code-reflection] RFR: BytecodeGenerator cleanup and switch support Message-ID: - `BytecodeGenerator` performs proprietary lowering transformation - `OpBuilder` and tests adjusted to do not lower before calling `BytecodeGenerator` - `BytecodeGenerator.ConstantLabelSwitchOp` is an internal lowered representation of `JavaOp.JavaSwitchOp` with constant labels, and it generates `tableswitch` or `lookupswitch` instruction - post-processing transformations are slightly refactored ------------- Commit messages: - switch operand fix - nit rename - imports reorder - imports reorder - tableswitch and lookupswitch generation - BytecodeGenerator.ConstantLabelSwitchOp work in progress - selective lowering in BytecodeGenerator - BytecodeGenerator cleanup Changes: https://git.openjdk.org/babylon/pull/706/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=706&range=00 Stats: 315 lines in 15 files changed: 176 ins; 93 del; 46 mod Patch: https://git.openjdk.org/babylon/pull/706.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/706/head:pull/706 PR: https://git.openjdk.org/babylon/pull/706 From maurizio.cimadamore at oracle.com Mon Dec 1 10:12:38 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 1 Dec 2025 10:12:38 +0000 Subject: Where does the code model stored in the class file In-Reply-To: References: Message-ID: Hi Nadeesh, the translation strategy has morphed a little... now all the code models are generated into a separate static nested class -- in this case: build/hat-example-mandel-1.0.classes/mandel/Main$$CM.class We did this to limit the size of the generated code by sharing common code patterns among all the code models in a class (see https://git.openjdk.org/babylon/pull/679) Hope this helps Maurizio On 29/11/2025 00:26, nadeesh t v wrote: > Hello, > IIRC some of the talks, ?code models are stored in class files. But > when I have inspected the class file of one of the example > s?from > HAT using *javap*, I have not seen that in the class file. > > javap -c -v build/hat-example-mandel-1.0.classes/mandel/Main.class > > > Have I overlooked the class file or is it not in the class file? > > -- > Thanks and Regards, > Nadeesh TV > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.fumero at oracle.com Mon Dec 1 10:23:06 2025 From: juan.fumero at oracle.com (Juan Jose Fumero Alfonso) Date: Mon, 1 Dec 2025 10:23:06 +0000 Subject: [External] : Re: Babylon building document correction In-Reply-To: References:

Message-ID: On Mon, 1 Dec 2025 17:03:34 GMT, Adam Sotona wrote: >> The current `BytecodeGenerator` implementation assumes that code models have already been lowered before generation. Both `SwitchExpressionOp` and `SwitchStatementOp` with all-constant labels are examples of operations that can be lowered an alternative way, allowing `BytecodeGenerator` to produce more efficient bytecode using `tableswitch` and `lookupswitch` instructions. >> >> The proposed change shifts the responsibility for lowering these operations into the `BytecodeGenerator` itself, enabling selective lowering during bytecode generation. Consequently, `OpBuilder` and `BytecodeGenerator` tests have been updated to avoid invoking the lower transformation step before the `BytecodeGenerator` is called. >> >> A new internal operation, `ConstantLabelSwitchOp`, has been introduced. This acts as an intermediate representation for lowered `SwitchExpressionOp` and `SwitchStatementOp` instances with constant labels. >> >> Lowering of `SwitchExpressionOp` and `SwitchStatementOp` into `ConstantLabelSwitchOp` is also a part of this PR. >> >> This PR also makes minor refinements to the BytecodeGenerator post-processing transformations. > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > test update src/jdk.incubator.code/share/classes/jdk/incubator/code/Block.java line 119: > 117: * @param arguments the target block arguments, a copy will be made as needed. > 118: */ > 119: public Reference(Block target, List arguments) { Why is this made public? ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/706#discussion_r2577896216 From jfumero at openjdk.org Mon Dec 1 17:11:50 2025 From: jfumero at openjdk.org (Juan Fumero) Date: Mon, 1 Dec 2025 17:11:50 GMT Subject: [code-reflection] RFR: [hat] Testing suite - avoid log duplications Message-ID: HAT Testing framework suite - avoid log duplications ------------- Commit messages: - [hat] Testing suite - avoid log duplications Changes: https://git.openjdk.org/babylon/pull/720/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=720&range=00 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/babylon/pull/720.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/720/head:pull/720 PR: https://git.openjdk.org/babylon/pull/720 From asotona at openjdk.org Mon Dec 1 17:12:23 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 1 Dec 2025 17:12:23 GMT Subject: [code-reflection] RFR: BytecodeGenerator cleanup and switch support [v5] In-Reply-To: References:

Message-ID: On Mon, 1 Dec 2025 16:59:07 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> test update > > src/jdk.incubator.code/share/classes/jdk/incubator/code/Block.java line 119: > >> 117: * @param arguments the target block arguments, a copy will be made as needed. >> 118: */ >> 119: public Reference(Block target, List arguments) { > > Why is this made public? @mabbay Do you need a help to fix the `Block.Reference` construction in the `BytecodeGenerator::getLabelsAndTargets`? ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/706#discussion_r2577927582 From asotona at openjdk.org Mon Dec 1 17:18:01 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 1 Dec 2025 17:18:01 GMT Subject: [code-reflection] RFR: BytecodeGenerator cleanup and switch support [v5] In-Reply-To: References:

Message-ID: <-9ej21ELFzj2GgG53VHnzoawcNbf5pHPj6pvQvBKhA0=.7c357255-c4f7-41e3-a26f-b6c95365e78d@github.com> On Wed, 3 Dec 2025 00:22:17 GMT, Adam Sotona wrote: >> The current `BytecodeGenerator` implementation assumes that code models have already been lowered before generation. Both `SwitchExpressionOp` and `SwitchStatementOp` with all-constant labels are examples of operations that can be lowered an alternative way, allowing `BytecodeGenerator` to produce more efficient bytecode using `tableswitch` and `lookupswitch` instructions. >> >> The proposed change shifts the responsibility for lowering these operations into the `BytecodeGenerator` itself, enabling selective lowering during bytecode generation. Consequently, `OpBuilder` and `BytecodeGenerator` tests have been updated to avoid invoking the lower transformation step before the `BytecodeGenerator` is called. >> >> A new internal operation, `ConstantLabelSwitchOp`, has been introduced. This acts as an intermediate representation for lowered `SwitchExpressionOp` and `SwitchStatementOp` instances with constant labels. >> >> Lowering of `SwitchExpressionOp` and `SwitchStatementOp` into `ConstantLabelSwitchOp` is also a part of this PR. >> >> Lowering of `BreakOp`, `SwitchFallthroughOp` and nested switches will be implemented in a follow-up PR. >> >> This PR also makes minor refinements to the BytecodeGenerator post-processing transformations. > > Adam Sotona has updated the pull request incrementally with two additional commits since the last revision: > > - Generalize the lower transform > - Keep switch cases in the same order as in source code src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/impl/LoweringTransform.java line 101: > 99: yield b; > 100: } > 101: case Lowerable lop -> lop.lower(b, null); Nested bodies should be lowered using this lowering transformation. src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java line 2148: > 2146: } > 2147: > 2148: public record BranchTarget(Block.Builder breakBlock, Block.Builder continueBlock) { This forms a new public API. Implementation code worth to internally share across the module and tests must be moved to a non-public package. The other option is to copy/paste. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/706#discussion_r2583883219 PR Review Comment: https://git.openjdk.org/babylon/pull/706#discussion_r2583879326 From mabbay at openjdk.org Wed Dec 3 10:03:59 2025 From: mabbay at openjdk.org (Mourad Abbay) Date: Wed, 3 Dec 2025 10:03:59 GMT Subject: [code-reflection] RFR: BytecodeGenerator cleanup and switch support [v10] In-Reply-To: <-9ej21ELFzj2GgG53VHnzoawcNbf5pHPj6pvQvBKhA0=.7c357255-c4f7-41e3-a26f-b6c95365e78d@github.com> References:

Message-ID: <4nw6EV85OOJbhVhHRoMvseK1aWNxFNSYWzIepvi0vCo=.7da73169-b239-4089-9f79-5d8bce008205@github.com> On Wed, 3 Dec 2025 13:57:21 GMT, Juan Fumero wrote: >> This PR introduces the type [`bfloat16`](https://cloud.google.com/blog/products/ai-machine-learning/bfloat16-the-secret-to-high-performance-on-cloud-tpus) for HAT. >> >> Testing for OpenCL: >> >> >> HAT=SHOW_CODE java -cp hat/job.jar hat.java test ffi-opencl hat.test.TestBFloat16Type >> >> >> Testing for CUDA: >> >> >> HAT=SHOW_CODE java -cp hat/job.jar hat.java test ffi-cuda hat.test.TestBFloat16Type >> >> >> Some tests are expecting to fail due to precision error. We will need to improve the type conversion with round-to-nearest-even for example. > > Juan Fumero has updated the pull request incrementally with one additional commit since the last revision: > > [hat] bfloat16 codegen refactored hat/core/src/main/java/hat/codebuilders/C99HATKernelBuilder.java line 126: > 124: if (OpTk.isAssignable(buildContext.lookup, javaType, MappableIface.class) && javaType instanceof ClassType classType) { > 125: globalPtrPrefix().suffix_t(classType).asterisk(); > 126: } else if (javaType instanceof ClassType classType && classType.toClassName().equals(F16.class.getCanonicalName())) { Can we leverage OpTk.isAssignable ? or at least avoid string comparisons on Class.getCanonicalName Something like OpTK.isAssignable(lookup, classType, F16.class) ? I think we have access to the lookup in the context... hat/core/src/main/java/hat/codebuilders/HATCodeBuilder.java line 84: > 82: } > 83: > 84: public T suffix_t(Class klass) { Can we compose using existing methods? return suffix_t(class.getSimpleName()); hat/core/src/main/java/hat/codebuilders/HATCodeBuilder.java line 89: > 87: > 88: public T suffix_u(Class klass) { > 89: return identifier(klass.getSimpleName()).identifier("_u"); Same as above ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/716#discussion_r2585272419 PR Review Comment: https://git.openjdk.org/babylon/pull/716#discussion_r2585257810 PR Review Comment: https://git.openjdk.org/babylon/pull/716#discussion_r2585259258 From gfrost at openjdk.org Wed Dec 3 14:14:59 2025 From: gfrost at openjdk.org (Gary Frost) Date: Wed, 3 Dec 2025 14:14:59 GMT Subject: [code-reflection] RFR: [hat] Proposal for bfloat16 [v4] In-Reply-To: <4nw6EV85OOJbhVhHRoMvseK1aWNxFNSYWzIepvi0vCo=.7da73169-b239-4089-9f79-5d8bce008205@github.com> References:

<4nw6EV85OOJbhVhHRoMvseK1aWNxFNSYWzIepvi0vCo=.7da73169-b239-4089-9f79-5d8bce008205@github.com> Message-ID: On Wed, 3 Dec 2025 14:08:37 GMT, Gary Frost wrote: >> Juan Fumero has updated the pull request incrementally with one additional commit since the last revision: >> >> [hat] bfloat16 codegen refactored > > hat/core/src/main/java/hat/codebuilders/C99HATKernelBuilder.java line 126: > >> 124: if (OpTk.isAssignable(buildContext.lookup, javaType, MappableIface.class) && javaType instanceof ClassType classType) { >> 125: globalPtrPrefix().suffix_t(classType).asterisk(); >> 126: } else if (javaType instanceof ClassType classType && classType.toClassName().equals(F16.class.getCanonicalName())) { > > Can we leverage OpTk.isAssignable ? or at least avoid string comparisons on Class.getCanonicalName > > Something like > OpTK.isAssignable(lookup, classType, F16.class) ? > > I think we have access to the lookup in the context... Actually if you check for DeviceType... you might be able to collapse multiple else ifs... here }else if (javaType instanceof ClassType classType && OpTk.isAssignable(javaType,DeviceType.class){ .... generate the typedef ... } ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/716#discussion_r2585283414 From gfrost at openjdk.org Wed Dec 3 14:18:03 2025 From: gfrost at openjdk.org (Gary Frost) Date: Wed, 3 Dec 2025 14:18:03 GMT Subject: [code-reflection] RFR: [hat] Proposal for bfloat16 [v2] In-Reply-To: <9FqDA6u6E-ykzhDTs3cAkijC-vacL7C5EzznxdlDvDs=.d426b224-51b8-4b10-ada5-39a0f2fb6784@github.com> References:

<9FqDA6u6E-ykzhDTs3cAkijC-vacL7C5EzznxdlDvDs=.d426b224-51b8-4b10-ada5-39a0f2fb6784@github.com> Message-ID: On Wed, 3 Dec 2025 13:45:07 GMT, Juan Fumero wrote: >> hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaHATKernelBuilder.java line 334: >> >>> 332: >>> 333: if (f32Mixed == HATF16BinaryOp.LAST_OP) { >>> 334: cparen(); >> >> Looks like separate executaionpaths here can create imbalanced paren? > > The `generateReducedFloatConversionToFloat` already inserts an open parenthesis. I moved it out to make it explicit and avoid confusion. Ah yes, we should avoid having paranthesis imbalances generated by helper methods. Pulling the oparen() (as you did here) out to the top level makes this more explict. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/716#discussion_r2585297758 From jfumero at openjdk.org Wed Dec 3 15:03:48 2025 From: jfumero at openjdk.org (Juan Fumero) Date: Wed, 3 Dec 2025 15:03:48 GMT Subject: [code-reflection] RFR: [hat] Proposal for bfloat16 [v6] In-Reply-To: References: Message-ID: > This PR introduces the type [`bfloat16`](https://cloud.google.com/blog/products/ai-machine-learning/bfloat16-the-secret-to-high-performance-on-cloud-tpus) for HAT. > > Testing for OpenCL: > > > HAT=SHOW_CODE java -cp hat/job.jar hat.java test ffi-opencl hat.test.TestBFloat16Type > > > Testing for CUDA: > > > HAT=SHOW_CODE java -cp hat/job.jar hat.java test ffi-cuda hat.test.TestBFloat16Type > > > Some tests are expecting to fail due to precision error. We will need to improve the type conversion with round-to-nearest-even for example. Juan Fumero has updated the pull request incrementally with one additional commit since the last revision: [hat] DeviceTypes control for the dialect and codegen simplified ------------- Changes: - all: https://git.openjdk.org/babylon/pull/716/files - new: https://git.openjdk.org/babylon/pull/716/files/b5dfe87f..e672cd0f Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=716&range=05 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=716&range=04-05 Stats: 147 lines in 13 files changed: 69 ins; 55 del; 23 mod Patch: https://git.openjdk.org/babylon/pull/716.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/716/head:pull/716 PR: https://git.openjdk.org/babylon/pull/716 From jfumero at openjdk.org Wed Dec 3 15:24:55 2025 From: jfumero at openjdk.org (Juan Fumero) Date: Wed, 3 Dec 2025 15:24:55 GMT Subject: [code-reflection] RFR: [hat] Proposal for bfloat16 [v4] In-Reply-To: References:

When a method is annotated with this annotation, the method becomes reflectable, and all the lambda expressions > 42: * and method references enclosed in it also become reflectable.

> 43: *

When a variable declaration (a field, or a local variable) is annotated with this annotation, all the methods, lambda expressions What does it mean "all the methods" in the context of an initializer expression? ------------- PR Review: https://git.openjdk.org/babylon/pull/726#pullrequestreview-3541427985 PR Review Comment: https://git.openjdk.org/babylon/pull/726#discussion_r2590172871 From psandoz at openjdk.org Thu Dec 4 18:48:11 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 4 Dec 2025 18:48:11 GMT Subject: [code-reflection] RFR: Make @Reflect a use-site annotation In-Reply-To: References:

Message-ID: On Thu, 4 Dec 2025 13:39:06 GMT, Maurizio Cimadamore wrote: >> In the current iteration of compiler support there are two ways to make a lambda reflectable: >> 1. cast the lambda to a type that is annotated with the `@Reflect` annotation (use-site) >> 2. pass the lambda to a functional interface whose declaration is annotated with `@Reflect` (decl-site) >> >> While (2) is handy in cases where the library wants to control reflectability of the lambdas it receives, this model is too weak and insecure, as it might lead to unknowing clients exposing private impl details with frameworks using code reflection. >> >> For this reason, we have revamped the `@Reflect` annotation to control, at the use-site, which program elements should support code reflection: >> >> * If a method is annotated with `@Reflect`, the method itself is reflectable, and all the lambdas it contains are reflectable; >> * If a field/local variable is annotated with `@Reflect`, all the lambdas that occur inside the initializer (if present), are reflectable; >> * If a cast type is annotated with `@Reflect` and the cast is applied to a lambda expression, that lambda expression is reflectable (this is the same as (1) above). >> >> This means it's no longer possible for a library to create a reflectable functional interface, like: >> >> >> @Reflect >> interface ReflectableRunnable extends Runnable { } >> >> >> And unilaterally decide, for _all_ clients whether their lambdas should be reflectable. >> >> To be clear, this is **not** how things will work longer term, but it's an interim step which provides the desired level of safety w/o requiring the additional language features. >> >> I've fixed all tests. I've tried to simplify both javac and JDK tests by dropping redundant functional interface declarations. >> >> I also fixed all the samples; for ONNX some tweaks were done, and I've decided to drop the OnnxFunction -- and to use a supplier instead. But if that's not desirable I can change back (or it can be changed back later). >> >> I also fixed HAT tests -- in that case it was a bit trickier, as there's lots of tests that end up passing reflectable lambdas to the HAT's compute method. Luckily, all these tests are annotated with `@HatTest`, so I've simply added an extra `@Reflect` to any such test method. Since `@Reflect` now propagates to the body, this guarantees that all the lambdas inside these test methods are treated as reflectable. >> >> Of course these HAT change end up enabling reflection for a lot more than it's required. I'll leave it to people more expert wi... > > src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java line 1499: > >> 1497: JavaType fiType = typeToTypeElement(tree.target); >> 1498: // build functional lambda >> 1499: Op lambdaOp = JavaOp.lambda(fiType, stack.body, true); > > Note: now _all_ lambdas we encounter when scanning a reflectable body are (by definition) quotable. This means that in several tests, the `isQuotable` attribute now shows up as `true` everywhere. And, in the JDK bytecode tests there is no longer a way to test that support for non-reflectable lambdas works correctly (so I dropped some tests there). Yes, if needed we could add something separately that built an explicit model (or transform an existing model, dropping the quoted property from lambda ops). ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/726#discussion_r2590104614 From duke at openjdk.org Thu Dec 4 18:59:45 2025 From: duke at openjdk.org (Ruby Chen) Date: Thu, 4 Dec 2025 18:59:45 GMT Subject: [code-reflection] RFR: ModuleOp generation from LambdaOp and FuncOp [v6] In-Reply-To: References: Message-ID: > Add support for generating a ModuleOp from either a LambdaOp or a FuncOp. The given LambdaOp will be converted into the root FuncOp, and the given FuncOp will be assigned as the root FuncOp. > > For `CoreOp.ModuleOp.ofLambdaOp()`, a unique name for the new root FuncOp must be passed as a parameter. Ruby Chen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - Merge branch 'openjdk:code-reflection' into module-op-support - Add tests - Merge branch 'openjdk:code-reflection' into module-op-support - removing commented code - Suggested changes - Merge branch 'openjdk:code-reflection' into module-op-support - Merge branch 'openjdk:code-reflection' into module-op-support - Update src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/core/CoreOp.java Co-authored-by: Paul Sandoz - ModuleOp generation from LambdaOp and FuncOp ------------- Changes: - all: https://git.openjdk.org/babylon/pull/691/files - new: https://git.openjdk.org/babylon/pull/691/files/ad4bc853..4654c480 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=691&range=05 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=691&range=04-05 Stats: 1616 lines in 29 files changed: 1322 ins; 201 del; 93 mod Patch: https://git.openjdk.org/babylon/pull/691.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/691/head:pull/691 PR: https://git.openjdk.org/babylon/pull/691 From mcimadamore at openjdk.org Thu Dec 4 19:26:20 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 4 Dec 2025 19:26:20 GMT Subject: [code-reflection] RFR: Make @Reflect a use-site annotation [v2] In-Reply-To: References: Message-ID: > In the current iteration of compiler support there are two ways to make a lambda reflectable: > 1. cast the lambda to a type that is annotated with the `@Reflect` annotation (use-site) > 2. pass the lambda to a functional interface whose declaration is annotated with `@Reflect` (decl-site) > > While (2) is handy in cases where the library wants to control reflectability of the lambdas it receives, this model is too weak and insecure, as it might lead to unknowing clients exposing private impl details with frameworks using code reflection. > > For this reason, we have revamped the `@Reflect` annotation to control, at the use-site, which program elements should support code reflection: > > * If a method is annotated with `@Reflect`, the method itself is reflectable, and all the lambdas it contains are reflectable; > * If a field/local variable is annotated with `@Reflect`, all the lambdas that occur inside the initializer (if present), are reflectable; > * If a cast type is annotated with `@Reflect` and the cast is applied to a lambda expression, that lambda expression is reflectable (this is the same as (1) above). > > This means it's no longer possible for a library to create a reflectable functional interface, like: > > > @Reflect > interface ReflectableRunnable extends Runnable { } > > > And unilaterally decide, for _all_ clients whether their lambdas should be reflectable. > > To be clear, this is **not** how things will work longer term, but it's an interim step which provides the desired level of safety w/o requiring the additional language features. > > I've fixed all tests. I've tried to simplify both javac and JDK tests by dropping redundant functional interface declarations. > > I also fixed all the samples; for ONNX some tweaks were done, and I've decided to drop the OnnxFunction -- and to use a supplier instead. But if that's not desirable I can change back (or it can be changed back later). > > I also fixed HAT tests -- in that case it was a bit trickier, as there's lots of tests that end up passing reflectable lambdas to the HAT's compute method. Luckily, all these tests are annotated with `@HatTest`, so I've simply added an extra `@Reflect` to any such test method. Since `@Reflect` now propagates to the body, this guarantees that all the lambdas inside these test methods are treated as reflectable. > > Of course these HAT change end up enabling reflection for a lot more than it's required. I'll leave it to people more expert with HAT to clean that up, if needed. > In the meantime, it was ... Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Fix javadoc - Fix HAT examples ------------- Changes: - all: https://git.openjdk.org/babylon/pull/726/files - new: https://git.openjdk.org/babylon/pull/726/files/11112ad9..5d2db31d Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=726&range=01 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=726&range=00-01 Stats: 75 lines in 21 files changed: 40 ins; 1 del; 34 mod Patch: https://git.openjdk.org/babylon/pull/726.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/726/head:pull/726 PR: https://git.openjdk.org/babylon/pull/726 From psandoz at openjdk.org Thu Dec 4 19:26:21 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 4 Dec 2025 19:26:21 GMT Subject: [code-reflection] RFR: Make @Reflect a use-site annotation [v2] In-Reply-To: References:

Message-ID: On Thu, 4 Dec 2025 19:22:31 GMT, Maurizio Cimadamore wrote: >> In the current iteration of compiler support there are two ways to make a lambda reflectable: >> 1. cast the lambda to a type that is annotated with the `@Reflect` annotation (use-site) >> 2. pass the lambda to a functional interface whose declaration is annotated with `@Reflect` (decl-site) >> >> While (2) is handy in cases where the library wants to control reflectability of the lambdas it receives, this model is too weak and insecure, as it might lead to unknowing clients exposing private impl details with frameworks using code reflection. >> >> For this reason, we have revamped the `@Reflect` annotation to control, at the use-site, which program elements should support code reflection: >> >> * If a method is annotated with `@Reflect`, the method itself is reflectable, and all the lambdas it contains are reflectable; >> * If a field/local variable is annotated with `@Reflect`, all the lambdas that occur inside the initializer (if present), are reflectable; >> * If a cast type is annotated with `@Reflect` and the cast is applied to a lambda expression, that lambda expression is reflectable (this is the same as (1) above). >> >> This means it's no longer possible for a library to create a reflectable functional interface, like: >> >> >> @Reflect >> interface ReflectableRunnable extends Runnable { } >> >> >> And unilaterally decide, for _all_ clients whether their lambdas should be reflectable. >> >> To be clear, this is **not** how things will work longer term, but it's an interim step which provides the desired level of safety w/o requiring the additional language features. >> >> I've fixed all tests. I've tried to simplify both javac and JDK tests by dropping redundant functional interface declarations. >> >> I also fixed all the samples; for ONNX some tweaks were done, and I've decided to drop the OnnxFunction -- and to use a supplier instead. But if that's not desirable I can change back (or it can be changed back later). >> >> I also fixed HAT tests -- in that case it was a bit trickier, as there's lots of tests that end up passing reflectable lambdas to the HAT's compute method. Luckily, all these tests are annotated with `@HatTest`, so I've simply added an extra `@Reflect` to any such test method. Since `@Reflect` now propagates to the body, this guarantees that all the lambdas inside these test methods are treated as reflectable. >> >> Of course these HAT change end up enabling reflection for a lot more than it's required. I'll leave it to people more expert wi... > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - Fix javadoc > - Fix HAT examples Marked as reviewed by psandoz (Lead). ------------- PR Review: https://git.openjdk.org/babylon/pull/726#pullrequestreview-3541700718 From mcimadamore at openjdk.org Thu Dec 4 19:26:22 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 4 Dec 2025 19:26:22 GMT Subject: [code-reflection] RFR: Make @Reflect a use-site annotation [v2] In-Reply-To: <_XMkvZTvpBA16m9VtdVDAdh-wgDKU5arIQNnG0NaxXc=.df17569f-167d-4c35-ac0a-4e97679c139a@github.com> References: <_XMkvZTvpBA16m9VtdVDAdh-wgDKU5arIQNnG0NaxXc=.df17569f-167d-4c35-ac0a-4e97679c139a@github.com> Message-ID: <5ON4qTfZbTcuw6eCnNCnXpEcNPc8wjT5aE6nHeg2nA8=.2b29c1da-d706-4bd9-8125-741a48542fdc@github.com> On Thu, 4 Dec 2025 18:41:00 GMT, Paul Sandoz wrote: >> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix javadoc >> - Fix HAT examples > > src/jdk.incubator.code/share/classes/jdk/incubator/code/Reflect.java line 43: > >> 41: *

When a method is annotated with this annotation, the method becomes reflectable, and all the lambda expressions >> 42: * and method references enclosed in it also become reflectable.

>> 43: *