From mcimadamore at openjdk.org Tue Jul 1 09:04:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 1 Jul 2025 09:04:54 GMT Subject: [code-reflection] RFR: Cleanup compiler code gen In-Reply-To: <9LK_t3iWyxNkof1cBSOVdUC-cc3AuhYd9WVQqk3NSJQ=.68fc582f-0ab7-4a2e-9a11-88bb5b6cd73f@github.com> References: <9LK_t3iWyxNkof1cBSOVdUC-cc3AuhYd9WVQqk3NSJQ=.68fc582f-0ab7-4a2e-9a11-88bb5b6cd73f@github.com> Message-ID: On Fri, 27 Jun 2025 22:56:19 GMT, Paul Sandoz wrote: > Remove option for storing the model as text now the alternative is stable (retain the enum for when we experiment with further kinds of encoding). > > Change the code extracting the Quoted instance from a structurally quoted lambda to not use the interpreter. Nice! ------------- PR Review: https://git.openjdk.org/babylon/pull/471#pullrequestreview-2974348086 From psandoz at openjdk.org Tue Jul 1 15:44:16 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 1 Jul 2025 15:44:16 GMT Subject: git: openjdk/babylon: code-reflection: Move OpDeclaration to internal package Message-ID: <32410b6e-37db-43aa-a23a-d4ad2cb68e59@openjdk.org> Changeset: 0285a976 Branch: code-reflection Author: Paul Sandoz Date: 2025-07-01 15:41:36 +0000 URL: https://git.openjdk.org/babylon/commit/0285a976c2c56360633dbc835c000f6368b57a19 Move OpDeclaration to internal package ! cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OpGen.java ! cr-examples/onnx/opgen/src/main/java/oracle/code/onnx/opgen/OperatorGen.java ! cr-examples/onnx/src/main/java/oracle/code/onnx/ir/ExplicitOnnxOps.java ! cr-examples/onnx/src/main/java/oracle/code/onnx/ir/OnnxOps.java + cr-examples/onnx/src/main/java/oracle/code/onnx/ir/OpFactoryHelper.java ! cr-examples/onnx/src/test/java/oracle/code/onnx/proto/OnnxModelTest.java - cr-examples/onnx/src/test/java/oracle/code/onnx/proto/OpFactoryHelper.java ! cr-examples/triton/src/main/java/oracle/code/triton/ArithMathOps.java ! cr-examples/triton/src/main/java/oracle/code/triton/OpFactoryHelper.java ! cr-examples/triton/src/main/java/oracle/code/triton/SCFOps.java ! cr-examples/triton/src/main/java/oracle/code/triton/TritonOps.java ! cr-examples/triton/src/main/java/oracle/code/triton/TritonTestOps.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/SlotOp.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/core/CoreOp.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/extern/OpFactory.java + src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/OpDeclaration.java ! test/jdk/java/lang/reflect/code/anf/AnfDialect.java From psandoz at openjdk.org Tue Jul 1 15:44:03 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 1 Jul 2025 15:44:03 GMT Subject: [code-reflection] Integrated: Move OpDeclaration to internal package In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 21:41:05 GMT, Paul Sandoz wrote: > Move OpDeclaration to internal package This pull request has now been integrated. Changeset: 0285a976 Author: Paul Sandoz URL: https://git.openjdk.org/babylon/commit/0285a976c2c56360633dbc835c000f6368b57a19 Stats: 778 lines in 18 files changed: 231 ins; 170 del; 377 mod Move OpDeclaration to internal package ------------- PR: https://git.openjdk.org/babylon/pull/475 From psandoz at openjdk.org Tue Jul 1 17:09:32 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 1 Jul 2025 17:09:32 GMT Subject: [code-reflection] RFR: Remove Java prefix from Java ops Message-ID: Remove Java prefix from Java ops as in `Java.IfOp` rather than `Java.JavaIfOp`. Rename op factory methods that use an `_` prefix (because the name is a Java keyword) to use a `_` postfix (like the ClassFile API). ------------- Commit messages: - HAT updates - Update examples - Remove Java prefix from Java ops. Changes: https://git.openjdk.org/babylon/pull/476/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=476&range=00 Stats: 548 lines in 44 files changed: 2 ins; 7 del; 539 mod Patch: https://git.openjdk.org/babylon/pull/476.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/476/head:pull/476 PR: https://git.openjdk.org/babylon/pull/476 From psandoz at openjdk.org Tue Jul 1 17:12:25 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 1 Jul 2025 17:12:25 GMT Subject: git: openjdk/babylon: code-reflection: Remove Java prefix from Java ops Message-ID: <11a9769f-ecf4-4a05-b984-1251bed4b8c2@openjdk.org> Changeset: aa6d615d Branch: code-reflection Author: Paul Sandoz Date: 2025-07-01 17:10:11 +0000 URL: https://git.openjdk.org/babylon/commit/aa6d615d4f54d2e1a3994277ef098e0bc75cffbf Remove Java prefix from Java ops ! cr-examples/onnx/src/main/java/oracle/code/onnx/compiler/OnnxTransformer.java ! cr-examples/onnx/src/test/java/oracle/code/onnx/CNNTest.java ! cr-examples/onnx/src/test/java/oracle/code/onnx/proto/OnnxModelTest.java ! cr-examples/triton/src/main/java/oracle/code/triton/SimpleCountedForLoopInfo.java ! cr-examples/triton/src/main/java/oracle/code/triton/TritonTransformer.java ! hat/core/src/main/java/hat/OpsAndTypes.java ! hat/core/src/main/java/hat/backend/codebuilders/HATCodeBuilderWithContext.java ! hat/core/src/main/java/hat/optools/ForOpWrapper.java ! hat/core/src/main/java/hat/optools/IfOpWrapper.java ! hat/core/src/main/java/hat/optools/JavaBreakOpWrapper.java ! hat/core/src/main/java/hat/optools/JavaContinueOpWrapper.java ! hat/core/src/main/java/hat/optools/JavaLabeledOpWrapper.java ! hat/core/src/main/java/hat/optools/OpWrapper.java ! hat/core/src/main/java/hat/optools/TernaryOpWrapper.java ! hat/core/src/main/java/hat/optools/WhileOpWrapper.java ! hat/examples/experiments/src/main/java/experiments/LayoutExample.java ! hat/examples/experiments/src/main/java/experiments/QuotedTest.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Block.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Quoted.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/StringConcatTransformer.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/BytecodeLift.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/core/CoreOp.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/OpBuilder.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java ! test/jdk/java/lang/reflect/code/TestBlockIndexes.java ! test/jdk/java/lang/reflect/code/TestBlockParameters.java ! test/jdk/java/lang/reflect/code/TestBuild.java ! test/jdk/java/lang/reflect/code/TestClosureOps.java ! test/jdk/java/lang/reflect/code/TestDominate.java ! test/jdk/java/lang/reflect/code/TestExceptionRegionOps.java ! test/jdk/java/lang/reflect/code/TestInline.java ! test/jdk/java/lang/reflect/code/TestLambdaOps.java ! test/jdk/java/lang/reflect/code/TestLinqUsingQuoted.java ! test/jdk/java/lang/reflect/code/TestPrimitiveTypePatterns.java ! test/jdk/java/lang/reflect/code/ad/ForwardDifferentiation.java ! test/jdk/java/lang/reflect/code/anf/AnfTransformer.java ! test/jdk/java/lang/reflect/code/bytecode/TestSlotOps.java ! test/jdk/java/lang/reflect/code/linq/Queryable.java ! test/jdk/java/lang/reflect/code/linq/TestQueryProvider.java ! test/jdk/java/lang/reflect/code/parser/TestParse.java ! test/jdk/java/lang/reflect/code/stream/StreamFuser.java ! test/jdk/java/lang/reflect/code/stream/StreamFuserUsingQuotable.java ! test/langtools/tools/javac/reflect/CodeReflectionTester.java From psandoz at openjdk.org Tue Jul 1 17:12:50 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 1 Jul 2025 17:12:50 GMT Subject: [code-reflection] Integrated: Remove Java prefix from Java ops In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 16:27:07 GMT, Paul Sandoz wrote: > Remove Java prefix from Java ops as in `Java.IfOp` rather than `Java.JavaIfOp`. > > Rename op factory methods that use an `_` prefix (because the name is a Java keyword) to use a `_` postfix (like the ClassFile API). This pull request has now been integrated. Changeset: aa6d615d Author: Paul Sandoz URL: https://git.openjdk.org/babylon/commit/aa6d615d4f54d2e1a3994277ef098e0bc75cffbf Stats: 548 lines in 44 files changed: 2 ins; 7 del; 539 mod Remove Java prefix from Java ops ------------- PR: https://git.openjdk.org/babylon/pull/476 From asotona at openjdk.org Wed Jul 2 16:14:45 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 2 Jul 2025 16:14:45 GMT Subject: [code-reflection] RFR: Onnx Record to tuple types conversion moved to TypeConverter Message-ID: + detection of constant arrays - removal of ArrayLen annotation ------------- Commit messages: - imports cleanup - Record to tuple types conversion moved to TypeConverter Changes: https://git.openjdk.org/babylon/pull/477/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=477&range=00 Stats: 506 lines in 5 files changed: 290 ins; 170 del; 46 mod Patch: https://git.openjdk.org/babylon/pull/477.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/477/head:pull/477 PR: https://git.openjdk.org/babylon/pull/477 From asotona at openjdk.org Thu Jul 3 09:25:14 2025 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 3 Jul 2025 09:25:14 GMT Subject: [code-reflection] RFR: Onnx Record to tuple types conversion moved to TypeConverter [v2] In-Reply-To: References: Message-ID: > + detection of constant arrays > - removal of ArrayLen annotation Adam Sotona 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 four additional commits since the last revision: - removed debug outputs - Merge remote-tracking branch 'babylon/code-reflection' into onnx-type-convertor - imports cleanup - Record to tuple types conversion moved to TypeConverter + detection of constant arrays - removal of ArrayLen annotation ------------- Changes: - all: https://git.openjdk.org/babylon/pull/477/files - new: https://git.openjdk.org/babylon/pull/477/files/cb5e4be4..956695d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=477&range=01 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=477&range=00-01 Stats: 1311 lines in 60 files changed: 233 ins; 180 del; 898 mod Patch: https://git.openjdk.org/babylon/pull/477.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/477/head:pull/477 PR: https://git.openjdk.org/babylon/pull/477 From asotona at openjdk.org Thu Jul 3 14:11:13 2025 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 3 Jul 2025 14:11:13 GMT Subject: [code-reflection] RFR: Onnx Record to tuple types conversion moved to TypeConverter [v3] In-Reply-To: References: Message-ID: > + detection of constant arrays > - removal of ArrayLen annotation Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: TensorDataStream work in progress ------------- Changes: - all: https://git.openjdk.org/babylon/pull/477/files - new: https://git.openjdk.org/babylon/pull/477/files/956695d1..4c706633 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=477&range=02 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=477&range=01-02 Stats: 12 lines in 1 file changed: 10 ins; 1 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/477.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/477/head:pull/477 PR: https://git.openjdk.org/babylon/pull/477 From asotona at openjdk.org Thu Jul 3 16:52:16 2025 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 3 Jul 2025 16:52:16 GMT Subject: [code-reflection] RFR: Onnx Record to tuple types conversion moved to TypeConverter [v4] In-Reply-To: References: Message-ID: > + detection of constant arrays > - removal of ArrayLen annotation Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: PartialEvaluator skipping lambdas ------------- Changes: - all: https://git.openjdk.org/babylon/pull/477/files - new: https://git.openjdk.org/babylon/pull/477/files/4c706633..cba39837 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=477&range=03 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=477&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/477.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/477/head:pull/477 PR: https://git.openjdk.org/babylon/pull/477 From psandoz at openjdk.org Thu Jul 3 16:55:43 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 3 Jul 2025 16:55:43 GMT Subject: [code-reflection] RFR: Block.Reference implements CodeItem Message-ID: <9DNPtHhclFeWZyEdjr4oswOke_OMQpevkKTTP84upN0=.e2da001c-735b-4eb4-bb58-e26ea3657c4e@github.com> `Block.Reference` implements `CodeItem`, thereby all items in a code model share the same top type. ------------- Commit messages: - Block.Reference implements CodeItem. Changes: https://git.openjdk.org/babylon/pull/478/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=478&range=00 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/babylon/pull/478.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/478/head:pull/478 PR: https://git.openjdk.org/babylon/pull/478 From psandoz at openjdk.org Thu Jul 3 17:11:34 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 3 Jul 2025 17:11:34 GMT Subject: git: openjdk/babylon: code-reflection: Block.Reference implements CodeItem Message-ID: <0eed9280-183b-4748-965c-7e8f994b3f18@openjdk.org> Changeset: 03e030d4 Branch: code-reflection Author: Paul Sandoz Date: 2025-07-03 17:08:50 +0000 URL: https://git.openjdk.org/babylon/commit/03e030d4d80f71f76418e61b2b42017130f1375a Block.Reference implements CodeItem ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Block.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/CodeItem.java From psandoz at openjdk.org Thu Jul 3 17:11:54 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 3 Jul 2025 17:11:54 GMT Subject: [code-reflection] Integrated: Block.Reference implements CodeItem In-Reply-To: <9DNPtHhclFeWZyEdjr4oswOke_OMQpevkKTTP84upN0=.e2da001c-735b-4eb4-bb58-e26ea3657c4e@github.com> References: <9DNPtHhclFeWZyEdjr4oswOke_OMQpevkKTTP84upN0=.e2da001c-735b-4eb4-bb58-e26ea3657c4e@github.com> Message-ID: <9UFPwd6lRPBnkQAc7ixPQlJXQglRtebazYit2txO5Ww=.3e2af615-b22f-4d9b-9b57-003e00ad976c@github.com> On Thu, 3 Jul 2025 16:50:10 GMT, Paul Sandoz wrote: > `Block.Reference` implements `CodeItem`, thereby all items in a code model share the same top type. This pull request has now been integrated. Changeset: 03e030d4 Author: Paul Sandoz URL: https://git.openjdk.org/babylon/commit/03e030d4d80f71f76418e61b2b42017130f1375a Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Block.Reference implements CodeItem ------------- PR: https://git.openjdk.org/babylon/pull/478 From gfrost at openjdk.org Sat Jul 5 10:46:56 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 5 Jul 2025 10:46:56 GMT Subject: [code-reflection] RFR: Sync with babylon changes and moved/renamed dirs for consistency Message-ID: This PR syncs with Babyon changes. Mostly from the HAT side this is a bunch of project/dir renames/moves to maintain a consistent pattern across the project. I added a new tools project. Here I plan on adding some of the tooling that I use to debug. Previously this was in core. Now core depende on tools. Move a few things out from core (into tools) which were unused by hat libs and apps. They will be used by incomming tooling. ------------- Commit messages: - Sync with upstream babylon changes and moved/renamed dirs for consistency" Changes: https://git.openjdk.org/babylon/pull/480/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=480&range=00 Stats: 991 lines in 100 files changed: 361 ins; 421 del; 209 mod Patch: https://git.openjdk.org/babylon/pull/480.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/480/head:pull/480 PR: https://git.openjdk.org/babylon/pull/480 From gfrost at openjdk.org Sat Jul 5 10:59:42 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 5 Jul 2025 10:59:42 GMT Subject: git: openjdk/babylon: code-reflection: Sync with babylon changes and moved/renamed dirs for consistency Message-ID: <8513747b-5ef0-4586-90ad-08f9f0331404@openjdk.org> Changeset: 66660319 Branch: code-reflection Author: Gary Frost Date: 2025-07-05 10:58:30 +0000 URL: https://git.openjdk.org/babylon/commit/666603190a5d58537a26b97f6f39ebe9f1564a70 Sync with babylon changes and moved/renamed dirs for consistency ! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaHATKernelBuilder.java ! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/PTXHATKernelBuilder.java ! hat/backends/ffi/opencl/src/main/java/hat/backend/ffi/OpenCLHATKernelBuilder.java ! hat/backends/ffi/shared/src/main/java/hat/backend/ffi/C99FFIBackend.java ! hat/backends/ffi/shared/src/main/java/hat/backend/ffi/Config.java ! hat/backends/jextracted/opencl/src/main/java/hat/backend/jextracted/OpenCLHatKernelBuilder.java ! hat/backends/jextracted/shared/src/main/java/hat/backend/jextracted/C99JExtractedBackend.java ! hat/core/src/main/java/hat/buffer/SchemaBuilder.java = hat/core/src/main/java/hat/codebuilders/C99HATComputeBuilder.java = hat/core/src/main/java/hat/codebuilders/C99HATKernelBuilder.java = hat/core/src/main/java/hat/codebuilders/CodeBuilder.java = hat/core/src/main/java/hat/codebuilders/HATCodeBuilder.java = hat/core/src/main/java/hat/codebuilders/HATCodeBuilderWithContext.java = hat/core/src/main/java/hat/codebuilders/TextBuilder.java ! hat/examples/experiments/src/main/java/experiments/RawLayout.java ! hat/examples/heal/pom.xml ! hat/examples/life/pom.xml ! hat/examples/mandel/pom.xml ! hat/examples/nbody/pom.xml ! hat/examples/nbody/src/main/java/nbody/Main.java ! hat/examples/nbody/src/main/java/nbody/NBodyGLWindow.java ! hat/examples/nbody/src/main/java/nbody/opencl/OpenCLNBodyGLWindow.java ! hat/examples/pom.xml = hat/examples/shared/pom.xml = hat/examples/shared/src/main/java/hat/util/ui/SevenSegmentDisplay.java ! hat/examples/violajones/pom.xml ! hat/hat/bld.java ! hat/hat/clean.java ! hat/hat/run.java ! hat/intellij/.idea/compiler.xml ! hat/intellij/.idea/modules.xml - hat/intellij/.idea/uiDesigner.xml ! hat/intellij/.idea/vcs.xml ! hat/intellij/backend_jextracted_opencl.iml - hat/intellij/blackscholes.iml - hat/intellij/chess.iml - hat/intellij/clwrap.iml - hat/intellij/cuwrap.iml + hat/intellij/example_blackscholes.iml = hat/intellij/example_experiments.iml = hat/intellij/example_heal.iml + hat/intellij/example_life.iml + hat/intellij/example_mandel.iml + hat/intellij/example_nbody.iml + hat/intellij/example_shared.iml + hat/intellij/example_squares.iml + hat/intellij/example_violajones.iml - hat/intellij/glwrap.iml - hat/intellij/life.iml - hat/intellij/mandel.iml - hat/intellij/nbody.iml + hat/intellij/notes.md - hat/intellij/squares.iml + hat/intellij/tools.iml - hat/intellij/view.iml - hat/intellij/violajones.iml - hat/intellij/wrap.iml + hat/intellij/wrap_cuda.iml + hat/intellij/wrap_opencl.iml + hat/intellij/wrap_opengl.iml + hat/intellij/wrap_shared.iml ! hat/pom.xml = hat/tools/pom.xml = hat/tools/src/main/java/hat/opcodebuilders/OpCodeBuilder.java = hat/tools/src/main/java/hat/opcodebuilders/StyledOpCodeBuilder.java = hat/tools/src/main/java/hat/text/JavaCodeBuilder.java = hat/tools/src/main/java/hat/text/TerminalColors.java + hat/tools/src/main/java/hat/tools/Tool.java = hat/wraps/cuda/pom.xml = hat/wraps/opencl/pom.xml = hat/wraps/opencl/src/main/java/wrap/opencl/CLPlatform.java = hat/wraps/opencl/src/main/java/wrap/opencl/CLStatusPtr.java = hat/wraps/opencl/src/main/java/wrap/opencl/CLWrapComputeContext.java = hat/wraps/opencl/src/main/java/wrap/opencl/Squares.java = hat/wraps/opengl/pom.xml = hat/wraps/opengl/src/main/java/wrap/opengl/Fonts.java = hat/wraps/opengl/src/main/java/wrap/opengl/GLCallbackEventHandler.java = hat/wraps/opengl/src/main/java/wrap/opengl/GLEventHandler.java = hat/wraps/opengl/src/main/java/wrap/opengl/GLFuncEventHandler.java = hat/wraps/opengl/src/main/java/wrap/opengl/GLStatusPtr.java = hat/wraps/opengl/src/main/java/wrap/opengl/GLTexture.java = hat/wraps/opengl/src/main/java/wrap/opengl/GLWindow.java ! hat/wraps/pom.xml = hat/wraps/shared/pom.xml = hat/wraps/shared/src/main/java/wrap/ArenaHolder.java = hat/wraps/shared/src/main/java/wrap/LayoutBuilder.java = hat/wraps/shared/src/main/java/wrap/Scalar.java = hat/wraps/shared/src/main/java/wrap/Sequence.java = hat/wraps/shared/src/main/java/wrap/Wrap.java From gfrost at openjdk.org Sat Jul 5 11:01:10 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 5 Jul 2025 11:01:10 GMT Subject: [code-reflection] RFR: Sync with babylon changes and moved/renamed dirs for consistency [v2] In-Reply-To: References: Message-ID: <83uXoa_8sstDKVB3Y5tYP_q7hz1pa3rU0iYwZugvQ9o=.6894b890-df63-4010-8856-ee2ebaad4e42@github.com> > This PR syncs with Babyon changes. > > Mostly from the HAT side this is a bunch of project/dir renames/moves to maintain a consistent pattern across the project. > > I added a new tools project. Here I plan on adding some of the tooling that I use to debug. Previously this was in core. > > Now core depende on tools. > > Move a few things out from core (into tools) which were unused by hat libs and apps. They will be used by incomming tooling. Gary Frost has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge code-reflection - Sync with upstream babylon changes and moved/renamed dirs for consistency" ------------- Changes: https://git.openjdk.org/babylon/pull/480/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=480&range=01 Stats: 948 lines in 89 files changed: 360 ins; 416 del; 172 mod Patch: https://git.openjdk.org/babylon/pull/480.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/480/head:pull/480 PR: https://git.openjdk.org/babylon/pull/480 From gfrost at openjdk.org Sat Jul 5 11:01:10 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 5 Jul 2025 11:01:10 GMT Subject: [code-reflection] Integrated: Sync with babylon changes and moved/renamed dirs for consistency In-Reply-To: References: Message-ID: On Sat, 5 Jul 2025 10:40:08 GMT, Gary Frost wrote: > This PR syncs with Babyon changes. > > Mostly from the HAT side this is a bunch of project/dir renames/moves to maintain a consistent pattern across the project. > > I added a new tools project. Here I plan on adding some of the tooling that I use to debug. Previously this was in core. > > Now core depende on tools. > > Move a few things out from core (into tools) which were unused by hat libs and apps. They will be used by incomming tooling. This pull request has now been integrated. Changeset: 66660319 Author: Gary Frost URL: https://git.openjdk.org/babylon/commit/666603190a5d58537a26b97f6f39ebe9f1564a70 Stats: 948 lines in 89 files changed: 360 ins; 416 del; 172 mod Sync with babylon changes and moved/renamed dirs for consistency ------------- PR: https://git.openjdk.org/babylon/pull/480 From gfrost at openjdk.org Sat Jul 5 11:26:31 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 5 Jul 2025 11:26:31 GMT Subject: git: openjdk/babylon: code-reflection: Added example-experiments to hat/bld and maven poms" Message-ID: <4eb953a1-2b10-45bf-94c5-61051c224f98@openjdk.org> Changeset: 298a0960 Branch: code-reflection Author: Gary Frost Date: 2025-07-05 11:24:31 +0000 URL: https://git.openjdk.org/babylon/commit/298a09605d065e8408856e12cbb3c202d377ba4e Added example-experiments to hat/bld and maven poms" ! hat/examples/experiments/pom.xml ! hat/examples/experiments/src/main/java/experiments/LayoutExample.java ! hat/examples/experiments/src/main/java/experiments/QuotedTest.java ! hat/examples/pom.xml ! hat/hat/bld.java From gfrost at openjdk.org Sat Jul 5 11:27:35 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 5 Jul 2025 11:27:35 GMT Subject: [code-reflection] Integrated: Added example-experiments to hat/bld and maven poms" Message-ID: <_3d8lJXvl00DcQl2949AOOsBC3TWrVwiL6LfQ2VBCEs=.99f8c6f2-46cb-4db3-99e4-d482a3c88f0e@github.com> Added the experiments dir to build system. Both the maven and hat/bld versions Note : recent changes have broken nbody (opengl wrapper) looking at it now ------------- Commit messages: - Added example-experiments to hat/bld and maven poms" Changes: https://git.openjdk.org/babylon/pull/481/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=481&range=00 Stats: 29 lines in 5 files changed: 13 ins; 4 del; 12 mod Patch: https://git.openjdk.org/babylon/pull/481.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/481/head:pull/481 PR: https://git.openjdk.org/babylon/pull/481 From gfrost at openjdk.org Sat Jul 5 11:27:35 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 5 Jul 2025 11:27:35 GMT Subject: [code-reflection] Integrated: Added example-experiments to hat/bld and maven poms" In-Reply-To: <_3d8lJXvl00DcQl2949AOOsBC3TWrVwiL6LfQ2VBCEs=.99f8c6f2-46cb-4db3-99e4-d482a3c88f0e@github.com> References: <_3d8lJXvl00DcQl2949AOOsBC3TWrVwiL6LfQ2VBCEs=.99f8c6f2-46cb-4db3-99e4-d482a3c88f0e@github.com> Message-ID: On Sat, 5 Jul 2025 11:23:02 GMT, Gary Frost wrote: > Added the experiments dir to build system. Both the maven and hat/bld versions > > Note : recent changes have broken nbody (opengl wrapper) looking at it now This pull request has now been integrated. Changeset: 298a0960 Author: Gary Frost URL: https://git.openjdk.org/babylon/commit/298a09605d065e8408856e12cbb3c202d377ba4e Stats: 29 lines in 5 files changed: 13 ins; 4 del; 12 mod Added example-experiments to hat/bld and maven poms" ------------- PR: https://git.openjdk.org/babylon/pull/481 From gfrost at openjdk.org Sat Jul 5 11:56:28 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 5 Jul 2025 11:56:28 GMT Subject: git: openjdk/babylon: code-reflection: Sadly opengl wrap had hardcoded package name this is fixed now Message-ID: Changeset: 36cec9f6 Branch: code-reflection Author: Gary Frost Date: 2025-07-05 11:55:13 +0000 URL: https://git.openjdk.org/babylon/commit/36cec9f6265f6db155555dc7c6d73b19f9bed63c Sadly opengl wrap had hardcoded package name this is fixed now ! hat/wraps/opengl/src/main/java/wrap/opengl/GLWindow.java From gfrost at openjdk.org Sat Jul 5 11:58:42 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 5 Jul 2025 11:58:42 GMT Subject: [code-reflection] Integrated: Sadly opengl wrap had hardcoded package name this is fixed now Message-ID: Extracted OpenGL used by wrap_opengl differs between linux anbd mac. We need to 'exclude' one source file when we build each. The wrapper code was trying to do this reflectively. Sadly it had hardcoded expected path for classes to look for. This broke when I moved the classes from 'wrap.glwrap' to 'wrap.opengl' to be consistent with other projects. This PR fixes this. This comment is way larger than the fix ;) ------------- Commit messages: - Sadly opengl wrap had hardcoded package name this is fixed now Changes: https://git.openjdk.org/babylon/pull/482/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=482&range=00 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/babylon/pull/482.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/482/head:pull/482 PR: https://git.openjdk.org/babylon/pull/482 From gfrost at openjdk.org Sat Jul 5 11:58:42 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 5 Jul 2025 11:58:42 GMT Subject: [code-reflection] Integrated: Sadly opengl wrap had hardcoded package name this is fixed now In-Reply-To: References: Message-ID: On Sat, 5 Jul 2025 11:53:54 GMT, Gary Frost wrote: > Extracted OpenGL used by wrap_opengl differs between linux anbd mac. We need to 'exclude' one source file when we build each. > The wrapper code was trying to do this reflectively. Sadly it had hardcoded expected path for classes to look for. > > This broke when I moved the classes from 'wrap.glwrap' to 'wrap.opengl' to be consistent with other projects. > > This PR fixes this. > > This comment is way larger than the fix ;) This pull request has now been integrated. Changeset: 36cec9f6 Author: Gary Frost URL: https://git.openjdk.org/babylon/commit/36cec9f6265f6db155555dc7c6d73b19f9bed63c Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Sadly opengl wrap had hardcoded package name this is fixed now ------------- PR: https://git.openjdk.org/babylon/pull/482 From gfrost at openjdk.org Sun Jul 6 05:15:23 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sun, 6 Jul 2025 05:15:23 GMT Subject: git: openjdk/babylon: code-reflection: renamed pom artifacts to align with docs and java @hat/bld Message-ID: <82fd0f53-071f-4bbb-b96b-c97dbd6588a9@openjdk.org> Changeset: d50ac7ea Branch: code-reflection Author: Gary Frost Date: 2025-07-06 05:13:00 +0000 URL: https://git.openjdk.org/babylon/commit/d50ac7ea345d6a32935b39711f5bb34561cf415e renamed pom artifacts to align with docs and java @hat/bld ! hat/backends/ffi/cuda/pom.xml ! hat/backends/ffi/hip/pom.xml ! hat/backends/ffi/mock/pom.xml ! hat/backends/ffi/opencl/pom.xml ! hat/backends/ffi/pom.xml ! hat/backends/ffi/shared/pom.xml ! hat/backends/ffi/spirv/pom.xml ! hat/backends/java/mt/pom.xml ! hat/backends/java/pom.xml ! hat/backends/java/seq/pom.xml ! hat/backends/pom.xml ! hat/core/pom.xml ! hat/examples/blackscholes/pom.xml ! hat/examples/experiments/pom.xml ! hat/examples/heal/pom.xml ! hat/examples/life/pom.xml ! hat/examples/mandel/pom.xml ! hat/examples/nbody/pom.xml ! hat/examples/pom.xml ! hat/examples/shared/pom.xml ! hat/examples/squares/pom.xml ! hat/examples/violajones/pom.xml ! hat/hat/bld.java ! hat/hat/run.java ! hat/tools/pom.xml ! hat/wraps/cuda/pom.xml ! hat/wraps/opencl/pom.xml ! hat/wraps/opengl/pom.xml From gfrost at openjdk.org Sun Jul 6 05:17:05 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sun, 6 Jul 2025 05:17:05 GMT Subject: [code-reflection] Integrated: renamed pom artifacts to align with docs and java @hat/bld Message-ID: Make the pom artifact names align with the docs and `java @hat/bld` targets. ------------- Commit messages: - renamed pom artifacts to align with docs and java @hat/bld Changes: https://git.openjdk.org/babylon/pull/483/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=483&range=00 Stats: 38 lines in 28 files changed: 5 ins; 0 del; 33 mod Patch: https://git.openjdk.org/babylon/pull/483.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/483/head:pull/483 PR: https://git.openjdk.org/babylon/pull/483 From gfrost at openjdk.org Sun Jul 6 05:17:05 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sun, 6 Jul 2025 05:17:05 GMT Subject: [code-reflection] Integrated: renamed pom artifacts to align with docs and java @hat/bld In-Reply-To: References: Message-ID: On Sun, 6 Jul 2025 05:11:27 GMT, Gary Frost wrote: > Make the pom artifact names align with the docs and `java @hat/bld` targets. This pull request has now been integrated. Changeset: d50ac7ea Author: Gary Frost URL: https://git.openjdk.org/babylon/commit/d50ac7ea345d6a32935b39711f5bb34561cf415e Stats: 38 lines in 28 files changed: 5 ins; 0 del; 33 mod renamed pom artifacts to align with docs and java @hat/bld ------------- PR: https://git.openjdk.org/babylon/pull/483 From gfrost at openjdk.org Mon Jul 7 08:53:52 2025 From: gfrost at openjdk.org (Gary Frost) Date: Mon, 7 Jul 2025 08:53:52 GMT Subject: git: openjdk/babylon: code-reflection: We can now build jextracted artifacts from maven Message-ID: <3a7d1048-8002-4b36-90ad-c8f68b45c3c8@openjdk.org> Changeset: 0466f705 Branch: code-reflection Author: Gary Frost Date: 2025-07-07 08:51:28 +0000 URL: https://git.openjdk.org/babylon/commit/0466f705abcfcf30cd503a91cd16b1b15226576d We can now build jextracted artifacts from maven ! hat/extractions/cuda/pom.xml ! hat/extractions/opencl/pom.xml ! hat/extractions/opengl/pom.xml ! hat/extractions/pom.xml - hat/hat/Hat.java - hat/hat/Job.java ! hat/hat/bld.java - hat/hat/debug - hat/hat/run-ffi-opencl-life - hat/hat/run-java - hat/hat/run-opencl ! hat/hat/run.java - hat/hat/tst ! hat/pom.xml ! hat/wraps/cuda/pom.xml ! hat/wraps/opencl/pom.xml ! hat/wraps/opengl/pom.xml From gfrost at openjdk.org Mon Jul 7 08:54:23 2025 From: gfrost at openjdk.org (Gary Frost) Date: Mon, 7 Jul 2025 08:54:23 GMT Subject: [code-reflection] Integrated: We can now build jextracted artifacts from maven Message-ID: Previously maven coould not extract opencl/opengl or cuda. Mainly because I had no idea how to get maven to 'generate code' and then build. I moved the cmake invoke from each subdir `extractions/[cuda|opencl|opnegl]/pom.xml` to the common parent and finally discovered how to get each child pom to not duplicate the build. So now mvn -e clean compile package install -Popencl,opengl And java @hat/bld Create the same artifacts ------------- Commit messages: - We can now build jextracted artifacts from maven Changes: https://git.openjdk.org/babylon/pull/484/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=484&range=00 Stats: 1620 lines in 17 files changed: 44 ins; 1502 del; 74 mod Patch: https://git.openjdk.org/babylon/pull/484.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/484/head:pull/484 PR: https://git.openjdk.org/babylon/pull/484 From gfrost at openjdk.org Mon Jul 7 08:54:23 2025 From: gfrost at openjdk.org (Gary Frost) Date: Mon, 7 Jul 2025 08:54:23 GMT Subject: [code-reflection] Integrated: We can now build jextracted artifacts from maven In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 08:48:20 GMT, Gary Frost wrote: > Previously maven coould not extract opencl/opengl or cuda. Mainly because I had no idea how to get maven to 'generate code' and then build. > > I moved the cmake invoke from each subdir `extractions/[cuda|opencl|opnegl]/pom.xml` to the common parent and finally discovered how to get each child pom to not duplicate the build. > > So now > > mvn -e clean compile package install -Popencl,opengl > > > And > > > java @hat/bld > > > Create the same artifacts This pull request has now been integrated. Changeset: 0466f705 Author: Gary Frost URL: https://git.openjdk.org/babylon/commit/0466f705abcfcf30cd503a91cd16b1b15226576d Stats: 1620 lines in 17 files changed: 44 ins; 1502 del; 74 mod We can now build jextracted artifacts from maven ------------- PR: https://git.openjdk.org/babylon/pull/484 From gfrost at openjdk.org Mon Jul 7 09:06:21 2025 From: gfrost at openjdk.org (Gary Frost) Date: Mon, 7 Jul 2025 09:06:21 GMT Subject: git: openjdk/babylon: code-reflection: Missed a project rename in hat/bld.java Message-ID: Changeset: 10754b70 Branch: code-reflection Author: Gary Frost Date: 2025-07-07 09:05:10 +0000 URL: https://git.openjdk.org/babylon/commit/10754b7094d1f6c4c38251262b4706013719889a Missed a project rename in hat/bld.java ! hat/hat/bld.java From gfrost at openjdk.org Mon Jul 7 09:08:36 2025 From: gfrost at openjdk.org (Gary Frost) Date: Mon, 7 Jul 2025 09:08:36 GMT Subject: [code-reflection] Integrated: Missed a project rename in hat/bld.java Message-ID: Whoops. I missed the rename of extraction artifacts in bld.java This is the fix ------------- Commit messages: - Missed a project rename in hat/bld.java Changes: https://git.openjdk.org/babylon/pull/485/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=485&range=00 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/babylon/pull/485.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/485/head:pull/485 PR: https://git.openjdk.org/babylon/pull/485 From gfrost at openjdk.org Mon Jul 7 09:08:36 2025 From: gfrost at openjdk.org (Gary Frost) Date: Mon, 7 Jul 2025 09:08:36 GMT Subject: [code-reflection] Integrated: Missed a project rename in hat/bld.java In-Reply-To: References: Message-ID: <8Lvx5_4MhKXo5xiR-qSS_r9s-TeDQEQGS3lQgsg8y-w=.d7b09f0d-a59c-4b6e-b4d7-56f84c31f5ff@github.com> On Mon, 7 Jul 2025 09:02:36 GMT, Gary Frost wrote: > Whoops. I missed the rename of extraction artifacts in bld.java > > This is the fix This pull request has now been integrated. Changeset: 10754b70 Author: Gary Frost URL: https://git.openjdk.org/babylon/commit/10754b7094d1f6c4c38251262b4706013719889a Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Missed a project rename in hat/bld.java ------------- PR: https://git.openjdk.org/babylon/pull/485 From asotona at openjdk.org Mon Jul 7 14:44:57 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 7 Jul 2025 14:44:57 GMT Subject: [code-reflection] Integrated: Onnx Record to tuple types conversion moved to TypeConverter In-Reply-To: References: Message-ID: <1Stah-_N4jgjjYd0Ct5dvWIf6Mz7HR59D6ZDuRDeWDg=.0e5138de-52a5-49d5-b469-2f3ced3ea827@github.com> On Wed, 2 Jul 2025 16:09:08 GMT, Adam Sotona wrote: > - detection of constant arrays > - removal of ArrayLen annotation > - TensorDataStream improvements > - PartialEvaluator fix of lambda support This pull request has now been integrated. Changeset: f9b500a4 Author: Adam Sotona URL: https://git.openjdk.org/babylon/commit/f9b500a4e0d5de0d3c9573ff89a6f564290d1a8f Stats: 516 lines in 7 files changed: 297 ins; 171 del; 48 mod Onnx Record to tuple types conversion moved to TypeConverter ------------- PR: https://git.openjdk.org/babylon/pull/477 From asotona at openjdk.org Mon Jul 7 14:45:27 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 7 Jul 2025 14:45:27 GMT Subject: git: openjdk/babylon: code-reflection: Onnx Record to tuple types conversion moved to TypeConverter Message-ID: Changeset: f9b500a4 Branch: code-reflection Author: Adam Sotona Date: 2025-07-07 14:42:24 +0000 URL: https://git.openjdk.org/babylon/commit/f9b500a4e0d5de0d3c9573ff89a6f564290d1a8f Onnx Record to tuple types conversion moved to TypeConverter ! cr-examples/onnx/src/main/java/oracle/code/onnx/ExplicitOnnxOperators.java ! cr-examples/onnx/src/main/java/oracle/code/onnx/OnnxRuntime.java ! cr-examples/onnx/src/main/java/oracle/code/onnx/compiler/OnnxTransformer.java ! cr-examples/onnx/src/main/java/oracle/code/onnx/compiler/PartialEvaluator.java + cr-examples/onnx/src/main/java/oracle/code/onnx/compiler/TypeConvertor.java ! cr-examples/onnx/src/main/java/oracle/code/onnx/genai/TensorDataStream.java ! cr-examples/onnx/src/test/java/oracle/code/onnx/SimpleTest.java From mcimadamore at openjdk.org Mon Jul 7 15:06:13 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Jul 2025 15:06:13 GMT Subject: [code-reflection] RFR: Issue errors when quotable constructs are found inside inner classes Message-ID: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> This PR adds check in `ReflectMethods` to issue errors when quotable methods, lambdas, method references are found inside an inner class. This includes member inner classes, local and anonymous inner classes, but static inner classes (sometimes referred to as *nested classes*) are ok. The issue is that if we allowed code reflection in these places, we would need to come up with uniform treatment for compiler-generated captured symbols. Currently `ReflectMethods` just allows method in an inner class to refer to a variable or a method in the enclosing class freely. While this is correct from a source code perspective, by the time we translate to bytecode, such references are no longer possible, and are typically mediated by compiler-generated symbols such as `this$0`. So, instead of generating a code model that might be unreliable, it is better, for now, to just disallow such cases. In principle, we should just "skip over" code elements we cannot support, and generate bytecode as usual. Indeed this is where I started, but then I realized that the support for lambda conversion into `Quoted` does not make sense unless we enable code reflection (as there's no real functional interface target we can use there). For this reason, an error is generated instead. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/babylon/pull/486/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=486&range=00 Stats: 164 lines in 7 files changed: 74 ins; 30 del; 60 mod Patch: https://git.openjdk.org/babylon/pull/486.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/486/head:pull/486 PR: https://git.openjdk.org/babylon/pull/486 From gfrost at openjdk.org Mon Jul 7 16:02:01 2025 From: gfrost at openjdk.org (Gary Frost) Date: Mon, 7 Jul 2025 16:02:01 GMT Subject: git: openjdk/babylon: code-reflection: Added a Java code builder Message-ID: Changeset: 89759a4c Branch: code-reflection Author: Gary Frost Date: 2025-07-07 15:58:12 +0000 URL: https://git.openjdk.org/babylon/commit/89759a4c16964c0f07e5450f405621c4d6737b1a Added a Java code builder ! hat/core/src/main/java/hat/codebuilders/HATCodeBuilderWithContext.java ! hat/intellij/.idea/compiler.xml ! hat/intellij/backend_jextracted_opencl.iml ! hat/intellij/example_nbody.iml ! hat/intellij/wrap_opencl.iml ! hat/intellij/wrap_opengl.iml = hat/tools/src/main/java/hat/codebuilders/OpCodeBuilder.java = hat/tools/src/main/java/hat/codebuilders/StyledOpCodeBuilder.java From gfrost at openjdk.org Mon Jul 7 16:01:38 2025 From: gfrost at openjdk.org (Gary Frost) Date: Mon, 7 Jul 2025 16:01:38 GMT Subject: [code-reflection] Integrated: Added a Java code builder Message-ID: I have some tooling to visualize code models when converted to C99, I figured we should have one that converts bacl to java source. So fernflowery style. This is not in core but in the news tools project (where I plan on adding some of the more useful tools I have collected) ------------- Commit messages: - Added a Java code builder so we can show what a code model looks like when converted back to Java Changes: https://git.openjdk.org/babylon/pull/487/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=487&range=00 Stats: 30 lines in 8 files changed: 2 ins; 15 del; 13 mod Patch: https://git.openjdk.org/babylon/pull/487.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/487/head:pull/487 PR: https://git.openjdk.org/babylon/pull/487 From gfrost at openjdk.org Mon Jul 7 16:01:39 2025 From: gfrost at openjdk.org (Gary Frost) Date: Mon, 7 Jul 2025 16:01:39 GMT Subject: [code-reflection] Integrated: Added a Java code builder In-Reply-To: References: Message-ID: <0jJ1v1McaOrIyB6bG1fnDlzRL9r3KFfyt4Gzv6aiHWs=.36125db9-9606-430f-95fd-1099c68b6fcd@github.com> On Mon, 7 Jul 2025 15:55:48 GMT, Gary Frost wrote: > I have some tooling to visualize code models when converted to C99, I figured we should have one that converts bacl to java source. > > So fernflowery style. > > This is not in core but in the news tools project (where I plan on adding some of the more useful tools I have collected) This pull request has now been integrated. Changeset: 89759a4c Author: Gary Frost URL: https://git.openjdk.org/babylon/commit/89759a4c16964c0f07e5450f405621c4d6737b1a Stats: 30 lines in 8 files changed: 2 ins; 15 del; 13 mod Added a Java code builder ------------- PR: https://git.openjdk.org/babylon/pull/487 From psandoz at openjdk.org Mon Jul 7 20:32:07 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 7 Jul 2025 20:32:07 GMT Subject: [code-reflection] RFR: CodeElement ancestor functionality Message-ID: Declare common ancestor methods on `CodeElement`. This enables more uniform traversal up the tree of code elements and querying of ancestors. The expression `e.ancestorOp().ancestorOp()` will first traverse up the code model tree from `e` to the nearest ancestor operation and then traverse again to the subsequent nearest ancestor operation, both skipping intermediate block and body elements. The first traversal can start from any kind of code element. The methods `ancestor{Op, Body, Block}` are currently implemented as default methods. While the implementations are simple it is easy to make mistakes handling unbound or root operations. They can be more directly implemented in a follow on PR. ------------- Commit messages: - Cleanup. - Doc updates. - Adjust isAncestorOf. Add test. - Update examples. - Merge remote-tracking branch 'upstream/code-reflection' into ancestor - Uses. Add CodeElement.isAncestorOf. - Unify ancestor functionality on CodeElement. Changes: https://git.openjdk.org/babylon/pull/479/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=479&range=00 Stats: 518 lines in 32 files changed: 326 ins; 112 del; 80 mod Patch: https://git.openjdk.org/babylon/pull/479.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/479/head:pull/479 PR: https://git.openjdk.org/babylon/pull/479 From psandoz at openjdk.org Mon Jul 7 20:57:54 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 7 Jul 2025 20:57:54 GMT Subject: [code-reflection] RFR: Issue errors when quotable constructs are found inside inner classes In-Reply-To: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> References: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> Message-ID: On Mon, 7 Jul 2025 15:01:34 GMT, Maurizio Cimadamore wrote: > This PR adds check in `ReflectMethods` to issue errors when quotable methods, lambdas, method references are found inside an inner class. This includes member inner classes, local and anonymous inner classes, but static inner classes (sometimes referred to as *nested classes*) are ok. > > The issue is that if we allowed code reflection in these places, we would need to come up with uniform treatment for compiler-generated captured symbols. > Currently `ReflectMethods` just allows method in an inner class to refer to a variable or a method in the enclosing class freely. While this is correct from a source code perspective, by the time we translate to bytecode, such references are no longer possible, and are typically mediated by compiler-generated symbols such as `this$0`. > > So, instead of generating a code model that might be unreliable, it is better, for now, to just disallow such cases. > > In principle, we should just "skip over" code elements we cannot support, and generate bytecode as usual. Indeed this is where I started, but then I realized that the support for lambda conversion into `Quoted` does not make sense unless we enable code reflection (as there's no real functional interface target we can use there). For this reason, an error is generated instead. Marked as reviewed by psandoz (Lead). I agree it is best to currently disable code reflection for such cases. I don't think the model is correct, as per the design, because the outer class is not referenced correctly e.g.: class Inner { @CodeReflection public void f() { TestInner.this.m(); m(); } } void m() { } func @"f" (%0 : java.type:"TestInner::Inner")java.type:"void" -> { invoke %0 @java.ref:"TestInner::m():void"; invoke %0 @java.ref:"TestInner::m():void"; return @loc="16:9"; }; So we cannot even interpret the invoke operations correctly using reflective method invocation as their operand is not of the correct type. A correct model might be: func @"f" (%0 : java.type:"TestInner", %1 : java.type:"TestInner::Inner")java.type:"void" -> { invoke %0 @java.ref:"TestInner::m():void"; invoke %0 @java.ref:"TestInner::m():void"; return @loc="16:9"; }; ``` How feasible would it be to, eventually, do this? ------------- PR Review: https://git.openjdk.org/babylon/pull/486#pullrequestreview-2995254651 PR Comment: https://git.openjdk.org/babylon/pull/486#issuecomment-3046496081 From mcimadamore at openjdk.org Mon Jul 7 21:18:47 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Jul 2025 21:18:47 GMT Subject: [code-reflection] RFR: Issue errors when quotable constructs are found inside inner classes In-Reply-To: References: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> Message-ID: On Mon, 7 Jul 2025 20:54:57 GMT, Paul Sandoz wrote: > > A correct model might be: > > ``` > func @"f" (%0 : java.type:"TestInner", %1 : java.type:"TestInner::Inner")java.type:"void" -> { > invoke %0 @java.ref:"TestInner::m():void"; > invoke %0 @java.ref:"TestInner::m():void"; > return @loc="16:9"; > }; > ``` > > How feasible would it be to, eventually, do this? Yes, this is what should come out (and there's a similar issue for variables that are "captured" -- e.g. a method in a local class can capture additional local variables that do not show up in the method. That said, this translation is not 100% true to how all Java compilers I know handle this. The enclosing `this` (or local variables captured by a local class) is *not* an additional parameter of the method. They are instead stored in the inner class instance and accessed when needed. In other words, except for the constructor of the inner class (which does get extra parameters), the signature of every other method is left unchanged. So, it is not even clear the above model is what we want -- I can imagine something like that being quite tricky to "lower" into bytecode. ------------- PR Comment: https://git.openjdk.org/babylon/pull/486#issuecomment-3046540342 From mcimadamore at openjdk.org Mon Jul 7 21:18:48 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Jul 2025 21:18:48 GMT Subject: [code-reflection] RFR: Issue errors when quotable constructs are found inside inner classes In-Reply-To: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> References: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> Message-ID: <88qVDsQELSTg7KH4VZK6X7bD_U8UFqCFBIqayH2sbb8=.203bccce-6bdd-4c1a-8de8-33a8ecaad904@github.com> On Mon, 7 Jul 2025 15:01:34 GMT, Maurizio Cimadamore wrote: > This PR adds check in `ReflectMethods` to issue errors when quotable methods, lambdas, method references are found inside an inner class. This includes member inner classes, local and anonymous inner classes, but static inner classes (sometimes referred to as *nested classes*) are ok. > > The issue is that if we allowed code reflection in these places, we would need to come up with uniform treatment for compiler-generated captured symbols. > Currently `ReflectMethods` just allows method in an inner class to refer to a variable or a method in the enclosing class freely. While this is correct from a source code perspective, by the time we translate to bytecode, such references are no longer possible, and are typically mediated by compiler-generated symbols such as `this$0`. > > So, instead of generating a code model that might be unreliable, it is better, for now, to just disallow such cases. > > In principle, we should just "skip over" code elements we cannot support, and generate bytecode as usual. Indeed this is where I started, but then I realized that the support for lambda conversion into `Quoted` does not make sense unless we enable code reflection (as there's no real functional interface target we can use there). For this reason, an error is generated instead. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4288: > 4286: {2} > 4287: > 4288: # 0: symbol, 1: symbol, 2: string these "skip" diagnostics are a leftover from when we did not support all possible AST nodes. Since we should now support everything, I've removed this. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/486#discussion_r2191023921 From mcimadamore at openjdk.org Mon Jul 7 21:22:53 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Jul 2025 21:22:53 GMT Subject: [code-reflection] RFR: Issue errors when quotable constructs are found inside inner classes In-Reply-To: References: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> Message-ID: On Mon, 7 Jul 2025 21:14:55 GMT, Maurizio Cimadamore wrote: > How feasible would it be to, eventually, do this? To reply more directly to your question: we already have code to generate a model like that -- when we generate a model for quotable lambdas, we add extra parameters to the model to map enclosing `this` (where available) as well as any captured vars. We could do exactly the same for any method declared inside an inner class. In terms of code we can do it -- but this wouldn't model the semantics of the code eventually generated by javac (perhaps this become clearer when thinking about how such an approach would scale to model the _constructor_ of an inner class). ------------- PR Comment: https://git.openjdk.org/babylon/pull/486#issuecomment-3046556052 From psandoz at openjdk.org Mon Jul 7 21:55:54 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 7 Jul 2025 21:55:54 GMT Subject: [code-reflection] RFR: Issue errors when quotable constructs are found inside inner classes In-Reply-To: References: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> Message-ID: <9bdE6nDT1YbLc-UR5s79vrcLT8oVhVi7OqlZLOzoWGU=.f0629611-7e0b-47db-9f91-7848d0ca5158@github.com> On Mon, 7 Jul 2025 21:20:33 GMT, Maurizio Cimadamore wrote: > > How feasible would it be to, eventually, do this? > > To reply more directly to your question: we already have code to generate a model like that -- when we generate a model for quotable lambdas, we add extra parameters to the model to map enclosing `this` (where available) as well as any captured vars. We could do exactly the same for any method declared inside an inner class. In terms of code we can do it -- but this wouldn't model the semantics of the code eventually generated by javac (perhaps this become clearer when thinking about how such an approach would scale to model the _constructor_ of an inner class). We are in effect extracting out something from its surrounding context and representing it as an isolated function whose parameters provide the context. Arguably modeling of instance methods is doing just that, as well quotable lambdas you point out, so we could do more of this and it would not look so out of place. (Similarly so for constructors when taking a functional view.) In this respect do we need to stick closely to the bytecode that javac generates? Interpreting or generating bytecode and executing would require the user passing the contextual arguments. (More broadly when generating bytecode and executing we have to also supply access control context and set things up appropriately. I seem to recall some difficulties around that, but the details escape me right now.) ------------- PR Comment: https://git.openjdk.org/babylon/pull/486#issuecomment-3046616758 From psandoz at openjdk.org Mon Jul 7 22:51:00 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 7 Jul 2025 22:51:00 GMT Subject: [code-reflection] RFR: Reduce Op writing to text methods. Message-ID: Reduce the methods on op for writing to text down to one, `toText`. Ensure all other functionality is located on `OpWriter`. ------------- Commit messages: - Reduce Op writing to text methods. Changes: https://git.openjdk.org/babylon/pull/488/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=488&range=00 Stats: 291 lines in 53 files changed: 24 ins; 49 del; 218 mod Patch: https://git.openjdk.org/babylon/pull/488.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/488/head:pull/488 PR: https://git.openjdk.org/babylon/pull/488 From mcimadamore at openjdk.org Tue Jul 8 10:07:53 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Jul 2025 10:07:53 GMT Subject: [code-reflection] RFR: Reduce Op writing to text methods. In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 22:46:41 GMT, Paul Sandoz wrote: > Reduce the methods on op for writing to text down to one, `toText`. Ensure all other functionality is located on `OpWriter`. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/babylon/pull/488#pullrequestreview-2996899950 From mcimadamore at openjdk.org Tue Jul 8 10:20:02 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Jul 2025 10:20:02 GMT Subject: [code-reflection] RFR: Issue errors when quotable constructs are found inside inner classes In-Reply-To: <9bdE6nDT1YbLc-UR5s79vrcLT8oVhVi7OqlZLOzoWGU=.f0629611-7e0b-47db-9f91-7848d0ca5158@github.com> References: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> <9bdE6nDT1YbLc-UR5s79vrcLT8oVhVi7OqlZLOzoWGU=.f0629611-7e0b-47db-9f91-7848d0ca5158@github.com> Message-ID: On Mon, 7 Jul 2025 21:53:00 GMT, Paul Sandoz wrote: > In this respect do we need to stick closely to the bytecode that javac generates? > > Interpreting or generating bytecode and executing would require the user passing the contextual arguments. (More broadly when generating bytecode and executing we have to also supply access control context and set things up appropriately. I seem to recall some difficulties around that, but the details escape me right now.) The main issue I see with this is that when you generate bytecode, now you have to: 1. emit synthetic fields storing `this$0` and, possibly captured values 2. remove all the synthetic parameters from the model 3. replace access to the now-removed synthetic parameters with access to the synthetic fields IMHO all the steps above are fairly tricky. Even computing the full set of synthetic field an inner class has is probably going to be tricky, as you will have to look at _all_ the instance method of the class, and look at all the synthetic parameters, and come up with some kind of "set of captures". Not sure how you compare captures from different instance methods. Not even sure how you can tell something *is* a synthetic parameter. To make this more feasible, I think some kind of parameter metadata is the bare minimum. But even if we had that metadata, (2) and (3) are still a lot of work. I think it would be somehow better if we could model the array of captures as a single entity -- say we have a fictional class called `CapturedValues` (this might be a core type?). Then, the above would become: func @"f" (%0 : CapturedValues, %1 : java.type:"TestInner::Inner")java.type:"void" -> { %2: load %0 CapturedValue::encl_this invoke %2 @java.ref:"TestInner::m():void"; invoke %2 @java.ref:"TestInner::m():void"; return @loc="16:9"; }; And, a constructor of an inner class is a constructor that accepts captured parameters, and writes them into the leading `CapturedValues` object (also passed as parameter). Adjusting this code is still tricky, as you still need to do (2) and (3) -- but since access to all captured state is mediated by "imaginary" fields in the `CapturedValues` "class", it is easier for a processor to understand which is which? ------------- PR Comment: https://git.openjdk.org/babylon/pull/486#issuecomment-3048280706 From mcimadamore at openjdk.org Tue Jul 8 10:40:35 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Jul 2025 10:40:35 GMT Subject: git: openjdk/babylon: code-reflection: Issue errors when quotable constructs are found inside inner classes Message-ID: <048c01b4-a202-4e2e-b63e-2ac2c17f1470@openjdk.org> Changeset: 815098b0 Branch: code-reflection Author: Maurizio Cimadamore Date: 2025-07-08 10:38:27 +0000 URL: https://git.openjdk.org/babylon/commit/815098b04e3960eb9ef5df1343968ce22401beed Issue errors when quotable constructs are found inside inner classes Reviewed-by: psandoz ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java ! test/langtools/tools/javac/diags/examples.not-yet.txt + test/langtools/tools/javac/reflect/TestNoCodeReflectionInInnerClasses.java + test/langtools/tools/javac/reflect/TestNoCodeReflectionInInnerClasses.out ! test/langtools/tools/javac/reflect/quoted/TestCaptureQuotable.java ! test/langtools/tools/javac/reflect/quoted/TestCaptureQuoted.java From mcimadamore at openjdk.org Tue Jul 8 10:41:06 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Jul 2025 10:41:06 GMT Subject: [code-reflection] Integrated: Issue errors when quotable constructs are found inside inner classes In-Reply-To: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> References: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> Message-ID: On Mon, 7 Jul 2025 15:01:34 GMT, Maurizio Cimadamore wrote: > This PR adds check in `ReflectMethods` to issue errors when quotable methods, lambdas, method references are found inside an inner class. This includes member inner classes, local and anonymous inner classes, but static inner classes (sometimes referred to as *nested classes*) are ok. > > The issue is that if we allowed code reflection in these places, we would need to come up with uniform treatment for compiler-generated captured symbols. > Currently `ReflectMethods` just allows method in an inner class to refer to a variable or a method in the enclosing class freely. While this is correct from a source code perspective, by the time we translate to bytecode, such references are no longer possible, and are typically mediated by compiler-generated symbols such as `this$0`. > > So, instead of generating a code model that might be unreliable, it is better, for now, to just disallow such cases. > > In principle, we should just "skip over" code elements we cannot support, and generate bytecode as usual. Indeed this is where I started, but then I realized that the support for lambda conversion into `Quoted` does not make sense unless we enable code reflection (as there's no real functional interface target we can use there). For this reason, an error is generated instead. This pull request has now been integrated. Changeset: 815098b0 Author: Maurizio Cimadamore URL: https://git.openjdk.org/babylon/commit/815098b04e3960eb9ef5df1343968ce22401beed Stats: 164 lines in 7 files changed: 74 ins; 30 del; 60 mod Issue errors when quotable constructs are found inside inner classes Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/babylon/pull/486 From mcimadamore at openjdk.org Tue Jul 8 12:12:34 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Jul 2025 12:12:34 GMT Subject: [code-reflection] RFR: Disallow `null` return expressions in quoted lambdas Message-ID: Lambda expressions that are turned into a `Quoted` instance don't have an associated functional interface. Instead, they are type checked bottom-up (the parameter types in such lambdas must be explicit), and the return type is inferred from the various return expressions in the lambda body. The aim of this patch is to establish a similar set of rules between quoted lambda return expressions and expressions that are allowed on the RHS of a `var`. More specifically, the RHS of a `var` is restricted as follows: 1. can't be `null` 2. can't be a "naked" array initializer, e.g. `{ 1, 2, 3 }` 3. can't be a poly expression (a lambda, or a method reference) Now, (2) and (3) are already taken care of. (2) is not allowed in return context, and (3) is already rejected, given the body of the quoted lambda is attributed w/o a target type. So this PR adds a check for (1), to reject `null` return expressions. There are some other quality-of-life changes to make sure the compiler doesn't generate spurious diagnostics in case of errors. I've beefed up the test a bit. First, I've added tests to make sure that invalid return expressions in quoted lambdas are correctly rejected, regardless of whether the quoted lambda appears in assignment vs. method vs. generic method context. Secondly, I've added an IR test to make sure that the inferred return type of a quoted lambda is correctly upward-projected, to get rid of any non-denotable type that might arise in the inference process. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/babylon/pull/489/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=489&range=00 Stats: 198 lines in 11 files changed: 179 ins; 9 del; 10 mod Patch: https://git.openjdk.org/babylon/pull/489.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/489/head:pull/489 PR: https://git.openjdk.org/babylon/pull/489 From psandoz at openjdk.org Tue Jul 8 15:53:53 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 8 Jul 2025 15:53:53 GMT Subject: [code-reflection] RFR: Disallow `null` return expressions in quoted lambdas In-Reply-To: References: Message-ID: <3l5fM1_8zbGUGroPQribt-hQih5dNLdMuybO3FEKdhM=.deb69177-d794-4b32-8551-c85bf43f8724@github.com> On Tue, 8 Jul 2025 12:07:13 GMT, Maurizio Cimadamore wrote: > Lambda expressions that are turned into a `Quoted` instance don't have an associated functional interface. Instead, they are type checked bottom-up (the parameter types in such lambdas must be explicit), and the return type is inferred from the various return expressions in the lambda body. > > The aim of this patch is to establish a similar set of rules between quoted lambda return expressions and expressions that are allowed on the RHS of a `var`. More specifically, the RHS of a `var` is restricted as follows: > > 1. can't be `null` > 2. can't be a "naked" array initializer, e.g. `{ 1, 2, 3 }` > 3. can't be a poly expression (a lambda, or a method reference) > > Now, (2) and (3) are already taken care of. (2) is not allowed in return context, and (3) is already rejected, given the body of the quoted lambda is attributed w/o a target type. > > So this PR adds a check for (1), to reject `null` return expressions. > > There are some other quality-of-life changes to make sure the compiler doesn't generate spurious diagnostics in case of errors. > > I've beefed up the test a bit. First, I've added tests to make sure that invalid return expressions in quoted lambdas are correctly rejected, regardless of whether the quoted lambda appears in assignment vs. method vs. generic method context. > > Secondly, I've added an IR test to make sure that the inferred return type of a quoted lambda is correctly upward-projected, to get rid of any non-denotable type that might arise in the inference process. Marked as reviewed by psandoz (Lead). ------------- PR Review: https://git.openjdk.org/babylon/pull/489#pullrequestreview-2998232480 From psandoz at openjdk.org Tue Jul 8 15:56:55 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 8 Jul 2025 15:56:55 GMT Subject: [code-reflection] Integrated: Reduce Op writing to text methods. In-Reply-To: References: Message-ID: <5QI39D3XOqHac7Gt83jUBkkqw5Pfq87LQXiFLjyACDo=.e07adb8a-ff2c-4fba-924e-f05b8ad28133@github.com> On Mon, 7 Jul 2025 22:46:41 GMT, Paul Sandoz wrote: > Reduce the methods on op for writing to text down to one, `toText`. Ensure all other functionality is located on `OpWriter`. This pull request has now been integrated. Changeset: 8aa678bf Author: Paul Sandoz URL: https://git.openjdk.org/babylon/commit/8aa678bf2a4429d5a2be797d3102eaf84ac30658 Stats: 291 lines in 53 files changed: 24 ins; 49 del; 218 mod Reduce Op writing to text methods. Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/babylon/pull/488 From psandoz at openjdk.org Tue Jul 8 15:58:01 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 8 Jul 2025 15:58:01 GMT Subject: git: openjdk/babylon: code-reflection: Reduce Op writing to text methods. Message-ID: Changeset: 8aa678bf Branch: code-reflection Author: Paul Sandoz Date: 2025-07-08 15:54:25 +0000 URL: https://git.openjdk.org/babylon/commit/8aa678bf2a4429d5a2be797d3102eaf84ac30658 Reduce Op writing to text methods. Reviewed-by: mcimadamore ! hat/core/src/main/java/hat/backend/DebugBackend.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Op.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/extern/OpWriter.java ! test/jdk/java/lang/reflect/code/CoreBinaryOpsTest.java ! test/jdk/java/lang/reflect/code/TestArrayCreation.java ! test/jdk/java/lang/reflect/code/TestArrayTypes.java ! test/jdk/java/lang/reflect/code/TestBinops.java ! test/jdk/java/lang/reflect/code/TestBlockOp.java ! test/jdk/java/lang/reflect/code/TestBreakContinue.java ! test/jdk/java/lang/reflect/code/TestClosureOps.java ! test/jdk/java/lang/reflect/code/TestConditionalExpression.java ! test/jdk/java/lang/reflect/code/TestConditionalOp.java ! test/jdk/java/lang/reflect/code/TestConstants.java ! test/jdk/java/lang/reflect/code/TestDominate.java ! test/jdk/java/lang/reflect/code/TestEnhancedForOp.java ! test/jdk/java/lang/reflect/code/TestExceptionRegionOps.java ! test/jdk/java/lang/reflect/code/TestForOp.java ! test/jdk/java/lang/reflect/code/TestIfOp.java ! test/jdk/java/lang/reflect/code/TestInline.java ! test/jdk/java/lang/reflect/code/TestInvokeSuper.java ! test/jdk/java/lang/reflect/code/TestLambdaOps.java ! test/jdk/java/lang/reflect/code/TestLinqUsingQuoted.java ! test/jdk/java/lang/reflect/code/TestLocalTransformationsAdaption.java ! test/jdk/java/lang/reflect/code/TestPatterns.java ! test/jdk/java/lang/reflect/code/TestPatterns2.java ! test/jdk/java/lang/reflect/code/TestPrimitiveTypePatterns.java ! test/jdk/java/lang/reflect/code/TestRemoveFinalVars.java ! test/jdk/java/lang/reflect/code/TestSSA.java ! test/jdk/java/lang/reflect/code/TestStringConcatTransform.java ! test/jdk/java/lang/reflect/code/TestTry.java ! test/jdk/java/lang/reflect/code/TestTryFinally.java ! test/jdk/java/lang/reflect/code/TestTryNested.java ! test/jdk/java/lang/reflect/code/TestUninitializedVariable.java ! test/jdk/java/lang/reflect/code/TestUsesDependsOn.java ! test/jdk/java/lang/reflect/code/TestWhileOp.java ! test/jdk/java/lang/reflect/code/ad/TestForwardAutoDiff.java ! test/jdk/java/lang/reflect/code/bytecode/TestArrayCreation.java ! test/jdk/java/lang/reflect/code/bytecode/TestBytecode.java ! test/jdk/java/lang/reflect/code/bytecode/TestInvokeSuper.java ! test/jdk/java/lang/reflect/code/bytecode/TestLiftCustomBytecode.java ! test/jdk/java/lang/reflect/code/bytecode/TestLiftExample.java ! test/jdk/java/lang/reflect/code/bytecode/TestNestedCapturingLambda.java ! test/jdk/java/lang/reflect/code/bytecode/TestQuoted.java ! test/jdk/java/lang/reflect/code/bytecode/TestSlots.java ! test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java ! test/jdk/java/lang/reflect/code/bytecode/TestTry.java ! test/jdk/java/lang/reflect/code/bytecode/TestTryFinally.java ! test/jdk/java/lang/reflect/code/bytecode/TestTryFinallyNested.java ! test/jdk/java/lang/reflect/code/bytecode/TestVarArg.java ! test/jdk/java/lang/reflect/code/expression/TestExpressionElimination.java ! test/jdk/java/lang/reflect/code/lower/CodeReflectionTester.java ! test/jdk/java/lang/reflect/code/stream/TestStream.java ! test/jdk/java/lang/reflect/code/stream/TestStreamUsingQuotable.java From psandoz at openjdk.org Tue Jul 8 16:17:58 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 8 Jul 2025 16:17:58 GMT Subject: [code-reflection] RFR: Issue errors when quotable constructs are found inside inner classes In-Reply-To: References: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> <9bdE6nDT1YbLc-UR5s79vrcLT8oVhVi7OqlZLOzoWGU=.f0629611-7e0b-47db-9f91-7848d0ca5158@github.com> Message-ID: On Tue, 8 Jul 2025 10:17:07 GMT, Maurizio Cimadamore wrote: > The main issue I see with this is that when you generate bytecode, now you have to Although we don't have to exactly do what the bytecode generated by javac does? Since we model `this` as an additional func operation parameter doing so for `Outer.this` and `Outer.Outer.this` etc would fit the same functional-like pattern, and is similar in many respects to what you suggest with `CapturedValues` but more literal. Then there are various translation strategies for generating bytecode - the most literal one being generating a method with all the parameters, and the user has to supply them, but some arguments could also be supplied at generation time and those become "constants". The down side is the `this` instances could be out of sync with each other. Alternatively we could devise a reflective operation that operates on an inner class instance to access the nearest enclosing class instance, if present, and so on? (There is no abstraction in reflection or method handles, i wonder if this motivates something for that?) ------------- PR Comment: https://git.openjdk.org/babylon/pull/486#issuecomment-3049548077 From psandoz at openjdk.org Tue Jul 8 16:19:26 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 8 Jul 2025 16:19:26 GMT Subject: [code-reflection] RFR: CodeElement ancestor functionality [v2] In-Reply-To: References: Message-ID: > Declare common ancestor methods on `CodeElement`. This enables more uniform traversal up the tree of code elements and querying of ancestors. > > The expression `e.ancestorOp().ancestorOp()` will first traverse up the code model tree from `e` to the nearest ancestor operation and then traverse again to the subsequent nearest ancestor operation, both skipping intermediate block and body elements. The first traversal can start from any kind of code element. > > The methods `ancestor{Op, Body, Block}` are currently implemented as default methods. While the implementations are simple it is easy to make mistakes handling unbound or root operations. They can be more directly implemented in a follow on PR. Paul Sandoz 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 eight additional commits since the last revision: - Merge remote-tracking branch 'upstream/code-reflection' into ancestor - Cleanup. - Doc updates. - Adjust isAncestorOf. Add test. - Update examples. - Merge remote-tracking branch 'upstream/code-reflection' into ancestor - Uses. Add CodeElement.isAncestorOf. - Unify ancestor functionality on CodeElement. ------------- Changes: - all: https://git.openjdk.org/babylon/pull/479/files - new: https://git.openjdk.org/babylon/pull/479/files/56e8c185..54107d94 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=479&range=01 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=479&range=00-01 Stats: 485 lines in 68 files changed: 100 ins; 94 del; 291 mod Patch: https://git.openjdk.org/babylon/pull/479.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/479/head:pull/479 PR: https://git.openjdk.org/babylon/pull/479 From mcimadamore at openjdk.org Tue Jul 8 16:28:59 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Jul 2025 16:28:59 GMT Subject: [code-reflection] RFR: Issue errors when quotable constructs are found inside inner classes In-Reply-To: References: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> <9bdE6nDT1YbLc-UR5s79vrcLT8oVhVi7OqlZLOzoWGU=.f0629611-7e0b-47db-9f91-7848d0ca5158@github.com> Message-ID: On Tue, 8 Jul 2025 16:14:50 GMT, Paul Sandoz wrote: > Although we don't have to exactly do what the bytecode generated by javac does? Well, I don't know what the constraints are. If we want the _semantics_ of the code model to match that of the generated code by javac (and some of the stuff javac generates is _mandated_ by the JLS) -- then I'd say that the proposed translation is just not a faithful implementation of the semantics of the original program. > The down side is the `this` instances could be out of sync with each other. Yes, I think this is more than just a downside. > Alternatively we could devise a reflective operation that operates on an inner class instance to access the nearest enclosing class instance, if present, and so on? (There is no abstraction in reflection or method handles, i wonder if this motivates something for that?) Even if we had that for the enclosing instance, what about captured values? These are completely implementation specific, not and not mandated by the JLS. So, while for enclosing instances it could make sense to expose a "give me one please" accessor reflectively, for captured values it seems to make a lot less sense. (also, we would need a similar reflective operation to _set_ such an enclosing instance, from the constructor of the inner class? Which feels... wrong?) ------------- PR Comment: https://git.openjdk.org/babylon/pull/486#issuecomment-3049581458 From mcimadamore at openjdk.org Tue Jul 8 16:40:57 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Jul 2025 16:40:57 GMT Subject: [code-reflection] RFR: Issue errors when quotable constructs are found inside inner classes In-Reply-To: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> References: <4tjJqKltwuLJuscAZBk6ebOaAZNGZllGxPMV0ik3B54=.57a12a6e-b860-4148-a56c-403583b45ba0@github.com> Message-ID: On Mon, 7 Jul 2025 15:01:34 GMT, Maurizio Cimadamore wrote: > This PR adds check in `ReflectMethods` to issue errors when quotable methods, lambdas, method references are found inside an inner class. This includes member inner classes, local and anonymous inner classes, but static inner classes (sometimes referred to as *nested classes*) are ok. > > The issue is that if we allowed code reflection in these places, we would need to come up with uniform treatment for compiler-generated captured symbols. > Currently `ReflectMethods` just allows method in an inner class to refer to a variable or a method in the enclosing class freely. While this is correct from a source code perspective, by the time we translate to bytecode, such references are no longer possible, and are typically mediated by compiler-generated symbols such as `this$0`. > > So, instead of generating a code model that might be unreliable, it is better, for now, to just disallow such cases. > > In principle, we should just "skip over" code elements we cannot support, and generate bytecode as usual. Indeed this is where I started, but then I realized that the support for lambda conversion into `Quoted` does not make sense unless we enable code reflection (as there's no real functional interface target we can use there). For this reason, an error is generated instead. Let me approach it from a completely different angle (for the sake of argument) Another possible answer could be to stick with the source code, rather than trying to play the "codegen" game. E.g. if the source code says we're accessing a member from an enclosing class, then the model should say we're accessing a member from an enclosing class. If the model is then used to generate the bytecode, at least it will be "trivial" to detect which parts of the model contain an enclosing instance access that needs to be patched. While correct in principle, this approach turns out to be problematic in practice. How exactly do we determine when enclosing instance access is required? We can (and we do) have complex cases where the same member is available both in the current class and the enclosing class. But maybe the one in the superclass is not accessible, so we prefer the enclosing class path. But the code model, most surely, doesn't have the level of finesse required to answer such questions -- and even if it did, I wonder if we would want code model processors to basically reimplement a biggie portion of the javac compiler in their own 3rd party logic. So, I think this means that the decision of "where did x comes from" (where x can be a member of an enclosing class, or some captured value) need to be made explicit in the model, otherwise processors will have an hard time figuring out which is which. ------------- PR Comment: https://git.openjdk.org/babylon/pull/486#issuecomment-3049613181 From mcimadamore at openjdk.org Tue Jul 8 16:42:51 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Jul 2025 16:42:51 GMT Subject: [code-reflection] Integrated: Disallow `null` return expressions in quoted lambdas In-Reply-To: References: Message-ID: <1pJjKIbplhIJNGvsKlIUZ2czz7q5kmmxYy2CE0l1YIY=.c98c9d78-2fc9-4928-8350-2f9a4d94ff3b@github.com> On Tue, 8 Jul 2025 12:07:13 GMT, Maurizio Cimadamore wrote: > Lambda expressions that are turned into a `Quoted` instance don't have an associated functional interface. Instead, they are type checked bottom-up (the parameter types in such lambdas must be explicit), and the return type is inferred from the various return expressions in the lambda body. > > The aim of this patch is to establish a similar set of rules between quoted lambda return expressions and expressions that are allowed on the RHS of a `var`. More specifically, the RHS of a `var` is restricted as follows: > > 1. can't be `null` > 2. can't be a "naked" array initializer, e.g. `{ 1, 2, 3 }` > 3. can't be a poly expression (a lambda, or a method reference) > > Now, (2) and (3) are already taken care of. (2) is not allowed in return context, and (3) is already rejected, given the body of the quoted lambda is attributed w/o a target type. > > So this PR adds a check for (1), to reject `null` return expressions. > > There are some other quality-of-life changes to make sure the compiler doesn't generate spurious diagnostics in case of errors. > > I've beefed up the test a bit. First, I've added tests to make sure that invalid return expressions in quoted lambdas are correctly rejected, regardless of whether the quoted lambda appears in assignment vs. method vs. generic method context. > > Secondly, I've added an IR test to make sure that the inferred return type of a quoted lambda is correctly upward-projected, to get rid of any non-denotable type that might arise in the inference process. This pull request has now been integrated. Changeset: 547623b9 Author: Maurizio Cimadamore URL: https://git.openjdk.org/babylon/commit/547623b9d698187a12124bb4cb2cdf6e5ab9ac87 Stats: 198 lines in 11 files changed: 179 ins; 9 del; 10 mod Disallow `null` return expressions in quoted lambdas Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/babylon/pull/489 From mcimadamore at openjdk.org Tue Jul 8 16:43:52 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Jul 2025 16:43:52 GMT Subject: git: openjdk/babylon: code-reflection: Disallow `null` return expressions in quoted lambdas Message-ID: Changeset: 547623b9 Branch: code-reflection Author: Maurizio Cimadamore Date: 2025-07-08 16:39:53 +0000 URL: https://git.openjdk.org/babylon/commit/547623b9d698187a12124bb4cb2cdf6e5ab9ac87 Disallow `null` return expressions in quoted lambdas Reviewed-by: psandoz ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/diags/examples.not-yet.txt ! test/langtools/tools/javac/reflect/QuotedTest.java ! test/langtools/tools/javac/reflect/TestNoCodeReflectionInInnerClasses.java ! test/langtools/tools/javac/reflect/quoted/TestAssignment.java ! test/langtools/tools/javac/reflect/quoted/TestAssignment.out ! test/langtools/tools/javac/reflect/quoted/TestGenericMethodCall.java ! test/langtools/tools/javac/reflect/quoted/TestGenericMethodCall.out ! test/langtools/tools/javac/reflect/quoted/TestMethodCall.java ! test/langtools/tools/javac/reflect/quoted/TestMethodCall.out From psandoz at openjdk.org Tue Jul 8 17:35:51 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 8 Jul 2025 17:35:51 GMT Subject: git: openjdk/babylon: code-reflection: CodeElement ancestor functionality Message-ID: Changeset: bf9ceea9 Branch: code-reflection Author: Paul Sandoz Date: 2025-07-08 17:33:00 +0000 URL: https://git.openjdk.org/babylon/commit/bf9ceea95246d958fd111fdd869f315ee33dd282 CodeElement ancestor functionality ! cr-examples/onnx/src/main/java/oracle/code/onnx/OnnxProtoBuilder.java ! cr-examples/triton/src/main/java/oracle/code/triton/SimpleCountedForLoopInfo.java ! cr-examples/triton/src/main/java/oracle/code/triton/TritonTransformer.java ! hat/backends/ffi/shared/src/main/java/hat/backend/ffi/FFIBackend.java ! hat/backends/jextracted/shared/src/main/java/hat/backend/jextracted/JExtractedBackend.java ! hat/core/src/main/java/hat/optools/BlockWrapper.java ! hat/core/src/main/java/hat/optools/OpWrapper.java ! hat/examples/experiments/src/main/java/experiments/QuotedTest.java ! hat/examples/experiments/src/main/java/experiments/TestQuoted.java ! hat/examples/experiments/src/main/java/experiments/Transform.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Block.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Body.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/CodeElement.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Op.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Quoted.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Value.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/Liveness.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/SSABraun.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/SSACytron.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/BytecodeGenerator.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/SlotOp.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/SlotToVarTransformer.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/UnresolvedTypesTransformer.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/extern/OpWriter.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/interpreter/Interpreter.java + test/jdk/java/lang/reflect/code/TestAncestors.java ! test/jdk/java/lang/reflect/code/TestBlockIndexes.java ! test/jdk/java/lang/reflect/code/TestBuild.java ! test/jdk/java/lang/reflect/code/TestClosureOps.java ! test/jdk/java/lang/reflect/code/TestLambdaOps.java ! test/jdk/java/lang/reflect/code/TestLiveness.java ! test/jdk/java/lang/reflect/code/TestLocalTransformationsAdaption.java ! test/jdk/java/lang/reflect/code/TestQuoteOp.java ! test/jdk/java/lang/reflect/code/anf/AnfTransformer.java ! test/jdk/java/lang/reflect/code/bytecode/Verifier.java From psandoz at openjdk.org Tue Jul 8 17:36:23 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 8 Jul 2025 17:36:23 GMT Subject: [code-reflection] RFR: CodeElement ancestor functionality [v3] In-Reply-To: References: Message-ID: > Declare common ancestor methods on `CodeElement`. This enables more uniform traversal up the tree of code elements and querying of ancestors. > > The expression `e.ancestorOp().ancestorOp()` will first traverse up the code model tree from `e` to the nearest ancestor operation and then traverse again to the subsequent nearest ancestor operation, both skipping intermediate block and body elements. The first traversal can start from any kind of code element. > > The methods `ancestor{Op, Body, Block}` are currently implemented as default methods. While the implementations are simple it is easy to make mistakes handling unbound or root operations. They can be more directly implemented in a follow on PR. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Remove findChildAncestor. Update HAT. ------------- Changes: - all: https://git.openjdk.org/babylon/pull/479/files - new: https://git.openjdk.org/babylon/pull/479/files/54107d94..4f1c4132 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=479&range=02 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=479&range=01-02 Stats: 63 lines in 8 files changed: 23 ins; 26 del; 14 mod Patch: https://git.openjdk.org/babylon/pull/479.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/479/head:pull/479 PR: https://git.openjdk.org/babylon/pull/479 From psandoz at openjdk.org Tue Jul 8 17:36:24 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 8 Jul 2025 17:36:24 GMT Subject: [code-reflection] Integrated: CodeElement ancestor functionality In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 22:29:33 GMT, Paul Sandoz wrote: > Declare common ancestor methods on `CodeElement`. This enables more uniform traversal up the tree of code elements and querying of ancestors. > > The expression `e.ancestorOp().ancestorOp()` will first traverse up the code model tree from `e` to the nearest ancestor operation and then traverse again to the subsequent nearest ancestor operation, both skipping intermediate block and body elements. The first traversal can start from any kind of code element. > > The methods `ancestor{Op, Body, Block}` are currently implemented as default methods. While the implementations are simple it is easy to make mistakes handling unbound or root operations. They can be more directly implemented in a follow on PR. This pull request has now been integrated. Changeset: bf9ceea9 Author: Paul Sandoz URL: https://git.openjdk.org/babylon/commit/bf9ceea95246d958fd111fdd869f315ee33dd282 Stats: 525 lines in 36 files changed: 323 ins; 112 del; 90 mod CodeElement ancestor functionality ------------- PR: https://git.openjdk.org/babylon/pull/479 From duke at openjdk.org Wed Jul 9 03:26:50 2025 From: duke at openjdk.org (duke) Date: Wed, 9 Jul 2025 03:26:50 GMT Subject: [code-reflection] Withdrawn: Disallow insertion of a root op in a block In-Reply-To: <8sB7qlbnONF4wEI39cUCoik0sXf2Oj8NV7TsJ-ZbDWA=.a4cd10a1-ef17-4170-8697-4fd15557b568@github.com> References: <8sB7qlbnONF4wEI39cUCoik0sXf2Oj8NV7TsJ-ZbDWA=.a4cd10a1-ef17-4170-8697-4fd15557b568@github.com> Message-ID: <9CI6Lqi9Pe04Xm7dt9EZtnTFHT0o5aYrXMAcY02emR8=.ea9213e2-b2a3-41af-8013-3e02a2e5ee4a@github.com> On Mon, 12 May 2025 21:42:35 GMT, Mourad Abbay wrote: > A root operation shouldn't be inserted in a block. This changes enforce this rule. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/babylon/pull/425 From psandoz at openjdk.org Wed Jul 9 17:47:29 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 9 Jul 2025 17:47:29 GMT Subject: [code-reflection] RFR: Remove Op::traverseOperands Message-ID: Remove `Op::traverseOperands`. Such traversal methods tend to be limited because it is not possible to control the traversal, and adding such facility will make the API more complex, likely more so that just writing the specific traversal method, since its only a few lines of code. Evidence in other areas of the code base that traverses up the tree of values indicates this is so, since this method is not used. A better approach would to broaden the functionality of `Value::dependsOn`, adding another method that returns a lazy stream of all dependent values, in order. ------------- Commit messages: - Remove Op::traverseOperands. Changes: https://git.openjdk.org/babylon/pull/490/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=490&range=00 Stats: 31 lines in 3 files changed: 6 ins; 24 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/490.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/490/head:pull/490 PR: https://git.openjdk.org/babylon/pull/490 From psandoz at openjdk.org Wed Jul 9 19:38:58 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 9 Jul 2025 19:38:58 GMT Subject: [code-reflection] Integrated: Remove Op::traverseOperands In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 17:43:30 GMT, Paul Sandoz wrote: > Remove `Op::traverseOperands`. Such traversal methods tend to be limited because it is not possible to control the traversal, and adding such facility will make the API more complex, likely more so that just writing the specific traversal method, since its only a few lines of code. > > Evidence in other areas of the code base that traverses up the tree of values indicates this is so, since this method is not used. A better approach would to broaden the functionality of `Value::dependsOn`, adding another method that returns a lazy stream of all dependent values, in order. This pull request has now been integrated. Changeset: 1935a8e1 Author: Paul Sandoz URL: https://git.openjdk.org/babylon/commit/1935a8e15f6d01e282f51ecccb6b477590ba5d45 Stats: 31 lines in 3 files changed: 6 ins; 24 del; 1 mod Remove Op::traverseOperands ------------- PR: https://git.openjdk.org/babylon/pull/490 From psandoz at openjdk.org Wed Jul 9 19:39:13 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 9 Jul 2025 19:39:13 GMT Subject: git: openjdk/babylon: code-reflection: Remove Op::traverseOperands Message-ID: Changeset: 1935a8e1 Branch: code-reflection Author: Paul Sandoz Date: 2025-07-09 19:35:58 +0000 URL: https://git.openjdk.org/babylon/commit/1935a8e15f6d01e282f51ecccb6b477590ba5d45 Remove Op::traverseOperands ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Op.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Value.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/Patterns.java From psandoz at openjdk.org Wed Jul 9 20:19:26 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 9 Jul 2025 20:19:26 GMT Subject: [code-reflection] RFR: Single method to append an operation to a block builder Message-ID: Reduce the number of methods to append an operation to a block builder down to a single method. `Block.Builder` no longer extends from `Function`, thereby removing the `apply(Op op)` method which just deferred to `op(Op op)`, and when to use which caused confusion. The functional abstraction can be achieved with `Block.Builder::op`. Remove the method `op` method that accepts a operation transformer, overriding the builder's transformer. This was another source of confusion. For the more advanced cases where a different transformer is required, the builder can be rebound to a new builder with a different transformer. ------------- Commit messages: - Update triton ops. - Block.Builder does not implement Function - Remove ops method - Remove block.op accepting transformer. Changes: https://git.openjdk.org/babylon/pull/491/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=491&range=00 Stats: 202 lines in 13 files changed: 1 ins; 80 del; 121 mod Patch: https://git.openjdk.org/babylon/pull/491.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/491/head:pull/491 PR: https://git.openjdk.org/babylon/pull/491 From psandoz at openjdk.org Thu Jul 10 20:13:32 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 10 Jul 2025 20:13:32 GMT Subject: git: openjdk/babylon: code-reflection: Single method to append an operation to a block builder Message-ID: <7f657889-d4ed-41ba-92d0-0307110e6587@openjdk.org> Changeset: 2b9116c4 Branch: code-reflection Author: Paul Sandoz Date: 2025-07-10 20:12:19 +0000 URL: https://git.openjdk.org/babylon/commit/2b9116c466512e8f8bf4aecdf015763289c895d9 Single method to append an operation to a block builder ! cr-examples/triton/src/main/java/oracle/code/triton/TritonOps.java ! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaBackend.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Block.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/SSACytron.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/StringConcatTransformer.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/core/CoreOp.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java ! test/jdk/java/lang/reflect/code/TestExceptionRegionOps.java ! test/jdk/java/lang/reflect/code/TestLocalTransformationsAdaption.java ! test/jdk/java/lang/reflect/code/ad/ForwardDifferentiation.java ! test/langtools/tools/javac/reflect/TestNoCodeReflectionInInnerClasses.java ! test/langtools/tools/javac/reflect/TestNoCodeReflectionInInnerClasses.out From psandoz at openjdk.org Thu Jul 10 20:14:54 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 10 Jul 2025 20:14:54 GMT Subject: [code-reflection] Integrated: Single method to append an operation to a block builder In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 20:14:54 GMT, Paul Sandoz wrote: > Reduce the number of methods to append an operation to a block builder down to a single method. > > `Block.Builder` no longer extends from `Function`, thereby removing the `apply(Op op)` method which just deferred to `op(Op op)`, and when to use which caused confusion. The functional abstraction can be achieved with `Block.Builder::op`. > > Remove the method `op` that accepts a operation transformer, overriding the builder's transformer. This was another source of confusion. For the more advanced cases where a different transformer is required, the builder can be rebound to a new builder with a different transformer. > > Remove the method `ops` which allowed building within the context of a lambda expression. This can also cause confusion as the builder variable is aliased with the lambda parameter. Such code, if needed can be factored into methods or explicit lambdas. This pull request has now been integrated. Changeset: 2b9116c4 Author: Paul Sandoz URL: https://git.openjdk.org/babylon/commit/2b9116c466512e8f8bf4aecdf015763289c895d9 Stats: 202 lines in 13 files changed: 1 ins; 80 del; 121 mod Single method to append an operation to a block builder ------------- PR: https://git.openjdk.org/babylon/pull/491 From psandoz at openjdk.org Thu Jul 10 21:06:03 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 10 Jul 2025 21:06:03 GMT Subject: [code-reflection] RFR: Lowering passes on transformer Message-ID: The switch operation lowering implementation needs to pass on the given operation transformer when lowering nested content. A given operation transformer may be one created when lowering a try or synchronized operation which may need to insert code when exiting non-exceptionally from the scope of the operation e.g., inserting code before a return operation. ------------- Commit messages: - Lowering passes on transformer Changes: https://git.openjdk.org/babylon/pull/492/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=492&range=00 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/babylon/pull/492.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/492/head:pull/492 PR: https://git.openjdk.org/babylon/pull/492 From psandoz at openjdk.org Thu Jul 10 21:11:38 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 10 Jul 2025 21:11:38 GMT Subject: [code-reflection] RFR: Lowering passes on transformer [v2] In-Reply-To: References: Message-ID: <5jV9e2rDqKx0itzhEBKoDyTNRjorVHWhqLiNEUc-C5c=.2c658c95-144a-4861-8c20-5b4fa1585b7f@github.com> > The switch operation lowering implementation needs to pass on the given operation transformer when lowering nested content. A given operation transformer may be one created when lowering a try or synchronized operation which may need to insert code when exiting non-exceptionally from the scope of the operation e.g., inserting code before a return operation. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.org/babylon/pull/492/files - new: https://git.openjdk.org/babylon/pull/492/files/14e3885c..b1d18fb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=492&range=01 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=492&range=00-01 Stats: 26 lines in 1 file changed: 26 ins; 0 del; 0 mod Patch: https://git.openjdk.org/babylon/pull/492.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/492/head:pull/492 PR: https://git.openjdk.org/babylon/pull/492 From psandoz at openjdk.org Thu Jul 10 21:14:52 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 10 Jul 2025 21:14:52 GMT Subject: git: openjdk/babylon: code-reflection: Lowering passes on transformer Message-ID: <1b6df39c-7145-43d6-9af0-99044f0b6980@openjdk.org> Changeset: 7f17268d Branch: code-reflection Author: Paul Sandoz Date: 2025-07-10 21:14:04 +0000 URL: https://git.openjdk.org/babylon/commit/7f17268d68ad4cde128ed83f71a9af9b03c3b16f Lowering passes on transformer ! src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java ! test/jdk/java/lang/reflect/code/TestSwitchStatementOp.java From psandoz at openjdk.org Thu Jul 10 21:16:52 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 10 Jul 2025 21:16:52 GMT Subject: [code-reflection] Integrated: Lowering passes on transformer In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 21:00:50 GMT, Paul Sandoz wrote: > The switch operation lowering implementation needs to pass on the given operation transformer when lowering nested content. A given operation transformer may be one created when lowering a try or synchronized operation which may need to insert code when exiting non-exceptionally from the scope of the operation e.g., inserting code before a return operation. This pull request has now been integrated. Changeset: 7f17268d Author: Paul Sandoz URL: https://git.openjdk.org/babylon/commit/7f17268d68ad4cde128ed83f71a9af9b03c3b16f Stats: 31 lines in 2 files changed: 26 ins; 1 del; 4 mod Lowering passes on transformer ------------- PR: https://git.openjdk.org/babylon/pull/492 From psandoz at openjdk.org Thu Jul 10 23:41:08 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 10 Jul 2025 23:41:08 GMT Subject: [code-reflection] RFR: Move Block.Builder.inline to analysis package Message-ID: Move the `Block.Builder.inline` method and dependent functionality to the class `Inliner` in the `analysis` package. ------------- Commit messages: - Move Block.Bulder.inline to analysis package Changes: https://git.openjdk.org/babylon/pull/493/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=493&range=00 Stats: 286 lines in 8 files changed: 141 ins; 121 del; 24 mod Patch: https://git.openjdk.org/babylon/pull/493.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/493/head:pull/493 PR: https://git.openjdk.org/babylon/pull/493 From psandoz at openjdk.org Fri Jul 11 18:17:49 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 11 Jul 2025 18:17:49 GMT Subject: git: openjdk/babylon: code-reflection: Move Block.Builder.inline to analysis package Message-ID: <09601f34-fcae-4c16-aa5d-396e447646bc@openjdk.org> Changeset: 97889b81 Branch: code-reflection Author: Paul Sandoz Date: 2025-07-11 18:16:44 +0000 URL: https://git.openjdk.org/babylon/commit/97889b818eda66f395b4e2cc00653b2f5426dca3 Move Block.Builder.inline to analysis package ! cr-examples/onnx/src/main/java/oracle/code/onnx/compiler/OnnxTransformer.java ! src/jdk.incubator.code/share/classes/jdk/incubator/code/Block.java + src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/Inliner.java ! test/jdk/java/lang/reflect/code/TestInline.java ! test/jdk/java/lang/reflect/code/TestLinqUsingQuoted.java ! test/jdk/java/lang/reflect/code/linq/Queryable.java ! test/jdk/java/lang/reflect/code/stream/StreamFuser.java ! test/jdk/java/lang/reflect/code/stream/StreamFuserUsingQuotable.java From psandoz at openjdk.org Fri Jul 11 18:19:57 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 11 Jul 2025 18:19:57 GMT Subject: [code-reflection] Integrated: Move Block.Builder.inline to analysis package In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 23:36:13 GMT, Paul Sandoz wrote: > Move the `Block.Builder.inline` method and dependent functionality to the class `Inliner` in the `analysis` package. This pull request has now been integrated. Changeset: 97889b81 Author: Paul Sandoz URL: https://git.openjdk.org/babylon/commit/97889b818eda66f395b4e2cc00653b2f5426dca3 Stats: 286 lines in 8 files changed: 141 ins; 121 del; 24 mod Move Block.Builder.inline to analysis package ------------- PR: https://git.openjdk.org/babylon/pull/493 From duke at openjdk.org Mon Jul 21 07:06:57 2025 From: duke at openjdk.org (Juan Fumero) Date: Mon, 21 Jul 2025 07:06:57 GMT Subject: [code-reflection] RFR: 1D Matrix Multiplication example for HAT [v6] In-Reply-To: References: Message-ID: > Add new example for 1D Matrix Multiplication in HAT. > > ### How to test? > > > ## Compile > java --add-modules jdk.incubator.code --enable-preview --source 24 bld > > ## Run with the OpenCL Backend > java @bldr/hatrun ffi-opencl matmul > > ## Run with the CUDA Backend > java @bldr/hatrun ffi-ptx matmul > > > #### Note that the generated kernel for OpenCL contains a race condition: > > > __kernel void matrixMultiplyKernel( > __global KernelContext_t *kc, __global F32Array_t* matrixA, __global F32Array_t* matrixB, __global F32Array_t* matrixC, int size > ){ > kc->x=get_global_id(0); // << Shared struct across all threads to store the thread-id > if(kc->xmaxX){ > for(int j = 0; j float acc = (float)0; > for(int k = 0; k acc=acc+matrixA->array[(long)(kc->x*size+k)]*matrixB->array[(long)(k*size+j)]; > } > matrixC->array[(long)(kc->x*size+j)]=acc; > } > } > return; > } > > > After applying a patch provided by Gary Frost to solve the race condition, it works. > > Patch: > > > diff --git a/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java b/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java > index ade90914d7e..2719fed31ed 100644 > --- a/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java > +++ b/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java > @@ -26,7 +26,6 @@ > > > import hat.buffer.Buffer; > -import hat.buffer.KernelContext; > import hat.callgraph.KernelCallGraph; > import hat.callgraph.KernelEntrypoint; > import hat.optools.FuncOpWrapper; > @@ -72,9 +71,13 @@ T typedefStructOrUnion(boolean isStruct, String name, Consumer consumer) { > > > public final T scope() { > - return > - identifier("kc").rarrow().identifier("x").equals().globalId().semicolon().nl(); > - //.identifier("kc").rarrow().identifier("maxX").equals().globalSize().semicolon().nl(); > + > + identifier("KernelContext_t").space().identifier("mine").semicolon().nl(); > + identifier("KernelContext_t").asterisk().space().identifier("kc").equals().ampersand().identifier("mine").semicolon().nl(); > + identifier("kc").rarrow().identifier("x").equals().globalId().semicolon().nl(); > + identifier("kc").rarrow().identifier("maxX").equals().identifier("global_kc").rarrow().identifier("maxX").semicolon().nl(); > + return self(); > + > } > > public abstract T globalPtr... Juan Fumero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge branch 'code-reflection' into dev/examples - Merge branch 'code-reflection' into dev/examples - Merge branch 'code-reflection' into dev/examples - Merge branch 'code-reflection' into dev/examples - Merge branch 'code-reflection' into dev/examples - Minor fix seq-comparison code - Merge with latest develop - Merge branch 'code-reflection' into dev/examples - Merge branch 'code-reflection' into dev/examples - Merge branch 'code-reflection' into dev/examples - ... and 5 more: https://git.openjdk.org/babylon/compare/97889b81...a56a0bb9 ------------- Changes: https://git.openjdk.org/babylon/pull/276/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=276&range=05 Stats: 252 lines in 5 files changed: 216 ins; 1 del; 35 mod Patch: https://git.openjdk.org/babylon/pull/276.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/276/head:pull/276 PR: https://git.openjdk.org/babylon/pull/276 From duke at openjdk.org Mon Jul 21 07:06:57 2025 From: duke at openjdk.org (Juan Fumero) Date: Mon, 21 Jul 2025 07:06:57 GMT Subject: [code-reflection] RFR: 1D Matrix Multiplication example for HAT [v5] In-Reply-To: References: Message-ID: <7cbNHvgJsspJgHLJ28ePNh-P_z-Ep2cFsx39sx2NKwg=.19b86cf8-f820-474d-9553-45eeb8ae24ad@github.com> On Fri, 20 Jun 2025 14:33:27 GMT, Juan Fumero wrote: >> Add new example for 1D Matrix Multiplication in HAT. >> >> ### How to test? >> >> >> ## Compile >> java --add-modules jdk.incubator.code --enable-preview --source 24 bld >> >> ## Run with the OpenCL Backend >> java @bldr/hatrun ffi-opencl matmul >> >> ## Run with the CUDA Backend >> java @bldr/hatrun ffi-ptx matmul >> >> >> #### Note that the generated kernel for OpenCL contains a race condition: >> >> >> __kernel void matrixMultiplyKernel( >> __global KernelContext_t *kc, __global F32Array_t* matrixA, __global F32Array_t* matrixB, __global F32Array_t* matrixC, int size >> ){ >> kc->x=get_global_id(0); // << Shared struct across all threads to store the thread-id >> if(kc->xmaxX){ >> for(int j = 0; j> float acc = (float)0; >> for(int k = 0; k> acc=acc+matrixA->array[(long)(kc->x*size+k)]*matrixB->array[(long)(k*size+j)]; >> } >> matrixC->array[(long)(kc->x*size+j)]=acc; >> } >> } >> return; >> } >> >> >> After applying a patch provided by Gary Frost to solve the race condition, it works. >> >> Patch: >> >> >> diff --git a/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java b/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java >> index ade90914d7e..2719fed31ed 100644 >> --- a/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java >> +++ b/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java >> @@ -26,7 +26,6 @@ >> >> >> import hat.buffer.Buffer; >> -import hat.buffer.KernelContext; >> import hat.callgraph.KernelCallGraph; >> import hat.callgraph.KernelEntrypoint; >> import hat.optools.FuncOpWrapper; >> @@ -72,9 +71,13 @@ T typedefStructOrUnion(boolean isStruct, String name, Consumer consumer) { >> >> >> public final T scope() { >> - return >> - identifier("kc").rarrow().identifier("x").equals().globalId().semicolon().nl(); >> - //.identifier("kc").rarrow().identifier("maxX").equals().globalSize().semicolon().nl(); >> + >> + identifier("KernelContext_t").space().identifier("mine").semicolon().nl(); >> + identifier("KernelContext_t").asterisk().space().identifier("kc").equals().ampersand().identifier("mine").semicolon().nl(); >> + identifier("kc").rarrow().identifier("x").equals().globalId().semicolon().nl(); >> + identifier("kc").rarrow().identifier("maxX").equals().identifie... > > Juan Fumero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'code-reflection' into dev/examples > - Merge branch 'code-reflection' into dev/examples > - Merge branch 'code-reflection' into dev/examples > - Merge branch 'code-reflection' into dev/examples > - Minor fix seq-comparison code > - Merge with latest develop > - Merge branch 'code-reflection' into dev/examples > - Merge branch 'code-reflection' into dev/examples > - Merge branch 'code-reflection' into dev/examples > - MatrixMult example moved to matmul directory > - ... and 4 more: https://git.openjdk.org/babylon/compare/e4b086c9...eb019756 PR conflicts solved. It complies with the latest version: 97889b818ed. @grfrost , shall we merge this? ------------- PR Comment: https://git.openjdk.org/babylon/pull/276#issuecomment-3095483208 From duke at openjdk.org Mon Jul 21 07:23:20 2025 From: duke at openjdk.org (duke) Date: Mon, 21 Jul 2025 07:23:20 GMT Subject: [code-reflection] RFR: 1D Matrix Multiplication example for HAT [v6] In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 07:06:57 GMT, Juan Fumero wrote: >> Add new example for 1D Matrix Multiplication in HAT. >> >> ### How to test? >> >> >> ## Compile >> java --add-modules jdk.incubator.code --enable-preview --source 24 bld >> >> ## Run with the OpenCL Backend >> java @bldr/hatrun ffi-opencl matmul >> >> ## Run with the CUDA Backend >> java @bldr/hatrun ffi-ptx matmul >> >> >> #### Note that the generated kernel for OpenCL contains a race condition: >> >> >> __kernel void matrixMultiplyKernel( >> __global KernelContext_t *kc, __global F32Array_t* matrixA, __global F32Array_t* matrixB, __global F32Array_t* matrixC, int size >> ){ >> kc->x=get_global_id(0); // << Shared struct across all threads to store the thread-id >> if(kc->xmaxX){ >> for(int j = 0; j> float acc = (float)0; >> for(int k = 0; k> acc=acc+matrixA->array[(long)(kc->x*size+k)]*matrixB->array[(long)(k*size+j)]; >> } >> matrixC->array[(long)(kc->x*size+j)]=acc; >> } >> } >> return; >> } >> >> >> After applying a patch provided by Gary Frost to solve the race condition, it works. >> >> Patch: >> >> >> diff --git a/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java b/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java >> index ade90914d7e..2719fed31ed 100644 >> --- a/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java >> +++ b/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java >> @@ -26,7 +26,6 @@ >> >> >> import hat.buffer.Buffer; >> -import hat.buffer.KernelContext; >> import hat.callgraph.KernelCallGraph; >> import hat.callgraph.KernelEntrypoint; >> import hat.optools.FuncOpWrapper; >> @@ -72,9 +71,13 @@ T typedefStructOrUnion(boolean isStruct, String name, Consumer consumer) { >> >> >> public final T scope() { >> - return >> - identifier("kc").rarrow().identifier("x").equals().globalId().semicolon().nl(); >> - //.identifier("kc").rarrow().identifier("maxX").equals().globalSize().semicolon().nl(); >> + >> + identifier("KernelContext_t").space().identifier("mine").semicolon().nl(); >> + identifier("KernelContext_t").asterisk().space().identifier("kc").equals().ampersand().identifier("mine").semicolon().nl(); >> + identifier("kc").rarrow().identifier("x").equals().globalId().semicolon().nl(); >> + identifier("kc").rarrow().identifier("maxX").equals().identifie... > > Juan Fumero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'code-reflection' into dev/examples > - Merge branch 'code-reflection' into dev/examples > - Merge branch 'code-reflection' into dev/examples > - Merge branch 'code-reflection' into dev/examples > - Merge branch 'code-reflection' into dev/examples > - Minor fix seq-comparison code > - Merge with latest develop > - Merge branch 'code-reflection' into dev/examples > - Merge branch 'code-reflection' into dev/examples > - Merge branch 'code-reflection' into dev/examples > - ... and 5 more: https://git.openjdk.org/babylon/compare/97889b81...a56a0bb9 @jjfumero Your change (at version a56a0bb9c96bdb983996ebd9ae5546bbd28575f2) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/babylon/pull/276#issuecomment-3095539285 From gfrost at openjdk.org Mon Jul 21 07:25:12 2025 From: gfrost at openjdk.org (Gary Frost) Date: Mon, 21 Jul 2025 07:25:12 GMT Subject: git: openjdk/babylon: code-reflection: 1D Matrix Multiplication example for HAT Message-ID: Changeset: 3c573e55 Branch: code-reflection Author: Juan Fumero Committer: Gary Frost Date: 2025-07-21 07:22:58 +0000 URL: https://git.openjdk.org/babylon/commit/3c573e556f02180302c12dd4b9093173748ded1a 1D Matrix Multiplication example for HAT ! hat/.gitignore + hat/examples/matmul/pom.xml + hat/examples/matmul/src/main/java/matmul/Main.java ! hat/examples/pom.xml ! hat/hat/bld.java From duke at openjdk.org Mon Jul 21 07:25:58 2025 From: duke at openjdk.org (Juan Fumero) Date: Mon, 21 Jul 2025 07:25:58 GMT Subject: [code-reflection] Integrated: 1D Matrix Multiplication example for HAT In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 10:12:08 GMT, Juan Fumero wrote: > Add new example for 1D Matrix Multiplication in HAT. > > ### How to test? > > > ## Compile > java --add-modules jdk.incubator.code --enable-preview --source 24 bld > > ## Run with the OpenCL Backend > java @bldr/hatrun ffi-opencl matmul > > ## Run with the CUDA Backend > java @bldr/hatrun ffi-ptx matmul > > > #### Note that the generated kernel for OpenCL contains a race condition: > > > __kernel void matrixMultiplyKernel( > __global KernelContext_t *kc, __global F32Array_t* matrixA, __global F32Array_t* matrixB, __global F32Array_t* matrixC, int size > ){ > kc->x=get_global_id(0); // << Shared struct across all threads to store the thread-id > if(kc->xmaxX){ > for(int j = 0; j float acc = (float)0; > for(int k = 0; k acc=acc+matrixA->array[(long)(kc->x*size+k)]*matrixB->array[(long)(k*size+j)]; > } > matrixC->array[(long)(kc->x*size+j)]=acc; > } > } > return; > } > > > After applying a patch provided by Gary Frost to solve the race condition, it works. > > Patch: > > > diff --git a/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java b/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java > index ade90914d7e..2719fed31ed 100644 > --- a/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java > +++ b/hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java > @@ -26,7 +26,6 @@ > > > import hat.buffer.Buffer; > -import hat.buffer.KernelContext; > import hat.callgraph.KernelCallGraph; > import hat.callgraph.KernelEntrypoint; > import hat.optools.FuncOpWrapper; > @@ -72,9 +71,13 @@ T typedefStructOrUnion(boolean isStruct, String name, Consumer consumer) { > > > public final T scope() { > - return > - identifier("kc").rarrow().identifier("x").equals().globalId().semicolon().nl(); > - //.identifier("kc").rarrow().identifier("maxX").equals().globalSize().semicolon().nl(); > + > + identifier("KernelContext_t").space().identifier("mine").semicolon().nl(); > + identifier("KernelContext_t").asterisk().space().identifier("kc").equals().ampersand().identifier("mine").semicolon().nl(); > + identifier("kc").rarrow().identifier("x").equals().globalId().semicolon().nl(); > + identifier("kc").rarrow().identifier("maxX").equals().identifier("global_kc").rarrow().identifier("maxX").semicolon().nl(); > + return self(); > + > } > > public abstract T globalPtr... This pull request has now been integrated. Changeset: 3c573e55 Author: Juan Fumero Committer: Gary Frost URL: https://git.openjdk.org/babylon/commit/3c573e556f02180302c12dd4b9093173748ded1a Stats: 252 lines in 5 files changed: 216 ins; 1 del; 35 mod 1D Matrix Multiplication example for HAT ------------- PR: https://git.openjdk.org/babylon/pull/276 From asotona at openjdk.org Mon Jul 21 15:50:38 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 21 Jul 2025 15:50:38 GMT Subject: [code-reflection] RFR: ONNX LLM example implementation Message-ID: ONNX LLM example implementation ------------- Commit messages: - LlamaDemo implementation Changes: https://git.openjdk.org/babylon/pull/495/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=495&range=00 Stats: 386 lines in 9 files changed: 298 ins; 78 del; 10 mod Patch: https://git.openjdk.org/babylon/pull/495.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/495/head:pull/495 PR: https://git.openjdk.org/babylon/pull/495 From asotona at openjdk.org Wed Jul 23 13:11:15 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 23 Jul 2025 13:11:15 GMT Subject: git: openjdk/babylon: code-reflection: ONNX LLM example implementation Message-ID: <1e9ba792-6700-4227-b6bc-bed66933e794@openjdk.org> Changeset: f41b774b Branch: code-reflection Author: Adam Sotona Date: 2025-07-23 13:09:17 +0000 URL: https://git.openjdk.org/babylon/commit/f41b774b78ff20266477cbd022ef125a4b72dac1 ONNX LLM example implementation ! cr-examples/onnx/README.md + cr-examples/onnx/lib/.gitignore ! cr-examples/onnx/pom.xml ! cr-examples/onnx/src/main/java/oracle/code/onnx/OnnxRuntime.java ! cr-examples/onnx/src/main/java/oracle/code/onnx/genai/OnnxGenRuntimeSession.java + cr-examples/onnx/src/test/java/oracle/code/onnx/llm/LlamaDemo.java + cr-examples/onnx/src/test/java/oracle/code/onnx/llm/LlamaModel.java + cr-examples/onnx/src/test/resources/oracle/code/onnx/llm/.gitignore + cr-examples/onnx/src/test/resources/oracle/code/onnx/llm/genai_config.json From asotona at openjdk.org Wed Jul 23 13:12:21 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 23 Jul 2025 13:12:21 GMT Subject: [code-reflection] Integrated: ONNX LLM example implementation In-Reply-To: References: Message-ID: <3WOCb_jRz-5B4wyqE5hR_fCUOVEE7iu0jLVRigmD67U=.0c659c52-494b-4ea3-b7f1-8a1b66766f81@github.com> On Mon, 21 Jul 2025 15:43:07 GMT, Adam Sotona wrote: > ONNX LLM example implementation This pull request has now been integrated. Changeset: f41b774b Author: Adam Sotona URL: https://git.openjdk.org/babylon/commit/f41b774b78ff20266477cbd022ef125a4b72dac1 Stats: 386 lines in 9 files changed: 298 ins; 78 del; 10 mod ONNX LLM example implementation ------------- PR: https://git.openjdk.org/babylon/pull/495 From duke at openjdk.org Wed Jul 23 14:06:11 2025 From: duke at openjdk.org (Juan Fumero) Date: Wed, 23 Jul 2025 14:06:11 GMT Subject: [code-reflection] RFR: [feature][HAT] 2D and 3D ranges for the NDRange API Message-ID: This patch introduces the concept of 2D and 3D ranges. This allows developers to do the following: - Accessing 1D, 2D and 3D thread indexing within the kernels. The `KernelContext` API has been extended to do this. - Dispatching 1D, 2D and 3D kernels via the `ComputeContext`. **IMPORTANT**: This patch has been tested for the OpenCL backend, the CUDA backend generates correct code, but for some reason I can't dispatch it due to CUDA incompatibilities (seems to be orthogonal to this PR). I will investigate this in a separate issue. An example of use is provided in the `matmul/Main.java` class. Example of 1D kernel in HAT: @CodeReflection public static void matrixMultiplyKernel1D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { if (kc.x < kc.maxX) { for (int j = 0; j < size; j++) { float acc = 0; for (int k = 0; k < size; k++) { acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + j)); } matrixC.array(kc.x * size + j, acc); } } } Example of a 2D kernel: @CodeReflection public static void matrixMultiplyKernel2D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { if (kc.x < kc.maxX) { if (kc.y < kc.maxY) { float acc = 0; for (int k = 0; k < size; k++) { acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + kc.y)); } matrixC.array(kc.x * size + kc.y, acc); } } } How to dispatch? The dispatcher now has more parameters to setup the max thread size for each dimension. In the case of a 2D: computeContext.dispatchKernel(maxX, maxY, kernelContext -> matrixMultiplyKernel2D(kernelContext, matrixA, matrixB, matrixC, size) ); ### How to test this patch? I extended the test-case for the matrix multiplication. Run with 1D: HAT=SHOW_CODE java @hat/run ffi-opencl matmul 1D Run with 2D HAT=SHOW_CODE java @hat/run ffi-opencl matmul 2D ------------- Commit messages: - [feature] 2D and 3D ranges for the NDRange API Changes: https://git.openjdk.org/babylon/pull/496/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=496&range=00 Stats: 404 lines in 23 files changed: 298 ins; 23 del; 83 mod Patch: https://git.openjdk.org/babylon/pull/496.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/496/head:pull/496 PR: https://git.openjdk.org/babylon/pull/496 From liach at openjdk.org Wed Jul 23 15:36:10 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 23 Jul 2025 15:36:10 GMT Subject: [code-reflection] RFR: [feature][HAT] 2D and 3D ranges for the NDRange API In-Reply-To: References: Message-ID: On Wed, 23 Jul 2025 14:00:10 GMT, Juan Fumero wrote: > This patch introduces the concept of 2D and 3D ranges. > > This allows developers to do the following: > - Accessing 1D, 2D and 3D thread indexing within the kernels. The `KernelContext` API has been extended to do this. > - Dispatching 1D, 2D and 3D kernels via the `ComputeContext`. > > **IMPORTANT**: This patch has been tested for the OpenCL backend, the CUDA backend generates correct code, but for some reason I can't dispatch it due to CUDA incompatibilities (seems to be orthogonal to this PR). I will investigate this in a separate issue. > > An example of use is provided in the `matmul/Main.java` class. > > Example of 1D kernel in HAT: > > > @CodeReflection > public static void matrixMultiplyKernel1D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { > if (kc.x < kc.maxX) { > for (int j = 0; j < size; j++) { > float acc = 0; > for (int k = 0; k < size; k++) { > acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + j)); > } > matrixC.array(kc.x * size + j, acc); > } > } > } > > > Example of a 2D kernel: > > > @CodeReflection > public static void matrixMultiplyKernel2D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { > if (kc.x < kc.maxX) { > if (kc.y < kc.maxY) { > float acc = 0; > for (int k = 0; k < size; k++) { > acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + kc.y)); > } > matrixC.array(kc.x * size + kc.y, acc); > } > } > } > > > How to dispatch? > > The dispatcher now has more parameters to setup the max thread size for each dimension. In the case of a 2D: > > > computeContext.dispatchKernel(maxX, maxY, > kernelContext -> matrixMultiplyKernel2D(kernelContext, matrixA, matrixB, matrixC, size) > ); > > > ### How to test this patch? > > I extended the test-case for the matrix multiplication. > > Run with 1D: > > > HAT=SHOW_CODE java @hat/run ffi-opencl matmul 1D > > > Run with 2D > > > HAT=SHOW_CODE java @hat/run ffi-opencl matmul 2D hat/core/src/main/java/hat/ComputeContext.java line 152: > 150: case 2 -> ndRange = accelerator.range(rangeX, rangeY); > 151: case 3 -> ndRange = accelerator.range(rangeX, rangeY, rangeZ); > 152: } Should we add a default branch that throws an exception instead of initializing `ndRange` to null? ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/496#discussion_r2225952022 From duke at openjdk.org Thu Jul 24 07:08:19 2025 From: duke at openjdk.org (Juan Fumero) Date: Thu, 24 Jul 2025 07:08:19 GMT Subject: [code-reflection] RFR: [feature][HAT] 2D and 3D ranges for the NDRange API In-Reply-To: References: Message-ID: On Thu, 24 Jul 2025 07:04:48 GMT, Juan Fumero wrote: >> hat/core/src/main/java/hat/ComputeContext.java line 152: >> >>> 150: case 2 -> ndRange = accelerator.range(rangeX, rangeY); >>> 151: case 3 -> ndRange = accelerator.range(rangeX, rangeY, rangeZ); >>> 152: } >> >> Should we add a default branch that throws an exception instead of initializing `ndRange` to null? > > I thought about this. However, this method is method is private, and only the public dispatch method sets the value. I will add the exception though. BTW, in near future we should have our own exceptions (e.g., `HATRuntimeException`). For this PR I will use the generic `RuntimeException` ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/496#discussion_r2227623274 From duke at openjdk.org Thu Jul 24 07:08:19 2025 From: duke at openjdk.org (Juan Fumero) Date: Thu, 24 Jul 2025 07:08:19 GMT Subject: [code-reflection] RFR: [feature][HAT] 2D and 3D ranges for the NDRange API In-Reply-To: References: Message-ID: On Wed, 23 Jul 2025 15:25:54 GMT, Chen Liang wrote: >> This patch introduces the concept of 2D and 3D ranges. >> >> This allows developers to do the following: >> - Accessing 1D, 2D and 3D thread indexing within the kernels. The `KernelContext` API has been extended to do this. >> - Dispatching 1D, 2D and 3D kernels via the `ComputeContext`. >> >> **IMPORTANT**: This patch has been tested for the OpenCL backend, the CUDA backend generates correct code, but for some reason I can't dispatch it due to CUDA incompatibilities (seems to be orthogonal to this PR). I will investigate this in a separate issue. >> >> An example of use is provided in the `matmul/Main.java` class. >> >> Example of 1D kernel in HAT: >> >> >> @CodeReflection >> public static void matrixMultiplyKernel1D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { >> if (kc.x < kc.maxX) { >> for (int j = 0; j < size; j++) { >> float acc = 0; >> for (int k = 0; k < size; k++) { >> acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + j)); >> } >> matrixC.array(kc.x * size + j, acc); >> } >> } >> } >> >> >> Example of a 2D kernel: >> >> >> @CodeReflection >> public static void matrixMultiplyKernel2D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { >> if (kc.x < kc.maxX) { >> if (kc.y < kc.maxY) { >> float acc = 0; >> for (int k = 0; k < size; k++) { >> acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + kc.y)); >> } >> matrixC.array(kc.x * size + kc.y, acc); >> } >> } >> } >> >> >> How to dispatch? >> >> The dispatcher now has more parameters to setup the max thread size for each dimension. In the case of a 2D: >> >> >> computeContext.dispatchKernel(maxX, maxY, >> kernelContext -> matrixMultiplyKernel2D(kernelContext, matrixA, matrixB, matrixC, size) >> ); >> >> >> ### How to test this patch? >> >> I extended the test-case for the matrix multiplication. >> >> Run with 1D: >> >> >> HAT=SHOW_CODE java @hat/run ffi-opencl matmul 1D >> >> >> Run with 2D >> >> >> HAT=SHOW_CODE java @hat/run ffi-opencl matmul 2D > > hat/core/src/main/java/hat/ComputeContext.java line 152: > >> 150: case 2 -> ndRange = accelerator.range(rangeX, rangeY); >> 151: case 3 -> ndRange = accelerator.range(rangeX, rangeY, rangeZ); >> 152: } > > Should we add a default branch that throws an exception instead of initializing `ndRange` to null? I thought about this. However, this method is method is private, and only the public dispatch method sets the value. I will add the exception though. ------------- PR Review Comment: https://git.openjdk.org/babylon/pull/496#discussion_r2227621008 From duke at openjdk.org Thu Jul 24 07:33:14 2025 From: duke at openjdk.org (Juan Fumero) Date: Thu, 24 Jul 2025 07:33:14 GMT Subject: [code-reflection] RFR: [feature][HAT] 2D and 3D ranges for the NDRange API [v2] In-Reply-To: References: Message-ID: > This patch introduces the concept of 2D and 3D ranges. > > This allows developers to do the following: > - Accessing 1D, 2D and 3D thread indexing within the kernels. The `KernelContext` API has been extended to do this. > - Dispatching 1D, 2D and 3D kernels via the `ComputeContext`. > > **IMPORTANT**: This patch has been tested for the OpenCL backend, the CUDA backend generates correct code, but for some reason I can't dispatch it due to CUDA incompatibilities (seems to be orthogonal to this PR). I will investigate this in a separate issue. > > An example of use is provided in the `matmul/Main.java` class. > > Example of 1D kernel in HAT: > > > @CodeReflection > public static void matrixMultiplyKernel1D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { > if (kc.x < kc.maxX) { > for (int j = 0; j < size; j++) { > float acc = 0; > for (int k = 0; k < size; k++) { > acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + j)); > } > matrixC.array(kc.x * size + j, acc); > } > } > } > > > Example of a 2D kernel: > > > @CodeReflection > public static void matrixMultiplyKernel2D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { > if (kc.x < kc.maxX) { > if (kc.y < kc.maxY) { > float acc = 0; > for (int k = 0; k < size; k++) { > acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + kc.y)); > } > matrixC.array(kc.x * size + kc.y, acc); > } > } > } > > > How to dispatch? > > The dispatcher now has more parameters to setup the max thread size for each dimension. In the case of a 2D: > > > computeContext.dispatchKernel(maxX, maxY, > kernelContext -> matrixMultiplyKernel2D(kernelContext, matrixA, matrixB, matrixC, size) > ); > > > ### How to test this patch? > > I extended the test-case for the matrix multiplication. > > Run with 1D: > > > HAT=SHOW_CODE java @hat/run ffi-opencl matmul 1D > > > Run with 2D > > > HAT=SHOW_CODE java @hat/run ffi-opencl matmul 2D Juan Fumero has updated the pull request incrementally with one additional commit since the last revision: [hat] launch exception if more than 3D configuration is set ------------- Changes: - all: https://git.openjdk.org/babylon/pull/496/files - new: https://git.openjdk.org/babylon/pull/496/files/3a081a5e..0bb26536 Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=496&range=01 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=496&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/496.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/496/head:pull/496 PR: https://git.openjdk.org/babylon/pull/496 From duke at openjdk.org Thu Jul 24 08:21:20 2025 From: duke at openjdk.org (Juan Fumero) Date: Thu, 24 Jul 2025 08:21:20 GMT Subject: [code-reflection] RFR: [feature][HAT] 2D and 3D ranges for the NDRange API [v3] In-Reply-To: References: Message-ID: > This patch introduces the concept of 2D and 3D ranges. > > This allows developers to do the following: > - Accessing 1D, 2D and 3D thread indexing within the kernels. The `KernelContext` API has been extended to do this. > - Dispatching 1D, 2D and 3D kernels via the `ComputeContext`. > > **IMPORTANT**: This patch has been tested for the OpenCL backend, the CUDA backend generates correct code, but for some reason I can't dispatch it due to CUDA incompatibilities (seems to be orthogonal to this PR). I will investigate this in a separate issue. > > An example of use is provided in the `matmul/Main.java` class. > > Example of 1D kernel in HAT: > > > @CodeReflection > public static void matrixMultiplyKernel1D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { > if (kc.x < kc.maxX) { > for (int j = 0; j < size; j++) { > float acc = 0; > for (int k = 0; k < size; k++) { > acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + j)); > } > matrixC.array(kc.x * size + j, acc); > } > } > } > > > Example of a 2D kernel: > > > @CodeReflection > public static void matrixMultiplyKernel2D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { > if (kc.x < kc.maxX) { > if (kc.y < kc.maxY) { > float acc = 0; > for (int k = 0; k < size; k++) { > acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + kc.y)); > } > matrixC.array(kc.x * size + kc.y, acc); > } > } > } > > > How to dispatch? > > The dispatcher now has more parameters to setup the max thread size for each dimension. In the case of a 2D: > > > computeContext.dispatchKernel(maxX, maxY, > kernelContext -> matrixMultiplyKernel2D(kernelContext, matrixA, matrixB, matrixC, size) > ); > > > ### How to test this patch? > > I extended the test-case for the matrix multiplication. > > Run with 1D: > > > HAT=SHOW_CODE java @hat/run ffi-opencl matmul 1D > > > Run with 2D > > > HAT=SHOW_CODE java @hat/run ffi-opencl matmul 2D Juan Fumero 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 three additional commits since the last revision: - Merge branch 'code-reflection' into dev/ndrange - [hat] launch exception if more than 3D configuration is set - [feature] 2D and 3D ranges for the NDRange API This patch introduces the concept of 2D and 3D ranges. This allows developers to: - Access 1D, 2D and 3D thread indexing within the kernels. The KernelContext API has been extended. - Dispatch 1D, 2D and 3D kernels via the ComputeContext. An example of use is provided in the matmul/Main.java class. ------------- Changes: - all: https://git.openjdk.org/babylon/pull/496/files - new: https://git.openjdk.org/babylon/pull/496/files/0bb26536..f69b190b Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=496&range=02 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=496&range=01-02 Stats: 386 lines in 9 files changed: 298 ins; 78 del; 10 mod Patch: https://git.openjdk.org/babylon/pull/496.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/496/head:pull/496 PR: https://git.openjdk.org/babylon/pull/496 From gfrost at openjdk.org Thu Jul 24 13:20:48 2025 From: gfrost at openjdk.org (Gary Frost) Date: Thu, 24 Jul 2025 13:20:48 GMT Subject: git: openjdk/babylon: code-reflection: [feature][HAT] 2D and 3D ranges for the NDRange API Message-ID: <27346194-493f-4cc2-bbdd-5f809fdb8073@openjdk.org> Changeset: 0159378c Branch: code-reflection Author: Juan Fumero Committer: Gary Frost Date: 2025-07-24 13:20:07 +0000 URL: https://git.openjdk.org/babylon/commit/0159378cbdd9045ac0d8c39f0df4d59e9ee5a14d [feature][HAT] 2D and 3D ranges for the NDRange API ! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaBackend.java ! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaHATKernelBuilder.java ! hat/backends/ffi/cuda/src/main/native/cpp/cuda_backend.cpp ! hat/backends/ffi/opencl/src/main/java/hat/backend/ffi/OpenCLBackend.java ! hat/backends/ffi/opencl/src/main/java/hat/backend/ffi/OpenCLHATKernelBuilder.java ! hat/backends/ffi/opencl/src/main/native/cpp/info.cpp ! hat/backends/ffi/opencl/src/main/native/cpp/opencl_backend_buffer.cpp ! hat/backends/ffi/opencl/src/main/native/cpp/opencl_backend_info.cpp ! hat/backends/ffi/opencl/src/main/native/cpp/opencl_backend_kernel.cpp ! hat/backends/ffi/opencl/src/main/native/cpp/opencl_backend_queue.cpp ! hat/backends/ffi/shared/src/main/java/hat/backend/ffi/C99FFIBackend.java ! hat/backends/ffi/shared/src/main/native/cpp/shared.cpp ! hat/backends/ffi/shared/src/main/native/include/shared.h ! hat/backends/jextracted/opencl/src/main/java/hat/backend/jextracted/OpenCLBackend.java ! hat/backends/jextracted/opencl/src/main/java/hat/backend/jextracted/OpenCLHatKernelBuilder.java ! hat/core/src/main/java/hat/Accelerator.java ! hat/core/src/main/java/hat/ComputeContext.java ! hat/core/src/main/java/hat/KernelContext.java ! hat/core/src/main/java/hat/NDRange.java ! hat/core/src/main/java/hat/backend/java/WorkStealer.java ! hat/core/src/main/java/hat/buffer/KernelContext.java ! hat/core/src/main/java/hat/codebuilders/C99HATKernelBuilder.java ! hat/examples/matmul/src/main/java/matmul/Main.java From duke at openjdk.org Thu Jul 24 13:23:11 2025 From: duke at openjdk.org (Juan Fumero) Date: Thu, 24 Jul 2025 13:23:11 GMT Subject: [code-reflection] RFR: [feature][HAT] 2D and 3D ranges for the NDRange API [v4] In-Reply-To: References: Message-ID: > This patch introduces the concept of 2D and 3D ranges. > > This allows developers to do the following: > - Accessing 1D, 2D and 3D thread indexing within the kernels. The `KernelContext` API has been extended to do this. > - Dispatching 1D, 2D and 3D kernels via the `ComputeContext`. > > **IMPORTANT**: This patch has been tested for the OpenCL backend, the CUDA backend generates correct code, but for some reason I can't dispatch it due to CUDA incompatibilities (seems to be orthogonal to this PR). I will investigate this in a separate issue. > > An example of use is provided in the `matmul/Main.java` class. > > Example of 1D kernel in HAT: > > > @CodeReflection > public static void matrixMultiplyKernel1D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { > if (kc.x < kc.maxX) { > for (int j = 0; j < size; j++) { > float acc = 0; > for (int k = 0; k < size; k++) { > acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + j)); > } > matrixC.array(kc.x * size + j, acc); > } > } > } > > > Example of a 2D kernel: > > > @CodeReflection > public static void matrixMultiplyKernel2D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { > if (kc.x < kc.maxX) { > if (kc.y < kc.maxY) { > float acc = 0; > for (int k = 0; k < size; k++) { > acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + kc.y)); > } > matrixC.array(kc.x * size + kc.y, acc); > } > } > } > > > How to dispatch? > > The dispatcher now has more parameters to setup the max thread size for each dimension. In the case of a 2D: > > > computeContext.dispatchKernel(maxX, maxY, > kernelContext -> matrixMultiplyKernel2D(kernelContext, matrixA, matrixB, matrixC, size) > ); > > > ### How to test this patch? > > I extended the test-case for the matrix multiplication. > > Run with 1D: > > > HAT=SHOW_CODE java @hat/run ffi-opencl matmul 1D > > > Run with 2D > > > HAT=SHOW_CODE java @hat/run ffi-opencl matmul 2D Juan Fumero has updated the pull request incrementally with one additional commit since the last revision: [hat] KernelContext dimensions fixed ------------- Changes: - all: https://git.openjdk.org/babylon/pull/496/files - new: https://git.openjdk.org/babylon/pull/496/files/f69b190b..c871ed2e Webrevs: - full: https://webrevs.openjdk.org/?repo=babylon&pr=496&range=03 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=496&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/babylon/pull/496.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/496/head:pull/496 PR: https://git.openjdk.org/babylon/pull/496 From duke at openjdk.org Thu Jul 24 13:23:12 2025 From: duke at openjdk.org (Juan Fumero) Date: Thu, 24 Jul 2025 13:23:12 GMT Subject: [code-reflection] RFR: [feature][HAT] 2D and 3D ranges for the NDRange API [v3] In-Reply-To: References: Message-ID: <5nOtbFy0iK0FksM19k55z114QICyaSwL4MY3hrmtKNE=.43386a33-b3dc-45a7-be8b-56ba8f4cfbed@github.com> On Thu, 24 Jul 2025 08:21:20 GMT, Juan Fumero wrote: >> This patch introduces the concept of 2D and 3D ranges. >> >> This allows developers to do the following: >> - Accessing 1D, 2D and 3D thread indexing within the kernels. The `KernelContext` API has been extended to do this. >> - Dispatching 1D, 2D and 3D kernels via the `ComputeContext`. >> >> **IMPORTANT**: This patch has been tested for the OpenCL backend, the CUDA backend generates correct code, but for some reason I can't dispatch it due to CUDA incompatibilities (seems to be orthogonal to this PR). I will investigate this in a separate issue. >> >> An example of use is provided in the `matmul/Main.java` class. >> >> Example of 1D kernel in HAT: >> >> >> @CodeReflection >> public static void matrixMultiplyKernel1D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { >> if (kc.x < kc.maxX) { >> for (int j = 0; j < size; j++) { >> float acc = 0; >> for (int k = 0; k < size; k++) { >> acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + j)); >> } >> matrixC.array(kc.x * size + j, acc); >> } >> } >> } >> >> >> Example of a 2D kernel: >> >> >> @CodeReflection >> public static void matrixMultiplyKernel2D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { >> if (kc.x < kc.maxX) { >> if (kc.y < kc.maxY) { >> float acc = 0; >> for (int k = 0; k < size; k++) { >> acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + kc.y)); >> } >> matrixC.array(kc.x * size + kc.y, acc); >> } >> } >> } >> >> >> How to dispatch? >> >> The dispatcher now has more parameters to setup the max thread size for each dimension. In the case of a 2D: >> >> >> computeContext.dispatchKernel(maxX, maxY, >> kernelContext -> matrixMultiplyKernel2D(kernelContext, matrixA, matrixB, matrixC, size) >> ); >> >> >> ### How to test this patch? >> >> I extended the test-case for the matrix multiplication. >> >> Run with 1D: >> >> >> HAT=SHOW_CODE java @hat/run ffi-opencl matmul 1D >> >> >> Run with 2D >> >> >> HAT=SHOW_CODE java @hat/run ffi-opencl matmul 2D > > Juan Fumero 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 three additional commits since the last revision: > > - Merge branch 'code-reflection' into dev/ndrange > - [hat] launch exception if more than 3D configuration is set > - [feature] 2D and 3D ranges for the NDRange API > > This patch introduces the concept of 2D and 3D ranges. > This allows developers to: > - Access 1D, 2D and 3D thread indexing within the kernels. > The KernelContext API has been extended. > - Dispatch 1D, 2D and 3D kernels via the ComputeContext. > > An example of use is provided in the matmul/Main.java class. I fixed the dimension based on Gary's feedback. This PR is ready. ------------- PR Comment: https://git.openjdk.org/babylon/pull/496#issuecomment-3113451887 From duke at openjdk.org Thu Jul 24 13:23:13 2025 From: duke at openjdk.org (Juan Fumero) Date: Thu, 24 Jul 2025 13:23:13 GMT Subject: [code-reflection] Integrated: [feature][HAT] 2D and 3D ranges for the NDRange API In-Reply-To: References: Message-ID: <_E7lZUHI4PIMgR8FIHHcOH62pfI9b4H4v21mZc6fYOI=.13031a03-280c-4769-887e-cfa9f6a372ad@github.com> On Wed, 23 Jul 2025 14:00:10 GMT, Juan Fumero wrote: > This patch introduces the concept of 2D and 3D ranges. > > This allows developers to do the following: > - Accessing 1D, 2D and 3D thread indexing within the kernels. The `KernelContext` API has been extended to do this. > - Dispatching 1D, 2D and 3D kernels via the `ComputeContext`. > > **IMPORTANT**: This patch has been tested for the OpenCL backend, the CUDA backend generates correct code, but for some reason I can't dispatch it due to CUDA incompatibilities (seems to be orthogonal to this PR). I will investigate this in a separate issue. > > An example of use is provided in the `matmul/Main.java` class. > > Example of 1D kernel in HAT: > > > @CodeReflection > public static void matrixMultiplyKernel1D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { > if (kc.x < kc.maxX) { > for (int j = 0; j < size; j++) { > float acc = 0; > for (int k = 0; k < size; k++) { > acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + j)); > } > matrixC.array(kc.x * size + j, acc); > } > } > } > > > Example of a 2D kernel: > > > @CodeReflection > public static void matrixMultiplyKernel2D(@RO KernelContext kc, @RO F32Array matrixA, @RO F32Array matrixB, @RW F32Array matrixC, int size) { > if (kc.x < kc.maxX) { > if (kc.y < kc.maxY) { > float acc = 0; > for (int k = 0; k < size; k++) { > acc += (matrixA.array(kc.x * size + k) * matrixB.array(k * size + kc.y)); > } > matrixC.array(kc.x * size + kc.y, acc); > } > } > } > > > How to dispatch? > > The dispatcher now has more parameters to setup the max thread size for each dimension. In the case of a 2D: > > > computeContext.dispatchKernel(maxX, maxY, > kernelContext -> matrixMultiplyKernel2D(kernelContext, matrixA, matrixB, matrixC, size) > ); > > > ### How to test this patch? > > I extended the test-case for the matrix multiplication. > > Run with 1D: > > > HAT=SHOW_CODE java @hat/run ffi-opencl matmul 1D > > > Run with 2D > > > HAT=SHOW_CODE java @hat/run ffi-opencl matmul 2D This pull request has now been integrated. Changeset: 0159378c Author: Juan Fumero Committer: Gary Frost URL: https://git.openjdk.org/babylon/commit/0159378cbdd9045ac0d8c39f0df4d59e9ee5a14d Stats: 405 lines in 23 files changed: 299 ins; 23 del; 83 mod [feature][HAT] 2D and 3D ranges for the NDRange API ------------- PR: https://git.openjdk.org/babylon/pull/496 From gfrost at openjdk.org Thu Jul 24 14:15:49 2025 From: gfrost at openjdk.org (Gary Frost) Date: Thu, 24 Jul 2025 14:15:49 GMT Subject: git: openjdk/babylon: code-reflection: Some documentation updates Message-ID: Changeset: ab4ef0a7 Branch: code-reflection Author: Gary Frost Date: 2025-07-24 14:14:36 +0000 URL: https://git.openjdk.org/babylon/commit/ab4ef0a70ea658a96fa405a728d2ba2cdcf6e95c Some documentation updates ! hat/docs/hat-01-03-building-hat.md + hat/docs/hat-array-and-vector-views.md ! hat/docs/hat-minimizing-buffer-transfers.md + hat/docs/hat-replace-kernel-graph-with-module-op.md From gfrost at openjdk.org Thu Jul 24 14:17:50 2025 From: gfrost at openjdk.org (Gary Frost) Date: Thu, 24 Jul 2025 14:17:50 GMT Subject: [code-reflection] Integrated: Some documentation updates Message-ID: Updated docs to reflect reality. Mostly additions describing project ideas. Added a section in the building/running with HAT, so how how we use `HAT` env variable to inject tracing, logging information at runtime. ------------- Commit messages: - Some documentation updates Changes: https://git.openjdk.org/babylon/pull/497/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=497&range=00 Stats: 465 lines in 4 files changed: 458 ins; 3 del; 4 mod Patch: https://git.openjdk.org/babylon/pull/497.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/497/head:pull/497 PR: https://git.openjdk.org/babylon/pull/497 From gfrost at openjdk.org Thu Jul 24 14:17:51 2025 From: gfrost at openjdk.org (Gary Frost) Date: Thu, 24 Jul 2025 14:17:51 GMT Subject: [code-reflection] Integrated: Some documentation updates In-Reply-To: References: Message-ID: On Thu, 24 Jul 2025 14:12:26 GMT, Gary Frost wrote: > Updated docs to reflect reality. > > Mostly additions describing project ideas. > > Added a section in the building/running with HAT, so how how we use `HAT` env variable to inject tracing, logging information at runtime. This pull request has now been integrated. Changeset: ab4ef0a7 Author: Gary Frost URL: https://git.openjdk.org/babylon/commit/ab4ef0a70ea658a96fa405a728d2ba2cdcf6e95c Stats: 465 lines in 4 files changed: 458 ins; 3 del; 4 mod Some documentation updates ------------- PR: https://git.openjdk.org/babylon/pull/497 From gfrost at openjdk.org Sat Jul 26 12:36:06 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 26 Jul 2025 12:36:06 GMT Subject: git: openjdk/babylon: code-reflection: Added some hat tooling from my secret stash Message-ID: Changeset: 85fa29bb Branch: code-reflection Author: Gary Frost Date: 2025-07-26 12:34:18 +0000 URL: https://git.openjdk.org/babylon/commit/85fa29bbd3b4be49b9daaea0a8527d17e22a0ea4 Added some hat tooling from my secret stash ! hat/.gitignore ! hat/hat/sanity.java ! hat/intellij/.idea/modules.xml ! hat/intellij/tools.iml - hat/tools/src/main/java/hat/codebuilders/OpCodeBuilder.java - hat/tools/src/main/java/hat/codebuilders/StyledOpCodeBuilder.java - hat/tools/src/main/java/hat/text/JavaCodeBuilder.java - hat/tools/src/main/java/hat/text/TerminalColors.java - hat/tools/src/main/java/hat/tools/Tool.java + hat/tools/src/main/java/hat/tools/text/JavaHATCodeBuilder.java + hat/tools/src/main/java/hat/tools/text/TestJavaHATCodeBuilder.java + hat/tools/src/main/java/hat/tools/textmodel/BabylonTextModel.java + hat/tools/src/main/java/hat/tools/textmodel/Cursor.java + hat/tools/src/main/java/hat/tools/textmodel/JavaTextModel.java + hat/tools/src/main/java/hat/tools/textmodel/TextModel.java + hat/tools/src/main/java/hat/tools/textmodel/html/Spanner.java + hat/tools/src/main/java/hat/tools/textmodel/html/tokens/GT_ENTITY.java + hat/tools/src/main/java/hat/tools/textmodel/html/tokens/LT_ENTITY.java + hat/tools/src/main/java/hat/tools/textmodel/terminal/ANSI.java + hat/tools/src/main/java/hat/tools/textmodel/terminal/CodeModelFormatter.java + hat/tools/src/main/java/hat/tools/textmodel/terminal/TestANSI.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/AbstractParentToken.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/AbstractToken.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/AbstractTokenWithCh.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/AbstractTokenWithLength.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Arrow.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/At.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Ch.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/CharLiteral.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Close.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Comment.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/DottedName.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Factory.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/FloatConst.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/IntConst.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Leaf.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/LeafReplacementToken.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/LineCol.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/LineComment.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Literal.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/MultiLineComment.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Nl.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Open.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/OpenClose.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Parent.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Parenthesis.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Pos.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/ReservedWord.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Root.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Seq.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/SingleCharLeaf.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Span.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/StringLiteral.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Token.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/Ws.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/defaults/Ch.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/defaults/CharLiteral.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/defaults/Close.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/defaults/LineComment.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/defaults/MultiLineComment.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/defaults/Nl.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/defaults/Open.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/defaults/Parenthesis.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/defaults/Seq.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/defaults/StringLiteral.java + hat/tools/src/main/java/hat/tools/textmodel/tokens/defaults/Ws.java + hat/tools/src/main/java/hat/tools/textmodel/ui/AbstractTextModelViewer.java + hat/tools/src/main/java/hat/tools/textmodel/ui/DocModelHighlightPainter.java + hat/tools/src/main/java/hat/tools/textmodel/ui/ElementSpan.java + hat/tools/src/main/java/hat/tools/textmodel/ui/FuncOpViewer.java + hat/tools/src/main/java/hat/tools/textmodel/ui/PaintableTextPane.java + hat/tools/src/main/java/hat/tools/textmodel/ui/TestFuncOpViewer.java + hat/tools/src/main/java/hat/tools/textmodel/ui/TextViewer.java From gfrost at openjdk.org Sat Jul 26 12:39:57 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 26 Jul 2025 12:39:57 GMT Subject: [code-reflection] Integrated: Added some hat tooling from my secret stash Message-ID: I have collected a bunch of tooling which I have used to analyse code models. I figured it was time to check them in, in case anyone else finds them useful. I will add a doc showing how to use them a little later. ------------- Commit messages: - Added some hat tooling from my secret stash Changes: https://git.openjdk.org/babylon/pull/498/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=498&range=00 Stats: 5216 lines in 73 files changed: 4749 ins; 458 del; 9 mod Patch: https://git.openjdk.org/babylon/pull/498.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/498/head:pull/498 PR: https://git.openjdk.org/babylon/pull/498 From gfrost at openjdk.org Sat Jul 26 12:39:58 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sat, 26 Jul 2025 12:39:58 GMT Subject: [code-reflection] Integrated: Added some hat tooling from my secret stash In-Reply-To: References: Message-ID: <7E6uc_KExG4jHGhNwQcC4yZqKKD9CTlxFp02fHj9mMo=.5a6eca66-312e-43ad-9f4f-1a302993d87a@github.com> On Sat, 26 Jul 2025 12:31:48 GMT, Gary Frost wrote: > I have collected a bunch of tooling which I have used to analyse code models. > > I figured it was time to check them in, in case anyone else finds them useful. > > I will add a doc showing how to use them a little later. This pull request has now been integrated. Changeset: 85fa29bb Author: Gary Frost URL: https://git.openjdk.org/babylon/commit/85fa29bbd3b4be49b9daaea0a8527d17e22a0ea4 Stats: 5216 lines in 73 files changed: 4749 ins; 458 del; 9 mod Added some hat tooling from my secret stash ------------- PR: https://git.openjdk.org/babylon/pull/498 From gfrost at openjdk.org Sun Jul 27 13:50:30 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sun, 27 Jul 2025 13:50:30 GMT Subject: git: openjdk/babylon: code-reflection: Add line number gutter to op viewer Message-ID: Changeset: 9d8d7c8e Branch: code-reflection Author: Gary Frost Date: 2025-07-27 13:49:26 +0000 URL: https://git.openjdk.org/babylon/commit/9d8d7c8ebf139f04e73314700c04d5f856229d97 Add line number gutter to op viewer ! hat/tools/src/main/java/hat/tools/textmodel/terminal/CodeModelFormatter.java ! hat/tools/src/main/java/hat/tools/textmodel/ui/AbstractTextModelViewer.java ! hat/tools/src/main/java/hat/tools/textmodel/ui/FuncOpViewer.java + hat/tools/src/main/java/hat/tools/textmodel/ui/TextGutter.java From gfrost at openjdk.org Sun Jul 27 13:53:02 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sun, 27 Jul 2025 13:53:02 GMT Subject: [code-reflection] Integrated: Add line number gutter to op viewer Message-ID: Added line number back to the op viewer tool. ------------- Commit messages: - Add line number gutter to op viewer Changes: https://git.openjdk.org/babylon/pull/499/files Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=499&range=00 Stats: 169 lines in 4 files changed: 141 ins; 15 del; 13 mod Patch: https://git.openjdk.org/babylon/pull/499.diff Fetch: git fetch https://git.openjdk.org/babylon.git pull/499/head:pull/499 PR: https://git.openjdk.org/babylon/pull/499 From gfrost at openjdk.org Sun Jul 27 13:53:02 2025 From: gfrost at openjdk.org (Gary Frost) Date: Sun, 27 Jul 2025 13:53:02 GMT Subject: [code-reflection] Integrated: Add line number gutter to op viewer In-Reply-To: References: Message-ID: On Sun, 27 Jul 2025 13:47:12 GMT, Gary Frost wrote: > Added line number back to the op viewer tool. This pull request has now been integrated. Changeset: 9d8d7c8e Author: Gary Frost URL: https://git.openjdk.org/babylon/commit/9d8d7c8ebf139f04e73314700c04d5f856229d97 Stats: 169 lines in 4 files changed: 141 ins; 15 del; 13 mod Add line number gutter to op viewer ------------- PR: https://git.openjdk.org/babylon/pull/499