From juan.fumero at oracle.com  Mon Sep  1 07:43:23 2025
From: juan.fumero at oracle.com (Juan Jose Fumero Alfonso)
Date: Mon, 1 Sep 2025 07:43:23 +0000
Subject: [issue][hat] CUDA Build for Linux with NVIDIA 580.76.05 and CUDA 13.0
Message-ID: <SJ0PR10MB4591ADBBF6E534DD5DDB79479B07A@SJ0PR10MB4591.namprd10.prod.outlook.com>

Hi all,
   Checking this morning on a new machine with Linux using the latest NVIDIA and CUDA drivers, the build fails for HAT:

```

/home/juan/repos/babylon/hat/backends/ffi/cuda/src/main/native/cpp/cuda_backend.cpp:85:31: error: too few arguments to function ?CUresult cuCtxCreate_v4(CUctx_st**, CUctxCreateParams*, unsigned int, CUdevice)?

   85 |         CUDA_CHECK(cuCtxCreate(&context, 0, device), "cuCtxCreate");

      |                               ^

/home/juan/repos/babylon/hat/backends/ffi/cuda/src/main/native/include/cuda_backend.h:78:16: note: in definition of macro ?CUDA_CHECK?

   78 |           .e = err, \

      |                ^~~

In file included from /home/juan/repos/babylon/hat/backends/ffi/cuda/src/main/native/include/cuda_backend.h:52:

/usr/local/cuda/include/cuda.h:6275:18: note: declared here

 6275 | CUresult CUDAAPI cuCtxCreate(CUcontext *pctx, CUctxCreateParams *ctxCreateParams, unsigned int flags, CUdevice dev);

      |                  ^~~~~~~~~~~

gmake[2]: *** [cuda/CMakeFiles/cuda_backend.dir/build.make:76: cuda/CMakeFiles/cuda_backend.dir/src/main/native/cpp/cuda_backend.cpp.o] Error 1

gmake[1]: *** [CMakeFiles/Makefile2:323: cuda/CMakeFiles/cuda_backend.dir/all] Error 2
```

For CUDA 13, this is the new call:
https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__CTX.html#group__CUDA__CTX_1g77e9fb578caefca5ed15b4acebf35265

This should be an easy fix, but I wonder if HAT should focus on CUDA 13+ or try to support both (12.x and 13+).

Juan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20250901/7fd91b5d/attachment-0001.htm>

From mcimadamore at openjdk.org  Mon Sep  1 10:16:03 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 10:16:03 GMT
Subject: [code-reflection] RFR: Fix lambda bugs [v8]
In-Reply-To: <DU1IBHZPSJd6Uo8SfccKYmFthFoFT1mqd1ARtkE-K8s=.735a2677-2035-49ad-9e27-0c576bc1283f@github.com>
References: <p25s5jYWGfNHZ8kkbcf2cF-ghnsXywswFh1sPGUQKHA=.2f902523-8d4c-45fd-966d-0cc54039721f@github.com>
 <DU1IBHZPSJd6Uo8SfccKYmFthFoFT1mqd1ARtkE-K8s=.735a2677-2035-49ad-9e27-0c576bc1283f@github.com>
Message-ID: <ao6FbA0q7FY5-yOvzCFYkYypgg1MF1hV-fMHk2I4V_Y=.5306929c-5b71-4f6d-8081-67dcc91dadc7@github.com>

On Fri, 29 Aug 2025 21:36:15 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Fix lambda bugs:
>> 1. Unnecessary load of static fields accessed inside the lambda body (bug 1).
>> 2. The model of a lambda expression that returns void, contains additional boxing whose result is not used (bug 2).
>> 3. Inner lambda is incorrectly quoted (bug 3).
>
> Mourad Abbay 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 10 additional commits since the last revision:
> 
>  - Merge branch 'code-reflection' into lambda-bugs
>  - Apply review comments
>  - Clarify comment
>  - Fix bug 3
>  - Add test cases to ensure bug 2 is fixed
>  - Fix bug 2
>  - Fix the bug of lambda model containing ReturnOp with value even though the lambda return type is void
>  - Add test case to ensure bug 1 is fixed
>  - Merge branch 'code-reflection' into lambda-bugs
>  - Fix lambda bug 1

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

> 1482:             // thus the condition (... body == tree)
> 1483:             // @@@ better name for isQuoted ?
> 1484:             boolean toQuote = (isQuoted && body == tree) || kind == FunctionalExpressionKind.QUOTED_STRUCTURAL;

Nice (and subtle!) fix

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

> 1502:             Type lambdaReturnType = tree.getDescriptorType(types).getReturnType();
> 1503:             if (tree.getBodyKind() == LambdaExpressionTree.BodyKind.EXPRESSION) {
> 1504:                 Value exprVal = toValue(((JCExpression) tree.body), lambdaReturnType);

I'd be tempted to check for `void` even before calling `toValue` -- it's a bit odd that we have to explicitly check for `VOID` in `coerce`

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

PR Review Comment: https://git.openjdk.org/babylon/pull/532#discussion_r2313525066
PR Review Comment: https://git.openjdk.org/babylon/pull/532#discussion_r2313526957

From mcimadamore at openjdk.org  Mon Sep  1 10:27:55 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 10:27:55 GMT
Subject: [code-reflection] RFR: Fix lambda bugs [v8]
In-Reply-To: <DU1IBHZPSJd6Uo8SfccKYmFthFoFT1mqd1ARtkE-K8s=.735a2677-2035-49ad-9e27-0c576bc1283f@github.com>
References: <p25s5jYWGfNHZ8kkbcf2cF-ghnsXywswFh1sPGUQKHA=.2f902523-8d4c-45fd-966d-0cc54039721f@github.com>
 <DU1IBHZPSJd6Uo8SfccKYmFthFoFT1mqd1ARtkE-K8s=.735a2677-2035-49ad-9e27-0c576bc1283f@github.com>
Message-ID: <u3i1g32ImNibPp3I41HONsM9H_3lJJevmtu2WPtMink=.afb26e84-62da-4b39-9517-2d9108dc827b@github.com>

On Fri, 29 Aug 2025 21:36:15 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Fix lambda bugs:
>> 1. Unnecessary load of static fields accessed inside the lambda body (bug 1).
>> 2. The model of a lambda expression that returns void, contains additional boxing whose result is not used (bug 2).
>> 3. Inner lambda is incorrectly quoted (bug 3).
>
> Mourad Abbay 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 10 additional commits since the last revision:
> 
>  - Merge branch 'code-reflection' into lambda-bugs
>  - Apply review comments
>  - Clarify comment
>  - Fix bug 3
>  - Add test cases to ensure bug 2 is fixed
>  - Fix bug 2
>  - Fix the bug of lambda model containing ReturnOp with value even though the lambda return type is void
>  - Add test case to ensure bug 1 is fixed
>  - Merge branch 'code-reflection' into lambda-bugs
>  - Fix lambda bug 1

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

> 1035:                     if (sym.name.equals(names._this) || sym.name.equals(names._super)) {
> 1036:                         result = thisValue();
> 1037:                     } else if (top.localToOp.containsKey(sym)) {

The correct check would be to see if `sym.getConstValue() != null`, which is also what the discriminator used by `QuotedLambdaScanner`:
https://github.com/mabbay/babylon/blob/77f2c77957677a95115bc9c829809ea099e20080/src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java#L577C73-L577C87

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

PR Review Comment: https://git.openjdk.org/babylon/pull/532#discussion_r2313557170

From mcimadamore at openjdk.org  Mon Sep  1 10:32:55 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 10:32:55 GMT
Subject: [code-reflection] RFR: Fix lambda bugs [v5]
In-Reply-To: <nlbcjuy5rPB1M0iDe0qp-aCrfPAYFP7CPfCihp8-STA=.aaf8e64e-816c-42ae-9bf9-b03b41082910@github.com>
References: <p25s5jYWGfNHZ8kkbcf2cF-ghnsXywswFh1sPGUQKHA=.2f902523-8d4c-45fd-966d-0cc54039721f@github.com>
 <AMl9LHujlZXymUmTSUA6gTU2q3rufSiZl8N9_e8t7HY=.671158d9-6e2c-4d50-8a91-59a44cdaa28e@github.com>
 <nlbcjuy5rPB1M0iDe0qp-aCrfPAYFP7CPfCihp8-STA=.aaf8e64e-816c-42ae-9bf9-b03b41082910@github.com>
Message-ID: <O86GCSdbITgBVENv-4EpkMJFgjVRFZwF5zpEfTEgp4k=.c7dc1550-7bbd-47cb-b6ee-f1aeea13b271@github.com>

On Tue, 26 Aug 2025 18:24:47 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bug 3
>
> test/langtools/tools/javac/reflect/QuotableSubtypeTest.java line 328:
> 
>> 326:             };
>> 327:             """)
>> 328:     // @@@ should this be the excepted behaviour in case we have a nested quotable lambda ?
> 
> Yes, the program behavior is to produce an instance of a functional interface whose implementation is bound to the lambda's body. Because the lambda is also targeted to a `Quotable` interface, there is additional program behaviour that gives access to the code model of the lambda via a corresponding Quoted instance.

I'm not sure about this... I get that the inner lambda has its own synthetic method with its own code model. But, if I take the outer lambda an execute it, e.g. using the Interpreter or BytecodeGenerator, won't I then have an issue -- as we would have lost the information that the nested lambda was quotable and, as such, required different treatment?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/532#discussion_r2313567805

From mcimadamore at openjdk.org  Mon Sep  1 10:37:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 10:37:00 GMT
Subject: [code-reflection] RFR: Update ReflectMethods.BodyScanner.coerce to
 handle null targetType
In-Reply-To: <WhI2B3roAVXSiXQtTwahV04v5Nn7I_MWAMbrdXo7SBI=.109c15a4-d27e-4cdc-a411-efeccf5e301f@github.com>
References: <WhI2B3roAVXSiXQtTwahV04v5Nn7I_MWAMbrdXo7SBI=.109c15a4-d27e-4cdc-a411-efeccf5e301f@github.com>
Message-ID: <Ttf08jhFBvFW1iKt91Jwx3BFpVawn9vVuJSCOALYUd0=.3e2840e2-7859-4b12-8d84-98777faee2f8@github.com>

On Fri, 29 Aug 2025 23:39:40 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> `ReflectMethods.BodyScanner.coerce` wasn't handling `null` targetType. For example, a `null` targetType may propagate to reach the method `coerce` when visiting case body of switch statement.

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

> 737: 
> 738:         Value coerce(Value sourceValue, Type sourceType, Type targetType) {
> 739:             if (targetType == null || targetType.hasTag(TypeTag.VOID)) {

Not sure about this -- as I'm not sure about `VOID`. E.g. this method should be called when we do have a target type. If there's no target type then there's nothing to coerce in the first place, and we shouldn't call this method. Can you describe more precisely why we end up with a `null` here?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/536#discussion_r2313576167

From gfrost at openjdk.org  Mon Sep  1 13:13:22 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 1 Sep 2025 13:13:22 GMT
Subject: git: openjdk/babylon: code-reflection: Hat remove opwrapper 4
Message-ID: <d24d6ee1-5f0d-455d-9b8d-026350ed0ab0@openjdk.org>

Changeset: 0b28fcbb
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-01 13:11:28 +0000
URL:       https://git.openjdk.org/babylon/commit/0b28fcbbe33a7da2251b6dcd3b5cec9d224ee2f6

Hat remove opwrapper 4

! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaBackend.java
! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/PTXHATKernelBuilder.java
! hat/backends/ffi/mock/src/main/java/hat/backend/ffi/MockBackend.java
! hat/backends/ffi/shared/src/main/java/hat/backend/ffi/C99FFIBackend.java
! hat/backends/ffi/shared/src/main/java/hat/backend/ffi/FFIBackend.java
! hat/backends/jextracted/shared/src/main/java/hat/backend/jextracted/C99JExtractedBackend.java
! hat/backends/jextracted/shared/src/main/java/hat/backend/jextracted/JExtractedBackend.java
! hat/core/src/main/java/hat/Accelerator.java
! hat/core/src/main/java/hat/ComputeContext.java
- hat/core/src/main/java/hat/OpsAndTypes.java
! hat/core/src/main/java/hat/backend/DebugBackend.java
! hat/core/src/main/java/hat/callgraph/ComputeCallGraph.java
! hat/core/src/main/java/hat/callgraph/KernelCallGraph.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/HATCodeBuilderContext.java
! hat/core/src/main/java/hat/codebuilders/HATCodeBuilderWithContext.java
! hat/core/src/main/java/hat/ifacemapper/MapperUtil.java
! hat/core/src/main/java/hat/ifacemapper/accessor/AccessorInfo.java
! hat/core/src/main/java/hat/optools/BinaryArithmeticOrLogicOperation.java
! hat/core/src/main/java/hat/optools/BinaryLogicalOpWrapper.java
! hat/core/src/main/java/hat/optools/BinaryOpWrapper.java
! hat/core/src/main/java/hat/optools/BinaryTestOpWrapper.java
- hat/core/src/main/java/hat/optools/BlockWrapper.java
- hat/core/src/main/java/hat/optools/BodyWrapper.java
! hat/core/src/main/java/hat/optools/ConstantOpWrapper.java
! hat/core/src/main/java/hat/optools/ConvOpWrapper.java
! hat/core/src/main/java/hat/optools/FieldAccessOpWrapper.java
! hat/core/src/main/java/hat/optools/FieldLoadOpWrapper.java
! hat/core/src/main/java/hat/optools/FieldStoreOpWrapper.java
! hat/core/src/main/java/hat/optools/ForOpWrapper.java
! hat/core/src/main/java/hat/optools/FuncCallOpWrapper.java
! hat/core/src/main/java/hat/optools/FuncOpWrapper.java
! hat/core/src/main/java/hat/optools/IfOpWrapper.java
! hat/core/src/main/java/hat/optools/InvokeOpWrapper.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/LambdaOpWrapper.java
! hat/core/src/main/java/hat/optools/LogicalOpWrapper.java
! hat/core/src/main/java/hat/optools/LoopOpWrapper.java
! hat/core/src/main/java/hat/optools/ModuleOpWrapper.java
+ hat/core/src/main/java/hat/optools/OpTk.java
! hat/core/src/main/java/hat/optools/OpWrapper.java
! hat/core/src/main/java/hat/optools/ReturnOpWrapper.java
! hat/core/src/main/java/hat/optools/RootSet.java
! hat/core/src/main/java/hat/optools/StructuralOpWrapper.java
! hat/core/src/main/java/hat/optools/TernaryOpWrapper.java
! hat/core/src/main/java/hat/optools/TupleOpWrapper.java
! hat/core/src/main/java/hat/optools/UnaryArithmeticOrLogicOpWrapper.java
! hat/core/src/main/java/hat/optools/UnaryOpWrapper.java
! hat/core/src/main/java/hat/optools/VarAccessOpWrapper.java
! hat/core/src/main/java/hat/optools/VarDeclarationOpWrapper.java
! hat/core/src/main/java/hat/optools/VarFuncDeclarationOpWrapper.java
! hat/core/src/main/java/hat/optools/VarLoadOpWrapper.java
! hat/core/src/main/java/hat/optools/VarOpWrapper.java
! hat/core/src/main/java/hat/optools/VarStoreOpWrapper.java
! hat/core/src/main/java/hat/optools/WhileOpWrapper.java
! hat/core/src/main/java/hat/optools/YieldOpWrapper.java
+ hat/core/src/main/java/hat/util/BiMap.java
! hat/core/src/main/java/hat/util/StreamCounter.java
+ hat/core/src/main/java/hat/util/StreamMutable.java
= hat/core/src/main/java/hat/util/StreamOptionalMutable.java
- hat/examples/experiments/src/main/java/experiments/InvokeToPtr.java
- hat/examples/experiments/src/main/java/experiments/PointyHat.java
- hat/examples/experiments/src/main/java/experiments/PointyHatArray.java
! hat/intellij/backend_jextracted_opencl.iml
! hat/intellij/wrap_opencl.iml
! hat/tools/src/main/java/hat/tools/text/JavaHATCodeBuilder.java


From gfrost at openjdk.org  Mon Sep  1 13:14:24 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 1 Sep 2025 13:14:24 GMT
Subject: [code-reflection] Integrated: Hat remove opwrapper 4
Message-ID: <lUv68tRuhFTlQmyCe3vbCseoqLKUpK1PPI9bBFUMhrc=.31410df3-407a-4e17-b33b-9ba1be409951@github.com>

Removal of OpWrappers continues. 

All but three OpWrappers are now stateless.  (FuncOp, LambdaOp & InvokeOp need cleaning up)

All the useful static helpers from the stateless wrappers consolidated in OpTK. 

Next step will involve actully deleting the stateless wrappers.

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

Commit messages:
 - Removed Lookup from all but three OpWrappers
 - Moved ParamTable to OpTk
 - Removed unused classes
 - HAT add missing Copyright
 - HAT moving all static OpWrapper methods to OpTk
 - HAT remove OpWrapper round 4

Changes: https://git.openjdk.org/babylon/pull/539/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=539&range=00
  Stats: 2366 lines in 70 files changed: 579 ins; 1540 del; 247 mod
  Patch: https://git.openjdk.org/babylon/pull/539.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/539/head:pull/539

PR: https://git.openjdk.org/babylon/pull/539

From gfrost at openjdk.org  Mon Sep  1 13:14:26 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 1 Sep 2025 13:14:26 GMT
Subject: [code-reflection] Integrated: Hat remove opwrapper 4
In-Reply-To: <lUv68tRuhFTlQmyCe3vbCseoqLKUpK1PPI9bBFUMhrc=.31410df3-407a-4e17-b33b-9ba1be409951@github.com>
References: <lUv68tRuhFTlQmyCe3vbCseoqLKUpK1PPI9bBFUMhrc=.31410df3-407a-4e17-b33b-9ba1be409951@github.com>
Message-ID: <Xs85zkK-EZ12RK6WNW88q1_BWPVzq64o4M6kRRLGL_s=.ef4fc6de-57d4-4915-a937-a1c7319a3b6c@github.com>

On Mon, 1 Sep 2025 13:08:53 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Removal of OpWrappers continues. 
> 
> All but three OpWrappers are now stateless.  (FuncOp, LambdaOp & InvokeOp need cleaning up)
> 
> All the useful static helpers from the stateless wrappers consolidated in OpTK. 
> 
> Next step will involve actully deleting the stateless wrappers.

This pull request has now been integrated.

Changeset: 0b28fcbb
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/0b28fcbbe33a7da2251b6dcd3b5cec9d224ee2f6
Stats:     2366 lines in 70 files changed: 579 ins; 1540 del; 247 mod

Hat remove opwrapper 4

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

PR: https://git.openjdk.org/babylon/pull/539

From mabbay at openjdk.org  Mon Sep  1 15:17:57 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 1 Sep 2025 15:17:57 GMT
Subject: [code-reflection] RFR: Update ReflectMethods.BodyScanner.coerce to
 handle null targetType
In-Reply-To: <Ttf08jhFBvFW1iKt91Jwx3BFpVawn9vVuJSCOALYUd0=.3e2840e2-7859-4b12-8d84-98777faee2f8@github.com>
References: <WhI2B3roAVXSiXQtTwahV04v5Nn7I_MWAMbrdXo7SBI=.109c15a4-d27e-4cdc-a411-efeccf5e301f@github.com>
 <Ttf08jhFBvFW1iKt91Jwx3BFpVawn9vVuJSCOALYUd0=.3e2840e2-7859-4b12-8d84-98777faee2f8@github.com>
Message-ID: <JQFPBNNKc487nSj4isHe5J4J3pdOsSeimRl6Cv6bieI=.8f3780be-3453-404b-b445-34095afe8f0e@github.com>

On Mon, 1 Sep 2025 10:34:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> `ReflectMethods.BodyScanner.coerce` wasn't handling `null` targetType. For example, a `null` targetType may propagate to reach the method `coerce` when visiting case body of switch statement.
>
> src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java line 739:
> 
>> 737: 
>> 738:         Value coerce(Value sourceValue, Type sourceType, Type targetType) {
>> 739:             if (targetType == null || targetType.hasTag(TypeTag.VOID)) {
> 
> Not sure about this -- as I'm not sure about `VOID`. E.g. this method should be called when we do have a target type. If there's no target type then there's nothing to coerce in the first place, and we shouldn't call this method. Can you describe more precisely why we end up with a `null` here?

For case body of a switch statement and body has a return. Because `bodyTarget` will be set to `yieldType` which is null, `bodyTarget` will then be used when we scan the return, this cause null to passed to `coerce`.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/536#discussion_r2314209482

From mabbay at openjdk.org  Mon Sep  1 15:36:03 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 1 Sep 2025 15:36:03 GMT
Subject: [code-reflection] RFR: Fix lambda bugs [v8]
In-Reply-To: <u3i1g32ImNibPp3I41HONsM9H_3lJJevmtu2WPtMink=.afb26e84-62da-4b39-9517-2d9108dc827b@github.com>
References: <p25s5jYWGfNHZ8kkbcf2cF-ghnsXywswFh1sPGUQKHA=.2f902523-8d4c-45fd-966d-0cc54039721f@github.com>
 <DU1IBHZPSJd6Uo8SfccKYmFthFoFT1mqd1ARtkE-K8s=.735a2677-2035-49ad-9e27-0c576bc1283f@github.com>
 <u3i1g32ImNibPp3I41HONsM9H_3lJJevmtu2WPtMink=.afb26e84-62da-4b39-9517-2d9108dc827b@github.com>
Message-ID: <1us9tmZ1zKX0H2vn8t6e376cA2Vw7bpRYgxBW_Osoeo=.643ea84a-000e-46f2-be0e-73f91a4686a5@github.com>

On Mon, 1 Sep 2025 10:25:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Mourad Abbay 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 10 additional commits since the last revision:
>> 
>>  - Merge branch 'code-reflection' into lambda-bugs
>>  - Apply review comments
>>  - Clarify comment
>>  - Fix bug 3
>>  - Add test cases to ensure bug 2 is fixed
>>  - Fix bug 2
>>  - Fix the bug of lambda model containing ReturnOp with value even though the lambda return type is void
>>  - Add test case to ensure bug 1 is fixed
>>  - Merge branch 'code-reflection' into lambda-bugs
>>  - Fix lambda bug 1
>
> src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java line 1037:
> 
>> 1035:                     if (sym.name.equals(names._this) || sym.name.equals(names._super)) {
>> 1036:                         result = thisValue();
>> 1037:                     } else if (top.localToOp.containsKey(sym)) {
> 
> The correct check would be to see if `sym.getConstValue() != null`, which is also what the discriminator used by `QuotedLambdaScanner`:
> https://github.com/mabbay/babylon/blob/77f2c77957677a95115bc9c829809ea099e20080/src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java#L577C73-L577C87

That check won't be enough, because for methods we don't register constant captured fields.
We need to check that `sym.getConstValue() != null && isQuoted`

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

PR Review Comment: https://git.openjdk.org/babylon/pull/532#discussion_r2314241483

From mabbay at openjdk.org  Mon Sep  1 15:39:00 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 1 Sep 2025 15:39:00 GMT
Subject: [code-reflection] RFR: Fix lambda bugs [v8]
In-Reply-To: <ao6FbA0q7FY5-yOvzCFYkYypgg1MF1hV-fMHk2I4V_Y=.5306929c-5b71-4f6d-8081-67dcc91dadc7@github.com>
References: <p25s5jYWGfNHZ8kkbcf2cF-ghnsXywswFh1sPGUQKHA=.2f902523-8d4c-45fd-966d-0cc54039721f@github.com>
 <DU1IBHZPSJd6Uo8SfccKYmFthFoFT1mqd1ARtkE-K8s=.735a2677-2035-49ad-9e27-0c576bc1283f@github.com>
 <ao6FbA0q7FY5-yOvzCFYkYypgg1MF1hV-fMHk2I4V_Y=.5306929c-5b71-4f6d-8081-67dcc91dadc7@github.com>
Message-ID: <CYE0vlI001LdX-fFrGhLa-I6CzrNd3beN5yt89UNF3k=.605ea116-0109-4bc4-a790-5586ff720c68@github.com>

On Mon, 1 Sep 2025 10:13:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Mourad Abbay 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 10 additional commits since the last revision:
>> 
>>  - Merge branch 'code-reflection' into lambda-bugs
>>  - Apply review comments
>>  - Clarify comment
>>  - Fix bug 3
>>  - Add test cases to ensure bug 2 is fixed
>>  - Fix bug 2
>>  - Fix the bug of lambda model containing ReturnOp with value even though the lambda return type is void
>>  - Add test case to ensure bug 1 is fixed
>>  - Merge branch 'code-reflection' into lambda-bugs
>>  - Fix lambda bug 1
>
> src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java line 1504:
> 
>> 1502:             Type lambdaReturnType = tree.getDescriptorType(types).getReturnType();
>> 1503:             if (tree.getBodyKind() == LambdaExpressionTree.BodyKind.EXPRESSION) {
>> 1504:                 Value exprVal = toValue(((JCExpression) tree.body), lambdaReturnType);
> 
> I'd be tempted to check for `void` even before calling `toValue` -- it's a bit odd that we have to explicitly check for `VOID` in `coerce`

We can check for `null` or `void` target type in `toValue`. Checking before `toValue` may require changes several places.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/532#discussion_r2314245294

From mabbay at openjdk.org  Mon Sep  1 15:51:57 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 1 Sep 2025 15:51:57 GMT
Subject: [code-reflection] RFR: Fix lambda bugs [v5]
In-Reply-To: <O86GCSdbITgBVENv-4EpkMJFgjVRFZwF5zpEfTEgp4k=.c7dc1550-7bbd-47cb-b6ee-f1aeea13b271@github.com>
References: <p25s5jYWGfNHZ8kkbcf2cF-ghnsXywswFh1sPGUQKHA=.2f902523-8d4c-45fd-966d-0cc54039721f@github.com>
 <AMl9LHujlZXymUmTSUA6gTU2q3rufSiZl8N9_e8t7HY=.671158d9-6e2c-4d50-8a91-59a44cdaa28e@github.com>
 <nlbcjuy5rPB1M0iDe0qp-aCrfPAYFP7CPfCihp8-STA=.aaf8e64e-816c-42ae-9bf9-b03b41082910@github.com>
 <O86GCSdbITgBVENv-4EpkMJFgjVRFZwF5zpEfTEgp4k=.c7dc1550-7bbd-47cb-b6ee-f1aeea13b271@github.com>
Message-ID: <j9MZhshR3P1nfXDkEiqNdzZrABT3WWLowsapIyIBpbs=.6944490d-6b9c-4b71-b8d1-4d5edfdc4d5b@github.com>

On Mon, 1 Sep 2025 10:30:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> test/langtools/tools/javac/reflect/QuotableSubtypeTest.java line 328:
>> 
>>> 326:             };
>>> 327:             """)
>>> 328:     // @@@ should this be the excepted behaviour in case we have a nested quotable lambda ?
>> 
>> Yes, the program behavior is to produce an instance of a functional interface whose implementation is bound to the lambda's body. Because the lambda is also targeted to a `Quotable` interface, there is additional program behaviour that gives access to the code model of the lambda via a corresponding Quoted instance.
>
> I'm not sure about this... I get that the inner lambda has its own synthetic method with its own code model. But, if I take the outer lambda an execute it, e.g. using the Interpreter or BytecodeGenerator, won't I then have an issue -- as we would have lost the information that the nested lambda was quotable and, as such, required different treatment?

The interpreter will make sure calling Op.ofQuotable for the inner lambda would return Quoted instance that has the  model of the lambda.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/532#discussion_r2314266568

From mcimadamore at openjdk.org  Mon Sep  1 17:30:55 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 1 Sep 2025 17:30:55 GMT
Subject: [code-reflection] RFR: Update ReflectMethods.BodyScanner.coerce to
 handle null targetType
In-Reply-To: <JQFPBNNKc487nSj4isHe5J4J3pdOsSeimRl6Cv6bieI=.8f3780be-3453-404b-b445-34095afe8f0e@github.com>
References: <WhI2B3roAVXSiXQtTwahV04v5Nn7I_MWAMbrdXo7SBI=.109c15a4-d27e-4cdc-a411-efeccf5e301f@github.com>
 <Ttf08jhFBvFW1iKt91Jwx3BFpVawn9vVuJSCOALYUd0=.3e2840e2-7859-4b12-8d84-98777faee2f8@github.com>
 <JQFPBNNKc487nSj4isHe5J4J3pdOsSeimRl6Cv6bieI=.8f3780be-3453-404b-b445-34095afe8f0e@github.com>
Message-ID: <AVIKrJ4GnvADwsJcgSpGowviyUi4Aiz4X34Vu4962es=.c411df40-87db-4fad-b2d9-d3f805969e5c@github.com>

On Mon, 1 Sep 2025 15:15:35 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java line 739:
>> 
>>> 737: 
>>> 738:         Value coerce(Value sourceValue, Type sourceType, Type targetType) {
>>> 739:             if (targetType == null || targetType.hasTag(TypeTag.VOID)) {
>> 
>> Not sure about this -- as I'm not sure about `VOID`. E.g. this method should be called when we do have a target type. If there's no target type then there's nothing to coerce in the first place, and we shouldn't call this method. Can you describe more precisely why we end up with a `null` here?
>
> For case body of a switch statement and body has a return. Because `bodyTarget` will be set to `yieldType` which is null, `bodyTarget` will then be used when we scan the return, this cause null to be passed to `coerce`.

Since `coerce` already handles void, would it be possible to use `voidType` as a possible type for `yieldType` ? (although, if there's no target `noType` might be better).

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

PR Review Comment: https://git.openjdk.org/babylon/pull/536#discussion_r2314387416

From gfrost at openjdk.org  Mon Sep  1 18:58:53 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 1 Sep 2025 18:58:53 GMT
Subject: git: openjdk/babylon: code-reflection: Hat remove opwrapper 5
Message-ID: <0222bf00-35d4-4528-b258-d627e6bd217d@openjdk.org>

Changeset: 71fc371a
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-01 18:57:53 +0000
URL:       https://git.openjdk.org/babylon/commit/71fc371a13ced86a7992d62ff4c73e6be7134921

Hat remove opwrapper 5

! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaBackend.java
! hat/backends/ffi/mock/src/main/java/hat/backend/ffi/MockBackend.java
! hat/backends/ffi/shared/src/main/java/hat/backend/ffi/C99FFIBackend.java
! hat/backends/ffi/shared/src/main/java/hat/backend/ffi/FFIBackend.java
! hat/backends/jextracted/shared/src/main/java/hat/backend/jextracted/C99JExtractedBackend.java
! hat/backends/jextracted/shared/src/main/java/hat/backend/jextracted/JExtractedBackend.java
! hat/core/src/main/java/hat/Accelerator.java
! hat/core/src/main/java/hat/ComputeContext.java
! hat/core/src/main/java/hat/backend/DebugBackend.java
! hat/core/src/main/java/hat/callgraph/CallGraph.java
! hat/core/src/main/java/hat/callgraph/ComputeCallGraph.java
! hat/core/src/main/java/hat/callgraph/ComputeEntrypoint.java
! hat/core/src/main/java/hat/callgraph/KernelCallGraph.java
! hat/core/src/main/java/hat/callgraph/KernelEntrypoint.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/HATCodeBuilder.java
! hat/core/src/main/java/hat/codebuilders/HATCodeBuilderContext.java
! hat/core/src/main/java/hat/codebuilders/HATCodeBuilderWithContext.java
! hat/core/src/main/java/hat/optools/FuncOpWrapper.java
! hat/core/src/main/java/hat/optools/InvokeOpWrapper.java
! hat/core/src/main/java/hat/optools/OpTk.java
! hat/core/src/main/java/hat/optools/OpWrapper.java
! hat/examples/experiments/src/main/java/experiments/QuotedTest.java
! hat/tools/src/main/java/hat/tools/text/JavaHATCodeBuilder.java
! hat/tools/src/main/java/hat/tools/text/TestJavaHATCodeBuilder.java


From gfrost at openjdk.org  Mon Sep  1 19:01:04 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 1 Sep 2025 19:01:04 GMT
Subject: [code-reflection] Integrated: Hat remove opwrapper 5
Message-ID: <QKM1LiEl__3yNgqG6Beqz-1g6ISuhtYAXEhswwb7HDQ=.e622f0e1-e39b-4e97-b4f1-32cb199e1b5f@github.com>

Removed OpWrappers from callgraph creation.  

One more round of refactoring and OpWrappers should be gone.

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

Commit messages:
 - removed opwrappers from callgraph creation
 - removed opwrappers from callgraph creation

Changes: https://git.openjdk.org/babylon/pull/540/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=540&range=00
  Stats: 436 lines in 26 files changed: 60 ins; 116 del; 260 mod
  Patch: https://git.openjdk.org/babylon/pull/540.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/540/head:pull/540

PR: https://git.openjdk.org/babylon/pull/540

From gfrost at openjdk.org  Mon Sep  1 19:01:04 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 1 Sep 2025 19:01:04 GMT
Subject: [code-reflection] Integrated: Hat remove opwrapper 5
In-Reply-To: <QKM1LiEl__3yNgqG6Beqz-1g6ISuhtYAXEhswwb7HDQ=.e622f0e1-e39b-4e97-b4f1-32cb199e1b5f@github.com>
References: <QKM1LiEl__3yNgqG6Beqz-1g6ISuhtYAXEhswwb7HDQ=.e622f0e1-e39b-4e97-b4f1-32cb199e1b5f@github.com>
Message-ID: <FxYHvue1EPs0zl7brDapO6OXnl7YMl3yKJcQWxSPJbo=.5ed5c4c2-5608-47fb-b081-d0c3277a66af@github.com>

On Mon, 1 Sep 2025 18:55:46 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Removed OpWrappers from callgraph creation.  
> 
> One more round of refactoring and OpWrappers should be gone.

This pull request has now been integrated.

Changeset: 71fc371a
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/71fc371a13ced86a7992d62ff4c73e6be7134921
Stats:     436 lines in 26 files changed: 60 ins; 116 del; 260 mod

Hat remove opwrapper 5

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

PR: https://git.openjdk.org/babylon/pull/540

From psandoz at openjdk.org  Tue Sep  2 15:39:04 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 2 Sep 2025 15:39:04 GMT
Subject: [code-reflection] RFR: Fix lambda bugs [v5]
In-Reply-To: <j9MZhshR3P1nfXDkEiqNdzZrABT3WWLowsapIyIBpbs=.6944490d-6b9c-4b71-b8d1-4d5edfdc4d5b@github.com>
References: <p25s5jYWGfNHZ8kkbcf2cF-ghnsXywswFh1sPGUQKHA=.2f902523-8d4c-45fd-966d-0cc54039721f@github.com>
 <AMl9LHujlZXymUmTSUA6gTU2q3rufSiZl8N9_e8t7HY=.671158d9-6e2c-4d50-8a91-59a44cdaa28e@github.com>
 <nlbcjuy5rPB1M0iDe0qp-aCrfPAYFP7CPfCihp8-STA=.aaf8e64e-816c-42ae-9bf9-b03b41082910@github.com>
 <O86GCSdbITgBVENv-4EpkMJFgjVRFZwF5zpEfTEgp4k=.c7dc1550-7bbd-47cb-b6ee-f1aeea13b271@github.com>
 <j9MZhshR3P1nfXDkEiqNdzZrABT3WWLowsapIyIBpbs=.6944490d-6b9c-4b71-b8d1-4d5edfdc4d5b@github.com>
Message-ID: <eHXTIeQgkRWS5Jix5oZlnVQ6ezvKjHqhd_5rA5LlaDE=.5ff19750-8372-4d41-a4b3-4c66d952052a@github.com>

On Mon, 1 Sep 2025 15:49:08 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> I'm not sure about this... I get that the inner lambda has its own synthetic method with its own code model. But, if I take the outer lambda an execute it, e.g. using the Interpreter or BytecodeGenerator, won't I then have an issue -- as we would have lost the information that the nested lambda was quotable and, as such, required different treatment?
>
> The interpreter will make sure calling Op.ofQuotable for the inner lambda would return Quoted instance that has the  model of the lambda.

I think we need to strengthen the signal that the lambda op's behavior is to produce an instance of a functional interface that may also be quotable. Requiring that we resolve the functional interface reference is too fragile.

The lambda op could have an optional attribute that indicates it has quotable behaviour, independent of whether the functional interface extends `Quotable` (or we cast an intersection of `Quotable`).

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

PR Review Comment: https://git.openjdk.org/babylon/pull/532#discussion_r2316463706

From gfrost at openjdk.org  Tue Sep  2 15:40:19 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 2 Sep 2025 15:40:19 GMT
Subject: git: openjdk/babylon: code-reflection: All OpWrappers now removed.
Message-ID: <79f9dd19-1fc5-4af3-88f4-d2664266c55d@openjdk.org>

Changeset: 59ace843
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-02 15:38:05 +0000
URL:       https://git.openjdk.org/babylon/commit/59ace843f281fa7756de63487e88930ba18f8b1f

All OpWrappers now removed.

! 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/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/FFIBackend.java
! hat/backends/jextracted/opencl/src/main/java/hat/backend/jextracted/OpenCLHatKernelBuilder.java
! hat/backends/jextracted/shared/src/main/java/hat/backend/jextracted/JExtractedBackend.java
! hat/core/src/main/java/hat/Accelerator.java
! hat/core/src/main/java/hat/ComputeContext.java
! hat/core/src/main/java/hat/callgraph/ComputeCallGraph.java
! hat/core/src/main/java/hat/callgraph/ComputeEntrypoint.java
! hat/core/src/main/java/hat/callgraph/KernelCallGraph.java
! hat/core/src/main/java/hat/callgraph/KernelEntrypoint.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/HATCodeBuilder.java
! hat/core/src/main/java/hat/codebuilders/HATCodeBuilderContext.java
! hat/core/src/main/java/hat/codebuilders/HATCodeBuilderWithContext.java
- hat/core/src/main/java/hat/optools/BinaryArithmeticOrLogicOperation.java
- hat/core/src/main/java/hat/optools/BinaryLogicalOpWrapper.java
- hat/core/src/main/java/hat/optools/BinaryOpWrapper.java
- hat/core/src/main/java/hat/optools/BinaryTestOpWrapper.java
- hat/core/src/main/java/hat/optools/CodeElementWrapper.java
- hat/core/src/main/java/hat/optools/ConstantOpWrapper.java
- hat/core/src/main/java/hat/optools/ConvOpWrapper.java
- hat/core/src/main/java/hat/optools/FieldAccessOpWrapper.java
- hat/core/src/main/java/hat/optools/FieldLoadOpWrapper.java
- hat/core/src/main/java/hat/optools/FieldStoreOpWrapper.java
- hat/core/src/main/java/hat/optools/ForOpWrapper.java
- hat/core/src/main/java/hat/optools/FuncCallOpWrapper.java
- hat/core/src/main/java/hat/optools/FuncOpWrapper.java
- hat/core/src/main/java/hat/optools/IfOpWrapper.java
- hat/core/src/main/java/hat/optools/InvokeOpWrapper.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/LambdaOpWrapper.java
- hat/core/src/main/java/hat/optools/LoadOpWrapper.java
- hat/core/src/main/java/hat/optools/LogicalOpWrapper.java
- hat/core/src/main/java/hat/optools/LoopOpWrapper.java
- hat/core/src/main/java/hat/optools/ModuleOpWrapper.java
! hat/core/src/main/java/hat/optools/OpTk.java
- hat/core/src/main/java/hat/optools/OpWrapper.java
- hat/core/src/main/java/hat/optools/ReturnOpWrapper.java
- hat/core/src/main/java/hat/optools/RootSet.java
- hat/core/src/main/java/hat/optools/StoreOpWrapper.java
- hat/core/src/main/java/hat/optools/StructuralOpWrapper.java
- hat/core/src/main/java/hat/optools/TernaryOpWrapper.java
- hat/core/src/main/java/hat/optools/TupleOpWrapper.java
- hat/core/src/main/java/hat/optools/UnaryArithmeticOrLogicOpWrapper.java
- hat/core/src/main/java/hat/optools/UnaryOpWrapper.java
- hat/core/src/main/java/hat/optools/VarAccessOpWrapper.java
- hat/core/src/main/java/hat/optools/VarDeclarationOpWrapper.java
- hat/core/src/main/java/hat/optools/VarFuncDeclarationOpWrapper.java
- hat/core/src/main/java/hat/optools/VarLoadOpWrapper.java
- hat/core/src/main/java/hat/optools/VarOpWrapper.java
- hat/core/src/main/java/hat/optools/VarStoreOpWrapper.java
- hat/core/src/main/java/hat/optools/WhileOpWrapper.java
- hat/core/src/main/java/hat/optools/YieldOpWrapper.java
! hat/examples/experiments/src/main/java/experiments/DependencyTree.java
! hat/examples/experiments/src/main/java/experiments/QuotedTest.java
! hat/tools/src/main/java/hat/tools/text/JavaHATCodeBuilder.java
! hat/tools/src/main/java/hat/tools/text/TestJavaHATCodeBuilder.java


From gfrost at openjdk.org  Tue Sep  2 15:41:14 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 2 Sep 2025 15:41:14 GMT
Subject: [code-reflection] Integrated: All OpWrappers now removed.
Message-ID: <Ai6Tx66JHMsc5Eb0I7NbzPCIYNlPv5PYuPBdpsrsJm0=.20dea782-a465-4a02-b2e3-d155d94b7e8d@github.com>

This is the final step of removing OpWrappers we now basically use the raw babylon code model ops. 

Lots of changes in this commit/PR.  Including lots of deletions in this one.

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

Commit messages:
 - all OpWrappers removed
 - cleaned all imports - ready to delete OpWrappers
 - removed OpWrapper.wrap and all seems ok
 - switched most of c99 code gen to non wrapped ops
 - Simplifying rootset capture
 - Moved rootset helper into OpTk

Changes: https://git.openjdk.org/babylon/pull/541/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=541&range=00
  Stats: 2423 lines in 63 files changed: 162 ins; 1818 del; 443 mod
  Patch: https://git.openjdk.org/babylon/pull/541.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/541/head:pull/541

PR: https://git.openjdk.org/babylon/pull/541

From gfrost at openjdk.org  Tue Sep  2 15:41:14 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 2 Sep 2025 15:41:14 GMT
Subject: [code-reflection] Integrated: All OpWrappers now removed.
In-Reply-To: <Ai6Tx66JHMsc5Eb0I7NbzPCIYNlPv5PYuPBdpsrsJm0=.20dea782-a465-4a02-b2e3-d155d94b7e8d@github.com>
References: <Ai6Tx66JHMsc5Eb0I7NbzPCIYNlPv5PYuPBdpsrsJm0=.20dea782-a465-4a02-b2e3-d155d94b7e8d@github.com>
Message-ID: <0c7BjPmtP1WNbtz3LmOarnLGcDF52A0DWBO_YugpFt8=.fd236fd8-6a1f-4276-8508-eca5154a270c@github.com>

On Tue, 2 Sep 2025 15:36:29 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> This is the final step of removing OpWrappers we now basically use the raw babylon code model ops. 
> 
> Lots of changes in this commit/PR.  Including lots of deletions in this one.

This pull request has now been integrated.

Changeset: 59ace843
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/59ace843f281fa7756de63487e88930ba18f8b1f
Stats:     2423 lines in 63 files changed: 162 ins; 1818 del; 443 mod

All OpWrappers now removed.

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

PR: https://git.openjdk.org/babylon/pull/541

From mabbay at openjdk.org  Tue Sep  2 19:34:40 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 2 Sep 2025 19:34:40 GMT
Subject: [code-reflection] RFR: Update ReflectMethods.BodyScanner.coerce to
 handle null targetType [v2]
In-Reply-To: <WhI2B3roAVXSiXQtTwahV04v5Nn7I_MWAMbrdXo7SBI=.109c15a4-d27e-4cdc-a411-efeccf5e301f@github.com>
References: <WhI2B3roAVXSiXQtTwahV04v5Nn7I_MWAMbrdXo7SBI=.109c15a4-d27e-4cdc-a411-efeccf5e301f@github.com>
Message-ID: <oNVZgjrnEKj4Q0V2FKhskHFMvQT2lCgKASMk1NGwnus=.3a900db9-7adb-4e61-98aa-8ef56a9b51ab@github.com>

> `ReflectMethods.BodyScanner.coerce` wasn't handling `null` targetType. For example, a `null` targetType may propagate to reach the method `coerce` when visiting case body of switch statement.

Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:

 - Move the checks out of coerce
 - Set bodyType to void when scanning a switch expression

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/536/files
  - new: https://git.openjdk.org/babylon/pull/536/files/3a58bffc..3b7ad47a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=536&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=536&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/babylon/pull/536.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/536/head:pull/536

PR: https://git.openjdk.org/babylon/pull/536

From duke at openjdk.org  Tue Sep  2 20:35:40 2025
From: duke at openjdk.org (Ruby Chen)
Date: Tue, 2 Sep 2025 20:35:40 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests
Message-ID: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>

Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a trivial phi is not removed from its own user list before `phi.replaceBy(same, this)` is called to replace all users of the trivial phi.  

Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones.

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

Commit messages:
 - Fix SSABraun bug and add SSA tests

Changes: https://git.openjdk.org/babylon/pull/542/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=542&range=00
  Stats: 156 lines in 2 files changed: 153 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/babylon/pull/542.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/542/head:pull/542

PR: https://git.openjdk.org/babylon/pull/542

From hgreule at openjdk.org  Tue Sep  2 21:04:52 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 2 Sep 2025 21:04:52 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests
In-Reply-To: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
Message-ID: <79JIcxNA10nUgXx0ZiFGBS26Jag8UQn9s7pE26Gmkxs=.47818999-1c75-49ee-b7dc-47f6ac45b168@github.com>

On Tue, 2 Sep 2025 20:30:58 GMT, Ruby Chen <duke at openjdk.org> wrote:

> Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a trivial phi is not removed from its own user list before `phi.replaceBy(same, this)` is called to replace all users of the trivial phi.  
> 
> Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones.

Hi, it's not obvious to me what the bug is. The `replaceBy` method has the `user == this` check; what's the difference to removing itself before? And is the returned list wrong, or why aren't you using it anymore?

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

PR Comment: https://git.openjdk.org/babylon/pull/542#issuecomment-3246778748

From duke at openjdk.org  Tue Sep  2 22:04:58 2025
From: duke at openjdk.org (Ruby Chen)
Date: Tue, 2 Sep 2025 22:04:58 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests
In-Reply-To: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
Message-ID: <nhLFAZgYCBEdxZFbV20bsrCV_RjZEbYdoT4NODwQQeM=.e042be69-a042-42f5-a809-be15115d7cdc@github.com>

On Tue, 2 Sep 2025 20:30:58 GMT, Ruby Chen <duke at openjdk.org> wrote:

> Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a trivial phi is not removed from its own user list before `phi.replaceBy(same, this)` is called to replace all users of the trivial phi.  
> 
> Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones.

Hi! Sorry about the confusion; I just realized this change doesn't actually fix the bug, and that the core of the problem lies in how the maps `additionalParameters` and `loads` update. 

Your original code in `tryRemoveTrivialPhi()` was correct, but when a phi is added to `additionalParameters` and is later replaced by a parameter via `replaceBy()`, both `additionalParameters` and `loads` are not updated to keep track of the new parameter. 

I can restore your code and implement those changes to make sure that the two maps replace deleted phis with appropriate values.

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

PR Comment: https://git.openjdk.org/babylon/pull/542#issuecomment-3246932311

From mcimadamore at openjdk.org  Wed Sep  3 10:03:06 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 Sep 2025 10:03:06 GMT
Subject: [code-reflection] RFR: Update ReflectMethods.BodyScanner.coerce to
 handle null targetType [v2]
In-Reply-To: <oNVZgjrnEKj4Q0V2FKhskHFMvQT2lCgKASMk1NGwnus=.3a900db9-7adb-4e61-98aa-8ef56a9b51ab@github.com>
References: <WhI2B3roAVXSiXQtTwahV04v5Nn7I_MWAMbrdXo7SBI=.109c15a4-d27e-4cdc-a411-efeccf5e301f@github.com>
 <oNVZgjrnEKj4Q0V2FKhskHFMvQT2lCgKASMk1NGwnus=.3a900db9-7adb-4e61-98aa-8ef56a9b51ab@github.com>
Message-ID: <8llDXkrtP3QrPhs9vpeeBU__G2Rd9RXlvtCdKYoZTT4=.20475a9f-3424-4a67-a694-87963e3a2209@github.com>

On Tue, 2 Sep 2025 19:34:40 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> `ReflectMethods.BodyScanner.coerce` wasn't handling `null` targetType. For example, a `null` targetType may propagate to reach the method `coerce` when visiting case body of switch statement.
>
> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move the checks out of coerce
>  - Set bodyType to void when scanning a switch expression

Looks good - I left some minor (optional) stylistic comments

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

> 718:                 pt = targetType;
> 719:                 scan(expression);
> 720:                 return result == null || targetType.hasTag(TypeTag.VOID) ? result : coerce(result, expression.type, targetType);

I'd suggest to format like this:


return (result == null || targetType.hasTag(TypeTag.VOID)) ?
    result : coerce(result, expression.type, targetType);


As sometimes humans have issue parsing long conditionals :-)

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

> 1772:         private Body.Builder visitCaseBody(JCTree tree, JCTree.JCCase c, FunctionType caseBodyType) {
> 1773:             Body.Builder body = null;
> 1774:             Type yieldType = tree.type != null ? adaptBottom(tree.type) : syms.voidType;

In general, javac uses `Type.noType` when no target exists. But I understand that here you also want to deal with cases where the target is `void` (because the target is automatically derived from some method return type). We can keep it as is, or we can turn void targets into `noType` and then have `toValue` ignore `noType` (instead of ignoring `void`). Your choice.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/babylon/pull/536#pullrequestreview-3179901532
PR Review Comment: https://git.openjdk.org/babylon/pull/536#discussion_r2318445353
PR Review Comment: https://git.openjdk.org/babylon/pull/536#discussion_r2318451964

From mabbay at openjdk.org  Wed Sep  3 13:41:13 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 3 Sep 2025 13:41:13 GMT
Subject: [code-reflection] RFR: Fix lambda bugs [v8]
In-Reply-To: <1us9tmZ1zKX0H2vn8t6e376cA2Vw7bpRYgxBW_Osoeo=.643ea84a-000e-46f2-be0e-73f91a4686a5@github.com>
References: <p25s5jYWGfNHZ8kkbcf2cF-ghnsXywswFh1sPGUQKHA=.2f902523-8d4c-45fd-966d-0cc54039721f@github.com>
 <DU1IBHZPSJd6Uo8SfccKYmFthFoFT1mqd1ARtkE-K8s=.735a2677-2035-49ad-9e27-0c576bc1283f@github.com>
 <u3i1g32ImNibPp3I41HONsM9H_3lJJevmtu2WPtMink=.afb26e84-62da-4b39-9517-2d9108dc827b@github.com>
 <1us9tmZ1zKX0H2vn8t6e376cA2Vw7bpRYgxBW_Osoeo=.643ea84a-000e-46f2-be0e-73f91a4686a5@github.com>
Message-ID: <OIrb8HbTEDMZteq2VcWWJ8jbfMUpKQ2bERGXR2eBQUk=.92e32385-3480-4345-a008-6aeb9e11b61f@github.com>

On Mon, 1 Sep 2025 15:33:44 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java line 1037:
>> 
>>> 1035:                     if (sym.name.equals(names._this) || sym.name.equals(names._super)) {
>>> 1036:                         result = thisValue();
>>> 1037:                     } else if (top.localToOp.containsKey(sym)) {
>> 
>> The correct check would be to see if `sym.getConstValue() != null`, which is also what the discriminator used by `QuotedLambdaScanner`:
>> https://github.com/mabbay/babylon/blob/77f2c77957677a95115bc9c829809ea099e20080/src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java#L577C73-L577C87
>
> That check won't be enough, because for methods we don't register constant captured fields.
> We need to check that `sym.getConstValue() != null && isQuoted`

we may need to unify the approach between methods and lambdas. For now, we embed constant fields for lambdas but we don't do it for methods. We may also consider doing true constant folding.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/532#discussion_r2319013715

From jfumero at openjdk.org  Wed Sep  3 13:44:08 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Wed, 3 Sep 2025 13:44:08 GMT
Subject: [code-reflection] RFR: [hat][fix] create context with v4 function
Message-ID: <OuGUTI_ySlVwPGIDbHaoFNYWRf2n0oGnyadG1btcHbY=.a88e003d-391c-4fde-8829-01bf186f393c@github.com>

Invoke the `cuCtxCreate` with 4 parameters to match the CUDA 13.0 default API. 

This patch has been tested for CUDA 12.8 and CUDA 13.0.

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

Commit messages:
 - [hat][fix] create context with v4 function

Changes: https://git.openjdk.org/babylon/pull/543/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=543&range=00
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/babylon/pull/543.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/543/head:pull/543

PR: https://git.openjdk.org/babylon/pull/543

From duke at openjdk.org  Wed Sep  3 13:44:08 2025
From: duke at openjdk.org (duke)
Date: Wed, 3 Sep 2025 13:44:08 GMT
Subject: [code-reflection] RFR: [hat][fix] create context with v4 function
In-Reply-To: <OuGUTI_ySlVwPGIDbHaoFNYWRf2n0oGnyadG1btcHbY=.a88e003d-391c-4fde-8829-01bf186f393c@github.com>
References: <OuGUTI_ySlVwPGIDbHaoFNYWRf2n0oGnyadG1btcHbY=.a88e003d-391c-4fde-8829-01bf186f393c@github.com>
Message-ID: <8UvgP6q7htHw0rdegdIffBBiR-lz8Uvt09pJ9cGhYLw=.3a86a7e5-66b1-408d-bacc-5cb4a3318146@github.com>

On Wed, 3 Sep 2025 13:37:06 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> Invoke the `cuCtxCreate` with 4 parameters to match the CUDA 13.0 default API. 
> 
> This patch has been tested for CUDA 12.8 and CUDA 13.0.

@jjfumero 
Your change (at version 44bfcf2e1b88c38c0bb9e4c330b7e1f6f2b7d9c1) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/babylon/pull/543#issuecomment-3249313484

From mabbay at openjdk.org  Wed Sep  3 13:49:07 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 3 Sep 2025 13:49:07 GMT
Subject: [code-reflection] RFR: Update ReflectMethods.BodyScanner.coerce to
 handle null targetType [v3]
In-Reply-To: <WhI2B3roAVXSiXQtTwahV04v5Nn7I_MWAMbrdXo7SBI=.109c15a4-d27e-4cdc-a411-efeccf5e301f@github.com>
References: <WhI2B3roAVXSiXQtTwahV04v5Nn7I_MWAMbrdXo7SBI=.109c15a4-d27e-4cdc-a411-efeccf5e301f@github.com>
Message-ID: <LKGcJosvqcGpkndZLK6GI1pvNOxqGdnXr8wVxwNZmMo=.d73d0530-5321-4d67-b19f-0c259b7b1501@github.com>

> `ReflectMethods.BodyScanner.coerce` wasn't handling `null` targetType. For example, a `null` targetType may propagate to reach the method `coerce` when visiting case body of switch statement.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/536/files
  - new: https://git.openjdk.org/babylon/pull/536/files/3b7ad47a..46768674

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=536&range=02
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=536&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/babylon/pull/536.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/536/head:pull/536

PR: https://git.openjdk.org/babylon/pull/536

From gfrost at openjdk.org  Wed Sep  3 13:49:38 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 3 Sep 2025 13:49:38 GMT
Subject: git: openjdk/babylon: code-reflection: [hat][fix] create context with
 v4 function
Message-ID: <a04dc914-f0ae-45e3-affd-69125e235126@openjdk.org>

Changeset: c2757a1c
Branch: code-reflection
Author:    Juan Fumero <jfumero at openjdk.org>
Committer: Gary Frost <gfrost at openjdk.org>
Date:      2025-09-03 13:46:49 +0000
URL:       https://git.openjdk.org/babylon/commit/c2757a1cdd68fd8e4d29d4e3e7cbed03b8b9a0e7

[hat][fix] create context with v4 function

! hat/backends/ffi/cuda/src/main/native/cpp/cuda_backend.cpp


From jfumero at openjdk.org  Wed Sep  3 13:52:06 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Wed, 3 Sep 2025 13:52:06 GMT
Subject: [code-reflection] Integrated: [hat][fix] create context with v4
 function
In-Reply-To: <OuGUTI_ySlVwPGIDbHaoFNYWRf2n0oGnyadG1btcHbY=.a88e003d-391c-4fde-8829-01bf186f393c@github.com>
References: <OuGUTI_ySlVwPGIDbHaoFNYWRf2n0oGnyadG1btcHbY=.a88e003d-391c-4fde-8829-01bf186f393c@github.com>
Message-ID: <fYU4qcFAuvYFrIECSPUu6-K51yx3ZoRPR8VuAgRR-b8=.d24a91f0-bfd2-462d-b502-3299d8b8f5ec@github.com>

On Wed, 3 Sep 2025 13:37:06 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> Invoke the `cuCtxCreate` with 4 parameters to match the CUDA 13.0 default API. 
> 
> This patch has been tested for CUDA 12.8 and CUDA 13.0.

This pull request has now been integrated.

Changeset: c2757a1c
Author:    Juan Fumero <jfumero at openjdk.org>
Committer: Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/c2757a1cdd68fd8e4d29d4e3e7cbed03b8b9a0e7
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

[hat][fix] create context with v4 function

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

PR: https://git.openjdk.org/babylon/pull/543

From gfrost at openjdk.org  Wed Sep  3 14:18:26 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 3 Sep 2025 14:18:26 GMT
Subject: git: openjdk/babylon: code-reflection: hat cleanup after removing
 OpWrappers
Message-ID: <b3f994f7-07d5-41cb-a095-873a6c0db5a5@openjdk.org>

Changeset: dbadf0d0
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-03 14:16:31 +0000
URL:       https://git.openjdk.org/babylon/commit/dbadf0d0d7e74227bc9e55055f651001140f5ca9

hat cleanup after removing OpWrappers

! 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/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/FFIBackend.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/backends/jextracted/shared/src/main/java/hat/backend/jextracted/JExtractedBackend.java
! hat/core/src/main/java/hat/Accelerator.java
! hat/core/src/main/java/hat/ComputeContext.java
! hat/core/src/main/java/hat/backend/DebugBackend.java
! hat/core/src/main/java/hat/buffer/BufferTracker.java
! hat/core/src/main/java/hat/callgraph/ComputeCallGraph.java
! hat/core/src/main/java/hat/callgraph/KernelCallGraph.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/HATCodeBuilderContext.java
! hat/core/src/main/java/hat/codebuilders/HATCodeBuilderWithContext.java
+ hat/core/src/main/java/hat/optools/FuncOpParams.java
! hat/core/src/main/java/hat/optools/OpTk.java
! hat/tools/src/main/java/hat/tools/text/JavaHATCodeBuilder.java


From gfrost at openjdk.org  Wed Sep  3 14:19:47 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 3 Sep 2025 14:19:47 GMT
Subject: [code-reflection] Integrated: hat cleanup after removing OpWrappers
Message-ID: <LVWzGqozWGLaaUDvDhEgby3DFeC80kPSrUJf9MWa0u4=.c750d115-2b3b-412a-ad93-2017f634193b@github.com>

After OpWrapper removal found some opportunities to simplify code. 

This PR just provides that cleanup

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

Commit messages:
 - hat cleanup after removing OpWrappers

Changes: https://git.openjdk.org/babylon/pull/544/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=544&range=00
  Stats: 674 lines in 22 files changed: 164 ins; 329 del; 181 mod
  Patch: https://git.openjdk.org/babylon/pull/544.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/544/head:pull/544

PR: https://git.openjdk.org/babylon/pull/544

From gfrost at openjdk.org  Wed Sep  3 14:19:48 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 3 Sep 2025 14:19:48 GMT
Subject: [code-reflection] Integrated: hat cleanup after removing OpWrappers
In-Reply-To: <LVWzGqozWGLaaUDvDhEgby3DFeC80kPSrUJf9MWa0u4=.c750d115-2b3b-412a-ad93-2017f634193b@github.com>
References: <LVWzGqozWGLaaUDvDhEgby3DFeC80kPSrUJf9MWa0u4=.c750d115-2b3b-412a-ad93-2017f634193b@github.com>
Message-ID: <01RLy8o5gGkRkixXuHuALsuyJrJxv34XzkA6Ma_xBm0=.bd50f49e-28e5-45f5-92fe-7bef73099fd3@github.com>

On Wed, 3 Sep 2025 14:14:27 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> After OpWrapper removal found some opportunities to simplify code. 
> 
> This PR just provides that cleanup

This pull request has now been integrated.

Changeset: dbadf0d0
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/dbadf0d0d7e74227bc9e55055f651001140f5ca9
Stats:     674 lines in 22 files changed: 164 ins; 329 del; 181 mod

hat cleanup after removing OpWrappers

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

PR: https://git.openjdk.org/babylon/pull/544

From mabbay at openjdk.org  Wed Sep  3 20:06:09 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 3 Sep 2025 20:06:09 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp
Message-ID: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>

In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.

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

Commit messages:
 - Add attribute to LambdaOp

Changes: https://git.openjdk.org/babylon/pull/545/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=00
  Stats: 49 lines in 5 files changed: 40 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/babylon/pull/545.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/545/head:pull/545

PR: https://git.openjdk.org/babylon/pull/545

From psandoz at openjdk.org  Wed Sep  3 20:22:01 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 3 Sep 2025 20:22:01 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp
In-Reply-To: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
Message-ID: <XHrrHrMdd6F3-cZDQB437MbTB-uGUF0Y92pfi-1QTb4=.4c564392-3723-44a2-b0ac-0691bb2a6d46@github.com>

On Wed, 3 Sep 2025 20:00:54 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.

src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java line 177:

> 175:             public Builder quotable() {
> 176:                 this.quotable = true;
> 177:                 return this;

Instead return a new instance of the Builder so its immutable, thereby quotable can be final.

src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java line 191:

> 189:             boolean isQuotable = def.extractAttributeValue(ATTRIBUTE_LAMBDA_IS_QUOTABLE,
> 190:                     false, v -> switch (v) {
> 191:                         case Boolean b -> b;

Can we use the `boolean` primitive type?

src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java line 264:

> 262:             m.put(ATTRIBUTE_LAMBDA_IS_QUOTABLE, isQuotable);
> 263:             return Collections.unmodifiableMap(m);
> 264:         }

Use `Map.of`.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/545#discussion_r2320082653
PR Review Comment: https://git.openjdk.org/babylon/pull/545#discussion_r2320085867
PR Review Comment: https://git.openjdk.org/babylon/pull/545#discussion_r2320083208

From mabbay at openjdk.org  Wed Sep  3 20:27:59 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 3 Sep 2025 20:27:59 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp
In-Reply-To: <XHrrHrMdd6F3-cZDQB437MbTB-uGUF0Y92pfi-1QTb4=.4c564392-3723-44a2-b0ac-0691bb2a6d46@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <XHrrHrMdd6F3-cZDQB437MbTB-uGUF0Y92pfi-1QTb4=.4c564392-3723-44a2-b0ac-0691bb2a6d46@github.com>
Message-ID: <lUS1ArI9wba0Fy6MKY1QF6gwckvAoIEf1XYigZsYXNQ=.f67eee27-5024-41c5-be5e-c701fcda95ac@github.com>

On Wed, 3 Sep 2025 20:17:28 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.
>
> src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java line 191:
> 
>> 189:             boolean isQuotable = def.extractAttributeValue(ATTRIBUTE_LAMBDA_IS_QUOTABLE,
>> 190:                     false, v -> switch (v) {
>> 191:                         case Boolean b -> b;
> 
> Can we use the `boolean` primitive type?

It's a preview feature

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

PR Review Comment: https://git.openjdk.org/babylon/pull/545#discussion_r2320101806

From psandoz at openjdk.org  Wed Sep  3 20:32:55 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 3 Sep 2025 20:32:55 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp
In-Reply-To: <lUS1ArI9wba0Fy6MKY1QF6gwckvAoIEf1XYigZsYXNQ=.f67eee27-5024-41c5-be5e-c701fcda95ac@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <XHrrHrMdd6F3-cZDQB437MbTB-uGUF0Y92pfi-1QTb4=.4c564392-3723-44a2-b0ac-0691bb2a6d46@github.com>
 <lUS1ArI9wba0Fy6MKY1QF6gwckvAoIEf1XYigZsYXNQ=.f67eee27-5024-41c5-be5e-c701fcda95ac@github.com>
Message-ID: <H2gXdYB2WEgcc9LFotRmAPE-FgxFGrh01p-8dT31fGk=.f717af82-dd8d-4cb3-a7ea-a81dfef1893d@github.com>

On Wed, 3 Sep 2025 20:25:31 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java line 191:
>> 
>>> 189:             boolean isQuotable = def.extractAttributeValue(ATTRIBUTE_LAMBDA_IS_QUOTABLE,
>>> 190:                     false, v -> switch (v) {
>>> 191:                         case Boolean b -> b;
>> 
>> Can we use the `boolean` primitive type?
>
> It's a preview feature

We should be able to use preview features as the `jdk.incubator.code` module is annotated with `@ParticipatesInPreview`, unless there is some odd restriction when javac calls code in the incubating module?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/545#discussion_r2320109469

From mabbay at openjdk.org  Wed Sep  3 20:37:06 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 3 Sep 2025 20:37:06 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v2]
In-Reply-To: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
Message-ID: <k0HOJW7zHGKueEYy4oBlFVKeOJOl0JzAqU6kfdOkhh0=.9cd999ff-589d-44c4-b3ef-64a4398a7285@github.com>

> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Apply review comments

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/545/files
  - new: https://git.openjdk.org/babylon/pull/545/files/12eeef41..29a62de1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=00-01

  Stats: 16 lines in 1 file changed: 9 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/babylon/pull/545.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/545/head:pull/545

PR: https://git.openjdk.org/babylon/pull/545

From forax at openjdk.org  Wed Sep  3 21:06:02 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 3 Sep 2025 21:06:02 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v2]
In-Reply-To: <H2gXdYB2WEgcc9LFotRmAPE-FgxFGrh01p-8dT31fGk=.f717af82-dd8d-4cb3-a7ea-a81dfef1893d@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <XHrrHrMdd6F3-cZDQB437MbTB-uGUF0Y92pfi-1QTb4=.4c564392-3723-44a2-b0ac-0691bb2a6d46@github.com>
 <lUS1ArI9wba0Fy6MKY1QF6gwckvAoIEf1XYigZsYXNQ=.f67eee27-5024-41c5-be5e-c701fcda95ac@github.com>
 <H2gXdYB2WEgcc9LFotRmAPE-FgxFGrh01p-8dT31fGk=.f717af82-dd8d-4cb3-a7ea-a81dfef1893d@github.com>
Message-ID: <Mchf1Jpl2OB7Mosozn2_wCS2cOuGvUUf31N3PDVd4rY=.845a180c-a44e-435f-89e1-29b8d6b45971@github.com>

On Wed, 3 Sep 2025 20:29:10 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> It's a preview feature
>
> We should be able to use preview features as the `jdk.incubator.code` module is annotated with `@ParticipatesInPreview`, unless there is some odd restriction when javac calls code in the incubating module?

Paul, there is no real difference at runtime betwen case Boolean and case boolean when you switch on an Object, case boolean just bloat the bytecode a little more.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/545#discussion_r2320210698

From psandoz at openjdk.org  Wed Sep  3 21:43:51 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 3 Sep 2025 21:43:51 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v2]
In-Reply-To: <Mchf1Jpl2OB7Mosozn2_wCS2cOuGvUUf31N3PDVd4rY=.845a180c-a44e-435f-89e1-29b8d6b45971@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <XHrrHrMdd6F3-cZDQB437MbTB-uGUF0Y92pfi-1QTb4=.4c564392-3723-44a2-b0ac-0691bb2a6d46@github.com>
 <lUS1ArI9wba0Fy6MKY1QF6gwckvAoIEf1XYigZsYXNQ=.f67eee27-5024-41c5-be5e-c701fcda95ac@github.com>
 <H2gXdYB2WEgcc9LFotRmAPE-FgxFGrh01p-8dT31fGk=.f717af82-dd8d-4cb3-a7ea-a81dfef1893d@github.com>
 <Mchf1Jpl2OB7Mosozn2_wCS2cOuGvUUf31N3PDVd4rY=.845a180c-a44e-435f-89e1-29b8d6b45971@github.com>
Message-ID: <MmAmapnyIO_-BwOwsrPNOcxgNpvn3eghoJ2ns2upr10=.d168de23-d404-4365-922b-44e85aa7d9a4@github.com>

On Wed, 3 Sep 2025 21:03:07 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> We should be able to use preview features as the `jdk.incubator.code` module is annotated with `@ParticipatesInPreview`, unless there is some odd restriction when javac calls code in the incubating module?
>
> Paul, there is no real difference at runtime betwen case Boolean and case boolean when you switch on an Object, case boolean just bloat the bytecode a little more.

I was thinking more subjectively, more clearly indicating the pattern variable cannot be null (i realize the `case null, default` is also present).

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

PR Review Comment: https://git.openjdk.org/babylon/pull/545#discussion_r2320290785

From forax at openjdk.org  Wed Sep  3 21:54:54 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 3 Sep 2025 21:54:54 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v2]
In-Reply-To: <MmAmapnyIO_-BwOwsrPNOcxgNpvn3eghoJ2ns2upr10=.d168de23-d404-4365-922b-44e85aa7d9a4@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <XHrrHrMdd6F3-cZDQB437MbTB-uGUF0Y92pfi-1QTb4=.4c564392-3723-44a2-b0ac-0691bb2a6d46@github.com>
 <lUS1ArI9wba0Fy6MKY1QF6gwckvAoIEf1XYigZsYXNQ=.f67eee27-5024-41c5-be5e-c701fcda95ac@github.com>
 <H2gXdYB2WEgcc9LFotRmAPE-FgxFGrh01p-8dT31fGk=.f717af82-dd8d-4cb3-a7ea-a81dfef1893d@github.com>
 <Mchf1Jpl2OB7Mosozn2_wCS2cOuGvUUf31N3PDVd4rY=.845a180c-a44e-435f-89e1-29b8d6b45971@github.com>
 <MmAmapnyIO_-BwOwsrPNOcxgNpvn3eghoJ2ns2upr10=.d168de23-d404-4365-922b-44e85aa7d9a4@github.com>
Message-ID: <6g5nddiQWijuPwFGZE2WVu9MWS4Y18Hg4-0KJgDkoMo=.72db7d72-fb41-4b6e-88d5-e426090246fa@github.com>

On Wed, 3 Sep 2025 21:40:42 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Paul, there is no real difference at runtime betwen case Boolean and case boolean when you switch on an Object, case boolean just bloat the bytecode a little more.
>
> I was thinking more subjectively, more clearly indicating the pattern variable cannot be null (i realize the `case null, default` is also present).

Conceptually, a case Foo is like an instanceof Foo, it does not match null.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/545#discussion_r2320309869

From liach at openjdk.org  Wed Sep  3 22:53:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Sep 2025 22:53:49 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v2]
In-Reply-To: <6g5nddiQWijuPwFGZE2WVu9MWS4Y18Hg4-0KJgDkoMo=.72db7d72-fb41-4b6e-88d5-e426090246fa@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <XHrrHrMdd6F3-cZDQB437MbTB-uGUF0Y92pfi-1QTb4=.4c564392-3723-44a2-b0ac-0691bb2a6d46@github.com>
 <lUS1ArI9wba0Fy6MKY1QF6gwckvAoIEf1XYigZsYXNQ=.f67eee27-5024-41c5-be5e-c701fcda95ac@github.com>
 <H2gXdYB2WEgcc9LFotRmAPE-FgxFGrh01p-8dT31fGk=.f717af82-dd8d-4cb3-a7ea-a81dfef1893d@github.com>
 <Mchf1Jpl2OB7Mosozn2_wCS2cOuGvUUf31N3PDVd4rY=.845a180c-a44e-435f-89e1-29b8d6b45971@github.com>
 <MmAmapnyIO_-BwOwsrPNOcxgNpvn3eghoJ2ns2upr10=.d168de23-d404-4365-922b-44e85aa7d9a4@github.com>
 <6g5nddiQWijuPwFGZE2WVu9MWS4Y18Hg4-0KJgDkoMo=.72db7d72-fb41-4b6e-88d5-e426090246fa@github.com>
Message-ID: <TcAd27iHZcivOXMIPQ6d3O1Z9WGUC1SyYpZh6HKnCwM=.9b4bf20c-46e5-4f01-a0db-d23b3d578732@github.com>

On Wed, 3 Sep 2025 21:52:34 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> I was thinking more subjectively, more clearly indicating the pattern variable cannot be null (i realize the `case null, default` is also present).
>
> Conceptually, a case Foo is like an instanceof Foo, it does not match null.

I recall `@ParticipatesInPreview` only works for preview APIs instead of language features that ClassFile API needed custom backdoors from the JDK. See https://bugs.openjdk.org/browse/JDK-8308093.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/545#discussion_r2320412584

From mcimadamore at openjdk.org  Thu Sep  4 11:49:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 4 Sep 2025 11:49:57 GMT
Subject: [code-reflection] RFR: Update ReflectMethods.BodyScanner.coerce to
 handle null targetType [v3]
In-Reply-To: <LKGcJosvqcGpkndZLK6GI1pvNOxqGdnXr8wVxwNZmMo=.d73d0530-5321-4d67-b19f-0c259b7b1501@github.com>
References: <WhI2B3roAVXSiXQtTwahV04v5Nn7I_MWAMbrdXo7SBI=.109c15a4-d27e-4cdc-a411-efeccf5e301f@github.com>
 <LKGcJosvqcGpkndZLK6GI1pvNOxqGdnXr8wVxwNZmMo=.d73d0530-5321-4d67-b19f-0c259b7b1501@github.com>
Message-ID: <gf3uQ8l1D9xM8ruL3dbBsLGqu-P-y5WD36ns-hF-Z7k=.ffa29af7-edab-4d62-8ed2-8f970472f538@github.com>

On Wed, 3 Sep 2025 13:49:07 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> `ReflectMethods.BodyScanner.coerce` wasn't handling `null` targetType. For example, a `null` targetType may propagate to reach the method `coerce` when visiting case body of switch statement.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions

Thanks!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/babylon/pull/536#pullrequestreview-3184792151

From asotona at openjdk.org  Thu Sep  4 12:22:06 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 4 Sep 2025 12:22:06 GMT
Subject: [code-reflection] RFR: OpWriter.ColoringOption proposal
Message-ID: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>

I propose OpWriter.ColoringOption, with NONE, ANSI and HTML  implementations:
- `OpWriter.toText(op, OpWriter.ColoringOption.ANSI))` will color the op with ANSI codes for terminal debug print
- `OpWriter.toText(op, OpWriter.ColoringOption.HTML))` will render the op with colors when dropped into an html `pre` block.

ANSI coloring sample:
<img width="989" height="746" alt="ansi-coloring" src="https://github.com/user-attachments/assets/2025bcbe-6c6c-48ab-8ed5-67ff88b47fe6" />

HTML coloring sample:
<img width="914" height="657" alt="html-coloring" src="https://github.com/user-attachments/assets/77f62787-68c1-4b12-b16d-e7a526570ad3" />

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

Commit messages:
 - OpWriter.ColoringOption

Changes: https://git.openjdk.org/babylon/pull/546/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=546&range=00
  Stats: 52 lines in 1 file changed: 44 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/babylon/pull/546.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/546/head:pull/546

PR: https://git.openjdk.org/babylon/pull/546

From jfumero at openjdk.org  Thu Sep  4 12:36:36 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Thu, 4 Sep 2025 12:36:36 GMT
Subject: [code-reflection] RFR: [proposal][hat] Enabling local/shared memory
 and local barriers within compute methods
Message-ID: <JQzSQWKPNCAZMOBdJEQ-3O-IOwBjMY0h1G0kmiuHMr8=.275c13bd-ea0e-48ab-b908-267cbe032176@github.com>

This patch enables a new extension for HAT to allow the use of local memory (as in OpenCL) / shared memory (CUDA). This extension is preliminary, and the implementation can be improved to use a new HAT dialect with new Ops from code reflection (Babylon).

This extension brings two new calls to the API:
a) Declaration and allocation of data structures in local/shared memory
b) Access to local barriers

Example:



private interface MyArray extends Buffer {
    void array(long index, int value);
    int array(long index);

    Schema<MyArray> schema = Schema.of(MyArray.class,
            myArray -> myArray
                    .array("array", 16));

    static MyArray create(Accelerator accelerator) {
        return schema.allocate(accelerator, 1);
    }

    static MyArray createLocal() {
            return create(new Accelerator(MethodHandles.lookup(), Backend.FIRST));
     }
}

@CodeReflection
private static void reduceLocal(@RO KernelContext context, @RW S32Array input, @RW S32Array partialSums) {
    int localId = context.lix;
    int localSize = context.lsx;
    int blockId = context.bix;

    // Prototype: allocate in shared memory an array of 16 ints
    MyArray sharedArray = MyArray.create();

    // Copy from global to shared memory
    sharedArray.array(localId, input.array(context.gix));

    // Reduction using local memory
    for (int offset = localSize / 2; offset > 0; offset /= 2) {
        context.barrier();
        if (localId < offset) {
            sharedArray.array(localId,  sharedArray.array(localId) +  sharedArray.array(localId + offset));
        }
    }
    if (localId == 0) {
        // copy from shared memory to global memory
        partialSums.array(blockId,  sharedArray.array(0));
    }
}
``` 

This brings low-level GPU programming to HAT, but for now this is just experimentation. 

### Running a few examples:

a) Reductions:


HAT=SHOW_CODE java -cp job.jar hat.java exp ffi-opencl Reduction

HAT=SHOW_CODE java -cp job.jar hat.java exp ffi-cuda Reduction


b) Fast Matrix Mult using loop tiling and local memory:


java @hat/run ffi-opencl matmul 2DTILING 

java @hat/run ffi-cuda matmul 2DTILING 


c) Another example of using shared memory data structures:


HAT=SHOW_CODE java -cp job.jar hat.java exp ffi-opencl LocalArray

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

Commit messages:
 - [hat] Remove old methods to allocate DS in local memory
 - [hat] Allocation of UDS in private memory disabled
 - [hat] Proposal for shared memory and barriers. Private mem support removed
 - [hat] Move again the isIfaceAccessor method to the OpTk class
 - Fix check for iFaceAccessor without the need for the OpTk old methods
 - minor change
 - Merge branch 'code-reflection' into hat/api/shared
 - [hat] Fix example in private memory
 - Unified interface for handling private and shared mem types
 - minor change
 - ... and 60 more: https://git.openjdk.org/babylon/compare/dbadf0d0...01c7ccfd

Changes: https://git.openjdk.org/babylon/pull/531/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=531&range=00
  Stats: 922 lines in 22 files changed: 859 ins; 15 del; 48 mod
  Patch: https://git.openjdk.org/babylon/pull/531.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/531/head:pull/531

PR: https://git.openjdk.org/babylon/pull/531

From duke at openjdk.org  Thu Sep  4 12:41:01 2025
From: duke at openjdk.org (duke)
Date: Thu, 4 Sep 2025 12:41:01 GMT
Subject: [code-reflection] RFR: [proposal][hat] Enabling local/shared
 memory and local barriers within compute methods
In-Reply-To: <JQzSQWKPNCAZMOBdJEQ-3O-IOwBjMY0h1G0kmiuHMr8=.275c13bd-ea0e-48ab-b908-267cbe032176@github.com>
References: <JQzSQWKPNCAZMOBdJEQ-3O-IOwBjMY0h1G0kmiuHMr8=.275c13bd-ea0e-48ab-b908-267cbe032176@github.com>
Message-ID: <64cSoGj1wrzWVvoOZR7WPqXmTRtUgqhQDEM6JebhHbw=.9944869d-24ce-4145-b736-34206cd0eb83@github.com>

On Fri, 22 Aug 2025 11:18:40 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> This patch enables a new extension for HAT to allow the use of local memory (as in OpenCL) / shared memory (CUDA). This extension is preliminary, and the implementation can be improved to use a new HAT dialect with new Ops from code reflection (Babylon).
> 
> This extension brings two new calls to the API:
> a) Declaration and allocation of data structures in local/shared memory
> b) Access to local barriers
> 
> Example:
> 
> 
> 
> private interface MyArray extends Buffer {
>     void array(long index, int value);
>     int array(long index);
> 
>     Schema<MyArray> schema = Schema.of(MyArray.class,
>             myArray -> myArray
>                     .array("array", 16));
> 
>     static MyArray create(Accelerator accelerator) {
>         return schema.allocate(accelerator, 1);
>     }
> 
>     static MyArray createLocal() {
>             return create(new Accelerator(MethodHandles.lookup(), Backend.FIRST));
>      }
> }
> 
> @CodeReflection
> private static void reduceLocal(@RO KernelContext context, @RW S32Array input, @RW S32Array partialSums) {
>     int localId = context.lix;
>     int localSize = context.lsx;
>     int blockId = context.bix;
> 
>     // Prototype: allocate in shared memory an array of 16 ints
>     MyArray sharedArray = MyArray.create();
> 
>     // Copy from global to shared memory
>     sharedArray.array(localId, input.array(context.gix));
> 
>     // Reduction using local memory
>     for (int offset = localSize / 2; offset > 0; offset /= 2) {
>         context.barrier();
>         if (localId < offset) {
>             sharedArray.array(localId,  sharedArray.array(localId) +  sharedArray.array(localId + offset));
>         }
>     }
>     if (localId == 0) {
>         // copy from shared memory to global memory
>         partialSums.array(blockId,  sharedArray.array(0));
>     }
> }
> ``` 
> 
> This brings low-level GPU programming to HAT, but for now this is just experimentation. 
> 
> ### Running a few examples:
> 
> a) Reductions:
> 
> 
> HAT=SHOW_CODE java -cp job.jar hat.java exp ffi-opencl Reduction
> 
> HAT=SHOW_CODE java -cp job.jar hat.java exp ffi-cuda Reduction
> 
> 
> b) Fast Matrix Mult using loop tiling and local memory:
> 
> 
> java @hat/run ffi-opencl matmul 2DTILING 
> 
> java @hat/run ffi-cuda matmul 2DTILING 
> 
> 
> c) Another example of using shared memory data structures:
> 
> 
> HAT=SHOW_CODE java -cp job.jar hat.java exp ffi-opencl LocalArray

@jjfumero 
Your change (at version 01c7ccfdef3e654f66fa9b2acb4110cdf0ca3331) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/babylon/pull/531#issuecomment-3253503272

From asotona at openjdk.org  Thu Sep  4 12:54:20 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 4 Sep 2025 12:54:20 GMT
Subject: [code-reflection] RFR: OpWriter.ColoringOption proposal [v2]
In-Reply-To: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
References: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
Message-ID: <Uml2L7vzQDuD4_IyjWUPftlA2dvutMt28KVjJm54Kf8=.d119b3f2-e6cc-4652-8ca5-c837372b642d@github.com>

> I propose OpWriter.ColoringOption, with NONE, ANSI and HTML  implementations:
> - `OpWriter.toText(op, OpWriter.ColoringOption.ANSI))` will color the op with ANSI codes for terminal debug print
> - `OpWriter.toText(op, OpWriter.ColoringOption.HTML))` will render the op with colors when dropped into an html `pre` block.
> 
> ANSI coloring sample:
> <img width="989" height="746" alt="ansi-coloring" src="https://github.com/user-attachments/assets/2025bcbe-6c6c-48ab-8ed5-67ff88b47fe6" />
> 
> HTML coloring sample:
> <img width="914" height="657" alt="html-coloring" src="https://github.com/user-attachments/assets/77f62787-68c1-4b12-b16d-e7a526570ad3" />

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Added OpWriter.ColoringOption.ANSI_HI

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/546/files
  - new: https://git.openjdk.org/babylon/pull/546/files/0d3dadca..095a11c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=546&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=546&range=00-01

  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/babylon/pull/546.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/546/head:pull/546

PR: https://git.openjdk.org/babylon/pull/546

From gfrost at openjdk.org  Thu Sep  4 13:03:39 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 4 Sep 2025 13:03:39 GMT
Subject: git: openjdk/babylon: code-reflection: [proposal][hat] Enabling
 local/shared memory and local barriers within compute methods
Message-ID: <16b47802-702e-40c6-826f-6db1a49231d7@openjdk.org>

Changeset: a16b8bf6
Branch: code-reflection
Author:    Juan Fumero <jfumero at openjdk.org>
Committer: Gary Frost <gfrost at openjdk.org>
Date:      2025-09-04 13:01:57 +0000
URL:       https://git.openjdk.org/babylon/commit/a16b8bf6b637cc6bc2c44dc0d733e19d5174512a

[proposal][hat] Enabling local/shared memory and local barriers within compute methods

! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaHATKernelBuilder.java
! hat/backends/ffi/opencl/src/main/java/hat/backend/ffi/OpenCLHATKernelBuilder.java
! 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/jextracted/opencl/src/main/java/hat/backend/jextracted/OpenCLHatKernelBuilder.java
! hat/core/src/main/java/hat/KernelContext.java
= hat/core/src/main/java/hat/Space.java
! hat/core/src/main/java/hat/buffer/Buffer.java
! hat/core/src/main/java/hat/buffer/F32Array.java
+ hat/core/src/main/java/hat/buffer/S32LocalArray.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/ifacemapper/Schema.java
= hat/core/src/main/java/hat/optools/InvokeOpWrapper.java
! hat/core/src/main/java/hat/optools/OpTk.java
+ hat/examples/experiments/src/main/java/experiments/LocalArray.java
+ hat/examples/experiments/src/main/java/experiments/Reduction.java
! hat/examples/matmul/src/main/java/matmul/Main.java
! hat/tools/src/main/java/hat/tools/text/JavaHATCodeBuilder.java


From jfumero at openjdk.org  Thu Sep  4 13:05:05 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Thu, 4 Sep 2025 13:05:05 GMT
Subject: [code-reflection] Integrated: [proposal][hat] Enabling local/shared
 memory and local barriers within compute methods
In-Reply-To: <JQzSQWKPNCAZMOBdJEQ-3O-IOwBjMY0h1G0kmiuHMr8=.275c13bd-ea0e-48ab-b908-267cbe032176@github.com>
References: <JQzSQWKPNCAZMOBdJEQ-3O-IOwBjMY0h1G0kmiuHMr8=.275c13bd-ea0e-48ab-b908-267cbe032176@github.com>
Message-ID: <gi1V8HvOdcJVFEdmzc2NDj4y9eW_rLFQ4tZ5GQwS518=.339c6a8a-34ea-4c1d-8f63-050d4cad02cc@github.com>

On Fri, 22 Aug 2025 11:18:40 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> This patch enables a new extension for HAT to allow the use of local memory (as in OpenCL) / shared memory (CUDA). This extension is preliminary, and the implementation can be improved to use a new HAT dialect with new Ops from code reflection (Babylon).
> 
> This extension brings two new calls to the API:
> a) Declaration and allocation of data structures in local/shared memory
> b) Access to local barriers
> 
> Example:
> 
> 
> 
> private interface MyArray extends Buffer {
>     void array(long index, int value);
>     int array(long index);
> 
>     Schema<MyArray> schema = Schema.of(MyArray.class,
>             myArray -> myArray
>                     .array("array", 16));
> 
>     static MyArray create(Accelerator accelerator) {
>         return schema.allocate(accelerator, 1);
>     }
> 
>     static MyArray createLocal() {
>             return create(new Accelerator(MethodHandles.lookup(), Backend.FIRST));
>      }
> }
> 
> @CodeReflection
> private static void reduceLocal(@RO KernelContext context, @RW S32Array input, @RW S32Array partialSums) {
>     int localId = context.lix;
>     int localSize = context.lsx;
>     int blockId = context.bix;
> 
>     // Prototype: allocate in shared memory an array of 16 ints
>     MyArray sharedArray = MyArray.create();
> 
>     // Copy from global to shared memory
>     sharedArray.array(localId, input.array(context.gix));
> 
>     // Reduction using local memory
>     for (int offset = localSize / 2; offset > 0; offset /= 2) {
>         context.barrier();
>         if (localId < offset) {
>             sharedArray.array(localId,  sharedArray.array(localId) +  sharedArray.array(localId + offset));
>         }
>     }
>     if (localId == 0) {
>         // copy from shared memory to global memory
>         partialSums.array(blockId,  sharedArray.array(0));
>     }
> }
> ``` 
> 
> This brings low-level GPU programming to HAT, but for now this is just experimentation. 
> 
> ### Running a few examples:
> 
> a) Reductions:
> 
> 
> HAT=SHOW_CODE java -cp job.jar hat.java exp ffi-opencl Reduction
> 
> HAT=SHOW_CODE java -cp job.jar hat.java exp ffi-cuda Reduction
> 
> 
> b) Fast Matrix Mult using loop tiling and local memory:
> 
> 
> java @hat/run ffi-opencl matmul 2DTILING 
> 
> java @hat/run ffi-cuda matmul 2DTILING 
> 
> 
> c) Another example of using shared memory data structures:
> 
> 
> HAT=SHOW_CODE java -cp job.jar hat.java exp ffi-opencl LocalArray

This pull request has now been integrated.

Changeset: a16b8bf6
Author:    Juan Fumero <jfumero at openjdk.org>
Committer: Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/a16b8bf6b637cc6bc2c44dc0d733e19d5174512a
Stats:     922 lines in 22 files changed: 859 ins; 15 del; 48 mod

[proposal][hat] Enabling local/shared memory and local barriers within compute methods

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

PR: https://git.openjdk.org/babylon/pull/531

From gfrost at openjdk.org  Thu Sep  4 13:33:57 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 4 Sep 2025 13:33:57 GMT
Subject: [code-reflection] RFR: OpWriter.ColoringOption proposal [v2]
In-Reply-To: <Uml2L7vzQDuD4_IyjWUPftlA2dvutMt28KVjJm54Kf8=.d119b3f2-e6cc-4652-8ca5-c837372b642d@github.com>
References: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
 <Uml2L7vzQDuD4_IyjWUPftlA2dvutMt28KVjJm54Kf8=.d119b3f2-e6cc-4652-8ca5-c837372b642d@github.com>
Message-ID: <iaZaeKuY9ug6FInkx8WF7Dh8Qnm8bIhxDc9IyvQ_1go=.f98e399c-1abd-4468-b1f8-8a5b64c05d97@github.com>

On Thu, 4 Sep 2025 12:54:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I propose OpWriter.ColoringOption, with NONE, ANSI, ANSI_HI and HTML  implementations:
>> - `OpWriter.toText(op, OpWriter.ColoringOption.ANSI))` will color the op with ANSI codes for terminal debug print (white background)
>> - `OpWriter.toText(op, OpWriter.ColoringOption.ANSI_HI))` will color the op with ANSI codes for terminal debug print (black background)
>> - `OpWriter.toText(op, OpWriter.ColoringOption.HTML))` will render the op with colors when dropped into an html `pre` block.
>> 
>> ANSI coloring sample:
>> <img width="989" height="746" alt="ansi-coloring" src="https://github.com/user-attachments/assets/2025bcbe-6c6c-48ab-8ed5-67ff88b47fe6" />
>> 
>> ANSI_HI coloring sample:
>> <img width="1267" height="566" alt="ansi-hi-coloring" src="https://github.com/user-attachments/assets/cd45838c-25b5-4980-9392-2b6ccf29e90b" />
>> 
>> 
>> HTML coloring sample:
>> <img width="914" height="657" alt="html-coloring" src="https://github.com/user-attachments/assets/77f62787-68c1-4b12-b16d-e7a526570ad3" />
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added OpWriter.ColoringOption.ANSI_HI

I like the idea of making OpWriter more flexible and feel this will be useful tooling.  I have suggested changes in this API for a while ;)

I personally think this solution is too concrete, and we should offer a 'colorize' iface (BiFunction(Sttring,Tag, String) which we can pass to OpWriter.toText().

The default implementation  of this iBiFunction would just return the String passed to it. 
 
OpWriter would then call this colorizer with a 'tag' enum/type (identifier, const, attribute, SSAid) and a String to be colorised, and  the Colorizer/BiFunction gets to return a suitable colorised version ANSI/CSI/HTML/.... whatever which gets written to the PrintWriter.

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

PR Comment: https://git.openjdk.org/babylon/pull/546#issuecomment-3253745139

From asotona at openjdk.org  Thu Sep  4 13:41:51 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 4 Sep 2025 13:41:51 GMT
Subject: [code-reflection] RFR: OpWriter.ColoringOption proposal [v2]
In-Reply-To: <Uml2L7vzQDuD4_IyjWUPftlA2dvutMt28KVjJm54Kf8=.d119b3f2-e6cc-4652-8ca5-c837372b642d@github.com>
References: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
 <Uml2L7vzQDuD4_IyjWUPftlA2dvutMt28KVjJm54Kf8=.d119b3f2-e6cc-4652-8ca5-c837372b642d@github.com>
Message-ID: <xpSoglJsLT-EbNTC1_e-mlYeCQ09Wny0tQC4VLXR9R0=.7cc0a9af-8336-4739-ad1f-6599eed7ac56@github.com>

On Thu, 4 Sep 2025 12:54:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I propose OpWriter.ColoringOption, with NONE, ANSI, ANSI_HI and HTML  implementations:
>> - `OpWriter.toText(op, OpWriter.ColoringOption.ANSI))` will color the op with ANSI codes for terminal debug print (white background)
>> - `OpWriter.toText(op, OpWriter.ColoringOption.ANSI_HI))` will color the op with ANSI codes for terminal debug print (black background)
>> - `OpWriter.toText(op, OpWriter.ColoringOption.HTML))` will render the op with colors when dropped into an html `pre` block.
>> 
>> ANSI coloring sample:
>> <img width="989" height="746" alt="ansi-coloring" src="https://github.com/user-attachments/assets/2025bcbe-6c6c-48ab-8ed5-67ff88b47fe6" />
>> 
>> ANSI_HI coloring sample:
>> <img width="1267" height="566" alt="ansi-hi-coloring" src="https://github.com/user-attachments/assets/cd45838c-25b5-4980-9392-2b6ccf29e90b" />
>> 
>> 
>> HTML coloring sample:
>> <img width="914" height="657" alt="html-coloring" src="https://github.com/user-attachments/assets/77f62787-68c1-4b12-b16d-e7a526570ad3" />
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added OpWriter.ColoringOption.ANSI_HI

Yes, I was also thinking to expose the internal `BiFunction<Class<? extends CodeItem>, String, String>`.
However then I realized that the colorings should be concrete and simple to enable.
Maybe even affect the default `op.toText()` by a system property (similar to Maven `-Dstyle.color=(auto|always|never)`).

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

PR Comment: https://git.openjdk.org/babylon/pull/546#issuecomment-3253782824

From gfrost at openjdk.org  Thu Sep  4 13:46:31 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 4 Sep 2025 13:46:31 GMT
Subject: git: openjdk/babylon: code-reflection: Post OpWrapper cleanup,
 removed some experiments and fixed =?UTF-8?B?VmlvbGFqb25lc+KApg==?=
Message-ID: <b49f5f00-374f-468b-8363-856d0e571937@openjdk.org>

Changeset: 25f28534
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-04 13:45:27 +0000
URL:       https://git.openjdk.org/babylon/commit/25f28534f317aa80241db70f7808a36c809971a3

Post OpWrapper cleanup, removed some experiments and fixed Violajones?

! 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/buffer/ChessState.java
- hat/examples/experiments/src/main/java/experiments/Chess.java
! hat/examples/experiments/src/main/java/experiments/DNA.java
- hat/examples/experiments/src/main/java/experiments/DependencyTree.java
- hat/examples/experiments/src/main/java/experiments/LambdaTest.java
! hat/examples/experiments/src/main/java/experiments/MinBufferTest.java
- hat/examples/experiments/src/main/java/experiments/PomChecker.java
- hat/examples/experiments/src/main/java/experiments/PrePostInc.java
- hat/examples/experiments/src/main/java/experiments/QuotedTest.java
! hat/examples/violajones/src/main/java/violajones/ViolaJonesCoreCompute.java


From gfrost at openjdk.org  Thu Sep  4 13:48:29 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 4 Sep 2025 13:48:29 GMT
Subject: [code-reflection] Integrated: Post OpWrapper cleanup,
 removed some experiments and fixed =?UTF-8?B?VmlvbGFqb25lc+KApg==?=
Message-ID: <f1zQ_h-0v1YGbfKpkm0nBKS9HKwFI6k4EB9xoDJwPn0=.cf782ad1-7a3a-4f88-8a80-2f2eb61d9761@github.com>

Another post Opwrapper cleanup. 

Also removed some dead experiments.

Patched Violajones example, where we had incorrect buffer access annotation on rgbToGrey kernel

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

Commit messages:
 - Post OpWrapper cleanup, removed some experiments and fixed Violajones buffer accesses

Changes: https://git.openjdk.org/babylon/pull/547/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=547&range=00
  Stats: 1114 lines in 12 files changed: 11 ins; 1064 del; 39 mod
  Patch: https://git.openjdk.org/babylon/pull/547.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/547/head:pull/547

PR: https://git.openjdk.org/babylon/pull/547

From gfrost at openjdk.org  Thu Sep  4 13:48:29 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 4 Sep 2025 13:48:29 GMT
Subject: [code-reflection] Integrated: Post OpWrapper cleanup,
 removed some experiments and fixed =?UTF-8?B?VmlvbGFqb25lc+KApg==?=
In-Reply-To: <f1zQ_h-0v1YGbfKpkm0nBKS9HKwFI6k4EB9xoDJwPn0=.cf782ad1-7a3a-4f88-8a80-2f2eb61d9761@github.com>
References: <f1zQ_h-0v1YGbfKpkm0nBKS9HKwFI6k4EB9xoDJwPn0=.cf782ad1-7a3a-4f88-8a80-2f2eb61d9761@github.com>
Message-ID: <K37BKnBQ86LnxeRLnSKIwKnxN_nhU48M87DJSFt2g6E=.27e5153b-c1de-4e1b-970c-9c21297ad35e@github.com>

On Thu, 4 Sep 2025 13:43:38 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Another post Opwrapper cleanup. 
> 
> Also removed some dead experiments.
> 
> Patched Violajones example, where we had incorrect buffer access annotation on rgbToGrey kernel

This pull request has now been integrated.

Changeset: 25f28534
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/25f28534f317aa80241db70f7808a36c809971a3
Stats:     1114 lines in 12 files changed: 11 ins; 1064 del; 39 mod

Post OpWrapper cleanup, removed some experiments and fixed Violajones?

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

PR: https://git.openjdk.org/babylon/pull/547

From mabbay at openjdk.org  Thu Sep  4 15:27:34 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 4 Sep 2025 15:27:34 GMT
Subject: git: openjdk/babylon: code-reflection: Update
 ReflectMethods.BodyScanner.coerce to handle null targetType
Message-ID: <249773bd-645d-4215-8419-173ae1142334@openjdk.org>

Changeset: 429eb174
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2025-09-04 15:26:49 +0000
URL:       https://git.openjdk.org/babylon/commit/429eb17462edf9d11d75dd14dc5ffea6a5e5b7c0

Update ReflectMethods.BodyScanner.coerce to handle null targetType

Reviewed-by: mcimadamore

! src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java
! test/langtools/tools/javac/reflect/SwitchStatementTest.java


From mabbay at openjdk.org  Thu Sep  4 15:29:57 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 4 Sep 2025 15:29:57 GMT
Subject: [code-reflection] Integrated: Update ReflectMethods.BodyScanner.coerce
 to handle null targetType
In-Reply-To: <WhI2B3roAVXSiXQtTwahV04v5Nn7I_MWAMbrdXo7SBI=.109c15a4-d27e-4cdc-a411-efeccf5e301f@github.com>
References: <WhI2B3roAVXSiXQtTwahV04v5Nn7I_MWAMbrdXo7SBI=.109c15a4-d27e-4cdc-a411-efeccf5e301f@github.com>
Message-ID: <fdfz5AP1xg381F2e9g6bW7RhoxizZ9ZaxdyABNcHNaU=.a25809fc-62cf-46e8-a008-fd85af2b30f4@github.com>

On Fri, 29 Aug 2025 23:39:40 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> `ReflectMethods.BodyScanner.coerce` wasn't handling `null` targetType. For example, a `null` targetType may propagate to reach the method `coerce` when visiting case body of switch statement.

This pull request has now been integrated.

Changeset: 429eb174
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/429eb17462edf9d11d75dd14dc5ffea6a5e5b7c0
Stats:     39 lines in 2 files changed: 29 ins; 7 del; 3 mod

Update ReflectMethods.BodyScanner.coerce to handle null targetType

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.org/babylon/pull/536

From mabbay at openjdk.org  Thu Sep  4 20:00:16 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 4 Sep 2025 20:00:16 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v3]
In-Reply-To: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
Message-ID: <aa9Fk-9NaffCOLxedjoMInk5zZ9rxnb3XyIzt62Kn2w=.3ed46c95-14d7-44e1-8d38-3f949772a39b@github.com>

> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Detect if a lambda is quotable when lifting bytecode

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/545/files
  - new: https://git.openjdk.org/babylon/pull/545/files/29a62de1..3a4da8a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=02
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=01-02

  Stats: 7 lines in 1 file changed: 5 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/babylon/pull/545.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/545/head:pull/545

PR: https://git.openjdk.org/babylon/pull/545

From mabbay at openjdk.org  Fri Sep  5 02:51:41 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Fri, 5 Sep 2025 02:51:41 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v4]
In-Reply-To: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
Message-ID: <pgawQYLvBBCkE9fCGOGijYizMUyBivhHygs3EUDxLbc=.644bf9d5-752d-4ab4-a890-3663a9f63e59@github.com>

> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.

Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:

 - Correct the way we detect if a lambda is quotable when lifting bytecode
 - Update expected models in tests to include the attribute

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/545/files
  - new: https://git.openjdk.org/babylon/pull/545/files/3a4da8a4..3259b02a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=03
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=02-03

  Stats: 38 lines in 4 files changed: 1 ins; 0 del; 37 mod
  Patch: https://git.openjdk.org/babylon/pull/545.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/545/head:pull/545

PR: https://git.openjdk.org/babylon/pull/545

From jfumero at openjdk.org  Fri Sep  5 13:19:46 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Fri, 5 Sep 2025 13:19:46 GMT
Subject: [code-reflection] RFR: New Examples: Dialects and Dynamic Function
 Builds
Message-ID: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>

- `DialectSample`: Example of how to extends the code reflection `Op` to create a new dialect. 
- `DynamicFunctionBuild`: Example of how to create a new function dynamically to compute the inverse of a square root.  The code model is built dynamically for a new method and it is evaluated in the `Interpreter`.

How to run?


mvn clean package
java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectSample
java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DynamicFunctionBuild

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

Commit messages:
 - minor comment
 - trip extra spaces
 - New example: building new functions dynamically with code reflection
 - [example] Fix printing for dialects
 - Code Reflection sample for creating new Ops for a dialect

Changes: https://git.openjdk.org/babylon/pull/549/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=00
  Stats: 432 lines in 3 files changed: 432 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/babylon/pull/549.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/549/head:pull/549

PR: https://git.openjdk.org/babylon/pull/549

From duke at openjdk.org  Fri Sep  5 13:19:46 2025
From: duke at openjdk.org (duke)
Date: Fri, 5 Sep 2025 13:19:46 GMT
Subject: [code-reflection] RFR: New Examples: Dialects and Dynamic Function
 Builds
In-Reply-To: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
References: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
Message-ID: <rhBaiomLL9JZmCnQugZh9VMO0Ljn-aaWnOxyBpqVYBY=.779cb287-d749-4556-b5e9-059454873a97@github.com>

On Fri, 5 Sep 2025 11:01:34 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> - `DialectSample`: Example of how to extends the code reflection `Op` to create a new dialect. 
> - `DynamicFunctionBuild`: Example of how to create a new function dynamically to compute the inverse of a square root.  The code model is built dynamically for a new method and it is evaluated in the `Interpreter`.
> 
> How to run?
> 
> 
> mvn clean package
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectSample
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DynamicFunctionBuild

@jjfumero 
Your change (at version 46bf9c9523babac4ea1a646a94efa6172588e1fc) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/babylon/pull/549#issuecomment-3258325381

From jfumero at openjdk.org  Fri Sep  5 13:57:07 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Fri, 5 Sep 2025 13:57:07 GMT
Subject: [code-reflection] RFR: New Examples: Dialects and Dynamic Function
 Builds [v2]
In-Reply-To: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
References: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
Message-ID: <YGUi7VJufSXxszWhWO67E-6DuXNFIc7Me1TS3YmOmYY=.65febfbe-e7dc-4683-998e-10d76d2cd8d3@github.com>

> - `DialectSample`: Example of how to extends the code reflection `Op` to create a new dialect. 
> - `DynamicFunctionBuild`: Example of how to create a new function dynamically to compute the inverse of a square root.  The code model is built dynamically for a new method and it is evaluated in the `Interpreter`.
> 
> How to run?
> 
> 
> mvn clean package
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectSample
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DynamicFunctionBuild

Juan Fumero has updated the pull request incrementally with one additional commit since the last revision:

  minor clean up

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/549/files
  - new: https://git.openjdk.org/babylon/pull/549/files/46bf9c95..dbde9d0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/babylon/pull/549.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/549/head:pull/549

PR: https://git.openjdk.org/babylon/pull/549

From duke at openjdk.org  Fri Sep  5 13:57:08 2025
From: duke at openjdk.org (duke)
Date: Fri, 5 Sep 2025 13:57:08 GMT
Subject: [code-reflection] RFR: New Examples: Dialects and Dynamic Function
 Builds
In-Reply-To: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
References: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
Message-ID: <i0kj76PRWW7GGOixX_lNYtbzOpMiSKtRrsGxq6UnSiU=.7f792b31-169b-4429-ba8c-bd76b2553e57@github.com>

On Fri, 5 Sep 2025 11:01:34 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> - `DialectSample`: Example of how to extends the code reflection `Op` to create a new dialect. 
> - `DynamicFunctionBuild`: Example of how to create a new function dynamically to compute the inverse of a square root.  The code model is built dynamically for a new method and it is evaluated in the `Interpreter`.
> 
> How to run?
> 
> 
> mvn clean package
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectSample
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DynamicFunctionBuild

@jjfumero 
Your change (at version dbde9d0bd45ac42d526e76b373e37e060ce5755f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/babylon/pull/549#issuecomment-3258431218

From gfrost at openjdk.org  Fri Sep  5 16:31:30 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 5 Sep 2025 16:31:30 GMT
Subject: git: openjdk/babylon: code-reflection: The OpWrapper removal caused a
 regression extracting nested ifaces
Message-ID: <42bbc20c-832d-4856-a490-feb83e6189da@openjdk.org>

Changeset: 5f135742
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-05 16:30:43 +0000
URL:       https://git.openjdk.org/babylon/commit/5f135742f877ca4f8eaeb888291b52b2cdbf2c01

The OpWrapper removal caused a regression extracting nested ifaces

! hat/core/src/main/java/hat/codebuilders/HATCodeBuilder.java
! hat/core/src/main/java/hat/codebuilders/HATCodeBuilderWithContext.java
- hat/core/src/main/java/hat/optools/InvokeOpWrapper.java


From gfrost at openjdk.org  Fri Sep  5 16:34:10 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 5 Sep 2025 16:34:10 GMT
Subject: [code-reflection] Integrated: The OpWrapper removal caused a
 regression extracting nested ifaces
Message-ID: <frH4uI8ZV9hk7-Ll1g3X6RIOJ9lc-MhABVVm5JMQCUc=.7a3f82af-a54a-4347-82ab-77ff6406e568@github.com>

This fixes a codegen bug where the lhs var assignment from a rhs iface buffer access was not generating the var decl ;)

This only affected violajones and heal examples.

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

Commit messages:
 - The OpWrapper removal caused a regression extracting nested ifaces

Changes: https://git.openjdk.org/babylon/pull/550/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=550&range=00
  Stats: 4 lines in 3 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/babylon/pull/550.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/550/head:pull/550

PR: https://git.openjdk.org/babylon/pull/550

From gfrost at openjdk.org  Fri Sep  5 16:34:12 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 5 Sep 2025 16:34:12 GMT
Subject: [code-reflection] Integrated: The OpWrapper removal caused a
 regression extracting nested ifaces
In-Reply-To: <frH4uI8ZV9hk7-Ll1g3X6RIOJ9lc-MhABVVm5JMQCUc=.7a3f82af-a54a-4347-82ab-77ff6406e568@github.com>
References: <frH4uI8ZV9hk7-Ll1g3X6RIOJ9lc-MhABVVm5JMQCUc=.7a3f82af-a54a-4347-82ab-77ff6406e568@github.com>
Message-ID: <hib8u6iQa_arWy1HBUGs6lGtbHFtxnYviY9ZXSnVWFs=.6ec77981-0914-4642-b3e5-d23822bccdc7@github.com>

On Fri, 5 Sep 2025 16:28:52 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> This fixes a codegen bug where the lhs var assignment from a rhs iface buffer access was not generating the var decl ;)
> 
> This only affected violajones and heal examples.

This pull request has now been integrated.

Changeset: 5f135742
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/5f135742f877ca4f8eaeb888291b52b2cdbf2c01
Stats:     4 lines in 3 files changed: 2 ins; 0 del; 2 mod

The OpWrapper removal caused a regression extracting nested ifaces

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

PR: https://git.openjdk.org/babylon/pull/550

From gfrost at openjdk.org  Fri Sep  5 16:48:09 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 5 Sep 2025 16:48:09 GMT
Subject: git: openjdk/babylon: code-reflection: Patch to cleanup code gen issue
 foo.bar vs foo->bar for nested ifaces
Message-ID: <2413f3ac-9ad1-4d58-9fe5-b7f0dcea048f@openjdk.org>

Changeset: 9087951d
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-05 16:45:54 +0000
URL:       https://git.openjdk.org/babylon/commit/9087951d1889fc5744c00955656cda9f06aa5f38

Patch to cleanup code gen issue foo.bar vs foo->bar for nested ifaces

! hat/core/src/main/java/hat/codebuilders/HATCodeBuilderWithContext.java


From gfrost at openjdk.org  Fri Sep  5 16:48:34 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 5 Sep 2025 16:48:34 GMT
Subject: [code-reflection] Integrated: Patch to cleanup code gen issue foo.bar
 vs foo->bar for nested ifaces
Message-ID: <XSDiCO2D79GNZh9iyYmNNvqIco8D0fg0Qf5-q1zuVfc=.5414d009-51f6-4c7a-9645-f6e9c9c08754@github.com>

Juan and I worked on a patch to simplify code gen issue. We were generating 'dot' references on ptrs to structs instead of 'arrow' references.

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

Commit messages:
 - Patch to cleanup code gen issue foo.bar vs foo->bar for nested ifaces

Changes: https://git.openjdk.org/babylon/pull/551/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=551&range=00
  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/babylon/pull/551.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/551/head:pull/551

PR: https://git.openjdk.org/babylon/pull/551

From gfrost at openjdk.org  Fri Sep  5 16:48:34 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 5 Sep 2025 16:48:34 GMT
Subject: [code-reflection] Integrated: Patch to cleanup code gen issue foo.bar
 vs foo->bar for nested ifaces
In-Reply-To: <XSDiCO2D79GNZh9iyYmNNvqIco8D0fg0Qf5-q1zuVfc=.5414d009-51f6-4c7a-9645-f6e9c9c08754@github.com>
References: <XSDiCO2D79GNZh9iyYmNNvqIco8D0fg0Qf5-q1zuVfc=.5414d009-51f6-4c7a-9645-f6e9c9c08754@github.com>
Message-ID: <VyTb4Vv1QnHa-F8A_4fyQ8errFRJF-1bVZNl22_SKLg=.642608b1-c45d-48a8-91f8-453606a869cc@github.com>

On Fri, 5 Sep 2025 16:42:50 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Juan and I worked on a patch to simplify code gen issue. We were generating 'dot' references on ptrs to structs instead of 'arrow' references.

This pull request has now been integrated.

Changeset: 9087951d
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/9087951d1889fc5744c00955656cda9f06aa5f38
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

Patch to cleanup code gen issue foo.bar vs foo->bar for nested ifaces

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

PR: https://git.openjdk.org/babylon/pull/551

From psandoz at openjdk.org  Fri Sep  5 19:38:27 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 5 Sep 2025 19:38:27 GMT
Subject: [code-reflection] RFR: New Examples: Dialects and Dynamic Function
 Builds [v2]
In-Reply-To: <YGUi7VJufSXxszWhWO67E-6DuXNFIc7Me1TS3YmOmYY=.65febfbe-e7dc-4683-998e-10d76d2cd8d3@github.com>
References: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
 <YGUi7VJufSXxszWhWO67E-6DuXNFIc7Me1TS3YmOmYY=.65febfbe-e7dc-4683-998e-10d76d2cd8d3@github.com>
Message-ID: <OgL92H7q56T1WcoTkb6UbRgaaYk5Ae_1L_MDJ0HkAd0=.6761909b-a42b-4a98-b60e-ffc70716dd6c@github.com>

On Fri, 5 Sep 2025 13:57:07 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

>> - `DialectSample`: Example of how to extends the code reflection `Op` to create a new dialect. 
>> - `DynamicFunctionBuild`: Example of how to create a new function dynamically to compute the inverse of a square root.  The code model is built dynamically for a new method and it is evaluated in the `Interpreter`.
>> 
>> How to run?
>> 
>> 
>> mvn clean package
>> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectSample
>> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DynamicFunctionBuild
>
> Juan Fumero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor clean up

cr-examples/samples/src/main/java/oracle/code/samples/DialectSample.java line 80:

> 78:         private TypeElement typeElement;
> 79: 
> 80:         MyAdd(String name, List<Value> operands, TypeElement typeElement) {

The operation name should not generally be something the user provides when constructing an operation. The name is for human readability in text, and the key that allows (re-)construction when parsing text back into code models. It's something that should be derived from other inputs and/or constant data. Further, its not something we should really use for pattern matching.

I would like to see if we could remove the name from the state of Op. `OpWriter` of course needs it. Maybe by default the written operation name is the operation (fully qualified) class name, and implementations can override it maybe via a separate interface. We might be able to group the name and externalization of state under one concept for reading/parsing.

cr-examples/samples/src/main/java/oracle/code/samples/DialectSample.java line 101:

> 99:         @Override
> 100:         public Map<String, Object> externalize() {
> 101:             return Map.of("", this.typeElement);

The `typeElement` is already part of the operation, it's result type so this is duplicating information. Instead consider a property of addition as an example e.g., the kind of addition for integral types like signed, unsigned, or saturating.

cr-examples/samples/src/main/java/oracle/code/samples/DialectSample.java line 221:

> 219:         @Override
> 220:         public Map<String, Object> externalize() {
> 221:             return Map.of("", this.typeDescriptor);

This can be the name of the function to invoke, which you are currently using as the operation name.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/549#discussion_r2325895385
PR Review Comment: https://git.openjdk.org/babylon/pull/549#discussion_r2325868741
PR Review Comment: https://git.openjdk.org/babylon/pull/549#discussion_r2325896949

From psandoz at openjdk.org  Fri Sep  5 21:01:26 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 5 Sep 2025 21:01:26 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v4]
In-Reply-To: <pgawQYLvBBCkE9fCGOGijYizMUyBivhHygs3EUDxLbc=.644bf9d5-752d-4ab4-a890-3663a9f63e59@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <pgawQYLvBBCkE9fCGOGijYizMUyBivhHygs3EUDxLbc=.644bf9d5-752d-4ab4-a890-3663a9f63e59@github.com>
Message-ID: <l47Wr3Xxc3LRT-YZ-ArZppP70TY9NwdaYXl8ZPBHa74=.81cec25a-2a30-4fa2-87ee-3bce0311fa38@github.com>

On Fri, 5 Sep 2025 02:51:41 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.
>
> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Correct the way we detect if a lambda is quotable when lifting bytecode
>  - Update expected models in tests to include the attribute

src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/BytecodeLift.java line 479:

> 477:                                                                        JavaType.type(inst.typeSymbol().returnType()));
> 478:                         // if FLAG_QUOTABLE is set, the lambda is quotable
> 479:                         if (inst.bootstrapArgs().get(inst.bootstrapArgs().size() - 3) instanceof Integer a

IIUC the flags argument should always be the fourth bootstrap argument? See [here](https://github.com/openjdk/babylon/blob/9ca6a4243794b974562c43ed6072dc0575c418ba/src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java#L510)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/545#discussion_r2326037006

From duke at openjdk.org  Fri Sep  5 21:15:48 2025
From: duke at openjdk.org (Ruby Chen)
Date: Fri, 5 Sep 2025 21:15:48 GMT
Subject: [code-reflection] RFR: Add buffer tagging and opt-out moduleOp backend
Message-ID: <6Ug6CjLyEgU5El3kGOrUpQWpSWbmnHA0XziL8c72he4=.30e21276-38ea-4b15-8505-0fe4e8076ce2@github.com>

Add a tool to tag kernel buffers with RO, WO, RW, or NA. 

Currently, the result of the buffer tagger is only used to assert that it matches with the respective buffer annotations in the HAT kernels. 

Also make moduleOp an opt-out backend for HAT, which can be disabled by passing the flag `noModuleOp` when running HAT. For example, running the mandel example with the ffi-opencl backend and moduleOp disabled can be done with

java @hat/run noModuleOp ffi-opencl mandel

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

Commit messages:
 - Clean up BufferTagger
 - Merge branch 'openjdk:code-reflection' into buffer-tagging
 - Merge branch 'openjdk:code-reflection' into buffer-tagging
 - Add buffer tagging and opt-out moduleOp backend

Changes: https://git.openjdk.org/babylon/pull/548/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=548&range=00
  Stats: 272 lines in 10 files changed: 240 ins; 18 del; 14 mod
  Patch: https://git.openjdk.org/babylon/pull/548.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/548/head:pull/548

PR: https://git.openjdk.org/babylon/pull/548

From gfrost at openjdk.org  Sat Sep  6 13:07:05 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Sat, 6 Sep 2025 13:07:05 GMT
Subject: git: openjdk/babylon: code-reflection: Hat cleanup codegen
Message-ID: <a529c172-6fc1-4f9a-b174-a06cee6a5fe0@openjdk.org>

Changeset: 5e338cc8
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-06 13:05:04 +0000
URL:       https://git.openjdk.org/babylon/commit/5e338cc88a01c278308165385c64f74e6146e24b

Hat cleanup codegen

! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaHATKernelBuilder.java
! hat/backends/ffi/opencl/src/main/java/hat/backend/ffi/OpenCLHATKernelBuilder.java
! hat/backends/jextracted/opencl/src/main/java/hat/backend/jextracted/OpenCLHatKernelBuilder.java
! hat/core/src/main/java/hat/buffer/ArgArray.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/HATCodeBuilderContext.java
! hat/core/src/main/java/hat/codebuilders/HATCodeBuilderWithContext.java
! hat/core/src/main/java/hat/optools/OpTk.java
! hat/tools/src/main/java/hat/tools/text/JavaHATCodeBuilder.java


From gfrost at openjdk.org  Sat Sep  6 13:08:01 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Sat, 6 Sep 2025 13:08:01 GMT
Subject: [code-reflection] Integrated: Hat cleanup codegen
Message-ID: <8iZuv1DoPw1Ndz-7xp7dC7WZZJf2XikCLmkeeiyavC8=.2322a487-6d32-4159-b637-42dc1d80e6a4@github.com>

We have multiple tiers of c99 code gen.  

In this cleanup I moved common functionality down the class hierarchy as much as possible, to avoid duplications. 

Also preferring not to pass strings, but compuse using Core.Op and Java.Op types. 

I also separated out calls to identifer() to varName(), funcName(), keyword() ....

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

Commit messages:
 - moved common code gen methods to base builder classes
 - move some code to OpTk and push some down to common HATBuilder

Changes: https://git.openjdk.org/babylon/pull/552/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=552&range=00
  Stats: 508 lines in 12 files changed: 165 ins; 236 del; 107 mod
  Patch: https://git.openjdk.org/babylon/pull/552.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/552/head:pull/552

PR: https://git.openjdk.org/babylon/pull/552

From gfrost at openjdk.org  Sat Sep  6 13:08:01 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Sat, 6 Sep 2025 13:08:01 GMT
Subject: [code-reflection] Integrated: Hat cleanup codegen
In-Reply-To: <8iZuv1DoPw1Ndz-7xp7dC7WZZJf2XikCLmkeeiyavC8=.2322a487-6d32-4159-b637-42dc1d80e6a4@github.com>
References: <8iZuv1DoPw1Ndz-7xp7dC7WZZJf2XikCLmkeeiyavC8=.2322a487-6d32-4159-b637-42dc1d80e6a4@github.com>
Message-ID: <GxmwpzsrVHCu8s3q4RfO2BXMJu2NLYQh8WWtHuz37N0=.a2199e48-0c0d-413d-9952-37010991f20e@github.com>

On Sat, 6 Sep 2025 13:03:19 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> We have multiple tiers of c99 code gen.  
> 
> In this cleanup I moved common functionality down the class hierarchy as much as possible, to avoid duplications. 
> 
> Also preferring not to pass strings, but compuse using Core.Op and Java.Op types. 
> 
> I also separated out calls to identifer() to varName(), funcName(), keyword() ....

This pull request has now been integrated.

Changeset: 5e338cc8
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/5e338cc88a01c278308165385c64f74e6146e24b
Stats:     508 lines in 12 files changed: 165 ins; 236 del; 107 mod

Hat cleanup codegen

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

PR: https://git.openjdk.org/babylon/pull/552

From gfrost at openjdk.org  Sun Sep  7 11:33:30 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 7 Sep 2025 11:33:30 GMT
Subject: git: openjdk/babylon: code-reflection: Hat more codegen cleanup
Message-ID: <b3ad27ed-6e3a-4ffa-822a-e3566769da49@openjdk.org>

Changeset: 4bee223d
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-07 11:31:21 +0000
URL:       https://git.openjdk.org/babylon/commit/4bee223d5f3d7dd08c863916553174e0612405c4

Hat more codegen cleanup

! 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/jextracted/opencl/src/main/java/hat/backend/jextracted/OpenCLHatKernelBuilder.java
! hat/core/src/main/java/hat/buffer/SchemaBuilder.java
+ hat/core/src/main/java/hat/codebuilders/BabylonOpBuilder.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/CodeBuilderContext.java
! hat/core/src/main/java/hat/codebuilders/HATCodeBuilder.java
- hat/core/src/main/java/hat/codebuilders/HATCodeBuilderContext.java
! hat/core/src/main/java/hat/codebuilders/HATCodeBuilderWithContext.java
+ hat/core/src/main/java/hat/codebuilders/ScopedCodeBuilderContext.java
! hat/core/src/main/java/hat/optools/OpTk.java
- hat/core/src/main/java/hat/util/StreamCounter.java
! hat/tools/src/main/java/hat/tools/text/JavaHATCodeBuilder.java


From gfrost at openjdk.org  Sun Sep  7 11:34:58 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 7 Sep 2025 11:34:58 GMT
Subject: [code-reflection] Integrated: Hat more codegen cleanup
Message-ID: <8WswKMsH_g6ORKmhZbQwGN0BDNx_Ae29Or4NhxqEHAs=.3f329382-5efa-42cf-8499-d07331fa6235@github.com>

Discovered more opportunities for c99 codegen cleanup. 

Lots of dead code removed as well as refactoring of common CodeBuilder patterns. 

PTXCodeBuilder can now be refactored to use the CodeBuilderContext and BabylonOpBuilder iface to simplify code gen

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

Commit messages:
 - removed StreamCounter
 - removing dead code, simplified StremCounted code
 - moved common code to OpTk

Changes: https://git.openjdk.org/babylon/pull/553/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=553&range=00
  Stats: 1331 lines in 17 files changed: 522 ins; 641 del; 168 mod
  Patch: https://git.openjdk.org/babylon/pull/553.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/553/head:pull/553

PR: https://git.openjdk.org/babylon/pull/553

From gfrost at openjdk.org  Sun Sep  7 11:34:59 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 7 Sep 2025 11:34:59 GMT
Subject: [code-reflection] Integrated: Hat more codegen cleanup
In-Reply-To: <8WswKMsH_g6ORKmhZbQwGN0BDNx_Ae29Or4NhxqEHAs=.3f329382-5efa-42cf-8499-d07331fa6235@github.com>
References: <8WswKMsH_g6ORKmhZbQwGN0BDNx_Ae29Or4NhxqEHAs=.3f329382-5efa-42cf-8499-d07331fa6235@github.com>
Message-ID: <yNNziCUqMKFpZShUAsVgi9vihX18ihYvzH3AH9bT9CA=.1c3ef4b7-1e2e-4aa7-8533-ac5701f26a03@github.com>

On Sun, 7 Sep 2025 11:29:38 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Discovered more opportunities for c99 codegen cleanup. 
> 
> Lots of dead code removed as well as refactoring of common CodeBuilder patterns. 
> 
> PTXCodeBuilder can now be refactored to use the CodeBuilderContext and BabylonOpBuilder iface to simplify code gen

This pull request has now been integrated.

Changeset: 4bee223d
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/4bee223d5f3d7dd08c863916553174e0612405c4
Stats:     1331 lines in 17 files changed: 522 ins; 641 del; 168 mod

Hat more codegen cleanup

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

PR: https://git.openjdk.org/babylon/pull/553

From adam.sotona at oracle.com  Mon Sep  8 15:56:39 2025
From: adam.sotona at oracle.com (Adam Sotona)
Date: Mon, 8 Sep 2025 15:56:39 +0000
Subject: CFV: New Babylon Reviewer: Juan Fumero 
In-Reply-To: <BF631D4C-F46A-4A5B-8162-1FCA37429321@oracle.com>
References: <BF631D4C-F46A-4A5B-8162-1FCA37429321@oracle.com>
Message-ID: <IA0PR10MB68433A53DF53E2C30210DDBE8C0CA@IA0PR10MB6843.namprd10.prod.outlook.com>

Vote: Yes

Adam

From: babylon-dev <babylon-dev-retn at openjdk.org> on behalf of Paul Sandoz <paul.sandoz at oracle.com>
Date: Monday, 25 August 2025 at 23:36
To: babylon-dev at openjdk.org <babylon-dev at openjdk.org>
Subject: CFV: New Babylon Reviewer: Juan Fumero

I hereby nominate Juan Fumero [1] to Babylon Reviewer [0].

Juan is a member of the Java Team at Oracle, has extensive experience in Java and GPUs, and is already contributing fixes and features to HAT, and examples of code reflection.

Votes are due by September 9th, 2025.

Only current Babylon Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3].

Paul.

[0] Project Babylon does not currently make any distinction between Committer and Reviewer, and PRs are not required to be reviewed by Reviewers before integration.
[1] https://openjdk.org/census#jfumero
[2] https://openjdk.java.net/census
[3] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20250908/4d9f8f92/attachment-0001.htm>

From gfrost at openjdk.org  Mon Sep  8 16:16:51 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 8 Sep 2025 16:16:51 GMT
Subject: git: openjdk/babylon: code-reflection: HAT more consistent use of
 scoped code builder context + removed initialization of KernelContext in
 kernels
Message-ID: <e0b546e9-bd69-458b-918e-2f87c8f0f496@openjdk.org>

Changeset: 4330ec27
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-08 16:14:59 +0000
URL:       https://git.openjdk.org/babylon/commit/4330ec273b9e9c1f1b9c3468fc635c8cd8a69650

HAT more consistent use of scoped code builder context + removed initialization of KernelContext in kernels

! 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/opencl/src/main/java/hat/backend/ffi/OpenCLBackend.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/jextracted/opencl/src/main/java/hat/backend/jextracted/OpenCLBackend.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/callgraph/KernelCallGraph.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/HATCodeBuilderWithContext.java
! hat/core/src/main/java/hat/optools/OpTk.java
! hat/tools/src/main/java/hat/tools/text/JavaHATCodeBuilder.java
! hat/tools/src/main/java/hat/tools/text/TestJavaHATCodeBuilder.java


From gfrost at openjdk.org  Mon Sep  8 16:18:06 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 8 Sep 2025 16:18:06 GMT
Subject: [code-reflection] Integrated: HAT more consistent use of scoped code
 builder context + removed initialization of KernelContext in kernels
Message-ID: <Z2VXIFp3ER_dk1Cr5k-gk8KbwjaoSZaNtwkriazBObw=.0bfb79df-92ff-4663-ada8-be1755290733@github.com>

More cleanup of C99 code gen for kernels and compute methods. 

We now pass in ScopedCodeBuildContext to both. 

We now inline map KernelContext accesses directly to appropriate methods for cuda and opencl 

So `kc.x` -> get_global_id(0) for opencl, rather than initializing a local KernelContext struct. 

This makes code gen less verbose.

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

Commit messages:
 - removed kernelcontext initialization from kernels
 - more consistant use of ScopedContext

Changes: https://git.openjdk.org/babylon/pull/555/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=555&range=00
  Stats: 491 lines in 16 files changed: 104 ins; 295 del; 92 mod
  Patch: https://git.openjdk.org/babylon/pull/555.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/555/head:pull/555

PR: https://git.openjdk.org/babylon/pull/555

From gfrost at openjdk.org  Mon Sep  8 16:18:06 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 8 Sep 2025 16:18:06 GMT
Subject: [code-reflection] Integrated: HAT more consistent use of scoped code
 builder context + removed initialization of KernelContext in kernels
In-Reply-To: <Z2VXIFp3ER_dk1Cr5k-gk8KbwjaoSZaNtwkriazBObw=.0bfb79df-92ff-4663-ada8-be1755290733@github.com>
References: <Z2VXIFp3ER_dk1Cr5k-gk8KbwjaoSZaNtwkriazBObw=.0bfb79df-92ff-4663-ada8-be1755290733@github.com>
Message-ID: <vUijXEFPrD63KQQXV-sQpY5lQf6uXU8viCdnXF27uW0=.1fd6ff58-4da5-4ace-97c5-1699d998b0af@github.com>

On Mon, 8 Sep 2025 16:13:06 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> More cleanup of C99 code gen for kernels and compute methods. 
> 
> We now pass in ScopedCodeBuildContext to both. 
> 
> We now inline map KernelContext accesses directly to appropriate methods for cuda and opencl 
> 
> So `kc.x` -> get_global_id(0) for opencl, rather than initializing a local KernelContext struct. 
> 
> This makes code gen less verbose.

This pull request has now been integrated.

Changeset: 4330ec27
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/4330ec273b9e9c1f1b9c3468fc635c8cd8a69650
Stats:     491 lines in 16 files changed: 104 ins; 295 del; 92 mod

HAT more consistent use of scoped code builder context + removed initialization of KernelContext in kernels

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

PR: https://git.openjdk.org/babylon/pull/555

From duke at openjdk.org  Mon Sep  8 16:30:28 2025
From: duke at openjdk.org (Ruby Chen)
Date: Mon, 8 Sep 2025 16:30:28 GMT
Subject: [code-reflection] RFR: Add buffer tagging and opt-out moduleOp
 backend [v2]
In-Reply-To: <6Ug6CjLyEgU5El3kGOrUpQWpSWbmnHA0XziL8c72he4=.30e21276-38ea-4b15-8505-0fe4e8076ce2@github.com>
References: <6Ug6CjLyEgU5El3kGOrUpQWpSWbmnHA0XziL8c72he4=.30e21276-38ea-4b15-8505-0fe4e8076ce2@github.com>
Message-ID: <-nNS252g3oKTG8uJeBv2yh0PLoW0NrZSJeiuwAgXAnQ=.0810c5f3-7761-45db-b479-e5904dd52f8c@github.com>

> Add a tool to tag kernel buffers with RO, WO, RW, or NA. 
> 
> Currently, the result of the buffer tagger is only used to assert that it matches with the respective buffer annotations in the HAT kernels. 
> 
> Also make moduleOp an opt-out backend for HAT, which can be disabled by passing the flag `noModuleOp` when running HAT. For example, running the mandel example with the ffi-opencl backend and moduleOp disabled can be done with
> 
> java @hat/run noModuleOp ffi-opencl mandel

Ruby Chen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'code-reflection' into buffer-tagging
 - Clean up BufferTagger
 - Merge branch 'openjdk:code-reflection' into buffer-tagging
 - Merge branch 'openjdk:code-reflection' into buffer-tagging
 - Add buffer tagging and opt-out moduleOp backend

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

Changes: https://git.openjdk.org/babylon/pull/548/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=548&range=01
  Stats: 277 lines in 10 files changed: 243 ins; 20 del; 14 mod
  Patch: https://git.openjdk.org/babylon/pull/548.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/548/head:pull/548

PR: https://git.openjdk.org/babylon/pull/548

From duke at openjdk.org  Mon Sep  8 16:48:27 2025
From: duke at openjdk.org (duke)
Date: Mon, 8 Sep 2025 16:48:27 GMT
Subject: [code-reflection] RFR: Add buffer tagging and opt-out moduleOp
 backend [v2]
In-Reply-To: <-nNS252g3oKTG8uJeBv2yh0PLoW0NrZSJeiuwAgXAnQ=.0810c5f3-7761-45db-b479-e5904dd52f8c@github.com>
References: <6Ug6CjLyEgU5El3kGOrUpQWpSWbmnHA0XziL8c72he4=.30e21276-38ea-4b15-8505-0fe4e8076ce2@github.com>
 <-nNS252g3oKTG8uJeBv2yh0PLoW0NrZSJeiuwAgXAnQ=.0810c5f3-7761-45db-b479-e5904dd52f8c@github.com>
Message-ID: <sVeU8j3Z110Xl4l587fRgVOYouyMqubPohcnUamnIUw=.ba89096d-f42d-40de-9c3e-d8df2cef5dfa@github.com>

On Mon, 8 Sep 2025 16:30:28 GMT, Ruby Chen <duke at openjdk.org> wrote:

>> Add a tool to tag kernel buffers with RO, WO, RW, or NA. 
>> 
>> Currently, the result of the buffer tagger is only used to assert that it matches with the respective buffer annotations in the HAT kernels. 
>> 
>> Also make moduleOp an opt-out backend for HAT, which can be disabled by passing the flag `noModuleOp` when running HAT. For example, running the mandel example with the ffi-opencl backend and moduleOp disabled can be done with
>> 
>> java @hat/run noModuleOp ffi-opencl mandel
>
> Ruby Chen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'code-reflection' into buffer-tagging
>  - Clean up BufferTagger
>  - Merge branch 'openjdk:code-reflection' into buffer-tagging
>  - Merge branch 'openjdk:code-reflection' into buffer-tagging
>  - Add buffer tagging and opt-out moduleOp backend

@rbrchen 
Your change (at version 75e5fc38ccb46c6e2a067fb471b2cfb0b63a6ac5) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/babylon/pull/548#issuecomment-3267130836

From gfrost at openjdk.org  Mon Sep  8 16:51:09 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 8 Sep 2025 16:51:09 GMT
Subject: git: openjdk/babylon: code-reflection: Add buffer tagging and opt-out
 moduleOp backend
Message-ID: <f8929b52-85a8-461d-934b-f385a95adb85@openjdk.org>

Changeset: 4cd871ef
Branch: code-reflection
Author:    Ruby Chen <ruby.r.chen at gmail.com>
Committer: Gary Frost <gfrost at openjdk.org>
Date:      2025-09-08 16:50:02 +0000
URL:       https://git.openjdk.org/babylon/commit/4cd871eff7c9fd85a78953e3a3b9b4a0e7bde3c5

Add buffer tagging and opt-out moduleOp backend

! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaBackend.java
! hat/backends/ffi/mock/src/main/java/hat/backend/ffi/MockBackend.java
! hat/backends/ffi/shared/src/main/java/hat/backend/ffi/C99FFIBackend.java
+ hat/core/src/main/java/hat/BufferTagger.java
! hat/core/src/main/java/hat/buffer/ArgArray.java
! hat/core/src/main/java/hat/callgraph/CallGraph.java
! hat/core/src/main/java/hat/callgraph/ComputeCallGraph.java
! hat/core/src/main/java/hat/callgraph/KernelCallGraph.java
! hat/hat/Script.java
! hat/hat/run.java


From duke at openjdk.org  Mon Sep  8 16:53:30 2025
From: duke at openjdk.org (Ruby Chen)
Date: Mon, 8 Sep 2025 16:53:30 GMT
Subject: [code-reflection] Integrated: Add buffer tagging and opt-out moduleOp
 backend
In-Reply-To: <6Ug6CjLyEgU5El3kGOrUpQWpSWbmnHA0XziL8c72he4=.30e21276-38ea-4b15-8505-0fe4e8076ce2@github.com>
References: <6Ug6CjLyEgU5El3kGOrUpQWpSWbmnHA0XziL8c72he4=.30e21276-38ea-4b15-8505-0fe4e8076ce2@github.com>
Message-ID: <DXHK_d85oMeYh9m_62d96elq58lVK2mXurgdCKBWUrs=.3140071d-e1ac-43ac-8749-3c7a977b4ba6@github.com>

On Thu, 4 Sep 2025 22:00:21 GMT, Ruby Chen <duke at openjdk.org> wrote:

> Add a tool to tag kernel buffers with RO, WO, RW, or NA. 
> 
> Currently, the result of the buffer tagger is only used to assert that it matches with the respective buffer annotations in the HAT kernels. 
> 
> Also make moduleOp an opt-out backend for HAT, which can be disabled by passing the flag `noModuleOp` when running HAT. For example, running the mandel example with the ffi-opencl backend and moduleOp disabled can be done with
> 
> java @hat/run noModuleOp ffi-opencl mandel

This pull request has now been integrated.

Changeset: 4cd871ef
Author:    Ruby Chen <ruby.r.chen at gmail.com>
Committer: Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/4cd871eff7c9fd85a78953e3a3b9b4a0e7bde3c5
Stats:     277 lines in 10 files changed: 243 ins; 20 del; 14 mod

Add buffer tagging and opt-out moduleOp backend

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

PR: https://git.openjdk.org/babylon/pull/548

From asotona at openjdk.org  Mon Sep  8 17:57:03 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Sep 2025 17:57:03 GMT
Subject: [code-reflection] RFR: OpWriter.ColoringOption proposal [v3]
In-Reply-To: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
References: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
Message-ID: <m3nZl3PGzxZwfQRck_h3zVgJ6nCDzEI-ehWHCw2mPNY=.2fdd4b99-44a6-414d-9c03-8a8181dbd6e5@github.com>

> I propose `OpWriter` enables simple ANSI coloring based on `jdk.incubator.code.extern.OpWriter.COLOR` system property.
> 
> ANSI coloring sample:
> <img width="989" height="746" alt="ansi-coloring" src="https://github.com/user-attachments/assets/2025bcbe-6c6c-48ab-8ed5-67ff88b47fe6" />

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed ColoringOption
  ANSI coloring is triggered by jdk.incubator.code.extern.OpWriter.COLOR property

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/546/files
  - new: https://git.openjdk.org/babylon/pull/546/files/095a11c7..d4501a1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=546&range=02
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=546&range=01-02

  Stats: 40 lines in 1 file changed: 0 ins; 35 del; 5 mod
  Patch: https://git.openjdk.org/babylon/pull/546.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/546/head:pull/546

PR: https://git.openjdk.org/babylon/pull/546

From asotona at openjdk.org  Mon Sep  8 17:57:05 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 8 Sep 2025 17:57:05 GMT
Subject: [code-reflection] RFR: OpWriter.ColoringOption proposal [v2]
In-Reply-To: <Uml2L7vzQDuD4_IyjWUPftlA2dvutMt28KVjJm54Kf8=.d119b3f2-e6cc-4652-8ca5-c837372b642d@github.com>
References: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
 <Uml2L7vzQDuD4_IyjWUPftlA2dvutMt28KVjJm54Kf8=.d119b3f2-e6cc-4652-8ca5-c837372b642d@github.com>
Message-ID: <bl4D8z9_N_CXUiRRt6SBMmS4tPRIo3pG48hmESrwLUA=.81582eb1-0e4b-48fb-94f6-571014855d6f@github.com>

On Thu, 4 Sep 2025 12:54:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I propose `OpWriter` enables simple ANSI coloring based on `jdk.incubator.code.extern.OpWriter.COLOR` system property.
>> 
>> ANSI coloring sample:
>> <img width="989" height="746" alt="ansi-coloring" src="https://github.com/user-attachments/assets/2025bcbe-6c6c-48ab-8ed5-67ff88b47fe6" />
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added OpWriter.ColoringOption.ANSI_HI

Based on the offline discussion I would like to split this effort.
This PR should provide just basic ANSI coloring triggered by a System property.
A more advanced tool exporting code model into various colored formats may be a subject of another PR and probably not directly into the code reflection module.

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

PR Comment: https://git.openjdk.org/babylon/pull/546#issuecomment-3267317419

From psandoz at openjdk.org  Mon Sep  8 18:36:35 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 8 Sep 2025 18:36:35 GMT
Subject: [code-reflection] RFR: OpWriter.ColoringOption proposal [v3]
In-Reply-To: <m3nZl3PGzxZwfQRck_h3zVgJ6nCDzEI-ehWHCw2mPNY=.2fdd4b99-44a6-414d-9c03-8a8181dbd6e5@github.com>
References: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
 <m3nZl3PGzxZwfQRck_h3zVgJ6nCDzEI-ehWHCw2mPNY=.2fdd4b99-44a6-414d-9c03-8a8181dbd6e5@github.com>
Message-ID: <iqD_Mo7zpMRjfMHL2nVaI2RLbzs1sSRLxQy9ILHi4e8=.e662a3c6-a47f-4cb4-9202-9e001594ec1a@github.com>

On Mon, 8 Sep 2025 17:57:03 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I propose `OpWriter` enables simple ANSI coloring based on `jdk.incubator.code.extern.OpWriter.COLOR` system property.
>> 
>> ANSI coloring sample:
>> <img width="989" height="746" alt="ansi-coloring" src="https://github.com/user-attachments/assets/2025bcbe-6c6c-48ab-8ed5-67ff88b47fe6" />
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed ColoringOption
>   ANSI coloring is triggered by jdk.incubator.code.extern.OpWriter.COLOR property

Internal property is good, avoiding any API changes.

src/jdk.incubator.code/share/classes/jdk/incubator/code/extern/OpWriter.java line 342:

> 340: 
> 341:     static BiFunction<Class<? extends CodeItem>, String, String> getDyer() {
> 342:         return Boolean.getBoolean("jdk.incubator.code.extern.OpWriter.COLOR") ? (itemType, text) -> "\033[3" +

Pull this out as a static final boolean.

src/jdk.incubator.code/share/classes/jdk/incubator/code/extern/OpWriter.java line 346:

> 344:                 itemType == Block.class ? '5': // purple
> 345:                 itemType == TypeElement.class ? '2': '1') // green : red
> 346:                 + "m" + text + "\033[0m" : (_, text) -> text;

Can you format to make the returning of the two functions clearer otherwise it is really hard to see where the first ends and the second starts e.g.:

  return COLOR
      ? (itemType, text) -> ...
      : (_, text) -> text;

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

PR Review: https://git.openjdk.org/babylon/pull/546#pullrequestreview-3197673168
PR Review Comment: https://git.openjdk.org/babylon/pull/546#discussion_r2331050519
PR Review Comment: https://git.openjdk.org/babylon/pull/546#discussion_r2331056218

From mabbay at openjdk.org  Mon Sep  8 21:52:44 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 8 Sep 2025 21:52:44 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v5]
In-Reply-To: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
Message-ID: <fMMsBXp-Oxu4qMjzT6ObmrqnfLQ8x6DePHomg7sUVm4=.5d315b38-e231-4e26-84ed-e574596e9b74@github.com>

> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Rectify the way we get the flags of a lambda invokedynamic

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/545/files
  - new: https://git.openjdk.org/babylon/pull/545/files/3259b02a..5f5dfe00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=04
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/babylon/pull/545.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/545/head:pull/545

PR: https://git.openjdk.org/babylon/pull/545

From mourad.abbay at oracle.com  Mon Sep  8 22:00:52 2025
From: mourad.abbay at oracle.com (Mourad Abbay)
Date: Mon, 8 Sep 2025 22:00:52 +0000
Subject: CFV: New Babylon Reviewer: Juan Fumero 
In-Reply-To: <BF631D4C-F46A-4A5B-8162-1FCA37429321@oracle.com>
References: <BF631D4C-F46A-4A5B-8162-1FCA37429321@oracle.com>
Message-ID: <CH0PR10MB538572774F7861E849590DDDF40CA@CH0PR10MB5385.namprd10.prod.outlook.com>

Vote: yes

Mourad.
________________________________
From: babylon-dev <babylon-dev-retn at openjdk.org> on behalf of Paul Sandoz <paul.sandoz at oracle.com>
Sent: Monday, August 25, 2025 10:36 PM
To: babylon-dev at openjdk.org <babylon-dev at openjdk.org>
Subject: CFV: New Babylon Reviewer: Juan Fumero

I hereby nominate Juan Fumero [1] to Babylon Reviewer [0].

Juan is a member of the Java Team at Oracle, has extensive experience in Java and GPUs, and is already contributing fixes and features to HAT, and examples of code reflection.

Votes are due by September 9th, 2025.

Only current Babylon Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3].

Paul.

[0] Project Babylon does not currently make any distinction between Committer and Reviewer, and PRs are not required to be reviewed by Reviewers before integration.
[1] https://openjdk.org/census#jfumero
[2] https://openjdk.java.net/census
[3] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20250908/58d2d04c/attachment-0001.htm>

From psandoz at openjdk.org  Mon Sep  8 22:38:19 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 8 Sep 2025 22:38:19 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v5]
In-Reply-To: <fMMsBXp-Oxu4qMjzT6ObmrqnfLQ8x6DePHomg7sUVm4=.5d315b38-e231-4e26-84ed-e574596e9b74@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <fMMsBXp-Oxu4qMjzT6ObmrqnfLQ8x6DePHomg7sUVm4=.5d315b38-e231-4e26-84ed-e574596e9b74@github.com>
Message-ID: <8PWVN4ng9idyVAhr4eL1MGB0GMUzOSabgQWSJX0WRa8=.188b26fc-0177-4a0e-a360-dbb751962c0b@github.com>

On Mon, 8 Sep 2025 21:52:44 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rectify the way we get the flags of a lambda invokedynamic

src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/BytecodeLift.java line 478:

> 476:                                                                        lambdaFunc,
> 477:                                                                        JavaType.type(inst.typeSymbol().returnType()));
> 478:                         // if FLAG_QUOTABLE is set, the lambda is quotable

I think it would be clearer if you check that the bootstrap method name is `altMetafactory` then it should be guaranteed there will be at least four arguments (otherwise the bytecode is not valid) e.g.,

if (bsm.methodName().equals("altMetafactory") {
    assert inst.bootstrapArgs().size() > 3;
    assert inst.bootstrapArgs().get(3) instanceof Integer;

    if (inst.bootstrapArgs().get(3) instanceof int flags
            && (flags & LambdaMetafactory.FLAG_QUOTABLE) != 0) {
        lambda = lambda.quotable();
    }
}

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

PR Review Comment: https://git.openjdk.org/babylon/pull/545#discussion_r2331480577

From mabbay at openjdk.org  Tue Sep  9 01:47:10 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 9 Sep 2025 01:47:10 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v6]
In-Reply-To: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
Message-ID: <rrLxoLqSKT4_Q-WjsOmP1JLHZHTglYOJQpCFhWgcmHA=.c7654ee7-2709-42b3-9224-f5114beb9910@github.com>

> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestion

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/545/files
  - new: https://git.openjdk.org/babylon/pull/545/files/5f5dfe00..1fa78060

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=05
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=04-05

  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/babylon/pull/545.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/545/head:pull/545

PR: https://git.openjdk.org/babylon/pull/545

From gfrost at openjdk.org  Tue Sep  9 08:42:59 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 9 Sep 2025 08:42:59 GMT
Subject: [code-reflection] RFR: OpWriter.ColoringOption proposal [v3]
In-Reply-To: <m3nZl3PGzxZwfQRck_h3zVgJ6nCDzEI-ehWHCw2mPNY=.2fdd4b99-44a6-414d-9c03-8a8181dbd6e5@github.com>
References: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
 <m3nZl3PGzxZwfQRck_h3zVgJ6nCDzEI-ehWHCw2mPNY=.2fdd4b99-44a6-414d-9c03-8a8181dbd6e5@github.com>
Message-ID: <NVAEpkahNxuvSBuyxf2BJH5Ks9Z9iqP8eDGpfPN2X-E=.b6fcfec3-dc31-41d3-b525-7487c36a9129@github.com>

On Mon, 8 Sep 2025 17:57:03 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I propose `OpWriter` enables simple ANSI coloring based on `jdk.incubator.code.extern.OpWriter.COLOR` system property.
>> 
>> ANSI coloring sample:
>> <img width="989" height="746" alt="ansi-coloring" src="https://github.com/user-attachments/assets/2025bcbe-6c6c-48ab-8ed5-67ff88b47fe6" />
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed ColoringOption
>   ANSI coloring is triggered by jdk.incubator.code.extern.OpWriter.COLOR property

As I mentioned in slack.  My problem here that that , if we have code which generates text from OpWriter buried in a lib call that you are unaware of, and you add this property on the command line (because you want to colorize some output from your call)  everyone now needs to defecnd their code against these CSI/ANSI sequences.

Specifically HAT was forced to reparse the output from OpWriter to apply its formmatting/tooling, this code is definately not expecting to see CSI/ANSI escape sequences in the output from OpWriter. 

I am in general favor of a solution, but the caller of OpWriter needs direct control of formatting, it should not be based on a global property IMHO.

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

PR Comment: https://git.openjdk.org/babylon/pull/546#issuecomment-3269551309

From asotona at openjdk.org  Tue Sep  9 08:54:15 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Sep 2025 08:54:15 GMT
Subject: [code-reflection] RFR: OpWriter.ColoringOption proposal [v3]
In-Reply-To: <m3nZl3PGzxZwfQRck_h3zVgJ6nCDzEI-ehWHCw2mPNY=.2fdd4b99-44a6-414d-9c03-8a8181dbd6e5@github.com>
References: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
 <m3nZl3PGzxZwfQRck_h3zVgJ6nCDzEI-ehWHCw2mPNY=.2fdd4b99-44a6-414d-9c03-8a8181dbd6e5@github.com>
Message-ID: <UYuvpu1_ZTL5dB_Uj3TH9pl0c7XtaJO_CnHmv4_YQk4=.d0778c4c-90ae-48ef-afdf-f448ef6205d3@github.com>

On Mon, 8 Sep 2025 17:57:03 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I propose `OpWriter` enables simple ANSI coloring based on `jdk.incubator.code.extern.OpWriter.COLOR` system property.
>> 
>> ANSI coloring sample:
>> <img width="989" height="746" alt="ansi-coloring" src="https://github.com/user-attachments/assets/2025bcbe-6c6c-48ab-8ed5-67ff88b47fe6" />
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed ColoringOption
>   ANSI coloring is triggered by jdk.incubator.code.extern.OpWriter.COLOR property

I see the problem. `OpWriter` declares:
 "A code model in textual form may be parsed back into the runtime form by parsing it."

Technically it should be easy for `OpParser` to ignore the coloring. 
The question here is if a 3rd-party parsers should be able to parse it (effectively making the textual form an API)?

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

PR Comment: https://git.openjdk.org/babylon/pull/546#issuecomment-3269593177

From jfumero at openjdk.org  Tue Sep  9 09:17:26 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Tue, 9 Sep 2025 09:17:26 GMT
Subject: [code-reflection] RFR: [hat] MxM example using Loop Tiling as default
Message-ID: <49LcOA13t5sjhB9HNeXAZH-7ERuvbIGL5LwU2R7edxU=.39f147fc-cbb3-456d-9930-1e0defa4c3c0@github.com>

MxM example using Loop Tiling as default. This one uses local memory, barrier and loop tiling. 

How to run? 


java @hat/run ffi-opencl matmul

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

Commit messages:
 - [hat] MxM example using Loop Tiling as default

Changes: https://git.openjdk.org/babylon/pull/556/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=556&range=00
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/babylon/pull/556.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/556/head:pull/556

PR: https://git.openjdk.org/babylon/pull/556

From duke at openjdk.org  Tue Sep  9 09:17:27 2025
From: duke at openjdk.org (duke)
Date: Tue, 9 Sep 2025 09:17:27 GMT
Subject: [code-reflection] RFR: [hat] MxM example using Loop Tiling as
 default
In-Reply-To: <49LcOA13t5sjhB9HNeXAZH-7ERuvbIGL5LwU2R7edxU=.39f147fc-cbb3-456d-9930-1e0defa4c3c0@github.com>
References: <49LcOA13t5sjhB9HNeXAZH-7ERuvbIGL5LwU2R7edxU=.39f147fc-cbb3-456d-9930-1e0defa4c3c0@github.com>
Message-ID: <6gcna73svSYE2z8dRai1xMm161QnxdHcs31fzcXyxgU=.c348d4c6-8b4d-48cd-a2f5-14474e485157@github.com>

On Tue, 9 Sep 2025 09:07:07 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> MxM example using Loop Tiling as default. This one uses local memory, barrier and loop tiling. 
> 
> How to run? 
> 
> 
> java @hat/run ffi-opencl matmul

@jjfumero 
Your change (at version 9cedcfd48fd44610132cde3e856c062aea206d2f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/babylon/pull/556#issuecomment-3269674269

From jfumero at openjdk.org  Tue Sep  9 09:18:02 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Tue, 9 Sep 2025 09:18:02 GMT
Subject: [code-reflection] RFR: New Examples: Dialects and Dynamic Function
 Builds [v2]
In-Reply-To: <YGUi7VJufSXxszWhWO67E-6DuXNFIc7Me1TS3YmOmYY=.65febfbe-e7dc-4683-998e-10d76d2cd8d3@github.com>
References: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
 <YGUi7VJufSXxszWhWO67E-6DuXNFIc7Me1TS3YmOmYY=.65febfbe-e7dc-4683-998e-10d76d2cd8d3@github.com>
Message-ID: <AlRjc5SbHilcByAwC7RhBrsRvj4-5i6ilcwKluN37YA=.4bfc28a6-4908-434f-9de1-959f24556a80@github.com>

On Fri, 5 Sep 2025 13:57:07 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

>> - `DialectSample`: Example of how to extends the code reflection `Op` to create a new dialect. 
>> - `DynamicFunctionBuild`: Example of how to create a new function dynamically to compute the inverse of a square root.  The code model is built dynamically for a new method and it is evaluated in the `Interpreter`.
>> 
>> How to run?
>> 
>> 
>> mvn clean package
>> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectSample
>> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DynamicFunctionBuild
>
> Juan Fumero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor clean up

Thanks Paul for the feedback. I will make some modifications to adapt to these changes.

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

PR Comment: https://git.openjdk.org/babylon/pull/549#issuecomment-3269684846

From jfumero at openjdk.org  Tue Sep  9 09:36:39 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Tue, 9 Sep 2025 09:36:39 GMT
Subject: [code-reflection] RFR: New Examples: Dialects and Dynamic Function
 Builds [v3]
In-Reply-To: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
References: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
Message-ID: <b2SS6UmzeYC17ONnr9yNIoqMZgCS4eLjB3MNUVc9BvE=.dee29be0-c909-434f-ad6d-00f08b0f7bf9@github.com>

> - `DialectSample`: Example of how to extends the code reflection `Op` to create a new dialect. 
> - `DynamicFunctionBuild`: Example of how to create a new function dynamically to compute the inverse of a square root.  The code model is built dynamically for a new method and it is evaluated in the `Interpreter`.
> 
> How to run?
> 
> 
> mvn clean package
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectSample
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DynamicFunctionBuild

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 eight additional commits since the last revision:

 - Dialect example to replace a specific function as an intrinsic
 - Merge branch 'code-reflection' into cr/examples/suite
 - minor clean up
 - minor comment
 - trip extra spaces
 - New example: building new functions dynamically with code reflection
 - [example] Fix printing for dialects
 - Code Reflection sample for creating new Ops for a dialect

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/549/files
  - new: https://git.openjdk.org/babylon/pull/549/files/dbde9d0b..bafb4a11

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=02
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=01-02

  Stats: 2408 lines in 35 files changed: 955 ins; 1084 del; 369 mod
  Patch: https://git.openjdk.org/babylon/pull/549.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/549/head:pull/549

PR: https://git.openjdk.org/babylon/pull/549

From gfrost at openjdk.org  Tue Sep  9 10:30:10 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 9 Sep 2025 10:30:10 GMT
Subject: git: openjdk/babylon: code-reflection: Fixes for cuda codegen issues
Message-ID: <f385ce7c-57c7-4400-941e-0add959d3b46@openjdk.org>

Changeset: 32003dd5
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-09 10:29:14 +0000
URL:       https://git.openjdk.org/babylon/commit/32003dd5709d340b8890247b1e44ced0a13b33a9

Fixes for cuda codegen issues

! 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/core/src/main/java/hat/BufferTagger.java
! hat/core/src/main/java/hat/codebuilders/C99HATKernelBuilder.java


From gfrost at openjdk.org  Tue Sep  9 10:31:55 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 9 Sep 2025 10:31:55 GMT
Subject: [code-reflection] Integrated: Fixes for cuda codegen issues
Message-ID: <IGNM6wvi7G1apd-HFyG_SUoou6FnJTh3T4Kd2W56qec=.b890e4e8-54b9-4160-b9e0-5e4de0e608bf@github.com>

Juan and I found some CUDA code gen issues. 

This PR addresses them.  

Also added Copyright to  BufferTagger.

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

Commit messages:
 - Fixes for cuda codegen issues

Changes: https://git.openjdk.org/babylon/pull/557/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=557&range=00
  Stats: 31 lines in 4 files changed: 25 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/babylon/pull/557.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/557/head:pull/557

PR: https://git.openjdk.org/babylon/pull/557

From gfrost at openjdk.org  Tue Sep  9 10:31:57 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 9 Sep 2025 10:31:57 GMT
Subject: [code-reflection] Integrated: Fixes for cuda codegen issues
In-Reply-To: <IGNM6wvi7G1apd-HFyG_SUoou6FnJTh3T4Kd2W56qec=.b890e4e8-54b9-4160-b9e0-5e4de0e608bf@github.com>
References: <IGNM6wvi7G1apd-HFyG_SUoou6FnJTh3T4Kd2W56qec=.b890e4e8-54b9-4160-b9e0-5e4de0e608bf@github.com>
Message-ID: <k5X2KVSav23sDOnFt7FwRbZ7-AIB90hMnfG2v4nUAmc=.1dddb7c8-1f19-47d3-a08e-962c72bfd72f@github.com>

On Tue, 9 Sep 2025 10:25:08 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Juan and I found some CUDA code gen issues. 
> 
> This PR addresses them.  
> 
> Also added Copyright to  BufferTagger.

This pull request has now been integrated.

Changeset: 32003dd5
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/32003dd5709d340b8890247b1e44ced0a13b33a9
Stats:     31 lines in 4 files changed: 25 ins; 4 del; 2 mod

Fixes for cuda codegen issues

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

PR: https://git.openjdk.org/babylon/pull/557

From asotona at openjdk.org  Tue Sep  9 11:41:09 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Sep 2025 11:41:09 GMT
Subject: [code-reflection] RFR: OpWriter.ColoringOption proposal [v4]
In-Reply-To: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
References: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
Message-ID: <Kx8dn4KBMO9BdQyvWTl_JJx8eGHKlzMAEIjCWI1MG2o=.17acbadd-fe4a-483d-a491-0536bbb94bd9@github.com>

> I propose `OpWriter` enables simple ANSI coloring based on `jdk.incubator.code.extern.OpWriter.COLOR` system property.
> 
> ANSI coloring sample:
> <img width="989" height="746" alt="ansi-coloring" src="https://github.com/user-attachments/assets/2025bcbe-6c6c-48ab-8ed5-67ff88b47fe6" />

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - OpParser filtering ANSI coloring
   
 - proposed changes applied

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/546/files
  - new: https://git.openjdk.org/babylon/pull/546/files/d4501a1f..30a37060

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=546&range=03
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=546&range=02-03

  Stats: 14 lines in 2 files changed: 9 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/babylon/pull/546.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/546/head:pull/546

PR: https://git.openjdk.org/babylon/pull/546

From psandoz at openjdk.org  Tue Sep  9 14:38:37 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 9 Sep 2025 14:38:37 GMT
Subject: [code-reflection] RFR: OpWriter.ColoringOption proposal [v4]
In-Reply-To: <Kx8dn4KBMO9BdQyvWTl_JJx8eGHKlzMAEIjCWI1MG2o=.17acbadd-fe4a-483d-a491-0536bbb94bd9@github.com>
References: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
 <Kx8dn4KBMO9BdQyvWTl_JJx8eGHKlzMAEIjCWI1MG2o=.17acbadd-fe4a-483d-a491-0536bbb94bd9@github.com>
Message-ID: <MF9EU11ubRQy07PxenF8aRqLc6RNxd-tfGZWtOb6ldM=.eb298300-b3cc-4745-aa61-356a92a7aff1@github.com>

On Tue, 9 Sep 2025 11:41:09 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I propose `OpWriter` enables simple ANSI coloring based on `jdk.incubator.code.extern.OpWriter.COLOR` system property.
>> 
>> ANSI coloring sample:
>> <img width="989" height="746" alt="ansi-coloring" src="https://github.com/user-attachments/assets/2025bcbe-6c6c-48ab-8ed5-67ff88b47fe6" />
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - OpParser filtering ANSI coloring
>    
>  - proposed changes applied

It's really hard to get agreement in this area of writing and reading (the larger elephant in the room is the lack of specification for the grammar, there are higher priority areas to focus on). At this point i think it best we do nothing in the incubator module and instead focus on external tooling, like in hat but perhaps moved out to a separate project.

src/jdk.incubator.code/share/classes/jdk/incubator/code/extern/OpParser.java line 189:

> 187: 
> 188:     static List<Op> parse(OpFactory opFactory, TypeElementFactory typeFactory, String in) {
> 189:         in = in.replaceAll("\\033\\[\\d+m", ""); // remove ANSI coloring

Cute hack, but it makes me uncomfortable.

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

PR Comment: https://git.openjdk.org/babylon/pull/546#issuecomment-3271023091
PR Review Comment: https://git.openjdk.org/babylon/pull/546#discussion_r2333860507

From asotona at openjdk.org  Tue Sep  9 16:14:25 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Sep 2025 16:14:25 GMT
Subject: [code-reflection] Withdrawn: OpWriter.ColoringOption proposal
In-Reply-To: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
References: <urFTMu9_4ZZGsO76YLak5NahZX7I4_QABuVz8z_uT4s=.8bbb9ab0-7252-4380-9f82-aa5ef53706c5@github.com>
Message-ID: <hhj41IrHT0gAzXNEmDd2LAmy90r2JNrY-TNWbElBdsw=.aafe3e4a-a4ae-41c8-9410-aeda94ea8404@github.com>

On Thu, 4 Sep 2025 12:10:23 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> I propose `OpWriter` enables simple ANSI coloring based on `jdk.incubator.code.extern.OpWriter.COLOR` system property.
> 
> ANSI coloring sample:
> <img width="989" height="746" alt="ansi-coloring" src="https://github.com/user-attachments/assets/2025bcbe-6c6c-48ab-8ed5-67ff88b47fe6" />

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/babylon/pull/546

From duke at openjdk.org  Tue Sep  9 17:53:03 2025
From: duke at openjdk.org (Ruby Chen)
Date: Tue, 9 Sep 2025 17:53:03 GMT
Subject: [code-reflection] RFR: Add local array support to BufferTagger
Message-ID: <04FZJtpI0WcJZxdI9kKCCgjpczOU2yrwkpm2jfMETf8=.93cd4d85-c949-49f7-b95f-73de13675570@github.com>

Add support for local arrays that are initialized in a kernel rather than passed as a parameter to the kernel.

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

Commit messages:
 - Add local array support to BufferTagger

Changes: https://git.openjdk.org/babylon/pull/559/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=559&range=00
  Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/babylon/pull/559.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/559/head:pull/559

PR: https://git.openjdk.org/babylon/pull/559

From duke at openjdk.org  Tue Sep  9 18:52:16 2025
From: duke at openjdk.org (Ruby Chen)
Date: Tue, 9 Sep 2025 18:52:16 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests [v2]
In-Reply-To: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
Message-ID: <JRY-QHNsS3NZDfgSxfNRVRzy0P-6exzJRNn9Zz42GLo=.ebabc1e5-a5ed-41dd-92c6-d4f4d48a39eb@github.com>

> Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a phi stored in `same` that is later deleted in a recursive `tryRemoveTrivialPhi()` call is still returned despite being deleted. 
> 
> Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones, which is the bug first presented itself.

Ruby Chen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Replace deleted phi after recursive call
 - Merge branch 'openjdk:code-reflection' into inline
 - Merge branch 'openjdk:code-reflection' into inline
 - Merge branch 'openjdk:code-reflection' into inline
 - Fix SSABraun bug and add SSA tests

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/542/files
  - new: https://git.openjdk.org/babylon/pull/542/files/380d75c6..e3ba9dd6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=542&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=542&range=00-01

  Stats: 4708 lines in 62 files changed: 1827 ins; 2312 del; 569 mod
  Patch: https://git.openjdk.org/babylon/pull/542.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/542/head:pull/542

PR: https://git.openjdk.org/babylon/pull/542

From hgreule at openjdk.org  Tue Sep  9 18:52:17 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 9 Sep 2025 18:52:17 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests
In-Reply-To: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
Message-ID: <k91gOvlDeHD0cfo8cVyH2WbL5YDgPuc72UMudAW2SOA=.572bc14e-5f5d-496a-96b5-3088dc56c95b@github.com>

On Tue, 2 Sep 2025 20:30:58 GMT, Ruby Chen <duke at openjdk.org> wrote:

> Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a phi stored in `same` that is later deleted in a recursive `tryRemoveTrivialPhi()` call is still returned despite being deleted. 
> 
> Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones, which is the bug first presented itself.

Interesting, thanks for the investigation!

A few pointers regarding the mentioned maps:
- `additionalParameters` should only need removal at this point, as we don't need a block parameter for the new definition anymore
- The loads are updated in `replaceBy`, but there might be cases where things go wrong there
- There also is `deletedPhis`, which is supposed to correct lookups to instead look for a definition in the dominating blocks

These are the parts not present in the original algorithm due to (im)mutability, so I always suspected these to be the most fragile parts of the implementation. If you have any ideas to simplify these "workarounds", I'd be very happy :)

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

PR Comment: https://git.openjdk.org/babylon/pull/542#issuecomment-3247821956

From duke at openjdk.org  Tue Sep  9 18:52:17 2025
From: duke at openjdk.org (Ruby Chen)
Date: Tue, 9 Sep 2025 18:52:17 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests
In-Reply-To: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
Message-ID: <mAeT0kH9pk4X9ND8e5QbB-lSblSr5gs1xtQx0iDE3e4=.af6f487f-4513-451f-8461-bfb9b5ed2900@github.com>

On Tue, 2 Sep 2025 20:30:58 GMT, Ruby Chen <duke at openjdk.org> wrote:

> Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a phi stored in `same` that is later deleted in a recursive `tryRemoveTrivialPhi()` call is still returned despite being deleted. 
> 
> Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones, which is the bug first presented itself.

Thanks for the pointers! I'll circle back to this PR with any ideas and/or code changes for the maps :)

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

PR Comment: https://git.openjdk.org/babylon/pull/542#issuecomment-3249940629

From jfumero at openjdk.org  Wed Sep 10 11:04:27 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Wed, 10 Sep 2025 11:04:27 GMT
Subject: [code-reflection] RFR: Initial Testing Framework for HAT
Message-ID: <wdbbhHMLGidwdvp0fPTaCNRKILv7VVhCFC7Z6y7EAjA=.0e23d648-3380-43b8-9fc4-64b20928acd2@github.com>

I added a testing framework for HAT. I will open a draft PR for the team to start playing with this. Any feedback is welcome. 


How to build and run? 

java @hat/bld

Run the whole suite for OpenCL:


java @hat/test suite ffi-opencl 


Run the whole suite for CUDA:


java @hat/test suite ffi-cuda 


Run a specific test:


java @hat/test ffi-opencl oracle.code.hat.TestArrays$testVectorAddition 

You can also combine with the usual Hat flags. For example, this enables printing of the codegen and info


HAT=SHOW_CODE,INFO java @hat/test ffi-opencl oracle.code.hat.TestArrays$testVectorAddition

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

Commit messages:
 - [hat] Test reductions added
 - [hat] Enable test suite
 - [hat] Testing matrices added
 - [hat] Testing framework improved
 - Add missing pom file
 - Add missing licenses
 - [hat] Add utility methods for testing
 - [hat] Testing single methods
 - [hat] scafolding for the testing framework

Changes: https://git.openjdk.org/babylon/pull/558/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=558&range=00
  Stats: 1820 lines in 17 files changed: 1775 ins; 1 del; 44 mod
  Patch: https://git.openjdk.org/babylon/pull/558.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/558/head:pull/558

PR: https://git.openjdk.org/babylon/pull/558

From duke at openjdk.org  Wed Sep 10 11:04:28 2025
From: duke at openjdk.org (duke)
Date: Wed, 10 Sep 2025 11:04:28 GMT
Subject: [code-reflection] RFR: Initial Testing Framework for HAT
In-Reply-To: <wdbbhHMLGidwdvp0fPTaCNRKILv7VVhCFC7Z6y7EAjA=.0e23d648-3380-43b8-9fc4-64b20928acd2@github.com>
References: <wdbbhHMLGidwdvp0fPTaCNRKILv7VVhCFC7Z6y7EAjA=.0e23d648-3380-43b8-9fc4-64b20928acd2@github.com>
Message-ID: <Gvyn_Ot23yKJLLszzAHihy-QlWQ3TfBlyIp4gH72cIk=.67cae146-112c-4873-9265-df2a90b2623b@github.com>

On Tue, 9 Sep 2025 15:44:02 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> I added a testing framework for HAT. I will open a draft PR for the team to start playing with this. Any feedback is welcome. 
> 
> 
> How to build and run? 
> 
> java @hat/bld
> 
> Run the whole suite for OpenCL:
> 
> 
> java @hat/test suite ffi-opencl 
> 
> 
> Run the whole suite for CUDA:
> 
> 
> java @hat/test suite ffi-cuda 
> 
> 
> Run a specific test:
> 
> 
> java @hat/test ffi-opencl oracle.code.hat.TestArrays$testVectorAddition 
> 
> You can also combine with the usual Hat flags. For example, this enables printing of the codegen and info
> 
> 
> HAT=SHOW_CODE,INFO java @hat/test ffi-opencl oracle.code.hat.TestArrays$testVectorAddition

@jjfumero 
Your change (at version 8281c10683614dbe15b2fee2dd57c9e63e7dd939) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/babylon/pull/558#issuecomment-3274437936

From mcimadamore at openjdk.org  Wed Sep 10 11:13:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Sep 2025 11:13:00 GMT
Subject: [code-reflection] RFR: Add sample annotation processor using code
 models
Message-ID: <JjiPTcoj2no8s-7hdaYY6HR2s_Mv0Pjm6i1V3p3IROY=.75a3591c-e636-4e84-b238-d7cc3ed8d09b@github.com>

This change adds a new sample of an annotation processor that uses code models to:
* reject unsupported methods (e.g. `System.gc`, `System.exit`)
* reject unsupported language construct (e.g. `try`, `throw`)

The annotation processor is somewhat configurable, and can be used by developers as an initial sketch upon which to build more custom compile-time checks.

When using the annotation processor to compile this:


class Foo {
   @CodeReflection
   void test1() {
      System.exit(1);
   }

    @CodeReflection
    void test2() {
        System.gc();
    }

    @CodeReflection
    void test3() {

       try {
           test2();
       } finally {
           test3();
       }

    }
}


The following error messages are generated:


Foo.java:5: error: System.exit not supported in reflectable methods
   void test1() {
        ^
Foo.java:10: error: System.gc not supported in reflectable methods
    void test2() {
         ^
Foo.java:15: error: try/catch statement not supported in reflectable methods
    void test3() {
         ^


When putting this together, I noted some issues, reported below:

* javac was failing to execute annotation processors that depended on `jdk.incubator.code` module
* obtaining the model from a method that contains attribution errors crashed the annotation processor
* some packages (e.g. the ones in java.base) are not exported to the dynamic module layer's `jdk.incubator.code`
* it is not possible to report the message at a more accurate location because the `Messager` API does not allow for this

Many thanks to @lahodaj for the invaluable help when fighting with module layers :-)

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

Commit messages:
 - Tweak annotation processor readme guide
 - Tweak documentation
 - Fix test
 - Add test
 - Initial push

Changes: https://git.openjdk.org/babylon/pull/554/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=554&range=00
  Stats: 381 lines in 9 files changed: 370 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/babylon/pull/554.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/554/head:pull/554

PR: https://git.openjdk.org/babylon/pull/554

From mcimadamore at openjdk.org  Wed Sep 10 11:13:04 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Sep 2025 11:13:04 GMT
Subject: [code-reflection] RFR: Add sample annotation processor using code
 models
In-Reply-To: <JjiPTcoj2no8s-7hdaYY6HR2s_Mv0Pjm6i1V3p3IROY=.75a3591c-e636-4e84-b238-d7cc3ed8d09b@github.com>
References: <JjiPTcoj2no8s-7hdaYY6HR2s_Mv0Pjm6i1V3p3IROY=.75a3591c-e636-4e84-b238-d7cc3ed8d09b@github.com>
Message-ID: <SAFTnwBWpQvfgUEw1SWuKAug_LUsy0DnDSj65siZeN0=.489ed44a-6149-43d9-85ed-b19e87e208d3@github.com>

On Mon, 8 Sep 2025 13:49:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This change adds a new sample of an annotation processor that uses code models to:
> * reject unsupported methods (e.g. `System.gc`, `System.exit`)
> * reject unsupported language construct (e.g. `try`, `throw`)
> 
> The annotation processor is somewhat configurable, and can be used by developers as an initial sketch upon which to build more custom compile-time checks.
> 
> When using the annotation processor to compile this:
> 
> 
> class Foo {
>    @CodeReflection
>    void test1() {
>       System.exit(1);
>    }
> 
>     @CodeReflection
>     void test2() {
>         System.gc();
>     }
> 
>     @CodeReflection
>     void test3() {
> 
>        try {
>            test2();
>        } finally {
>            test3();
>        }
> 
>     }
> }
> 
> 
> The following error messages are generated:
> 
> 
> Foo.java:5: error: System.exit not supported in reflectable methods
>    void test1() {
>         ^
> Foo.java:10: error: System.gc not supported in reflectable methods
>     void test2() {
>          ^
> Foo.java:15: error: try/catch statement not supported in reflectable methods
>     void test3() {
>          ^
> 
> 
> When putting this together, I noted some issues, reported below:
> 
> * javac was failing to execute annotation processors that depended on `jdk.incubator.code` module
> * obtaining the model from a method that contains attribution errors crashed the annotation processor
> * some packages (e.g. the ones in java.base) are not exported to the dynamic module layer's `jdk.incubator.code`
> * it is not possible to report the message at a more accurate location because the `Messager` API does not allow for this
> 
> Many thanks to @lahodaj for the invaluable help when fighting with module layers :-)

cr-examples/samples/src/main/java/oracle/code/samples/CodeReflectionProcessor.java line 31:

> 29: @SupportedAnnotationTypes("jdk.incubator.code.CodeReflection")
> 30: @SupportedSourceVersion(SourceVersion.RELEASE_26)
> 31: public class CodeReflectionProcessor extends AbstractProcessor {

Once we agree this example is sufficient, I can add some documentation to describe what it does, and how to use it

src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java line 196:

> 194: 
> 195:     protected ClassLoader getClassLoader(URL[] urls) {
> 196:         ClassLoader thisClassLoader = CodeReflectionSupport.CODE_LAYER != null ?

We need to use a "base" classloader which is the same as the one used to build the `jdk.incubator.code` module layer (if it exists), otherwise we won't be able to load types defined there.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 1174:

> 1172:             ModuleLayer layer = bootLayer.defineModulesWithOneLoader(cf, ClassLoader.getSystemClassLoader());
> 1173:             return ServiceLoader.load(layer, service);
> 1174:         } else if (CodeReflectionSupport.CODE_LAYER != null) {

In some cases javac uses the service loader API to load processors and plugins directly -- again, we need to make sure the `jdk.incubator.code` layer is used if present.

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 1766:

> 1764:                 // But we need to do so by calling a method in java.base reflectively
> 1765:                 try {
> 1766:                     Class<?> codeModuleLayerInit = Class.forName("jdk.internal.access.code.CodeModuleLayerInit");

If the babylon module is not in the module graph when running javac, then we need to explicitly export all java.base packages to that module, to make sure it runs correctly (this might be too broad).

src/jdk.incubator.code/share/classes/jdk/incubator/code/Op.java line 597:

> 595:                         try {
> 596:                             return reflectMethods.getMethodBody(enclosingClass, methodTree, attribBlock, make);
> 597:                         } catch (Throwable ex) {

This avoids crashing if `reflectMethods` throws (which can happen if the source code we come from contains type checking errors -- such as calling methods with wrong arity)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/554#discussion_r2330348286
PR Review Comment: https://git.openjdk.org/babylon/pull/554#discussion_r2330332719
PR Review Comment: https://git.openjdk.org/babylon/pull/554#discussion_r2330335256
PR Review Comment: https://git.openjdk.org/babylon/pull/554#discussion_r2330804373
PR Review Comment: https://git.openjdk.org/babylon/pull/554#discussion_r2330338305

From jlahoda at openjdk.org  Wed Sep 10 11:13:05 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Sep 2025 11:13:05 GMT
Subject: [code-reflection] RFR: Add sample annotation processor using code
 models
In-Reply-To: <JjiPTcoj2no8s-7hdaYY6HR2s_Mv0Pjm6i1V3p3IROY=.75a3591c-e636-4e84-b238-d7cc3ed8d09b@github.com>
References: <JjiPTcoj2no8s-7hdaYY6HR2s_Mv0Pjm6i1V3p3IROY=.75a3591c-e636-4e84-b238-d7cc3ed8d09b@github.com>
Message-ID: <HjXVo6EB8Xh7zQGegzwseVHiKIWyMIA0q_-1EK6gTXQ=.72dc2d05-fd21-425a-816a-965e4940047c@github.com>

On Mon, 8 Sep 2025 13:49:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This change adds a new sample of an annotation processor that uses code models to:
> * reject unsupported methods (e.g. `System.gc`, `System.exit`)
> * reject unsupported language construct (e.g. `try`, `throw`)
> 
> The annotation processor is somewhat configurable, and can be used by developers as an initial sketch upon which to build more custom compile-time checks.
> 
> When using the annotation processor to compile this:
> 
> 
> class Foo {
>    @CodeReflection
>    void test1() {
>       System.exit(1);
>    }
> 
>     @CodeReflection
>     void test2() {
>         System.gc();
>     }
> 
>     @CodeReflection
>     void test3() {
> 
>        try {
>            test2();
>        } finally {
>            test3();
>        }
> 
>     }
> }
> 
> 
> The following error messages are generated:
> 
> 
> Foo.java:5: error: System.exit not supported in reflectable methods
>    void test1() {
>         ^
> Foo.java:10: error: System.gc not supported in reflectable methods
>     void test2() {
>          ^
> Foo.java:15: error: try/catch statement not supported in reflectable methods
>     void test3() {
>          ^
> 
> 
> When putting this together, I noted some issues, reported below:
> 
> * javac was failing to execute annotation processors that depended on `jdk.incubator.code` module
> * obtaining the model from a method that contains attribution errors crashed the annotation processor
> * some packages (e.g. the ones in java.base) are not exported to the dynamic module layer's `jdk.incubator.code`
> * it is not possible to report the message at a more accurate location because the `Messager` API does not allow for this
> 
> Many thanks to @lahodaj for the invaluable help when fighting with module layers :-)

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 1171:

> 1169:             ModuleFinder finder = ModuleFinder.of(paths.toArray(new Path[paths.size()]));
> 1170:             ModuleLayer bootLayer = ModuleLayer.boot();
> 1171:             Configuration cf = bootLayer.configuration().resolveAndBind(ModuleFinder.of(), finder, Collections.emptySet());

I would expect something like this:

            ModuleLayer augmentedModuleLayer;
            ClassLoader parentCL;
            if (CodeReflectionSupport.CODE_LAYER != null) {
                augmentedModuleLayer = CodeReflectionSupport.CODE_LAYER;
                parentCL = CodeReflectionSupport.CODE_LAYER.findLoader("jdk.incubator.code");
            } else {
                augmentedModuleLayer = bootLayer;
                parentCL = ClassLoader.getSystemClassLoader();
            }
            Configuration cf = augmentedModuleLayer.configuration().resolveAndBind(ModuleFinder.of(), finder, Collections.emptySet());
            ModuleLayer layer = augmentedModuleLayer.defineModulesWithOneLoader(cf, parentCL);
            return ServiceLoader.load(layer, service);


here rather than the `CODE_LAYER != null` test below.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/554#discussion_r2330387940

From mcimadamore at openjdk.org  Wed Sep 10 11:13:07 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Sep 2025 11:13:07 GMT
Subject: [code-reflection] RFR: Add sample annotation processor using code
 models
In-Reply-To: <SAFTnwBWpQvfgUEw1SWuKAug_LUsy0DnDSj65siZeN0=.489ed44a-6149-43d9-85ed-b19e87e208d3@github.com>
References: <JjiPTcoj2no8s-7hdaYY6HR2s_Mv0Pjm6i1V3p3IROY=.75a3591c-e636-4e84-b238-d7cc3ed8d09b@github.com>
 <SAFTnwBWpQvfgUEw1SWuKAug_LUsy0DnDSj65siZeN0=.489ed44a-6149-43d9-85ed-b19e87e208d3@github.com>
Message-ID: <KxcLNrKW9WEmjS_5i3JpSbivsX9k1U4EzAvMe-SFn38=.21afbe37-f775-4e7a-b039-cd319fcdff97@github.com>

On Mon, 8 Sep 2025 16:47:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This change adds a new sample of an annotation processor that uses code models to:
>> * reject unsupported methods (e.g. `System.gc`, `System.exit`)
>> * reject unsupported language construct (e.g. `try`, `throw`)
>> 
>> The annotation processor is somewhat configurable, and can be used by developers as an initial sketch upon which to build more custom compile-time checks.
>> 
>> When using the annotation processor to compile this:
>> 
>> 
>> class Foo {
>>    @CodeReflection
>>    void test1() {
>>       System.exit(1);
>>    }
>> 
>>     @CodeReflection
>>     void test2() {
>>         System.gc();
>>     }
>> 
>>     @CodeReflection
>>     void test3() {
>> 
>>        try {
>>            test2();
>>        } finally {
>>            test3();
>>        }
>> 
>>     }
>> }
>> 
>> 
>> The following error messages are generated:
>> 
>> 
>> Foo.java:5: error: System.exit not supported in reflectable methods
>>    void test1() {
>>         ^
>> Foo.java:10: error: System.gc not supported in reflectable methods
>>     void test2() {
>>          ^
>> Foo.java:15: error: try/catch statement not supported in reflectable methods
>>     void test3() {
>>          ^
>> 
>> 
>> When putting this together, I noted some issues, reported below:
>> 
>> * javac was failing to execute annotation processors that depended on `jdk.incubator.code` module
>> * obtaining the model from a method that contains attribution errors crashed the annotation processor
>> * some packages (e.g. the ones in java.base) are not exported to the dynamic module layer's `jdk.incubator.code`
>> * it is not possible to report the message at a more accurate location because the `Messager` API does not allow for this
>> 
>> Many thanks to @lahodaj for the invaluable help when fighting with module layers :-)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 1766:
> 
>> 1764:                 // But we need to do so by calling a method in java.base reflectively
>> 1765:                 try {
>> 1766:                     Class<?> codeModuleLayerInit = Class.forName("jdk.internal.access.code.CodeModuleLayerInit");
> 
> If the babylon module is not in the module graph when running javac, then we need to explicitly export all java.base packages to that module, to make sure it runs correctly (this might be too broad).

Note - we have to call through reflection, otherwise javac might fail to compile against a bootstrap JDK

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

PR Review Comment: https://git.openjdk.org/babylon/pull/554#discussion_r2330805953

From mcimadamore at openjdk.org  Wed Sep 10 11:28:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Sep 2025 11:28:53 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v6]
In-Reply-To: <rrLxoLqSKT4_Q-WjsOmP1JLHZHTglYOJQpCFhWgcmHA=.c7654ee7-2709-42b3-9224-f5114beb9910@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <rrLxoLqSKT4_Q-WjsOmP1JLHZHTglYOJQpCFhWgcmHA=.c7654ee7-2709-42b3-9224-f5114beb9910@github.com>
Message-ID: <eTHYanajW03RXvaliuu2wzXFKTLxHkxb-bIMHQ-idFc=.a0a42b8f-23a8-46f4-846c-ad0ae2834e52@github.com>

On Tue, 9 Sep 2025 01:47:10 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestion

The change in this PR looks good. But, I'd like to remind ourselves that we have probably several issues when it comes to dealing with lambda expressions. There are a bunch of reasons where javac wants to use the `altMetafactory` instead of the regular one:

1. when the target of the lambda has one or more "empty markers" -- e.g. `(Runnable & Cloneable) () -> ...`
2. when the target of the lambda is serializable -- e.g. `(Runnable & Serializable) () -> ...
3. when the metafactory needs to also implement one or more "bridge" methods

An example of (3) is as follows:


interface A<X> {
    void m(X x);
}

interface B<X extends Number> {
    void m(X x);
}

interface C extends A<Integer>, B<Integer> { }

C c = (i) -> System.out.println(i);


In the above example javac will ask the `altMetafactory` to generate an additional bridge implementation for the `(Ljava/lang/Object;)V` signature.

While there's things we can do to detect (1) and (2), I think the kind of analysis required for (3) is rather difficult, and compile-dependent:

https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L927

And I'm quite skeptical we can reproduce this at runtime (as the runtime capabilities to detect overriding based on source-level types are rather limited).

So, more generally, I think both `Interpreter` and `BytecodeGenerator` might have some issues in this area.

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

PR Comment: https://git.openjdk.org/babylon/pull/545#issuecomment-3274529189

From mcimadamore at openjdk.org  Wed Sep 10 11:55:32 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Sep 2025 11:55:32 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v6]
In-Reply-To: <eTHYanajW03RXvaliuu2wzXFKTLxHkxb-bIMHQ-idFc=.a0a42b8f-23a8-46f4-846c-ad0ae2834e52@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <rrLxoLqSKT4_Q-WjsOmP1JLHZHTglYOJQpCFhWgcmHA=.c7654ee7-2709-42b3-9224-f5114beb9910@github.com>
 <eTHYanajW03RXvaliuu2wzXFKTLxHkxb-bIMHQ-idFc=.a0a42b8f-23a8-46f4-846c-ad0ae2834e52@github.com>
Message-ID: <QODhtDlUOA3iHnsYCO5_SSTAlkHO1uJxTAvETlQflPs=.5d4eff59-cc8b-4145-b8d8-73b1b89de19a@github.com>

On Wed, 10 Sep 2025 11:26:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> So, more generally, I think both `Interpreter` and `BytecodeGenerator` might have some issues in this area.

I tried something like this:


class Test {
    public interface A<X> {
        void m(X x);
    }

    public interface B<X extends Number> {
        void m(X x);
    }

    public interface C extends A<Integer>, B<Integer> { }

    @CodeReflection
    static C getC() {
        C c = i -> System.out.println(i);
        return c;
    }

    public static void main(String[] args) throws Throwable {
        var method = Test.class.getDeclaredMethod("getC");
        var op = (CoreOp.FuncOp) Op.ofMethod(method).get();
        A<?> a = (A<?>)Interpreter.invoke(MethodHandles.lookup(), op);
        a.m(null);
    }
}


This (surprisingly) seems to work. I believe the reason is that `Interpreter` uses `MethodHandleProxies::asInterfaceInstance` -- whose javadoc says:


* Because of the possibility of {@linkplain java.lang.reflect.Method#isBridge bridge methods}
     * and other corner cases, the interface may also have several abstract methods
     * with the same name but having distinct descriptors (types of returns and parameters).
     * In this case, all the methods are bound in common to the one given target.
     * The type check and effective {@code asType} conversion is applied to each
     * method type descriptor, and all abstract methods are bound to the target in common.
     * Beyond this type check, no further checks are made to determine that the
     * abstract methods are related in any way.


So, this special "fallback overrides" end up saving the day in this case.

However, a similar example using `BytecodeGenerator` fails:


class Test {
    public interface A<X> {
        void m(X x);
    }

    public interface B<X extends Number> {
        void m(X x);
    }

    public interface C extends A<Integer>, B<Integer> { }

    @CodeReflection
    static void run() {
        C c = i -> System.out.println(i);
        A<?> a = (A<?>)c;
        a.m(null);
    }

    public static void main(String[] args) throws Throwable {
        var method = Test.class.getDeclaredMethod("run");
        var op = (CoreOp.FuncOp) Op.ofMethod(method).get();
        var handle = BytecodeGenerator.generate(MethodHandles.lookup(), op);
        handle.invokeExact();
    }
}


The error I see is:


WARNING: Using incubator modules: jdk.incubator.code
Exception in thread "main" java.lang.AbstractMethodError: Receiver class run_0x0000000097069000$$Lambda/0x000000009706dbb0 does not define or inherit an implementation of the resolved method 'abstract void m(java.lang.Object)' of interface Test$A.
	at Test.main(Test.java:33)


Which is kind of expected: the generated instance is missing a bridge (as it's generated via regular metafactory).

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

PR Comment: https://git.openjdk.org/babylon/pull/545#issuecomment-3274613153

From gfrost at openjdk.org  Wed Sep 10 13:25:24 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 10 Sep 2025 13:25:24 GMT
Subject: git: openjdk/babylon: code-reflection: Initial Testing Framework for
 HAT
Message-ID: <66acf0de-ec7f-4ecb-9474-728422e199fd@openjdk.org>

Changeset: 0e0082fd
Branch: code-reflection
Author:    Juan Fumero <jfumero at openjdk.org>
Committer: Gary Frost <gfrost at openjdk.org>
Date:      2025-09-10 13:22:53 +0000
URL:       https://git.openjdk.org/babylon/commit/0e0082fdf6931f354fd28ec5d83ce1a909470e5d

Initial Testing Framework for HAT

! hat/hat/bld.java
+ hat/hat/test
+ hat/hat/test.java
! hat/pom.xml
+ hat/tests/pom.xml
+ hat/tests/src/main/java/oracle/code/hat/TestArrays.java
+ hat/tests/src/main/java/oracle/code/hat/TestLocal.java
+ hat/tests/src/main/java/oracle/code/hat/TestMandel.java
+ hat/tests/src/main/java/oracle/code/hat/TestMatMul.java
+ hat/tests/src/main/java/oracle/code/hat/TestReductions.java
+ hat/tests/src/main/java/oracle/code/hat/annotation/HatTest.java
+ hat/tests/src/main/java/oracle/code/hat/engine/Colours.java
+ hat/tests/src/main/java/oracle/code/hat/engine/HatAssertionError.java
+ hat/tests/src/main/java/oracle/code/hat/engine/HatAsserts.java
+ hat/tests/src/main/java/oracle/code/hat/engine/HatTestEngine.java
+ hat/tests/src/main/java/oracle/code/hat/engine/HatTestFormatter.java
+ hat/tests/src/test/java/oracle/code/hat/AppTest.java


From jfumero at openjdk.org  Wed Sep 10 13:26:12 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Wed, 10 Sep 2025 13:26:12 GMT
Subject: [code-reflection] Integrated: Initial Testing Framework for HAT
In-Reply-To: <wdbbhHMLGidwdvp0fPTaCNRKILv7VVhCFC7Z6y7EAjA=.0e23d648-3380-43b8-9fc4-64b20928acd2@github.com>
References: <wdbbhHMLGidwdvp0fPTaCNRKILv7VVhCFC7Z6y7EAjA=.0e23d648-3380-43b8-9fc4-64b20928acd2@github.com>
Message-ID: <lPXmpyxI4tMngxXEx1xJLrw8t55mgkJa0P-Hmo-oYJg=.bafa87b5-7e2f-4035-9a21-7aad9537e649@github.com>

On Tue, 9 Sep 2025 15:44:02 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> I added a testing framework for HAT. I will open a draft PR for the team to start playing with this. Any feedback is welcome. 
> 
> 
> How to build and run? 
> 
> java @hat/bld
> 
> Run the whole suite for OpenCL:
> 
> 
> java @hat/test suite ffi-opencl 
> 
> 
> Run the whole suite for CUDA:
> 
> 
> java @hat/test suite ffi-cuda 
> 
> 
> Run a specific test:
> 
> 
> java @hat/test ffi-opencl oracle.code.hat.TestArrays$testVectorAddition 
> 
> You can also combine with the usual Hat flags. For example, this enables printing of the codegen and info
> 
> 
> HAT=SHOW_CODE,INFO java @hat/test ffi-opencl oracle.code.hat.TestArrays$testVectorAddition

This pull request has now been integrated.

Changeset: 0e0082fd
Author:    Juan Fumero <jfumero at openjdk.org>
Committer: Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/0e0082fdf6931f354fd28ec5d83ce1a909470e5d
Stats:     1820 lines in 17 files changed: 1775 ins; 1 del; 44 mod

Initial Testing Framework for HAT

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

PR: https://git.openjdk.org/babylon/pull/558

From psandoz at openjdk.org  Wed Sep 10 16:09:57 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 10 Sep 2025 16:09:57 GMT
Subject: [code-reflection] RFR: Add sample annotation processor using code
 models
In-Reply-To: <JjiPTcoj2no8s-7hdaYY6HR2s_Mv0Pjm6i1V3p3IROY=.75a3591c-e636-4e84-b238-d7cc3ed8d09b@github.com>
References: <JjiPTcoj2no8s-7hdaYY6HR2s_Mv0Pjm6i1V3p3IROY=.75a3591c-e636-4e84-b238-d7cc3ed8d09b@github.com>
Message-ID: <orv_G26owQE84y6OoCQpgtXxEg9CXNw2vrtzwSUKWGc=.a341ead5-250a-4665-8215-45b8b0b68567@github.com>

On Mon, 8 Sep 2025 13:49:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This change adds a new sample of an annotation processor that uses code models to:
> * reject unsupported methods (e.g. `System.gc`, `System.exit`)
> * reject unsupported language construct (e.g. `try`, `throw`)
> 
> The annotation processor is somewhat configurable, and can be used by developers as an initial sketch upon which to build more custom compile-time checks.
> 
> When using the annotation processor to compile this:
> 
> 
> class Foo {
>    @CodeReflection
>    void test1() {
>       System.exit(1);
>    }
> 
>     @CodeReflection
>     void test2() {
>         System.gc();
>     }
> 
>     @CodeReflection
>     void test3() {
> 
>        try {
>            test2();
>        } finally {
>            test3();
>        }
> 
>     }
> }
> 
> 
> The following error messages are generated:
> 
> 
> Foo.java:5: error: System.exit not supported in reflectable methods
>    void test1() {
>         ^
> Foo.java:10: error: System.gc not supported in reflectable methods
>     void test2() {
>          ^
> Foo.java:15: error: try/catch statement not supported in reflectable methods
>     void test3() {
>          ^
> 
> 
> When putting this together, I noted some issues, reported below:
> 
> * javac was failing to execute annotation processors that depended on `jdk.incubator.code` module
> * obtaining the model from a method that contains attribution errors crashed the annotation processor
> * some packages (e.g. the ones in java.base) are not exported to the dynamic module layer's `jdk.incubator.code`
> * it is not possible to report the message at a more accurate location because the `Messager` API does not allow for this
> 
> Many thanks to @lahodaj for the invaluable help when fighting with module layers :-)

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/554#pullrequestreview-3206854837

From duke at openjdk.org  Wed Sep 10 17:06:15 2025
From: duke at openjdk.org (Ruby Chen)
Date: Wed, 10 Sep 2025 17:06:15 GMT
Subject: [code-reflection] RFR: Add local array support to BufferTagger
 [v2]
In-Reply-To: <04FZJtpI0WcJZxdI9kKCCgjpczOU2yrwkpm2jfMETf8=.93cd4d85-c949-49f7-b95f-73de13675570@github.com>
References: <04FZJtpI0WcJZxdI9kKCCgjpczOU2yrwkpm2jfMETf8=.93cd4d85-c949-49f7-b95f-73de13675570@github.com>
Message-ID: <Id3yGOJwO6tr16HtRnrEwRn1RLW82uphySeVATnXfgo=.d29ad6f2-8506-464f-8233-58c21c669d61@github.com>

> Add support for local arrays that are initialized in a kernel rather than passed as a parameter to the kernel.
> 
> Also add opt-in for buffer tagging: add `-DbufferTagging=true` to enable.

Ruby Chen has updated the pull request incrementally with one additional commit since the last revision:

  Add opt-in bufferTagging flag and minor refactoring

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/559/files
  - new: https://git.openjdk.org/babylon/pull/559/files/5bb4334a..eb1d1628

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=559&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=559&range=00-01

  Stats: 27 lines in 6 files changed: 16 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/babylon/pull/559.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/559/head:pull/559

PR: https://git.openjdk.org/babylon/pull/559

From duke at openjdk.org  Wed Sep 10 17:12:53 2025
From: duke at openjdk.org (duke)
Date: Wed, 10 Sep 2025 17:12:53 GMT
Subject: [code-reflection] RFR: Add local array support to BufferTagger
 [v2]
In-Reply-To: <Id3yGOJwO6tr16HtRnrEwRn1RLW82uphySeVATnXfgo=.d29ad6f2-8506-464f-8233-58c21c669d61@github.com>
References: <04FZJtpI0WcJZxdI9kKCCgjpczOU2yrwkpm2jfMETf8=.93cd4d85-c949-49f7-b95f-73de13675570@github.com>
 <Id3yGOJwO6tr16HtRnrEwRn1RLW82uphySeVATnXfgo=.d29ad6f2-8506-464f-8233-58c21c669d61@github.com>
Message-ID: <4XZk7Yqkbv-tRICOK_e_HrAY0vLYJTCwUCVVc7M2zOY=.ffaa45e7-3710-438a-b635-60a7a899974b@github.com>

On Wed, 10 Sep 2025 17:06:15 GMT, Ruby Chen <duke at openjdk.org> wrote:

>> Add support for local arrays that are initialized in a kernel rather than passed as a parameter to the kernel.
>> 
>> Also add opt-in for buffer tagging: add `-DbufferTagging=true` to enable.
>
> Ruby Chen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add opt-in bufferTagging flag and minor refactoring

@rbrchen 
Your change (at version eb1d1628b0941a5a5812e2c4191591a81bf8f7b8) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/babylon/pull/559#issuecomment-3275792888

From psandoz at openjdk.org  Wed Sep 10 17:25:00 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 10 Sep 2025 17:25:00 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v6]
In-Reply-To: <rrLxoLqSKT4_Q-WjsOmP1JLHZHTglYOJQpCFhWgcmHA=.c7654ee7-2709-42b3-9224-f5114beb9910@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <rrLxoLqSKT4_Q-WjsOmP1JLHZHTglYOJQpCFhWgcmHA=.c7654ee7-2709-42b3-9224-f5114beb9910@github.com>
Message-ID: <D6PGfPecSXcrQR-46hreq63Jor5B4kB53u-iz8RdO9s=.75c3aa8d-97ea-4005-be87-86fe763b92a9@github.com>

On Tue, 9 Sep 2025 01:47:10 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestion

In a follow on PR we could adjust the lifter to throw a friendlier error for flags related to serialization and bridges.

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

Marked as reviewed by psandoz (Lead).

PR Review: https://git.openjdk.org/babylon/pull/545#pullrequestreview-3207120805

From psandoz at openjdk.org  Wed Sep 10 17:25:02 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 10 Sep 2025 17:25:02 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v6]
In-Reply-To: <QODhtDlUOA3iHnsYCO5_SSTAlkHO1uJxTAvETlQflPs=.5d4eff59-cc8b-4145-b8d8-73b1b89de19a@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <rrLxoLqSKT4_Q-WjsOmP1JLHZHTglYOJQpCFhWgcmHA=.c7654ee7-2709-42b3-9224-f5114beb9910@github.com>
 <eTHYanajW03RXvaliuu2wzXFKTLxHkxb-bIMHQ-idFc=.a0a42b8f-23a8-46f4-846c-ad0ae2834e52@github.com>
 <QODhtDlUOA3iHnsYCO5_SSTAlkHO1uJxTAvETlQflPs=.5d4eff59-cc8b-4145-b8d8-73b1b89de19a@github.com>
Message-ID: <rjzg6NQomh3H0g286F6OMZT-qf97ky5aph5VsoKQHlY=.6982b68f-4518-4d6e-9fc2-ced803e41109@github.com>

On Wed, 10 Sep 2025 11:52:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The change in this PR looks good. But, I'd like to remind ourselves that we have probably several issues when it comes to dealing with lambda expressions. There are a bunch of reasons where javac wants to use the `altMetafactory` instead of the regular one:
>> 
>> 1. when the target of the lambda has one or more "empty markers" -- e.g. `(Runnable & Cloneable) () -> ...`
>> 2. when the target of the lambda is serializable -- e.g. `(Runnable & Serializable) () -> ...
>> 3. when the metafactory needs to also implement one or more "bridge" methods
>> 
>> An example of (3) is as follows:
>> 
>> 
>> interface A<X> {
>>     void m(X x);
>> }
>> 
>> interface B<X extends Number> {
>>     void m(X x);
>> }
>> 
>> interface C extends A<Integer>, B<Integer> { }
>> 
>> C c = (i) -> System.out.println(i);
>> 
>> 
>> In the above example javac will ask the `altMetafactory` to generate an additional bridge implementation for the `(Ljava/lang/Object;)V` signature.
>> 
>> While there's things we can do to detect (1) and (2), I think the kind of analysis required for (3) is rather difficult, and compile-dependent:
>> 
>> https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L927
>> 
>> And I'm quite skeptical we can reproduce this at runtime (as the runtime capabilities to detect overriding based on source-level types are rather limited).
>> 
>> So, more generally, I think both `Interpreter` and `BytecodeGenerator` might have some issues in this area.
>
>> So, more generally, I think both `Interpreter` and `BytecodeGenerator` might have some issues in this area.
> 
> I tried something like this:
> 
> 
> class Test {
>     public interface A<X> {
>         void m(X x);
>     }
> 
>     public interface B<X extends Number> {
>         void m(X x);
>     }
> 
>     public interface C extends A<Integer>, B<Integer> { }
> 
>     @CodeReflection
>     static C getC() {
>         C c = i -> System.out.println(i);
>         return c;
>     }
> 
>     public static void main(String[] args) throws Throwable {
>         var method = Test.class.getDeclaredMethod("getC");
>         var op = (CoreOp.FuncOp) Op.ofMethod(method).get();
>         A<?> a = (A<?>)Interpreter.invoke(MethodHandles.lookup(), op);
>         a.m(null);
>     }
> }
> 
> 
> This (surprisingly) seems to work. I believe the reason is that `Interpreter` uses `MethodHandleProxies::asInterfaceInstance` -- whose javadoc says:
> 
> 
> * Because of the possibility of {@linkplain java.lang.reflect.Method#isBridge bridge methods}
>      * and other corner cases, the interface may also have several abstract methods
>      * with the same name but having distinct descriptors (types of returns and parameters).
>      * In this case, all the methods are bound in common to the one given target.
>      * The type check and effective {@code asType} conversion is applied to each
>      * method type descriptor, and all abstract methods are bound to the target in common.
>      * Beyond this type check, no further checks are made to determine that the
>      * abstract methods are related in any way.
> 
> 
> So, this special "fallback overrides" end up saving the day in this case.
> 
> However, a similar example using `BytecodeGenerator` fails:
> 
> 
> class Test {
>     public interface A<X> {
>         void m(X x);
>     }
> 
>     public interface B<X extends Number> {
>         void m(X x);
>     }
> 
>     public interface C extends A<Integer>, B<Integer> { }
> 
>     @CodeReflection
>     static void run() {
>         C c = i -> System.out.println(i);
>         A<?> a = (A<?>)c;
>         a.m(null);
>     }
> 
>     public static void main(String[] args) throws Throwable {
>         var method = Test.class.getDeclaredMethod("run");
>         var op = (CoreOp.FuncOp) Op.ofMethod(method).get();
>         var handle = BytecodeGenerator.generate(MethodHandles.lookup(), op);
>         handle.invokeExact();
>     }
> }
> 
> 
> The error I see is:
> 
> 
> WARNING: Using incubator modules: jdk.incubator.code
> Exception in thread "main" java.lang.AbstractMethodError: Receiver class run_0x0000000097069000$$Lambda/0x00000000970...

@mcimadamore good points. Complete reverse engineering is hard. I also suspected that the bytecode generator does not produce correct bytecode behaviour for these cases, and i don't know if there is sufficient information held by the lambda op instance in these cases to generate the bytecode. Fixing both the generator and lifter together is important.

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

PR Comment: https://git.openjdk.org/babylon/pull/545#issuecomment-3275823722

From gfrost at openjdk.org  Wed Sep 10 17:52:58 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 10 Sep 2025 17:52:58 GMT
Subject: git: openjdk/babylon: code-reflection: Add local array support to
 BufferTagger
Message-ID: <bf99778b-f7d1-4715-bab6-566260380062@openjdk.org>

Changeset: 4e621f39
Branch: code-reflection
Author:    Ruby Chen <ruby.r.chen at gmail.com>
Committer: Gary Frost <gfrost at openjdk.org>
Date:      2025-09-10 17:51:23 +0000
URL:       https://git.openjdk.org/babylon/commit/4e621f395b7fd35038397038ddc2bdf9806c461e

Add local array support to BufferTagger

! hat/core/src/main/java/hat/BufferTagger.java
! hat/core/src/main/java/hat/buffer/ArgArray.java
! hat/core/src/main/java/hat/callgraph/CallGraph.java
! hat/core/src/main/java/hat/callgraph/KernelCallGraph.java
! hat/hat/Script.java
! hat/hat/run.java


From duke at openjdk.org  Wed Sep 10 17:54:14 2025
From: duke at openjdk.org (Ruby Chen)
Date: Wed, 10 Sep 2025 17:54:14 GMT
Subject: [code-reflection] Integrated: Add local array support to BufferTagger
In-Reply-To: <04FZJtpI0WcJZxdI9kKCCgjpczOU2yrwkpm2jfMETf8=.93cd4d85-c949-49f7-b95f-73de13675570@github.com>
References: <04FZJtpI0WcJZxdI9kKCCgjpczOU2yrwkpm2jfMETf8=.93cd4d85-c949-49f7-b95f-73de13675570@github.com>
Message-ID: <_aRrgzE-V96DYIYhXzHNY5bnL9-l74CDTTgmJUcDAGo=.b9d91e1f-9263-44ca-80a2-fb8cd7fe53ad@github.com>

On Tue, 9 Sep 2025 17:42:46 GMT, Ruby Chen <duke at openjdk.org> wrote:

> Add support for local arrays that are initialized in a kernel rather than passed as a parameter to the kernel.
> 
> Also add opt-in for buffer tagging: add `-DbufferTagging=true` to enable.

This pull request has now been integrated.

Changeset: 4e621f39
Author:    Ruby Chen <ruby.r.chen at gmail.com>
Committer: Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/4e621f395b7fd35038397038ddc2bdf9806c461e
Stats:     30 lines in 6 files changed: 16 ins; 3 del; 11 mod

Add local array support to BufferTagger

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

PR: https://git.openjdk.org/babylon/pull/559

From paul.sandoz at oracle.com  Wed Sep 10 18:00:27 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 10 Sep 2025 18:00:27 +0000
Subject: Result: New Babylon Reviewer: Juan Fumero
Message-ID: <9BF59821-8D40-4E3C-BF19-47F8A87D295B@oracle.com>

Voting for Juan Fumero [1] is now closed.

Yes: 5
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination.

Paul.

[1] https://mail.openjdk.org/pipermail/babylon-dev/2025-August/003362.html

From mcimadamore at openjdk.org  Wed Sep 10 18:19:07 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Sep 2025 18:19:07 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v6]
In-Reply-To: <QODhtDlUOA3iHnsYCO5_SSTAlkHO1uJxTAvETlQflPs=.5d4eff59-cc8b-4145-b8d8-73b1b89de19a@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
 <rrLxoLqSKT4_Q-WjsOmP1JLHZHTglYOJQpCFhWgcmHA=.c7654ee7-2709-42b3-9224-f5114beb9910@github.com>
 <eTHYanajW03RXvaliuu2wzXFKTLxHkxb-bIMHQ-idFc=.a0a42b8f-23a8-46f4-846c-ad0ae2834e52@github.com>
 <QODhtDlUOA3iHnsYCO5_SSTAlkHO1uJxTAvETlQflPs=.5d4eff59-cc8b-4145-b8d8-73b1b89de19a@github.com>
Message-ID: <ClzFbYFNoZBVRxXrBs7BbcUawHoWsZumc05j9aoeKNc=.80c0872b-73c8-40a8-b389-585f7792a24c@github.com>

On Wed, 10 Sep 2025 11:52:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The change in this PR looks good. But, I'd like to remind ourselves that we have probably several issues when it comes to dealing with lambda expressions. There are a bunch of reasons where javac wants to use the `altMetafactory` instead of the regular one:
>> 
>> 1. when the target of the lambda has one or more "empty markers" -- e.g. `(Runnable & Cloneable) () -> ...`
>> 2. when the target of the lambda is serializable -- e.g. `(Runnable & Serializable) () -> ...
>> 3. when the metafactory needs to also implement one or more "bridge" methods
>> 
>> An example of (3) is as follows:
>> 
>> 
>> interface A<X> {
>>     void m(X x);
>> }
>> 
>> interface B<X extends Number> {
>>     void m(X x);
>> }
>> 
>> interface C extends A<Integer>, B<Integer> { }
>> 
>> C c = (i) -> System.out.println(i);
>> 
>> 
>> In the above example javac will ask the `altMetafactory` to generate an additional bridge implementation for the `(Ljava/lang/Object;)V` signature.
>> 
>> While there's things we can do to detect (1) and (2), I think the kind of analysis required for (3) is rather difficult, and compile-dependent:
>> 
>> https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L927
>> 
>> And I'm quite skeptical we can reproduce this at runtime (as the runtime capabilities to detect overriding based on source-level types are rather limited).
>> 
>> So, more generally, I think both `Interpreter` and `BytecodeGenerator` might have some issues in this area.
>
>> So, more generally, I think both `Interpreter` and `BytecodeGenerator` might have some issues in this area.
> 
> I tried something like this:
> 
> 
> class Test {
>     public interface A<X> {
>         void m(X x);
>     }
> 
>     public interface B<X extends Number> {
>         void m(X x);
>     }
> 
>     public interface C extends A<Integer>, B<Integer> { }
> 
>     @CodeReflection
>     static C getC() {
>         C c = i -> System.out.println(i);
>         return c;
>     }
> 
>     public static void main(String[] args) throws Throwable {
>         var method = Test.class.getDeclaredMethod("getC");
>         var op = (CoreOp.FuncOp) Op.ofMethod(method).get();
>         A<?> a = (A<?>)Interpreter.invoke(MethodHandles.lookup(), op);
>         a.m(null);
>     }
> }
> 
> 
> This (surprisingly) seems to work. I believe the reason is that `Interpreter` uses `MethodHandleProxies::asInterfaceInstance` -- whose javadoc says:
> 
> 
> * Because of the possibility of {@linkplain java.lang.reflect.Method#isBridge bridge methods}
>      * and other corner cases, the interface may also have several abstract methods
>      * with the same name but having distinct descriptors (types of returns and parameters).
>      * In this case, all the methods are bound in common to the one given target.
>      * The type check and effective {@code asType} conversion is applied to each
>      * method type descriptor, and all abstract methods are bound to the target in common.
>      * Beyond this type check, no further checks are made to determine that the
>      * abstract methods are related in any way.
> 
> 
> So, this special "fallback overrides" end up saving the day in this case.
> 
> However, a similar example using `BytecodeGenerator` fails:
> 
> 
> class Test {
>     public interface A<X> {
>         void m(X x);
>     }
> 
>     public interface B<X extends Number> {
>         void m(X x);
>     }
> 
>     public interface C extends A<Integer>, B<Integer> { }
> 
>     @CodeReflection
>     static void run() {
>         C c = i -> System.out.println(i);
>         A<?> a = (A<?>)c;
>         a.m(null);
>     }
> 
>     public static void main(String[] args) throws Throwable {
>         var method = Test.class.getDeclaredMethod("run");
>         var op = (CoreOp.FuncOp) Op.ofMethod(method).get();
>         var handle = BytecodeGenerator.generate(MethodHandles.lookup(), op);
>         handle.invokeExact();
>     }
> }
> 
> 
> The error I see is:
> 
> 
> WARNING: Using incubator modules: jdk.incubator.code
> Exception in thread "main" java.lang.AbstractMethodError: Receiver class run_0x0000000097069000$$Lambda/0x00000000970...

> @mcimadamore good points. Complete reverse engineering is hard. I also suspected that the bytecode generator does not produce correct bytecode behaviour for these cases, and i don't know if there is sufficient information held by the lambda op instance in these cases to generate the bytecode. Fixing both the generator and lifter together is important.

So... one thing I was positively surprised about was that, even after some extensive poking, `MethodHandleProxies` is indeed more resilient than it seems. It basically overrides any abstract methods it finds in superclasses.

To me, this suggests that we might be able to do something similar in `BytecodeGenerator` and just pass all the abstract signatures to the alternate metafactory so that they will be bridged. One complication is that when generating bytecode we might not have a `.class`, so there might not be a way for us to answer that question. But... if we can resolve the target interface to a `j,l.r.Type` then we can do the same analysis that `MethodHandleProxies` does, and call it a day.

With respect to the other issues I enumerated, my feeling is that what's missing from `LambdaOp` is that it should provide a "list" of all target types it wants to conform to. Not just one. This would allow you quickly to detect whether the lambda is serializable, quotable, or implementing marker interfaces, etc. So effectively you can implement the full spectrum of lambda expressions via code models -- perhaps with some minor incompatibility that nobody will care about.

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

PR Comment: https://git.openjdk.org/babylon/pull/545#issuecomment-3276029590

From hgreule at openjdk.org  Wed Sep 10 19:24:25 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 10 Sep 2025 19:24:25 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests [v2]
In-Reply-To: <JRY-QHNsS3NZDfgSxfNRVRzy0P-6exzJRNn9Zz42GLo=.ebabc1e5-a5ed-41dd-92c6-d4f4d48a39eb@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
 <JRY-QHNsS3NZDfgSxfNRVRzy0P-6exzJRNn9Zz42GLo=.ebabc1e5-a5ed-41dd-92c6-d4f4d48a39eb@github.com>
Message-ID: <21DFkWMwt7iyq8sVcYCQd7MfMJgCGvf29Woud36vAME=.b2891a99-304b-4bcf-8d45-8142a4f44fcc@github.com>

On Tue, 9 Sep 2025 18:52:16 GMT, Ruby Chen <duke at openjdk.org> wrote:

>> Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a phi stored in `same` that is later deleted in a recursive `tryRemoveTrivialPhi()` call is still returned despite being deleted. 
>> 
>> Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones, which is the bug first presented itself.
>
> Ruby Chen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Replace deleted phi after recursive call
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Fix SSABraun bug and add SSA tests

Okay I looked into this a bit closer now with your latest change, and I think it makes sense this way. Interestingly, the original implementation works slightly different than what's described in the paper https://github.com/libfirm/libfirm/blob/114012d1d93427e63ba2f2ab51318e8a1b92f06c/ir/ir/ircons.c#L6.
I wonder if this is an oversight in the algorithm described in the paper.

src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/SSABraun.java line 200:

> 198:         for (Phi user : phiUsers) {
> 199:             Val res = tryRemoveTrivialPhi(user);
> 200:             if (same.equals(user)) {

For consistency, could you also use `==` here?

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

PR Review: https://git.openjdk.org/babylon/pull/542#pullrequestreview-3207523885
PR Review Comment: https://git.openjdk.org/babylon/pull/542#discussion_r2337691489

From duke at openjdk.org  Wed Sep 10 19:36:09 2025
From: duke at openjdk.org (Ruby Chen)
Date: Wed, 10 Sep 2025 19:36:09 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests [v2]
In-Reply-To: <21DFkWMwt7iyq8sVcYCQd7MfMJgCGvf29Woud36vAME=.b2891a99-304b-4bcf-8d45-8142a4f44fcc@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
 <JRY-QHNsS3NZDfgSxfNRVRzy0P-6exzJRNn9Zz42GLo=.ebabc1e5-a5ed-41dd-92c6-d4f4d48a39eb@github.com>
 <21DFkWMwt7iyq8sVcYCQd7MfMJgCGvf29Woud36vAME=.b2891a99-304b-4bcf-8d45-8142a4f44fcc@github.com>
Message-ID: <UvylIXTeDFxHJWKvjUA9f8brCEMCg9HFIJ6yhN3TovI=.a905b7ee-9800-413f-8614-e4cc1140460c@github.com>

On Wed, 10 Sep 2025 19:21:23 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Ruby Chen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Replace deleted phi after recursive call
>>  - Merge branch 'openjdk:code-reflection' into inline
>>  - Merge branch 'openjdk:code-reflection' into inline
>>  - Merge branch 'openjdk:code-reflection' into inline
>>  - Fix SSABraun bug and add SSA tests
>
> src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/SSABraun.java line 200:
> 
>> 198:         for (Phi user : phiUsers) {
>> 199:             Val res = tryRemoveTrivialPhi(user);
>> 200:             if (same.equals(user)) {
> 
> For consistency, could you also use `==` here?

Actually, I'm looking into that right now! I'm not sure if that might cause some issues if there are two var stores that use the same operand - doing some testing atm

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

PR Review Comment: https://git.openjdk.org/babylon/pull/542#discussion_r2337717675

From duke at openjdk.org  Wed Sep 10 19:43:04 2025
From: duke at openjdk.org (Ruby Chen)
Date: Wed, 10 Sep 2025 19:43:04 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests [v2]
In-Reply-To: <JRY-QHNsS3NZDfgSxfNRVRzy0P-6exzJRNn9Zz42GLo=.ebabc1e5-a5ed-41dd-92c6-d4f4d48a39eb@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
 <JRY-QHNsS3NZDfgSxfNRVRzy0P-6exzJRNn9Zz42GLo=.ebabc1e5-a5ed-41dd-92c6-d4f4d48a39eb@github.com>
Message-ID: <fvNGgUlgOvrmhtZcQ0QfUjf8S9W5wQGbkNNykozemuY=.f0999423-cfa2-4cdb-b363-aa250f8944df@github.com>

On Tue, 9 Sep 2025 18:52:16 GMT, Ruby Chen <duke at openjdk.org> wrote:

>> Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a phi stored in `same` that is later deleted in a recursive `tryRemoveTrivialPhi()` call is still returned despite being deleted. 
>> 
>> Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones, which is the bug first presented itself.
>
> Ruby Chen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Replace deleted phi after recursive call
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Fix SSABraun bug and add SSA tests

Thanks for looking it over! Yeah, I think it might've been an oversight in the paper's algorithm. Looking at the actual implementation right now, I see how they arrived at the paper's pseudocode, but it's interesting that the paper went ahead with those slight differences :')

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

PR Comment: https://git.openjdk.org/babylon/pull/542#issuecomment-3276279590

From jfumero at openjdk.org  Thu Sep 11 06:30:33 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Thu, 11 Sep 2025 06:30:33 GMT
Subject: [code-reflection] RFR: [HAT] Testing framework improved with general
 statistics
Message-ID: <NxHIHHND5FmXmvpy7Drt1oEJQTTtN_mON4KDC8jjVOk=.8f248337-3a3e-421e-9e73-fafa3dde5947@github.com>

This patch improves the testing for HAT with a final report with a summary and pass-rates. 

How to run? 


java @hat/test suite ffi-opencl



java @hat/test suite ffi-cuda

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

Commit messages:
 - [hat] Testing - final report only when running the test-suite
 - [hat] Testing - including test-report
 - [hat] Testing - delete old package
 - Merge branch 'code-reflection' into hat/testing/framework
 - [hat] Test reductions added
 - [hat] Enable test suite
 - [hat] Testing matrices added
 - [hat] Testing framework improved
 - Add missing pom file
 - Add missing licenses
 - ... and 3 more: https://git.openjdk.org/babylon/compare/4e621f39...dfeffa38

Changes: https://git.openjdk.org/babylon/pull/561/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=561&range=00
  Stats: 153 lines in 5 files changed: 77 ins; 75 del; 1 mod
  Patch: https://git.openjdk.org/babylon/pull/561.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/561/head:pull/561

PR: https://git.openjdk.org/babylon/pull/561

From gfrost at openjdk.org  Thu Sep 11 09:21:49 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 11 Sep 2025 09:21:49 GMT
Subject: git: openjdk/babylon: code-reflection: More codegen tweaks
Message-ID: <3f8cee82-fd80-4f35-b147-e5afc8f7b7d4@openjdk.org>

Changeset: 6f6b9546
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-11 09:19:40 +0000
URL:       https://git.openjdk.org/babylon/commit/6f6b9546bc1bb2575340369ae30c1b0e24e5c5ee

More codegen tweaks

! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/PTXHATKernelBuilder.java
! hat/backends/ffi/shared/src/main/java/hat/backend/ffi/Config.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/core/src/main/java/hat/codebuilders/TextRenderer.java


From gfrost at openjdk.org  Thu Sep 11 09:23:37 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 11 Sep 2025 09:23:37 GMT
Subject: [code-reflection] Integrated: More codegen tweaks
Message-ID: <1NIYzvJKz3P10gdZLk7_I0bf-togs7uOqWQ52AnWZl4=.0920764a-997f-4a08-94d3-cd8e75138557@github.com>

Cleaned up codegen where we were generating 'raw' append(str) and emiText(str).

We should always call one of the methods in the TextRenderer iface. ... identifier,label,literal etc 

This helps when styling/colorizing

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

Commit messages:
 - More codegen tweaks

Changes: https://git.openjdk.org/babylon/pull/562/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=562&range=00
  Stats: 243 lines in 8 files changed: 90 ins; 34 del; 119 mod
  Patch: https://git.openjdk.org/babylon/pull/562.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/562/head:pull/562

PR: https://git.openjdk.org/babylon/pull/562

From gfrost at openjdk.org  Thu Sep 11 09:23:38 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 11 Sep 2025 09:23:38 GMT
Subject: [code-reflection] Integrated: More codegen tweaks
In-Reply-To: <1NIYzvJKz3P10gdZLk7_I0bf-togs7uOqWQ52AnWZl4=.0920764a-997f-4a08-94d3-cd8e75138557@github.com>
References: <1NIYzvJKz3P10gdZLk7_I0bf-togs7uOqWQ52AnWZl4=.0920764a-997f-4a08-94d3-cd8e75138557@github.com>
Message-ID: <dS7RIglBSKVRg6gjeOQmrw4pfTQnYy6Tar7dz4Gv30A=.66ce81b4-6a31-4f04-88b3-fef1597f8282@github.com>

On Thu, 11 Sep 2025 09:16:41 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Cleaned up codegen where we were generating 'raw' append(str) and emiText(str).
> 
> We should always call one of the methods in the TextRenderer iface. ... identifier,label,literal etc 
> 
> This helps when styling/colorizing

This pull request has now been integrated.

Changeset: 6f6b9546
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/6f6b9546bc1bb2575340369ae30c1b0e24e5c5ee
Stats:     243 lines in 8 files changed: 90 ins; 34 del; 119 mod

More codegen tweaks

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

PR: https://git.openjdk.org/babylon/pull/562

From jfumero at openjdk.org  Thu Sep 11 11:09:53 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Thu, 11 Sep 2025 11:09:53 GMT
Subject: [code-reflection] Withdrawn: [HAT] Testing framework improved with
 general statistics
In-Reply-To: <NxHIHHND5FmXmvpy7Drt1oEJQTTtN_mON4KDC8jjVOk=.8f248337-3a3e-421e-9e73-fafa3dde5947@github.com>
References: <NxHIHHND5FmXmvpy7Drt1oEJQTTtN_mON4KDC8jjVOk=.8f248337-3a3e-421e-9e73-fafa3dde5947@github.com>
Message-ID: <7yDCoJo2P7PwkHDjxHIIYJCKB3A8ABt9yOV0fygeWtI=.4aa841b7-2215-482c-ae09-a6c78a551bd2@github.com>

On Thu, 11 Sep 2025 06:22:54 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> This patch improves the testing for HAT with a final report with a summary and pass-rates. 
> 
> How to run? 
> 
> 
> java @hat/test suite ffi-opencl
> 
> 
> 
> java @hat/test suite ffi-cuda

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/babylon/pull/561

From duke at openjdk.org  Thu Sep 11 11:12:59 2025
From: duke at openjdk.org (duke)
Date: Thu, 11 Sep 2025 11:12:59 GMT
Subject: git: openjdk/babylon: code-reflection: [HAT] Testing framework
 improved with general statistics (#561)
Message-ID: <b233b63b-8630-4026-b950-6958780ff2af@openjdk.org>

Changeset: 8a881040
Branch: code-reflection
Author:    Juan Fumero <jfumero at openjdk.org>
Committer: GitHub <noreply at github.com>
Date:      2025-09-11 13:06:58 +0000
URL:       https://git.openjdk.org/babylon/commit/8a881040948fc0b8198e161d7dfb5a888ad640cb

[HAT] Testing framework improved with general statistics (#561)

* [hat] scafolding for the testing framework

* [hat] Testing single methods

* [hat] Add utility methods for testing

* Add missing licenses

* Add missing pom file

* [hat] Testing framework improved

* [hat] Testing matrices added

* [hat] Enable test suite

* [hat] Test reductions added

* [hat] Testing - delete old package

* [hat] Testing - including test-report

* [hat] Testing - final report only when running the test-suite

! hat/hat/Script.java
! hat/hat/test.java
! hat/tests/src/main/java/oracle/code/hat/TestMatMul.java
! hat/tests/src/main/java/oracle/code/hat/engine/HatTestEngine.java
- hat/tests/src/test/java/oracle/code/hat/AppTest.java


From duke at openjdk.org  Thu Sep 11 11:57:23 2025
From: duke at openjdk.org (duke)
Date: Thu, 11 Sep 2025 11:57:23 GMT
Subject: git: openjdk/babylon: code-reflection: [hat] MxM example using Loop
 Tiling as default (#556)
Message-ID: <eddc220f-0d4f-4863-8c31-07604a9f8295@openjdk.org>

Changeset: 98c0f3d7
Branch: code-reflection
Author:    Juan Fumero <jfumero at openjdk.org>
Committer: GitHub <noreply at github.com>
Date:      2025-09-11 13:55:50 +0000
URL:       https://git.openjdk.org/babylon/commit/98c0f3d7a85d31edd2336cb68d3474f80576a6b4

[hat] MxM example using Loop Tiling as default (#556)


! hat/examples/matmul/src/main/java/matmul/Main.java


From jfumero at openjdk.org  Thu Sep 11 11:59:00 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Thu, 11 Sep 2025 11:59:00 GMT
Subject: [code-reflection] Withdrawn: [hat] MxM example using Loop Tiling as
 default
In-Reply-To: <49LcOA13t5sjhB9HNeXAZH-7ERuvbIGL5LwU2R7edxU=.39f147fc-cbb3-456d-9930-1e0defa4c3c0@github.com>
References: <49LcOA13t5sjhB9HNeXAZH-7ERuvbIGL5LwU2R7edxU=.39f147fc-cbb3-456d-9930-1e0defa4c3c0@github.com>
Message-ID: <c4SXLCZF8orJBkRZ2J__uO_QFUuXIFzck8wlPAtstOQ=.f09645b3-35fa-4f74-91f5-b70d94da1ea6@github.com>

On Tue, 9 Sep 2025 09:07:07 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> MxM example using Loop Tiling as default. This one uses local memory, barrier and loop tiling. 
> 
> How to run? 
> 
> 
> java @hat/run ffi-opencl matmul

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/babylon/pull/556

From jfumero at openjdk.org  Thu Sep 11 12:13:15 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Thu, 11 Sep 2025 12:13:15 GMT
Subject: [code-reflection] RFR: New Examples: Dialects and Dynamic Function
 Builds [v4]
In-Reply-To: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
References: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
Message-ID: <fAnHv-HBi0BWUJswTxwtYkXNAibJpkmPVrUIOiveggM=.b115c692-5471-4c6a-a586-e111b09a1f3f@github.com>

> - `DialectSample`: Example of how to extends the code reflection `Op` to create a new dialect. 
> - `DynamicFunctionBuild`: Example of how to create a new function dynamically to compute the inverse of a square root.  The code model is built dynamically for a new method and it is evaluated in the `Interpreter`.
> 
> How to run?
> 
> ##### Run DialectWithInvoke
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectWithInvoke
> 
> 
> ##### Run DialectFMAOp
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectFMAOp
> 
> 
> ##### Run DynamicFunctionBuild
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DynamicFunctionBuild

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 10 additional commits since the last revision:

 - [examples][suite] Two more examples for creating dialects with code reflection
 - Merge branch 'code-reflection' into cr/examples/suite
 - Dialect example to replace a specific function as an intrinsic
 - Merge branch 'code-reflection' into cr/examples/suite
 - minor clean up
 - minor comment
 - trip extra spaces
 - New example: building new functions dynamically with code reflection
 - [example] Fix printing for dialects
 - Code Reflection sample for creating new Ops for a dialect

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/549/files
  - new: https://git.openjdk.org/babylon/pull/549/files/bafb4a11..2df4a704

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=03
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=02-03

  Stats: 2547 lines in 30 files changed: 2193 ins; 293 del; 61 mod
  Patch: https://git.openjdk.org/babylon/pull/549.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/549/head:pull/549

PR: https://git.openjdk.org/babylon/pull/549

From jfumero at openjdk.org  Thu Sep 11 12:18:05 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Thu, 11 Sep 2025 12:18:05 GMT
Subject: [code-reflection] RFR: New Examples: Dialects and Dynamic Function
 Builds [v5]
In-Reply-To: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
References: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
Message-ID: <fOssdm0alGC6i9zEhGSkoN8VF2CVOGXZvZ43S0irqIA=.ac385d77-83c8-4e3d-9732-7e6d3304d0ff@github.com>

> - `DialectSample`: Example of how to extends the code reflection `Op` to create a new dialect. 
> - `DynamicFunctionBuild`: Example of how to create a new function dynamically to compute the inverse of a square root.  The code model is built dynamically for a new method and it is evaluated in the `Interpreter`.
> 
> How to run?
> 
> ##### Run DialectWithInvoke
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectWithInvoke
> 
> 
> ##### Run DialectFMAOp
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectFMAOp
> 
> 
> ##### Run DynamicFunctionBuild
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DynamicFunctionBuild

Juan Fumero has updated the pull request incrementally with one additional commit since the last revision:

  [example] transform dialectified model to SSA

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/549/files
  - new: https://git.openjdk.org/babylon/pull/549/files/2df4a704..062b540d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=04
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=03-04

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/babylon/pull/549.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/549/head:pull/549

PR: https://git.openjdk.org/babylon/pull/549

From jfumero at openjdk.org  Thu Sep 11 12:24:54 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Thu, 11 Sep 2025 12:24:54 GMT
Subject: [code-reflection] RFR: New Examples: Dialects and Dynamic Function
 Builds [v6]
In-Reply-To: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
References: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
Message-ID: <OdJx8zfMxQKXJ4w_9Y-YBpeCjzcjn3F1r3ByJuClv7k=.6779df43-1b46-47ef-84e8-c79fb88bca98@github.com>

> - `DialectSample`: Example of how to extends the code reflection `Op` to create a new dialect. 
> - `DynamicFunctionBuild`: Example of how to create a new function dynamically to compute the inverse of a square root.  The code model is built dynamically for a new method and it is evaluated in the `Interpreter`.
> 
> How to run?
> 
> ##### Run DialectWithInvoke
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectWithInvoke
> 
> 
> ##### Run DialectFMAOp
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectFMAOp
> 
> 
> ##### Run DynamicFunctionBuild
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DynamicFunctionBuild

Juan Fumero has updated the pull request incrementally with one additional commit since the last revision:

  minor change - README code samples updated

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/549/files
  - new: https://git.openjdk.org/babylon/pull/549/files/062b540d..28296c2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=05
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/babylon/pull/549.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/549/head:pull/549

PR: https://git.openjdk.org/babylon/pull/549

From gfrost at openjdk.org  Thu Sep 11 15:59:40 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 11 Sep 2025 15:59:40 GMT
Subject: git: openjdk/babylon: code-reflection: more codegen cleanup
Message-ID: <b254d3c5-b13c-4ff5-b16b-703408abe523@openjdk.org>

Changeset: aec075a4
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-11 15:57:51 +0000
URL:       https://git.openjdk.org/babylon/commit/aec075a4ad0d38606009d672120d23506bb3b40e

more codegen cleanup

! hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaBackend.java
! hat/core/src/main/java/hat/codebuilders/CodeBuilder.java
= hat/core/src/main/java/hat/codebuilders/CodeRenderer.java
! hat/core/src/main/java/hat/codebuilders/TextBuilder.java
+ hat/tools/src/main/java/hat/tools/text/OpCodeBuilder.java
! hat/tools/src/main/java/hat/tools/text/TestJavaHATCodeBuilder.java


From gfrost at openjdk.org  Thu Sep 11 16:01:15 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 11 Sep 2025 16:01:15 GMT
Subject: [code-reflection] Integrated: more codegen cleanup
Message-ID: <S_JTjsPnBkbszqT20VPjAI8HK6yIaqNvNSzt6c8qfAc=.f0355f93-08db-4b0b-8e56-259afc6febc5@github.com>

Some minor codegen changes.  

Also includes a CUDA codegen fix that I missed last time out.  Which was incorectly passing ndrange as a kernel arg.

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

Commit messages:
 - more codegen cleanup

Changes: https://git.openjdk.org/babylon/pull/563/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=563&range=00
  Stats: 962 lines in 6 files changed: 890 ins; 56 del; 16 mod
  Patch: https://git.openjdk.org/babylon/pull/563.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/563/head:pull/563

PR: https://git.openjdk.org/babylon/pull/563

From gfrost at openjdk.org  Thu Sep 11 16:01:16 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 11 Sep 2025 16:01:16 GMT
Subject: [code-reflection] Integrated: more codegen cleanup
In-Reply-To: <S_JTjsPnBkbszqT20VPjAI8HK6yIaqNvNSzt6c8qfAc=.f0355f93-08db-4b0b-8e56-259afc6febc5@github.com>
References: <S_JTjsPnBkbszqT20VPjAI8HK6yIaqNvNSzt6c8qfAc=.f0355f93-08db-4b0b-8e56-259afc6febc5@github.com>
Message-ID: <V_hiJXGnWrMEBpdvYESqYgfQEhmaiJdz0ewdnjzwd_A=.158674f7-d82c-45e3-a95d-81bcf3a9c22b@github.com>

On Thu, 11 Sep 2025 15:54:55 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Some minor codegen changes.  
> 
> Also includes a CUDA codegen fix that I missed last time out.  Which was incorectly passing ndrange as a kernel arg.

This pull request has now been integrated.

Changeset: aec075a4
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/aec075a4ad0d38606009d672120d23506bb3b40e
Stats:     962 lines in 6 files changed: 890 ins; 56 del; 16 mod

more codegen cleanup

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

PR: https://git.openjdk.org/babylon/pull/563

From gfrost at openjdk.org  Thu Sep 11 17:21:09 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 11 Sep 2025 17:21:09 GMT
Subject: git: openjdk/babylon: code-reflection: added tests to pom and intellij
 builds
Message-ID: <487f13ef-fe4e-445b-8240-c4eac209b53c@openjdk.org>

Changeset: e087fd67
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-11 17:18:10 +0000
URL:       https://git.openjdk.org/babylon/commit/e087fd671d0231747d1df476d526daaa6b85def5

added tests to pom and intellij builds

! hat/intellij/.idea/modules.xml
+ hat/intellij/tests.iml
! hat/tests/pom.xml


From gfrost at openjdk.org  Thu Sep 11 17:21:24 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 11 Sep 2025 17:21:24 GMT
Subject: [code-reflection] Integrated: added tests to pom and intellij builds
Message-ID: <IUB7Rom0k8VqQpRLatT-I9cUvqrmvEv46F_4lve6k5M=.9fb414e5-50b2-4547-8a66-26bb0138b44a@github.com>

Added tests to maven build (was previously building to hat-tests-1.0-SNAPSHOT) which was not picked up by the @hat/test script

Also added intellij/tests.iml and added tests to intellij/.idea/modules.iml so tests are included in the intellij project

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

Commit messages:
 - added tests to pom and intellij builds

Changes: https://git.openjdk.org/babylon/pull/564/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=564&range=00
  Stats: 130 lines in 3 files changed: 45 ins; 62 del; 23 mod
  Patch: https://git.openjdk.org/babylon/pull/564.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/564/head:pull/564

PR: https://git.openjdk.org/babylon/pull/564

From gfrost at openjdk.org  Thu Sep 11 17:21:24 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 11 Sep 2025 17:21:24 GMT
Subject: [code-reflection] Integrated: added tests to pom and intellij builds
In-Reply-To: <IUB7Rom0k8VqQpRLatT-I9cUvqrmvEv46F_4lve6k5M=.9fb414e5-50b2-4547-8a66-26bb0138b44a@github.com>
References: <IUB7Rom0k8VqQpRLatT-I9cUvqrmvEv46F_4lve6k5M=.9fb414e5-50b2-4547-8a66-26bb0138b44a@github.com>
Message-ID: <frk1YYSqzB9gCJyAXfqpLGhnq5ZVBd6T7wOcsd-23PQ=.0846e18f-b5d2-4d9a-a842-2aaf215fee99@github.com>

On Thu, 11 Sep 2025 17:13:41 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Added tests to maven build (was previously building to hat-tests-1.0-SNAPSHOT) which was not picked up by the @hat/test script
> 
> Also added intellij/tests.iml and added tests to intellij/.idea/modules.iml so tests are included in the intellij project

This pull request has now been integrated.

Changeset: e087fd67
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/e087fd671d0231747d1df476d526daaa6b85def5
Stats:     130 lines in 3 files changed: 45 ins; 62 del; 23 mod

added tests to pom and intellij builds

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

PR: https://git.openjdk.org/babylon/pull/564

From duke at openjdk.org  Thu Sep 11 18:09:39 2025
From: duke at openjdk.org (Ruby Chen)
Date: Thu, 11 Sep 2025 18:09:39 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests [v3]
In-Reply-To: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
Message-ID: <qVsSxngs7oLioEhSauQrKc_Xe4rmpaJObhq__zWOPbo=.47dc507b-6d6b-4a4c-8258-5479cb9107ef@github.com>

> Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a phi stored in `same` that is later deleted in a recursive `tryRemoveTrivialPhi()` call is still returned despite being deleted. 
> 
> Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones, which is the bug first presented itself.

Ruby Chen has updated the pull request incrementally with one additional commit since the last revision:

  Add one more test and change equals

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/542/files
  - new: https://git.openjdk.org/babylon/pull/542/files/e3ba9dd6..a2a723e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=542&range=02
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=542&range=01-02

  Stats: 24 lines in 2 files changed: 23 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/babylon/pull/542.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/542/head:pull/542

PR: https://git.openjdk.org/babylon/pull/542

From duke at openjdk.org  Thu Sep 11 18:09:41 2025
From: duke at openjdk.org (duke)
Date: Thu, 11 Sep 2025 18:09:41 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests [v2]
In-Reply-To: <JRY-QHNsS3NZDfgSxfNRVRzy0P-6exzJRNn9Zz42GLo=.ebabc1e5-a5ed-41dd-92c6-d4f4d48a39eb@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
 <JRY-QHNsS3NZDfgSxfNRVRzy0P-6exzJRNn9Zz42GLo=.ebabc1e5-a5ed-41dd-92c6-d4f4d48a39eb@github.com>
Message-ID: <1NiNSt14wsDJKiuS1OOTSG2uauU2Chs8_i0Xh22Lx8k=.e33b5f53-817b-4212-8029-35988b5db1cd@github.com>

On Tue, 9 Sep 2025 18:52:16 GMT, Ruby Chen <duke at openjdk.org> wrote:

>> Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a phi stored in `same` that is later deleted in a recursive `tryRemoveTrivialPhi()` call is still returned despite being deleted. 
>> 
>> Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones, which is the bug first presented itself.
>
> Ruby Chen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Replace deleted phi after recursive call
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Fix SSABraun bug and add SSA tests

@rbrchen 
Your change (at version a2a723e5fbafcb957075eb1fff942ece59689fb7) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/babylon/pull/542#issuecomment-3282100967

From duke at openjdk.org  Thu Sep 11 18:09:42 2025
From: duke at openjdk.org (Ruby Chen)
Date: Thu, 11 Sep 2025 18:09:42 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests [v2]
In-Reply-To: <UvylIXTeDFxHJWKvjUA9f8brCEMCg9HFIJ6yhN3TovI=.a905b7ee-9800-413f-8614-e4cc1140460c@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
 <JRY-QHNsS3NZDfgSxfNRVRzy0P-6exzJRNn9Zz42GLo=.ebabc1e5-a5ed-41dd-92c6-d4f4d48a39eb@github.com>
 <21DFkWMwt7iyq8sVcYCQd7MfMJgCGvf29Woud36vAME=.b2891a99-304b-4bcf-8d45-8142a4f44fcc@github.com>
 <UvylIXTeDFxHJWKvjUA9f8brCEMCg9HFIJ6yhN3TovI=.a905b7ee-9800-413f-8614-e4cc1140460c@github.com>
Message-ID: <E_Rwwe2zTdBAOk1zEQJQ2l5THfo7JIZ3tCZLN2BKTtw=.8b30c9d7-af5c-4d02-9e54-7edbf854da77@github.com>

On Wed, 10 Sep 2025 19:32:57 GMT, Ruby Chen <duke at openjdk.org> wrote:

>> src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/SSABraun.java line 200:
>> 
>>> 198:         for (Phi user : phiUsers) {
>>> 199:             Val res = tryRemoveTrivialPhi(user);
>>> 200:             if (same.equals(user)) {
>> 
>> For consistency, could you also use `==` here?
>
> Actually, I'm looking into that right now! I'm not sure if that might cause some issues if there are two var stores that use the same operand - doing some testing atm
> Can I ask why you chose to use `==` instead of `.equals()` when comparing Vals/Phis?

I think for now, I'll move forward with `==` but I'll also keep an eye out in case it causes any issues ?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/542#discussion_r2341952953

From psandoz at openjdk.org  Thu Sep 11 18:24:44 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 11 Sep 2025 18:24:44 GMT
Subject: git: openjdk/babylon: code-reflection: Fix SSABraun bug and add SSA
 tests
Message-ID: <2cdc0464-1bdf-4c55-820d-54df5b624484@openjdk.org>

Changeset: ab94fe70
Branch: code-reflection
Author:    Ruby Chen <ruby.r.chen at gmail.com>
Committer: Paul Sandoz <psandoz at openjdk.org>
Date:      2025-09-11 18:22:32 +0000
URL:       https://git.openjdk.org/babylon/commit/ab94fe70c5fd3522469ff12a74e27d1ad4157002

Fix SSABraun bug and add SSA tests

Reviewed-by: psandoz

! src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/SSABraun.java
! test/jdk/java/lang/reflect/code/TestSSA.java


From duke at openjdk.org  Thu Sep 11 18:25:53 2025
From: duke at openjdk.org (Ruby Chen)
Date: Thu, 11 Sep 2025 18:25:53 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests [v4]
In-Reply-To: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
Message-ID: <sOHF7J7lUpUTiEG-FZ69IvRZIRw9oOBRADEqywmouKc=.9ec47671-10a8-4919-bf78-41ff6bfbdf57@github.com>

> Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a phi stored in `same` that is later deleted in a recursive `tryRemoveTrivialPhi()` call is still returned despite being deleted. 
> 
> Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones, which is the bug first presented itself.

Ruby Chen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'openjdk:code-reflection' into inline
 - Add one more test and change equals
 - Replace deleted phi after recursive call
 - Merge branch 'openjdk:code-reflection' into inline
 - Merge branch 'openjdk:code-reflection' into inline
 - Merge branch 'openjdk:code-reflection' into inline
 - Fix SSABraun bug and add SSA tests

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/542/files
  - new: https://git.openjdk.org/babylon/pull/542/files/a2a723e5..0f1d75d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=542&range=03
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=542&range=02-03

  Stats: 2998 lines in 36 files changed: 2738 ins; 76 del; 184 mod
  Patch: https://git.openjdk.org/babylon/pull/542.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/542/head:pull/542

PR: https://git.openjdk.org/babylon/pull/542

From psandoz at openjdk.org  Thu Sep 11 18:25:54 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 11 Sep 2025 18:25:54 GMT
Subject: [code-reflection] RFR: Fix SSABraun bug and add SSA tests [v4]
In-Reply-To: <sOHF7J7lUpUTiEG-FZ69IvRZIRw9oOBRADEqywmouKc=.9ec47671-10a8-4919-bf78-41ff6bfbdf57@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
 <sOHF7J7lUpUTiEG-FZ69IvRZIRw9oOBRADEqywmouKc=.9ec47671-10a8-4919-bf78-41ff6bfbdf57@github.com>
Message-ID: <RdFiwsTO-uZRiRrp-EV6Vhx8gw4Fyh07NWd4My_dRFo=.ebc0f497-5ccc-4276-bd33-0218bbd91ac6@github.com>

On Thu, 11 Sep 2025 18:22:43 GMT, Ruby Chen <duke at openjdk.org> wrote:

>> Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a phi stored in `same` that is later deleted in a recursive `tryRemoveTrivialPhi()` call is still returned despite being deleted. 
>> 
>> Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones, which is the bug first presented itself.
>
> Ruby Chen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Add one more test and change equals
>  - Replace deleted phi after recursive call
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Merge branch 'openjdk:code-reflection' into inline
>  - Fix SSABraun bug and add SSA tests

Well done. We can investigate and address the use of identity equality in another PR, if necessary.

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

Marked as reviewed by psandoz (Lead).

PR Review: https://git.openjdk.org/babylon/pull/542#pullrequestreview-3213132021

From duke at openjdk.org  Thu Sep 11 18:25:55 2025
From: duke at openjdk.org (Ruby Chen)
Date: Thu, 11 Sep 2025 18:25:55 GMT
Subject: [code-reflection] Integrated: Fix SSABraun bug and add SSA tests
In-Reply-To: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
References: <cJWkYRd5zPe645lY8-cQHoGnL3XhABwjHLUuwvHDHVE=.3817043d-c6f3-4545-84db-53f0cd63cb4b@github.com>
Message-ID: <hPnRqkO6kTHgx6swHwfUC8yYtealIvFsPifec5N78B0=.18f71de4-44e8-47fa-988d-5a1cba7cf814@github.com>

On Tue, 2 Sep 2025 20:30:58 GMT, Ruby Chen <duke at openjdk.org> wrote:

> Fix a bug in SSABraun where, in `tryRemoveTrivialPhi()`, a phi stored in `same` that is later deleted in a recursive `tryRemoveTrivialPhi()` call is still returned despite being deleted. 
> 
> Add five tests to TestSSA: `deadCode(), ifelseLoopNested(), violaJones(), binarySearch(),` and `quicksort()`. `violaJones()` is inspired by the method `findFeaturesKernel` in HAT kernel ViolaJones, which is the bug first presented itself.

This pull request has now been integrated.

Changeset: ab94fe70
Author:    Ruby Chen <ruby.r.chen at gmail.com>
Committer: Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/ab94fe70c5fd3522469ff12a74e27d1ad4157002
Stats:     176 lines in 2 files changed: 175 ins; 0 del; 1 mod

Fix SSABraun bug and add SSA tests

Reviewed-by: psandoz

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

PR: https://git.openjdk.org/babylon/pull/542

From jfumero at openjdk.org  Fri Sep 12 08:25:41 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Fri, 12 Sep 2025 08:25:41 GMT
Subject: git: openjdk/babylon: code-reflection: New Examples: Dialects and
 Dynamic Function Builds
Message-ID: <a54d7c10-ec2d-4f0a-82dd-836399abeeb0@openjdk.org>

Changeset: a9055a8e
Branch: code-reflection
Author:    Juan Fumero <jfumero at openjdk.org>
Date:      2025-09-12 08:21:31 +0000
URL:       https://git.openjdk.org/babylon/commit/a9055a8e867abb3b0765c9ba0559f34c51fd342a

New Examples: Dialects and Dynamic Function Builds

! cr-examples/samples/README.md
+ cr-examples/samples/src/main/java/oracle/code/samples/DialectFMAOp.java
+ cr-examples/samples/src/main/java/oracle/code/samples/DialectWithInvoke.java
+ cr-examples/samples/src/main/java/oracle/code/samples/DynamicFunctionBuild.java


From jfumero at openjdk.org  Fri Sep 12 08:26:29 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Fri, 12 Sep 2025 08:26:29 GMT
Subject: [code-reflection] RFR: New Examples: Dialects and Dynamic Function
 Builds [v7]
In-Reply-To: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
References: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
Message-ID: <6zQxSCz1bmq1QvRlnCvVFxp0xD5m7HMUYdhBS34jSds=.f54deeb8-6c20-4bbc-8333-1bd7595b2635@github.com>

> - `DialectSample`: Example of how to extends the code reflection `Op` to create a new dialect. 
> - `DynamicFunctionBuild`: Example of how to create a new function dynamically to compute the inverse of a square root.  The code model is built dynamically for a new method and it is evaluated in the `Interpreter`.
> 
> How to run?
> 
> ##### Run DialectWithInvoke
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectWithInvoke
> 
> 
> ##### Run DialectFMAOp
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectFMAOp
> 
> 
> ##### Run DynamicFunctionBuild
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DynamicFunctionBuild

Juan Fumero has updated the pull request incrementally with one additional commit since the last revision:

  [samples] Dialect solved NPE

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/549/files
  - new: https://git.openjdk.org/babylon/pull/549/files/28296c2f..0c18e7d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=06
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=549&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/babylon/pull/549.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/549/head:pull/549

PR: https://git.openjdk.org/babylon/pull/549

From jfumero at openjdk.org  Fri Sep 12 08:26:31 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Fri, 12 Sep 2025 08:26:31 GMT
Subject: [code-reflection] Integrated: New Examples: Dialects and Dynamic
 Function Builds
In-Reply-To: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
References: <s9_gZAz_ILHC5sMYVx0BdqBVGWg8ObNW7-U9McRJIo0=.35bfebb0-355a-4ce0-aba8-3911f83af234@github.com>
Message-ID: <YALMZSXHWAm6NQSSpw5jwImFUmH7pCtQu-KoLmcZGRI=.e876e3cc-843a-4e5a-a5f0-ed735ef32a8a@github.com>

On Fri, 5 Sep 2025 11:01:34 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> - `DialectSample`: Example of how to extends the code reflection `Op` to create a new dialect. 
> - `DynamicFunctionBuild`: Example of how to create a new function dynamically to compute the inverse of a square root.  The code model is built dynamically for a new method and it is evaluated in the `Interpreter`.
> 
> How to run?
> 
> ##### Run DialectWithInvoke
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectWithInvoke
> 
> 
> ##### Run DialectFMAOp
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DialectFMAOp
> 
> 
> ##### Run DynamicFunctionBuild
> 
> 
> java --enable-preview -cp target/crsamples-1.0-SNAPSHOT.jar oracle.code.samples.DynamicFunctionBuild

This pull request has now been integrated.

Changeset: a9055a8e
Author:    Juan Fumero <jfumero at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/a9055a8e867abb3b0765c9ba0559f34c51fd342a
Stats:     534 lines in 4 files changed: 532 ins; 1 del; 1 mod

New Examples: Dialects and Dynamic Function Builds

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

PR: https://git.openjdk.org/babylon/pull/549

From asotona at openjdk.org  Fri Sep 12 10:04:00 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 12 Sep 2025 10:04:00 GMT
Subject: [code-reflection] RFR: ONNX fixes
Message-ID: <EwGmgmXyALOT3VeeqhaxiDJLB67JPFPhGXTK2t1BNOM=.723b8145-2419-4a30-9962-3ebdb0c7cdf0@github.com>

This patch includes:
- `OnnxTransformer` fix of returning in-code constructed list of tensors
- `README.md` fix of the examples execution
- workaround to avoid CNFE when the `ReleaseEnv` class is attempted to load in the above shutdown hook from already closed classloader

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

Commit messages:
 - workaround to avoid CNFE when the ReleaseEnv class is attempted to load in the above shutdown hook from already closed classloader
 - fixed ONNX readme
 - OnnxTransformer fix

Changes: https://git.openjdk.org/babylon/pull/565/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=565&range=00
  Stats: 10 lines in 3 files changed: 6 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/babylon/pull/565.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/565/head:pull/565

PR: https://git.openjdk.org/babylon/pull/565

From mcimadamore at openjdk.org  Fri Sep 12 16:26:32 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 12 Sep 2025 16:26:32 GMT
Subject: [code-reflection] RFR: Add sample annotation processor using code
 models [v2]
In-Reply-To: <JjiPTcoj2no8s-7hdaYY6HR2s_Mv0Pjm6i1V3p3IROY=.75a3591c-e636-4e84-b238-d7cc3ed8d09b@github.com>
References: <JjiPTcoj2no8s-7hdaYY6HR2s_Mv0Pjm6i1V3p3IROY=.75a3591c-e636-4e84-b238-d7cc3ed8d09b@github.com>
Message-ID: <YlBsOM9PkmdMlPGfZrH3cySYOCQA2lp9DPKiJqbIcEE=.fb681e0c-80a4-4512-9541-a3e0f8c2c1c2@github.com>

> This change adds a new sample of an annotation processor that uses code models to:
> * reject unsupported methods (e.g. `System.gc`, `System.exit`)
> * reject unsupported language construct (e.g. `try`, `throw`)
> 
> The annotation processor is somewhat configurable, and can be used by developers as an initial sketch upon which to build more custom compile-time checks.
> 
> When using the annotation processor to compile this:
> 
> 
> class Foo {
>    @CodeReflection
>    void test1() {
>       System.exit(1);
>    }
> 
>     @CodeReflection
>     void test2() {
>         System.gc();
>     }
> 
>     @CodeReflection
>     void test3() {
> 
>        try {
>            test2();
>        } finally {
>            test3();
>        }
> 
>     }
> }
> 
> 
> The following error messages are generated:
> 
> 
> Foo.java:5: error: System.exit not supported in reflectable methods
>    void test1() {
>         ^
> Foo.java:10: error: System.gc not supported in reflectable methods
>     void test2() {
>          ^
> Foo.java:15: error: try/catch statement not supported in reflectable methods
>     void test3() {
>          ^
> 
> 
> When putting this together, I noted some issues, reported below:
> 
> * javac was failing to execute annotation processors that depended on `jdk.incubator.code` module
> * obtaining the model from a method that contains attribution errors crashed the annotation processor
> * some packages (e.g. the ones in java.base) are not exported to the dynamic module layer's `jdk.incubator.code`
> * it is not possible to report the message at a more accurate location because the `Messager` API does not allow for this
> 
> Many thanks to @lahodaj for the invaluable help when fighting with module layers :-)

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'code-reflection' into codemodel_anno_processor
 - Tweak annotation processor readme guide
 - Tweak documentation
 - Fix test
   Fix JavacFileManager.getServiceLoader
 - Add test
   Make sure java.base packages are exported to dynamic layer's module
 - Initial push

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

Changes: https://git.openjdk.org/babylon/pull/554/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=554&range=01
  Stats: 385 lines in 9 files changed: 370 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/babylon/pull/554.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/554/head:pull/554

PR: https://git.openjdk.org/babylon/pull/554

From mcimadamore at openjdk.org  Fri Sep 12 16:26:34 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 12 Sep 2025 16:26:34 GMT
Subject: [code-reflection] Integrated: Add sample annotation processor using
 code models
In-Reply-To: <JjiPTcoj2no8s-7hdaYY6HR2s_Mv0Pjm6i1V3p3IROY=.75a3591c-e636-4e84-b238-d7cc3ed8d09b@github.com>
References: <JjiPTcoj2no8s-7hdaYY6HR2s_Mv0Pjm6i1V3p3IROY=.75a3591c-e636-4e84-b238-d7cc3ed8d09b@github.com>
Message-ID: <JzSFzFPPYV64WjUsF9BbZddc7Ffssz43-mIdC5FDlcY=.66ff0069-bc8b-4ac5-a2bc-2cf4de6ac0f1@github.com>

On Mon, 8 Sep 2025 13:49:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This change adds a new sample of an annotation processor that uses code models to:
> * reject unsupported methods (e.g. `System.gc`, `System.exit`)
> * reject unsupported language construct (e.g. `try`, `throw`)
> 
> The annotation processor is somewhat configurable, and can be used by developers as an initial sketch upon which to build more custom compile-time checks.
> 
> When using the annotation processor to compile this:
> 
> 
> class Foo {
>    @CodeReflection
>    void test1() {
>       System.exit(1);
>    }
> 
>     @CodeReflection
>     void test2() {
>         System.gc();
>     }
> 
>     @CodeReflection
>     void test3() {
> 
>        try {
>            test2();
>        } finally {
>            test3();
>        }
> 
>     }
> }
> 
> 
> The following error messages are generated:
> 
> 
> Foo.java:5: error: System.exit not supported in reflectable methods
>    void test1() {
>         ^
> Foo.java:10: error: System.gc not supported in reflectable methods
>     void test2() {
>          ^
> Foo.java:15: error: try/catch statement not supported in reflectable methods
>     void test3() {
>          ^
> 
> 
> When putting this together, I noted some issues, reported below:
> 
> * javac was failing to execute annotation processors that depended on `jdk.incubator.code` module
> * obtaining the model from a method that contains attribution errors crashed the annotation processor
> * some packages (e.g. the ones in java.base) are not exported to the dynamic module layer's `jdk.incubator.code`
> * it is not possible to report the message at a more accurate location because the `Messager` API does not allow for this
> 
> Many thanks to @lahodaj for the invaluable help when fighting with module layers :-)

This pull request has now been integrated.

Changeset: c1638369
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/c1638369da5940a78f57398e87ccd7b4bac5f667
Stats:     385 lines in 9 files changed: 370 ins; 0 del; 15 mod

Add sample annotation processor using code models

Reviewed-by: psandoz

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

PR: https://git.openjdk.org/babylon/pull/554

From mcimadamore at openjdk.org  Fri Sep 12 16:29:44 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 12 Sep 2025 16:29:44 GMT
Subject: git: openjdk/babylon: code-reflection: Add sample annotation processor
 using code models
Message-ID: <bfeb2f6f-4f10-47df-8cd0-6bd0dc06702d@openjdk.org>

Changeset: c1638369
Branch: code-reflection
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2025-09-12 16:22:50 +0000
URL:       https://git.openjdk.org/babylon/commit/c1638369da5940a78f57398e87ccd7b4bac5f667

Add sample annotation processor using code models

Reviewed-by: psandoz

! cr-examples/samples/README.md
+ cr-examples/samples/src/main/java/oracle/code/samples/CodeReflectionProcessor.java
+ src/java.base/share/classes/jdk/internal/access/code/CodeModuleLayerInit.java
! src/java.base/share/classes/module-info.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/jdk.incubator.code/share/classes/jdk/incubator/code/Op.java
+ test/langtools/tools/javac/reflect/TestCodeModelProcessors.java


From psandoz at openjdk.org  Fri Sep 12 17:01:52 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 12 Sep 2025 17:01:52 GMT
Subject: [code-reflection] RFR: ONNX fixes
In-Reply-To: <EwGmgmXyALOT3VeeqhaxiDJLB67JPFPhGXTK2t1BNOM=.723b8145-2419-4a30-9962-3ebdb0c7cdf0@github.com>
References: <EwGmgmXyALOT3VeeqhaxiDJLB67JPFPhGXTK2t1BNOM=.723b8145-2419-4a30-9962-3ebdb0c7cdf0@github.com>
Message-ID: <D5ujGGtRVVa-KCc2V9CTv6gtgMSUVy0GYnhwwBVBWmw=.49c66307-37d1-4f4f-86e3-c81c57f1ad5c@github.com>

On Fri, 12 Sep 2025 09:58:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch includes:
> - `OnnxTransformer` fix of returning in-code constructed list of tensors
> - `README.md` fix of the examples execution
> - workaround to avoid CNFE when the `ReleaseEnv` class is attempted to load in the above shutdown hook from already closed classloader

cr-examples/onnx/src/main/java/oracle/code/onnx/OnnxRuntime.java line 266:

> 264:             // workaround to avoid CNFE when the ReleaseEnv class is attempted to load in the above shutdown hook from already closed classloader
> 265:             Class.forName("oracle.code.onnx.foreign.OrtApi$ReleaseEnv");
> 266:         } catch (ClassNotFoundException _) {}

That's awkward. Can you move it to the static initializer block?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/565#discussion_r2344920533

From mabbay at openjdk.org  Fri Sep 12 17:49:31 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Fri, 12 Sep 2025 17:49:31 GMT
Subject: [code-reflection] RFR: Use JUnit instead of TestNG
Message-ID: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>

Use JUnit instead of TestNG

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

Commit messages:
 - Use junit instead of testng

Changes: https://git.openjdk.org/babylon/pull/566/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=566&range=00
  Stats: 79 lines in 8 files changed: 19 ins; 8 del; 52 mod
  Patch: https://git.openjdk.org/babylon/pull/566.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/566/head:pull/566

PR: https://git.openjdk.org/babylon/pull/566

From psandoz at openjdk.org  Fri Sep 12 17:56:49 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 12 Sep 2025 17:56:49 GMT
Subject: [code-reflection] RFR: Use JUnit instead of TestNG
In-Reply-To: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
References: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
Message-ID: <ynNz9kEvKieF5TRrpNesvIgVxEMLW7hAgnmDhRJ_KY0=.aab4f4ac-5564-4f64-be80-72a2000dccde@github.com>

On Fri, 12 Sep 2025 17:42:38 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Use JUnit instead of TestNG

One area we need to pay special attention to is the order of arguments of assert methods. junit and testng switch the order actual and expected parameters of such methods.

test/langtools/tools/javac/reflect/quoted/TestCaptureQuoted.java line 140:

> 138: 
> 139: 
> 140:     public static Object[][] ints() {

Can we directly return `IntStream`?

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

PR Review: https://git.openjdk.org/babylon/pull/566#pullrequestreview-3218086965
PR Review Comment: https://git.openjdk.org/babylon/pull/566#discussion_r2345043694

From gfrost at openjdk.org  Sun Sep 14 15:35:01 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 14 Sep 2025 15:35:01 GMT
Subject: git: openjdk/babylon: code-reflection: Align build artifacts maven,
 @hat/bld and  hat/job.jar
Message-ID: <01c599ea-3028-41ca-9d9c-d87378a82f1a@openjdk.org>

Changeset: c2b67cc6
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-14 15:34:00 +0000
URL:       https://git.openjdk.org/babylon/commit/c2b67cc6d08218ccd100354ea880b9877f96b96b

Align build artifacts maven, @hat/bld and  hat/job.jar

! hat/extractions/cuda/pom.xml
! hat/extractions/opencl/pom.xml
! hat/extractions/opengl/pom.xml
! hat/hat/bld.java
+ hat/hat/job.jar
! hat/hat/run.java


From gfrost at openjdk.org  Sun Sep 14 15:36:57 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 14 Sep 2025 15:36:57 GMT
Subject: [code-reflection] Integrated: Align build artifacts maven,
 @hat/bld and  hat/job.jar
Message-ID: <My6QzXtY1QoRognXagV9WHVBMNydF4YdLrQQl-ImYfo=.26c8031a-f7e2-49ee-8223-209bc8c5ea88@github.com>

Aligning naming of artifacts across the three build mechanisms. 

Specifically `bash maven.bash` and `java @/hat/bld` generated `hat-extractions-opencl` whereas `java -cp hat/job.jar hat.java bld` created `hat-extracted-opencl`

This now allows us to run using `java @hat/run ffi-opencl nbody` or `java -cp hat/job.jar hat.java run ffi-opencl nbody`

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

Commit messages:
 - Align build artifacts maven, @hat/bld and  hat/job.jar

Changes: https://git.openjdk.org/babylon/pull/567/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=567&range=00
  Stats: 10 lines in 6 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/babylon/pull/567.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/567/head:pull/567

PR: https://git.openjdk.org/babylon/pull/567

From gfrost at openjdk.org  Sun Sep 14 15:36:58 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 14 Sep 2025 15:36:58 GMT
Subject: [code-reflection] Integrated: Align build artifacts maven,
 @hat/bld and  hat/job.jar
In-Reply-To: <My6QzXtY1QoRognXagV9WHVBMNydF4YdLrQQl-ImYfo=.26c8031a-f7e2-49ee-8223-209bc8c5ea88@github.com>
References: <My6QzXtY1QoRognXagV9WHVBMNydF4YdLrQQl-ImYfo=.26c8031a-f7e2-49ee-8223-209bc8c5ea88@github.com>
Message-ID: <KVCeAtuKKFM5qglZwiJ1m_W2kVmD5t_eYl-J9Nblths=.3b65e3d9-10a1-4458-a358-2a1ad56b64a2@github.com>

On Sun, 14 Sep 2025 15:30:18 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Aligning naming of artifacts across the three build mechanisms. 
> 
> Specifically `bash maven.bash` and `java @/hat/bld` generated `hat-extractions-opencl` whereas `java -cp hat/job.jar hat.java bld` created `hat-extracted-opencl`
> 
> This now allows us to run using `java @hat/run ffi-opencl nbody` or `java -cp hat/job.jar hat.java run ffi-opencl nbody`

This pull request has now been integrated.

Changeset: c2b67cc6
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/c2b67cc6d08218ccd100354ea880b9877f96b96b
Stats:     10 lines in 6 files changed: 0 ins; 0 del; 10 mod

Align build artifacts maven, @hat/bld and  hat/job.jar

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

PR: https://git.openjdk.org/babylon/pull/567

From gfrost at openjdk.org  Sun Sep 14 16:20:11 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 14 Sep 2025 16:20:11 GMT
Subject: git: openjdk/babylon: code-reflection: add ability to run tests from
 job.jar
Message-ID: <c55f1ba0-105c-465f-b25e-81ce22110ef9@openjdk.org>

Changeset: b6620893
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-14 16:18:37 +0000
URL:       https://git.openjdk.org/babylon/commit/b662089307cb6b3752ce25146f83f1d6f2012ee9

add ability to run tests from job.jar

+ hat/hat.java


From gfrost at openjdk.org  Sun Sep 14 16:22:30 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 14 Sep 2025 16:22:30 GMT
Subject: [code-reflection] Integrated: add ability to run tests from job.jar
Message-ID: <XBYAlzgDeKEndZCbHNRs1X-kxup0T6QTFzyVOAwsVlI=.1f2da8ad-57db-4a91-b971-544de8b374d8@github.com>

Added ability to run the test suite using job.jar 


java -cp hat/job.jar hat.java bld 
java -cp hat/job.jar hat.java test ffi-opencl

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

Commit messages:
 - add ability to run tests from job.jar
 - add ability to run tests from job.jar

Changes: https://git.openjdk.org/babylon/pull/568/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=568&range=00
  Stats: 312 lines in 1 file changed: 312 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/babylon/pull/568.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/568/head:pull/568

PR: https://git.openjdk.org/babylon/pull/568

From gfrost at openjdk.org  Sun Sep 14 16:22:31 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 14 Sep 2025 16:22:31 GMT
Subject: [code-reflection] Integrated: add ability to run tests from job.jar
In-Reply-To: <XBYAlzgDeKEndZCbHNRs1X-kxup0T6QTFzyVOAwsVlI=.1f2da8ad-57db-4a91-b971-544de8b374d8@github.com>
References: <XBYAlzgDeKEndZCbHNRs1X-kxup0T6QTFzyVOAwsVlI=.1f2da8ad-57db-4a91-b971-544de8b374d8@github.com>
Message-ID: <0qNOtjsdFdMz120U9b808ImBE9SjDpAfuTIIAzk9Poo=.4b59eb16-94be-4660-bd3c-886e642253f8@github.com>

On Sun, 14 Sep 2025 16:12:16 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Added ability to run the test suite using job.jar 
> 
> 
> java -cp hat/job.jar hat.java bld 
> java -cp hat/job.jar hat.java test ffi-opencl

This pull request has now been integrated.

Changeset: b6620893
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/b662089307cb6b3752ce25146f83f1d6f2012ee9
Stats:     312 lines in 1 file changed: 312 ins; 0 del; 0 mod

add ability to run tests from job.jar

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

PR: https://git.openjdk.org/babylon/pull/568

From asotona at openjdk.org  Mon Sep 15 08:54:10 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 15 Sep 2025 08:54:10 GMT
Subject: [code-reflection] RFR: ONNX fixes [v2]
In-Reply-To: <EwGmgmXyALOT3VeeqhaxiDJLB67JPFPhGXTK2t1BNOM=.723b8145-2419-4a30-9962-3ebdb0c7cdf0@github.com>
References: <EwGmgmXyALOT3VeeqhaxiDJLB67JPFPhGXTK2t1BNOM=.723b8145-2419-4a30-9962-3ebdb0c7cdf0@github.com>
Message-ID: <kLd7eUG7EZIZuF37OkyM-anFechy7GrGwp8Q24M2I-Q=.fb2d3106-1684-49de-aefa-adbb1e586dd6@github.com>

> This patch includes:
> - `OnnxTransformer` fix of returning in-code constructed list of tensors
> - `README.md` fix of the examples execution
> - workaround to avoid CNFE when the `ReleaseEnv` class is attempted to load in the above shutdown hook from already closed classloader

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  CNFE workaround moved to static initializer

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/565/files
  - new: https://git.openjdk.org/babylon/pull/565/files/1fd921f2..6877c7b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=565&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=565&range=00-01

  Stats: 10 lines in 1 file changed: 6 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/babylon/pull/565.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/565/head:pull/565

PR: https://git.openjdk.org/babylon/pull/565

From mcimadamore at openjdk.org  Mon Sep 15 12:26:35 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Sep 2025 12:26:35 GMT
Subject: [code-reflection] RFR: Use JUnit instead of TestNG
In-Reply-To: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
References: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
Message-ID: <RJq6giOxs7WZzXJP7ugW4GNNg9AZpj40zMHnre9CbKU=.bbc48dc6-bcf8-40c1-9980-adc6fd7c97a7@github.com>

On Fri, 12 Sep 2025 17:42:38 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Use JUnit instead of TestNG

Aside from @PaulSandoz comment, PR looks good

test/langtools/tools/javac/reflect/TestIRFromAnnotation.java line 68:

> 66:                                                 // in method superInterfaceMethodInvocation
> 67:             "LocalClassTest.java",              // name of local classes is not stable at annotation processing time
> 68:             "TestLocalCapture.java",            // plain junit test

When looking again at this, it would perhaps be beneficial to put all the IR tests in a separate folder. It seems a bit sad that whenever we add a "plain" test we have to come back and list it here.

The exclusion for `SuperTest`/`LocalClassTest` of course make more sense, so it's ok for them to stay.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/babylon/pull/566#pullrequestreview-3224337709
PR Review Comment: https://git.openjdk.org/babylon/pull/566#discussion_r2348821943

From mcimadamore at openjdk.org  Mon Sep 15 12:26:37 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Sep 2025 12:26:37 GMT
Subject: [code-reflection] RFR: Use JUnit instead of TestNG
In-Reply-To: <RJq6giOxs7WZzXJP7ugW4GNNg9AZpj40zMHnre9CbKU=.bbc48dc6-bcf8-40c1-9980-adc6fd7c97a7@github.com>
References: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
 <RJq6giOxs7WZzXJP7ugW4GNNg9AZpj40zMHnre9CbKU=.bbc48dc6-bcf8-40c1-9980-adc6fd7c97a7@github.com>
Message-ID: <RJty7U0FbV8JJKZXeN3PuWk7AoSW4splSh7-r2B2L0w=.dc6a0da8-f109-44ee-a0b3-0ef2b4bc8ac2@github.com>

On Mon, 15 Sep 2025 12:22:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Use JUnit instead of TestNG
>
> test/langtools/tools/javac/reflect/TestIRFromAnnotation.java line 68:
> 
>> 66:                                                 // in method superInterfaceMethodInvocation
>> 67:             "LocalClassTest.java",              // name of local classes is not stable at annotation processing time
>> 68:             "TestLocalCapture.java",            // plain junit test
> 
> When looking again at this, it would perhaps be beneficial to put all the IR tests in a separate folder. It seems a bit sad that whenever we add a "plain" test we have to come back and list it here.
> 
> The exclusion for `SuperTest`/`LocalClassTest` of course make more sense, so it's ok for them to stay.

(for the records, I'm not suggesting we tackle this in this PR -- more noting for "future work")

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

PR Review Comment: https://git.openjdk.org/babylon/pull/566#discussion_r2348823094

From gfrost at openjdk.org  Mon Sep 15 12:31:25 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 15 Sep 2025 12:31:25 GMT
Subject: [code-reflection] Integrated: cleaned up test stanza of hat.java test
Message-ID: <-4N5j08SaBODPjRDU3J7ES7HgwHv3J0aRXymhJnGa0U=.259f2929-977c-489e-a398-d8b428fc3cd8@github.com>

Cleaned up `test` stanza of hat.java.

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

Commit messages:
 - cleaned up test stanza of hat.java test

Changes: https://git.openjdk.org/babylon/pull/569/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=569&range=00
  Stats: 95 lines in 1 file changed: 1 ins; 45 del; 49 mod
  Patch: https://git.openjdk.org/babylon/pull/569.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/569/head:pull/569

PR: https://git.openjdk.org/babylon/pull/569

From gfrost at openjdk.org  Mon Sep 15 12:31:26 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 15 Sep 2025 12:31:26 GMT
Subject: [code-reflection] Integrated: cleaned up test stanza of hat.java test
In-Reply-To: <-4N5j08SaBODPjRDU3J7ES7HgwHv3J0aRXymhJnGa0U=.259f2929-977c-489e-a398-d8b428fc3cd8@github.com>
References: <-4N5j08SaBODPjRDU3J7ES7HgwHv3J0aRXymhJnGa0U=.259f2929-977c-489e-a398-d8b428fc3cd8@github.com>
Message-ID: <fQCXx9Gc9GJYLVxnhl5yIrc2P81BnbsSEfWSi0ip1jw=.2f2fba05-5f0e-4b22-8449-066f95e35049@github.com>

On Mon, 15 Sep 2025 12:24:19 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Cleaned up `test` stanza of hat.java.

This pull request has now been integrated.

Changeset: bde6eb45
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/bde6eb45f9e4dec5621e4d397fa902e989ee994c
Stats:     95 lines in 1 file changed: 1 ins; 45 del; 49 mod

cleaned up test stanza of hat.java test

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

PR: https://git.openjdk.org/babylon/pull/569

From gfrost at openjdk.org  Mon Sep 15 12:32:05 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Mon, 15 Sep 2025 12:32:05 GMT
Subject: git: openjdk/babylon: code-reflection: cleaned up test stanza of
 hat.java test
Message-ID: <058424b6-6e86-44a5-8a33-39b877ca0f12@openjdk.org>

Changeset: bde6eb45
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-15 12:27:44 +0000
URL:       https://git.openjdk.org/babylon/commit/bde6eb45f9e4dec5621e4d397fa902e989ee994c

cleaned up test stanza of hat.java test

! hat/hat.java


From mabbay at openjdk.org  Mon Sep 15 12:43:03 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 15 Sep 2025 12:43:03 GMT
Subject: git: openjdk/babylon: code-reflection: Add isQuotable attribute to
 LambdaOp
Message-ID: <0f5a6347-f984-4024-9952-3160b163f890@openjdk.org>

Changeset: d276cba1
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2025-09-15 12:40:37 +0000
URL:       https://git.openjdk.org/babylon/commit/d276cba1b4f99b8959e9177b3951ea393ef7acf2

Add isQuotable attribute to LambdaOp

Reviewed-by: psandoz

! src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/BytecodeGenerator.java
! src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/BytecodeLift.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
! src/jdk.incubator.code/share/classes/jdk/incubator/code/interpreter/Interpreter.java
! test/langtools/tools/javac/reflect/QuotableIntersectionTest.java
! test/langtools/tools/javac/reflect/QuotableSubtypeTest.java
! test/langtools/tools/javac/reflect/UnreachableTest.java


From mabbay at openjdk.org  Mon Sep 15 12:44:40 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 15 Sep 2025 12:44:40 GMT
Subject: [code-reflection] RFR: Add isQuotable attribute to LambdaOp [v7]
In-Reply-To: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
Message-ID: <G5BM3Pm5sj36XZZb1LUhcpxMoyBbaqB_n08A3gs37ns=.4bbe33ca-066f-400e-b4dc-4a09c8a0dab4@github.com>

> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.

Mourad Abbay 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 branch 'code-reflection' into lambda-isQuotable-attr
 - Apply suggestion
 - Rectify the way we get the flags of a lambda invokedynamic
 - Correct the way we detect if a lambda is quotable when lifting bytecode
 - Update expected models in tests to include the attribute
 - Detect if a lambda is quotable when lifting bytecode
 - Apply review comments
 - Add attribute to LambdaOp

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/545/files
  - new: https://git.openjdk.org/babylon/pull/545/files/1fa78060..19a3a2ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=06
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=545&range=05-06

  Stats: 12968 lines in 156 files changed: 6395 ins; 5614 del; 959 mod
  Patch: https://git.openjdk.org/babylon/pull/545.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/545/head:pull/545

PR: https://git.openjdk.org/babylon/pull/545

From mabbay at openjdk.org  Mon Sep 15 12:44:41 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 15 Sep 2025 12:44:41 GMT
Subject: [code-reflection] Integrated: Add isQuotable attribute to LambdaOp
In-Reply-To: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
References: <3eF2aFDT1W1GRLVrD8Y9P2dCy-2swEr588i5d0kZcYU=.c84db98d-f55c-496c-bb57-dd189227e0f1@github.com>
Message-ID: <tAZ_ArE-34zPUhy4x3c4hdsqtgnPtB9Up8eZ93Z63P8=.17c72f74-11ad-4c65-bd59-5912b98b8ff0@github.com>

On Wed, 3 Sep 2025 20:00:54 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> In the `interpreter` and `ByteCodeGenerator` we detect if a lambda is quotable based on its functional interface. This approach will not work if intersection type is used e.g. `Runnable r = (Runnable & Quotable) () -> {};` This PR adds a flag to LambdaOp that will be set by the `javac` for quotable lambdas.

This pull request has now been integrated.

Changeset: d276cba1
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/d276cba1b4f99b8959e9177b3951ea393ef7acf2
Stats:     100 lines in 8 files changed: 56 ins; 0 del; 44 mod

Add isQuotable attribute to LambdaOp

Reviewed-by: psandoz

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

PR: https://git.openjdk.org/babylon/pull/545

From mabbay at openjdk.org  Mon Sep 15 12:47:37 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 15 Sep 2025 12:47:37 GMT
Subject: [code-reflection] RFR: Use JUnit instead of TestNG
In-Reply-To: <ynNz9kEvKieF5TRrpNesvIgVxEMLW7hAgnmDhRJ_KY0=.aab4f4ac-5564-4f64-be80-72a2000dccde@github.com>
References: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
 <ynNz9kEvKieF5TRrpNesvIgVxEMLW7hAgnmDhRJ_KY0=.aab4f4ac-5564-4f64-be80-72a2000dccde@github.com>
Message-ID: <jFdQrJI5m_5Z03s-2BmehEJV_PNmNVLYI3EdOW27fjk=.6376d27c-1491-40b7-b8c6-ed5432a62cbe@github.com>

On Fri, 12 Sep 2025 17:53:57 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> One area we need to pay special attention to is the order of arguments of assert methods. junit and testng switch the order actual and expected parameters of such methods.

Yes. But It won't affect the test result, right ?

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

PR Comment: https://git.openjdk.org/babylon/pull/566#issuecomment-3292000038

From mcimadamore at openjdk.org  Mon Sep 15 13:21:37 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Sep 2025 13:21:37 GMT
Subject: [code-reflection] RFR: Use JUnit instead of TestNG
In-Reply-To: <jFdQrJI5m_5Z03s-2BmehEJV_PNmNVLYI3EdOW27fjk=.6376d27c-1491-40b7-b8c6-ed5432a62cbe@github.com>
References: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
 <ynNz9kEvKieF5TRrpNesvIgVxEMLW7hAgnmDhRJ_KY0=.aab4f4ac-5564-4f64-be80-72a2000dccde@github.com>
 <jFdQrJI5m_5Z03s-2BmehEJV_PNmNVLYI3EdOW27fjk=.6376d27c-1491-40b7-b8c6-ed5432a62cbe@github.com>
Message-ID: <3ZdF7qfGSfPU0TqGlSO3pD5bxWjKjKHFJo8IiDcOQoY=.318f3e6b-9bfe-4714-a70f-3b1faabeb453@github.com>

On Mon, 15 Sep 2025 12:45:03 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> > One area we need to pay special attention to is the order of arguments of assert methods. junit and testng switch the order actual and expected parameters of such methods.
> 
> Yes. But It won't affect the test result, right ?

In the case of assertEquals, probably not -- but it might result in confusing error messages. You might try to provoke a failure and compare before/after?

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

PR Comment: https://git.openjdk.org/babylon/pull/566#issuecomment-3292123641

From mabbay at openjdk.org  Mon Sep 15 14:38:15 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 15 Sep 2025 14:38:15 GMT
Subject: [code-reflection] RFR: Use JUnit instead of TestNG [v2]
In-Reply-To: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
References: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
Message-ID: <TUgaUeHA3W_JQmyxhFqdPGc4-mDGB65i2Y4TAwnltD8=.2609b4c1-3ded-4071-a7dc-0caee752f081@github.com>

> Use JUnit instead of TestNG

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Make JUnit method-source return IntStream

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/566/files
  - new: https://git.openjdk.org/babylon/pull/566/files/8870bed3..9ae3967a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=566&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=566&range=00-01

  Stats: 12 lines in 3 files changed: 0 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/babylon/pull/566.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/566/head:pull/566

PR: https://git.openjdk.org/babylon/pull/566

From mabbay at openjdk.org  Mon Sep 15 14:38:19 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 15 Sep 2025 14:38:19 GMT
Subject: [code-reflection] RFR: Use JUnit instead of TestNG [v2]
In-Reply-To: <RJty7U0FbV8JJKZXeN3PuWk7AoSW4splSh7-r2B2L0w=.dc6a0da8-f109-44ee-a0b3-0ef2b4bc8ac2@github.com>
References: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
 <RJq6giOxs7WZzXJP7ugW4GNNg9AZpj40zMHnre9CbKU=.bbc48dc6-bcf8-40c1-9980-adc6fd7c97a7@github.com>
 <RJty7U0FbV8JJKZXeN3PuWk7AoSW4splSh7-r2B2L0w=.dc6a0da8-f109-44ee-a0b3-0ef2b4bc8ac2@github.com>
Message-ID: <F2gOk-0xMZfKDvAzGpfFyvJMku-MBqfyfmTrcyssSks=.be25d76c-ed03-48c6-9771-072a100f6c5f@github.com>

On Mon, 15 Sep 2025 12:23:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> test/langtools/tools/javac/reflect/TestIRFromAnnotation.java line 68:
>> 
>>> 66:                                                 // in method superInterfaceMethodInvocation
>>> 67:             "LocalClassTest.java",              // name of local classes is not stable at annotation processing time
>>> 68:             "TestLocalCapture.java",            // plain junit test
>> 
>> When looking again at this, it would perhaps be beneficial to put all the IR tests in a separate folder. It seems a bit sad that whenever we add a "plain" test we have to come back and list it here.
>> 
>> The exclusion for `SuperTest`/`LocalClassTest` of course make more sense, so it's ok for them to stay.
>
> (for the records, I'm not suggesting we tackle this in this PR -- more noting for "future work")

Actually, "plain" test should be in the runtime tests directory.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/566#discussion_r2349219900

From mcimadamore at openjdk.org  Mon Sep 15 14:51:19 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Sep 2025 14:51:19 GMT
Subject: [code-reflection] RFR: Use JUnit instead of TestNG [v2]
In-Reply-To: <F2gOk-0xMZfKDvAzGpfFyvJMku-MBqfyfmTrcyssSks=.be25d76c-ed03-48c6-9771-072a100f6c5f@github.com>
References: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
 <RJq6giOxs7WZzXJP7ugW4GNNg9AZpj40zMHnre9CbKU=.bbc48dc6-bcf8-40c1-9980-adc6fd7c97a7@github.com>
 <RJty7U0FbV8JJKZXeN3PuWk7AoSW4splSh7-r2B2L0w=.dc6a0da8-f109-44ee-a0b3-0ef2b4bc8ac2@github.com>
 <F2gOk-0xMZfKDvAzGpfFyvJMku-MBqfyfmTrcyssSks=.be25d76c-ed03-48c6-9771-072a100f6c5f@github.com>
Message-ID: <yUs3XjtEWjkTccbBhoTcRt1sjS8FdEcwb0NuhaARPPc=.e7b42a50-83f2-4277-95f4-232f02e6b02f@github.com>

On Mon, 15 Sep 2025 14:34:33 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> (for the records, I'm not suggesting we tackle this in this PR -- more noting for "future work")
>
> Actually, "plain" test should be in the runtime tests directory.

Or that :-)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/566#discussion_r2349261456

From psandoz at openjdk.org  Mon Sep 15 15:41:47 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 15 Sep 2025 15:41:47 GMT
Subject: [code-reflection] RFR: ONNX fixes [v2]
In-Reply-To: <kLd7eUG7EZIZuF37OkyM-anFechy7GrGwp8Q24M2I-Q=.fb2d3106-1684-49de-aefa-adbb1e586dd6@github.com>
References: <EwGmgmXyALOT3VeeqhaxiDJLB67JPFPhGXTK2t1BNOM=.723b8145-2419-4a30-9962-3ebdb0c7cdf0@github.com>
 <kLd7eUG7EZIZuF37OkyM-anFechy7GrGwp8Q24M2I-Q=.fb2d3106-1684-49de-aefa-adbb1e586dd6@github.com>
Message-ID: <fBc5ZnBCdgxWKAFPf4RSZmF6pYj4-kUJ4yh3JN2NgP8=.b4cbed10-a7d0-4eb7-80ce-174c6e6769ea@github.com>

On Mon, 15 Sep 2025 08:54:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This patch includes:
>> - `OnnxTransformer` fix of returning in-code constructed list of tensors
>> - `README.md` fix of the examples execution
>> - workaround to avoid CNFE when the `ReleaseEnv` class is attempted to load in the above shutdown hook from already closed classloader
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CNFE workaround moved to static initializer

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/565#pullrequestreview-3225263655

From asotona at openjdk.org  Mon Sep 15 16:57:05 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 15 Sep 2025 16:57:05 GMT
Subject: git: openjdk/babylon: code-reflection: ONNX fixes
Message-ID: <c4e06c75-7303-49ea-bd9d-36ac016f6dc9@openjdk.org>

Changeset: 8a8d67d6
Branch: code-reflection
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2025-09-15 16:56:25 +0000
URL:       https://git.openjdk.org/babylon/commit/8a8d67d6f87d77082dff363b19c444677031ebf1

ONNX fixes

Reviewed-by: psandoz

! cr-examples/onnx/README.md
! cr-examples/onnx/src/main/java/oracle/code/onnx/OnnxRuntime.java
! cr-examples/onnx/src/main/java/oracle/code/onnx/compiler/OnnxTransformer.java


From asotona at openjdk.org  Mon Sep 15 16:59:46 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 15 Sep 2025 16:59:46 GMT
Subject: [code-reflection] RFR: ONNX fixes [v2]
In-Reply-To: <kLd7eUG7EZIZuF37OkyM-anFechy7GrGwp8Q24M2I-Q=.fb2d3106-1684-49de-aefa-adbb1e586dd6@github.com>
References: <EwGmgmXyALOT3VeeqhaxiDJLB67JPFPhGXTK2t1BNOM=.723b8145-2419-4a30-9962-3ebdb0c7cdf0@github.com>
 <kLd7eUG7EZIZuF37OkyM-anFechy7GrGwp8Q24M2I-Q=.fb2d3106-1684-49de-aefa-adbb1e586dd6@github.com>
Message-ID: <Tx8qbslKoJNQg4JOem5HTQd-HLEMYe5227vh-NnRVM0=.7a734c65-415b-41c0-8e9b-cac465d05621@github.com>

On Mon, 15 Sep 2025 08:54:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This patch includes:
>> - `OnnxTransformer` fix of returning in-code constructed list of tensors
>> - `README.md` fix of the examples execution
>> - workaround to avoid CNFE when the `ReleaseEnv` class is attempted to load in the above shutdown hook from already closed classloader
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CNFE workaround moved to static initializer

Thank you!

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

PR Comment: https://git.openjdk.org/babylon/pull/565#issuecomment-3293100416

From asotona at openjdk.org  Mon Sep 15 16:59:47 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 15 Sep 2025 16:59:47 GMT
Subject: [code-reflection] Integrated: ONNX fixes
In-Reply-To: <EwGmgmXyALOT3VeeqhaxiDJLB67JPFPhGXTK2t1BNOM=.723b8145-2419-4a30-9962-3ebdb0c7cdf0@github.com>
References: <EwGmgmXyALOT3VeeqhaxiDJLB67JPFPhGXTK2t1BNOM=.723b8145-2419-4a30-9962-3ebdb0c7cdf0@github.com>
Message-ID: <P8HHHB6oP787NgkgqGjqn5aS_4lTmZi_2b1ymuST8Os=.9400ae1a-146b-4c15-8630-26aa766132e2@github.com>

On Fri, 12 Sep 2025 09:58:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch includes:
> - `OnnxTransformer` fix of returning in-code constructed list of tensors
> - `README.md` fix of the examples execution
> - workaround to avoid CNFE when the `ReleaseEnv` class is attempted to load in the above shutdown hook from already closed classloader

This pull request has now been integrated.

Changeset: 8a8d67d6
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/8a8d67d6f87d77082dff363b19c444677031ebf1
Stats:     12 lines in 3 files changed: 8 ins; 1 del; 3 mod

ONNX fixes

Reviewed-by: psandoz

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

PR: https://git.openjdk.org/babylon/pull/565

From mabbay at openjdk.org  Mon Sep 15 22:56:30 2025
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 15 Sep 2025 22:56:30 GMT
Subject: [code-reflection] RFR: Update compiler tests to use JUnit instead
 of TestNG [v3]
In-Reply-To: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
References: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
Message-ID: <BRNYDioM4-30c2hJGAKVPlkfgNstHBzdBzloYxatJfM=.28337091-1042-4006-899f-b1d7d32ea6ef@github.com>

> Update compiler tests to use JUnit instead of TestNG.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Swap arguments of assertEquals to match JUnit spec.

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/566/files
  - new: https://git.openjdk.org/babylon/pull/566/files/9ae3967a..33c4fcdb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=566&range=02
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=566&range=01-02

  Stats: 44 lines in 5 files changed: 0 ins; 0 del; 44 mod
  Patch: https://git.openjdk.org/babylon/pull/566.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/566/head:pull/566

PR: https://git.openjdk.org/babylon/pull/566

From jfumero at openjdk.org  Tue Sep 16 14:59:34 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Tue, 16 Sep 2025 14:59:34 GMT
Subject: [code-reflection] RFR: Examples Improved - FMA Dialect refactored
Message-ID: <2jRIfDlPK67GZx-tntyoQGuhAUpk2nFkgHbPIVdF3iQ=.6e9696d9-eabd-4b8c-a2f4-6c0a5eafc01a@github.com>

- Examples Improved - FMA Dialect refactored
- README fixed 
- Documentation fixed

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

Commit messages:
 - Refactor FMA Op example to use multiFilter and clean-up
 - Fix examples README and javadoc

Changes: https://git.openjdk.org/babylon/pull/570/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=570&range=00
  Stats: 63 lines in 8 files changed: 20 ins; 11 del; 32 mod
  Patch: https://git.openjdk.org/babylon/pull/570.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/570/head:pull/570

PR: https://git.openjdk.org/babylon/pull/570

From gfrost at openjdk.org  Wed Sep 17 08:36:48 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 17 Sep 2025 08:36:48 GMT
Subject: [code-reflection] Integrated: added Emanuel Peter's normal mapping
 demo - not hatified yet
Message-ID: <NMMcOY-aVAH0xkss9a8wKKnHHnmhUTxLfrI7VopBF7I=.8d5d859f-cbf0-404d-beff-ea54cbefb734@github.com>

This is a copy of Emanuel Peters 2005 JVMLS Normal Mapping example. 

I made a few changes to accommodate our build structure.  It has been added to hat.java and to maven. 

We should be able tio create a HAT variant of this code. Both to demo GPU perf als this will be a good reference if/when we get around to a VectorAPI backend. 


java -cp hat/job.jar  hat.java bld 
java -cp hat/job.jar hat.java run ffi-opencl normmap

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

Commit messages:
 - added Emanuel Peter's normal mapping demo - not hatified yet

Changes: https://git.openjdk.org/babylon/pull/572/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=572&range=00
  Stats: 550 lines in 8 files changed: 548 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/babylon/pull/572.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/572/head:pull/572

PR: https://git.openjdk.org/babylon/pull/572

From gfrost at openjdk.org  Wed Sep 17 08:36:49 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 17 Sep 2025 08:36:49 GMT
Subject: [code-reflection] Integrated: added Emanuel Peter's normal mapping
 demo - not hatified yet
In-Reply-To: <NMMcOY-aVAH0xkss9a8wKKnHHnmhUTxLfrI7VopBF7I=.8d5d859f-cbf0-404d-beff-ea54cbefb734@github.com>
References: <NMMcOY-aVAH0xkss9a8wKKnHHnmhUTxLfrI7VopBF7I=.8d5d859f-cbf0-404d-beff-ea54cbefb734@github.com>
Message-ID: <fCk6dE8I7XVsGnuGONNYk1y53jjhQV3CIn1d3BW3-EU=.30615087-f1e1-4fe2-b5d9-d056665da417@github.com>

On Wed, 17 Sep 2025 08:28:30 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> This is a copy of Emanuel Peters 2005 JVMLS Normal Mapping example. 
> 
> I made a few changes to accommodate our build structure.  It has been added to hat.java and to maven. 
> 
> We should be able tio create a HAT variant of this code. Both to demo GPU perf als this will be a good reference if/when we get around to a VectorAPI backend. 
> 
> 
> java -cp hat/job.jar  hat.java bld 
> java -cp hat/job.jar hat.java run ffi-opencl normmap

This pull request has now been integrated.

Changeset: 97a023cb
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/97a023cbbeacd0ca4c5025173dc31bf4c25cbb20
Stats:     550 lines in 8 files changed: 548 ins; 0 del; 2 mod

added Emanuel Peter's normal mapping demo - not hatified yet

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

PR: https://git.openjdk.org/babylon/pull/572

From gfrost at openjdk.org  Wed Sep 17 08:38:47 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 17 Sep 2025 08:38:47 GMT
Subject: git: openjdk/babylon: code-reflection: added Emanuel Peter's normal
 mapping demo - not hatified yet
Message-ID: <04da39d7-0cca-4e32-ac0e-8431a24a9874@openjdk.org>

Changeset: 97a023cb
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-17 08:32:28 +0000
URL:       https://git.openjdk.org/babylon/commit/97a023cbbeacd0ca4c5025173dc31bf4c25cbb20

added Emanuel Peter's normal mapping demo - not hatified yet

= hat/examples/normmap/pom.xml
+ hat/examples/normmap/src/main/java/normmap/Main.java
+ hat/examples/normmap/src/main/resources/images/normal_map.png
! hat/examples/pom.xml
! hat/hat.java
! hat/intellij/.idea/modules.xml
+ hat/intellij/example_normmap.iml
= hat/tests/.gitignore


From gfrost at openjdk.org  Wed Sep 17 12:35:13 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 17 Sep 2025 12:35:13 GMT
Subject: [code-reflection] Integrated: Allow hat.java run to pass -DXXXX
 options when running
Message-ID: <b59Zfz0S2ZH9Z2p2lahBbaTC2tZgDzzYHNRjn3pceB8=.c0c6d636-e25e-4122-ac29-002005ea497e@github.com>

This allows us to pass HAT options and also other properties when running via `java -cp hat/job.jar run ....`

For example 

                      run ffi-opencl mandel
                      run ffi-opencl nbody 4096
                      run ffi-opencl -DHAT=SHOW_CODE  -DbufferTagging=true nbody 4096
                      run ffi-opencl -DHAT=SHOW_KERNEL_MODEL heal
                      run ffi-opencl -DHAT=MINIMIZE_BUFFERS life
 ```
 
Note that configs are initialized from env HAT or from HAT property.  This has always been the case, but has not been documented 
 
 So 
 ```
   run ffi-opencl -DHAT=SHOW_KERNEL_MODEL heal
 ```
 is equiv of 
 ```
  HAT=SHOW_KERNEL_MODEL  run ffi-opencl  heal
  ```

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

Commit messages:
 - Allow hat.java run to pass -DXXXX options when running

Changes: https://git.openjdk.org/babylon/pull/574/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=574&range=00
  Stats: 26 lines in 1 file changed: 14 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/babylon/pull/574.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/574/head:pull/574

PR: https://git.openjdk.org/babylon/pull/574

From gfrost at openjdk.org  Wed Sep 17 12:35:13 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 17 Sep 2025 12:35:13 GMT
Subject: [code-reflection] Integrated: Allow hat.java run to pass -DXXXX
 options when running
In-Reply-To: <b59Zfz0S2ZH9Z2p2lahBbaTC2tZgDzzYHNRjn3pceB8=.c0c6d636-e25e-4122-ac29-002005ea497e@github.com>
References: <b59Zfz0S2ZH9Z2p2lahBbaTC2tZgDzzYHNRjn3pceB8=.c0c6d636-e25e-4122-ac29-002005ea497e@github.com>
Message-ID: <lZN6f1y_FzKzDL_6OMHSVtts1wZ8KG3arHhUhPryxn8=.75d2e626-fb9a-446c-833e-981623cf25c3@github.com>

On Wed, 17 Sep 2025 12:28:03 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> This allows us to pass HAT options and also other properties when running via `java -cp hat/job.jar run ....`
> 
> For example 
> 
>                       run ffi-opencl mandel
>                       run ffi-opencl nbody 4096
>                       run ffi-opencl -DHAT=SHOW_CODE  -DbufferTagging=true nbody 4096
>                       run ffi-opencl -DHAT=SHOW_KERNEL_MODEL heal
>                       run ffi-opencl -DHAT=MINIMIZE_BUFFERS life
>  ```
>  
> Note that configs are initialized from env HAT or from HAT property.  This has always been the case, but has not been documented 
>  
>  So 
>  ```
>    run ffi-opencl -DHAT=SHOW_KERNEL_MODEL heal
>  ```
>  is equiv of 
>  ```
>   HAT=SHOW_KERNEL_MODEL  run ffi-opencl  heal
>   ```

This pull request has now been integrated.

Changeset: d3561b7d
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/d3561b7dec7d2b4bdba24fa1bdead26620e66ce1
Stats:     26 lines in 1 file changed: 14 ins; 8 del; 4 mod

Allow hat.java run to pass -DXXXX options when running

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

PR: https://git.openjdk.org/babylon/pull/574

From gfrost at openjdk.org  Wed Sep 17 12:38:25 2025
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 17 Sep 2025 12:38:25 GMT
Subject: git: openjdk/babylon: code-reflection: Allow hat.java run to pass
 -DXXXX options when running
Message-ID: <31a12bc7-c39d-4013-965b-dcb26bd54da7@openjdk.org>

Changeset: d3561b7d
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2025-09-17 12:32:17 +0000
URL:       https://git.openjdk.org/babylon/commit/d3561b7dec7d2b4bdba24fa1bdead26620e66ce1

Allow hat.java run to pass -DXXXX options when running

! hat/hat.java


From jfumero at openjdk.org  Wed Sep 17 14:16:45 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Wed, 17 Sep 2025 14:16:45 GMT
Subject: [code-reflection] RFR: [hat][proposal] Analysis for constants before
 the codegen
Message-ID: <mRCQLLMizooT62Z4O6YvobgL7hs6_tR8MCrGiphSfGg=.86b28137-44b5-4897-a79f-6279fa5a554e@github.com>

How to test?


HAT=SHOW_CODE java @hat/test ffi-opencl oracle.code.hat.TestConstants


Whole suite:


HAT=SHOW_CODE java @hat/test suite ffi-opencl


Example:


    @CodeReflection
    public static void vectorWithConstants(@RO KernelContext kc, @RO S32Array arrayA, @RO S32Array arrayB, @RW S32Array arrayC) {
        final int BM = 100;
        if (kc.x < kc.gsx) {
            final int valueA = arrayA.array(kc.x);
            final int valueB = arrayB.array(kc.x);
            arrayC.array(kc.x, (BM + valueA + valueB));
        }
    }


Generated code:


__kernel void vectorWithConstants(
    __global KernelContext_t* kc,
    __global S32Array_t* arrayA,
    __global S32Array_t* arrayB,
    __global S32Array_t* arrayC
){
    const int BM = 100;
    if(get_global_id(0)<get_global_size(0)){
        const int valueA = arrayA->array[(long)get_global_id(0)];
        const int valueB = arrayB->array[(long)get_global_id(0)];
        arrayC->array[(long)get_global_id(0)]=BM+valueA+valueB;
    }
    return;
}

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

Commit messages:
 - [hat] Proposal for analysing final values in HAT
 - Revert back
 - Generate constants from final for OpenCL and CUDA

Changes: https://git.openjdk.org/babylon/pull/575/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=575&range=00
  Stats: 140 lines in 7 files changed: 136 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/babylon/pull/575.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/575/head:pull/575

PR: https://git.openjdk.org/babylon/pull/575

From jfumero at openjdk.org  Wed Sep 17 14:26:45 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Wed, 17 Sep 2025 14:26:45 GMT
Subject: [code-reflection] RFR: [hat][proposal] Analysis for constants
 before the codegen [v2]
In-Reply-To: <mRCQLLMizooT62Z4O6YvobgL7hs6_tR8MCrGiphSfGg=.86b28137-44b5-4897-a79f-6279fa5a554e@github.com>
References: <mRCQLLMizooT62Z4O6YvobgL7hs6_tR8MCrGiphSfGg=.86b28137-44b5-4897-a79f-6279fa5a554e@github.com>
Message-ID: <l5JCdABz-ONbIcfy6PtZ68j26-KJSGRRikosOHgG6hI=.973ff880-d145-45ff-bb1f-fadc29c079fd@github.com>

> How to test?
> 
> 
> HAT=SHOW_CODE java @hat/test ffi-opencl oracle.code.hat.TestConstants
> 
> 
> Whole suite:
> 
> 
> HAT=SHOW_CODE java @hat/test suite ffi-opencl
> 
> 
> Example:
> 
> 
>     @CodeReflection
>     public static void vectorWithConstants(@RO KernelContext kc, @RO S32Array arrayA, @RO S32Array arrayB, @RW S32Array arrayC) {
>         final int BM = 100;
>         if (kc.x < kc.gsx) {
>             final int valueA = arrayA.array(kc.x);
>             final int valueB = arrayB.array(kc.x);
>             arrayC.array(kc.x, (BM + valueA + valueB));
>         }
>     }
> 
> 
> Generated code:
> 
> 
> __kernel void vectorWithConstants(
>     __global KernelContext_t* kc,
>     __global S32Array_t* arrayA,
>     __global S32Array_t* arrayB,
>     __global S32Array_t* arrayC
> ){
>     const int BM = 100;
>     if(get_global_id(0)<get_global_size(0)){
>         const int valueA = arrayA->array[(long)get_global_id(0)];
>         const int valueB = arrayB->array[(long)get_global_id(0)];
>         arrayC->array[(long)get_global_id(0)]=BM+valueA+valueB;
>     }
>     return;
> }

Juan Fumero has updated the pull request incrementally with one additional commit since the last revision:

  clean-up

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/575/files
  - new: https://git.openjdk.org/babylon/pull/575/files/9ce4ea2c..d4648792

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=575&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=575&range=00-01

  Stats: 23 lines in 1 file changed: 15 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/babylon/pull/575.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/575/head:pull/575

PR: https://git.openjdk.org/babylon/pull/575

From duke at openjdk.org  Wed Sep 17 15:26:28 2025
From: duke at openjdk.org (duke)
Date: Wed, 17 Sep 2025 15:26:28 GMT
Subject: git: openjdk/babylon: code-reflection: [hat] CUDA backend supported
 for CUDA < 12 (#576)
Message-ID: <a091cc99-ffb4-4757-bd63-690346b95fe0@openjdk.org>

Changeset: 3fc82e5b
Branch: code-reflection
Author:    Juan Fumero <jfumero at openjdk.org>
Committer: GitHub <noreply at github.com>
Date:      2025-09-17 17:20:29 +0000
URL:       https://git.openjdk.org/babylon/commit/3fc82e5b1fa110f26ec712521156f0a47bf9dbb3

[hat] CUDA backend supported for CUDA < 12 (#576)


! hat/backends/ffi/cuda/src/main/native/cpp/cuda_backend.cpp


From psandoz at openjdk.org  Wed Sep 17 17:10:10 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 Sep 2025 17:10:10 GMT
Subject: [code-reflection] RFR: Examples Improved - FMA Dialect refactored
In-Reply-To: <2jRIfDlPK67GZx-tntyoQGuhAUpk2nFkgHbPIVdF3iQ=.6e9696d9-eabd-4b8c-a2f4-6c0a5eafc01a@github.com>
References: <2jRIfDlPK67GZx-tntyoQGuhAUpk2nFkgHbPIVdF3iQ=.6e9696d9-eabd-4b8c-a2f4-6c0a5eafc01a@github.com>
Message-ID: <i5x2tX0eWOe91_eeQwYToLWSwr3W96PgkielTP4M3-k=.cf0aa1d8-c320-4928-8c86-c27b821b6818@github.com>

On Tue, 16 Sep 2025 14:49:34 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> - Examples Improved - FMA Dialect refactored
> - README fixed 
> - Documentation fixed

You can remove the local variable `pending`.

cr-examples/samples/src/main/java/oracle/code/samples/DialectFMAOp.java line 159:

> 157:         CoreOp.FuncOp dialectModel = functionModel.transform((builder, op) -> {
> 158:             CopyContext context = builder.context();
> 159:             if (op instanceof JavaOp.MulOp mulOp && nodesInvolved.contains(mulOp)) {

It might be clearer if you do this:

if (!nodesInvolved.contains(op)) {
    builder.op(op);
} else if (op instanceof JavaOp.MulOp) {
} else if (op instanceof JavaOp.AddOp) {
  // We know at this point the add op is the root of the expression `add(mul(a, b), c)` 
}


It would nice if we could easily accumulate the operand values a, b, c, we need pattern matching. I original thought Value::dependsOn could help, but that is different since it returns a Set since one or more operands could be the same value. We need an easier way to traverse up the tree of the expression e.g. value -> List<value> (represents the operands of an op if value is a result of that op, otherwise empty.)

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

PR Review: https://git.openjdk.org/babylon/pull/570#pullrequestreview-3235430823
PR Review Comment: https://git.openjdk.org/babylon/pull/570#discussion_r2356177455

From psandoz at openjdk.org  Wed Sep 17 18:02:27 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 Sep 2025 18:02:27 GMT
Subject: [code-reflection] RFR: Update compiler tests to use JUnit instead
 of TestNG [v3]
In-Reply-To: <BRNYDioM4-30c2hJGAKVPlkfgNstHBzdBzloYxatJfM=.28337091-1042-4006-899f-b1d7d32ea6ef@github.com>
References: <se3XjVN_6PVn5AXhssc2C1qUn32nhrSyhr7p0RML-68=.f88798a0-e6b2-46a8-971d-9c068757d969@github.com>
 <BRNYDioM4-30c2hJGAKVPlkfgNstHBzdBzloYxatJfM=.28337091-1042-4006-899f-b1d7d32ea6ef@github.com>
Message-ID: <gZ5Yp0mlVrpVscWSNBtls08syTku6yDCsSjQSAuOHmU=.6031213e-06d0-4459-b972-feed4e63fef7@github.com>

On Mon, 15 Sep 2025 22:56:30 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Update compiler tests to use JUnit instead of TestNG.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swap arguments of assertEquals to match JUnit spec.

Marked as reviewed by psandoz (Lead).

test/langtools/tools/javac/reflect/TestLocalCapture.java line 42:

> 40: import org.junit.jupiter.params.provider.MethodSource;
> 41: 
> 42: import java.util.stream.IntStream;

Suggestion: use IntelliJ to reorder your imports.

test/langtools/tools/javac/reflect/TestLocalCapture.java line 69:

> 67: 
> 68:     public static IntStream ints() {
> 69:         return IntStream.range(0, 50);

Nice!

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

PR Review: https://git.openjdk.org/babylon/pull/566#pullrequestreview-3235619860
PR Review Comment: https://git.openjdk.org/babylon/pull/566#discussion_r2356312930
PR Review Comment: https://git.openjdk.org/babylon/pull/566#discussion_r2356313589

From jfumero at openjdk.org  Wed Sep 17 18:07:45 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Wed, 17 Sep 2025 18:07:45 GMT
Subject: [code-reflection] RFR: Examples Improved - FMA Dialect refactored
In-Reply-To: <i5x2tX0eWOe91_eeQwYToLWSwr3W96PgkielTP4M3-k=.cf0aa1d8-c320-4928-8c86-c27b821b6818@github.com>
References: <2jRIfDlPK67GZx-tntyoQGuhAUpk2nFkgHbPIVdF3iQ=.6e9696d9-eabd-4b8c-a2f4-6c0a5eafc01a@github.com>
 <i5x2tX0eWOe91_eeQwYToLWSwr3W96PgkielTP4M3-k=.cf0aa1d8-c320-4928-8c86-c27b821b6818@github.com>
Message-ID: <Ezzq9vsKXqfVRzSM2er4ZzJlqTu1WtixaYd4Y0SVSZI=.ad0c2710-9883-4b14-9f22-d041b0403342@github.com>

On Wed, 17 Sep 2025 17:06:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> - Examples Improved - FMA Dialect refactored
>> - README fixed 
>> - Documentation fixed
>
> cr-examples/samples/src/main/java/oracle/code/samples/DialectFMAOp.java line 159:
> 
>> 157:         CoreOp.FuncOp dialectModel = functionModel.transform((builder, op) -> {
>> 158:             CopyContext context = builder.context();
>> 159:             if (op instanceof JavaOp.MulOp mulOp && nodesInvolved.contains(mulOp)) {
> 
> It might be clearer if you do this:
> 
> if (!nodesInvolved.contains(op)) {
>     builder.op(op);
> } else if (op instanceof JavaOp.MulOp) {
> } else if (op instanceof JavaOp.AddOp) {
>   // We know at this point the add op is the root of the expression `add(mul(a, b), c)` 
> }
> 
> 
> It would nice if we could easily accumulate the operand values a, b, c, we need pattern matching. I original thought Value::dependsOn could help, but that is different since it returns a Set since one or more operands could be the same value. We need an easier way to traverse up the tree of the expression e.g. value -> List<value> (represents the operands of an op if value is a result of that op, otherwise empty.)

Thanks, good point. Yes, I think pattern matching will help here.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/570#discussion_r2356329872

From jfumero at openjdk.org  Wed Sep 17 18:14:40 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Wed, 17 Sep 2025 18:14:40 GMT
Subject: [code-reflection] RFR: Examples Improved - FMA Dialect refactored
 [v2]
In-Reply-To: <2jRIfDlPK67GZx-tntyoQGuhAUpk2nFkgHbPIVdF3iQ=.6e9696d9-eabd-4b8c-a2f4-6c0a5eafc01a@github.com>
References: <2jRIfDlPK67GZx-tntyoQGuhAUpk2nFkgHbPIVdF3iQ=.6e9696d9-eabd-4b8c-a2f4-6c0a5eafc01a@github.com>
Message-ID: <H8TWQpKOUnG-n2XjMAZbxXFNY6KlXz8CXXQ_0KIrgAw=.2cb381be-39af-406f-9eaa-c69b586750c9@github.com>

> - Examples Improved - FMA Dialect refactored
> - README fixed 
> - Documentation fixed

Juan Fumero has updated the pull request incrementally with one additional commit since the last revision:

  [samples] Clean-up

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/570/files
  - new: https://git.openjdk.org/babylon/pull/570/files/3b415a91..db972356

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=570&range=01
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=570&range=00-01

  Stats: 11 lines in 1 file changed: 1 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/babylon/pull/570.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/570/head:pull/570

PR: https://git.openjdk.org/babylon/pull/570

From psandoz at openjdk.org  Wed Sep 17 18:14:40 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 Sep 2025 18:14:40 GMT
Subject: [code-reflection] RFR: Examples Improved - FMA Dialect refactored
 [v2]
In-Reply-To: <H8TWQpKOUnG-n2XjMAZbxXFNY6KlXz8CXXQ_0KIrgAw=.2cb381be-39af-406f-9eaa-c69b586750c9@github.com>
References: <2jRIfDlPK67GZx-tntyoQGuhAUpk2nFkgHbPIVdF3iQ=.6e9696d9-eabd-4b8c-a2f4-6c0a5eafc01a@github.com>
 <H8TWQpKOUnG-n2XjMAZbxXFNY6KlXz8CXXQ_0KIrgAw=.2cb381be-39af-406f-9eaa-c69b586750c9@github.com>
Message-ID: <OR3_P3ySPllzvzY207qviGd_4WthgH4Ex_Lhqi6KEdY=.da83ce2f-5540-4285-ac86-92bf78873f4b@github.com>

On Wed, 17 Sep 2025 18:11:32 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

>> - Examples Improved - FMA Dialect refactored
>> - README fixed 
>> - Documentation fixed
>
> Juan Fumero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [samples] Clean-up

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/570#pullrequestreview-3235656820

From duke at openjdk.org  Wed Sep 17 20:03:08 2025
From: duke at openjdk.org (duke)
Date: Wed, 17 Sep 2025 20:03:08 GMT
Subject: git: openjdk/babylon: code-reflection: Examples Improved - FMA Dialect
 refactored (#570)
Message-ID: <f46f3e43-2cb3-410a-9478-9aa606ceb672@openjdk.org>

Changeset: 0b9a8387
Branch: code-reflection
Author:    Juan Fumero <jfumero at openjdk.org>
Committer: GitHub <noreply at github.com>
Date:      2025-09-17 22:01:54 +0000
URL:       https://git.openjdk.org/babylon/commit/0b9a8387b88e26462aaa93d43ee3e93aebf6ab6c

Examples Improved - FMA Dialect refactored (#570)

* Fix examples README and javadoc

* Refactor FMA Op example to use multiFilter and clean-up

* [samples] Clean-up

! cr-examples/samples/README.md
! cr-examples/samples/src/main/java/oracle/code/samples/DialectFMAOp.java
! cr-examples/samples/src/main/java/oracle/code/samples/DialectWithInvoke.java
! cr-examples/samples/src/main/java/oracle/code/samples/DynamicFunctionBuild.java
! cr-examples/samples/src/main/java/oracle/code/samples/HelloCodeReflection.java
! cr-examples/samples/src/main/java/oracle/code/samples/InlineExample.java
! cr-examples/samples/src/main/java/oracle/code/samples/MathOptimizer.java
! cr-examples/samples/src/main/java/oracle/code/samples/MathOptimizerWithInlining.java


From jfumero at openjdk.org  Wed Sep 17 20:04:41 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Wed, 17 Sep 2025 20:04:41 GMT
Subject: [code-reflection] Withdrawn: Examples Improved - FMA Dialect
 refactored
In-Reply-To: <2jRIfDlPK67GZx-tntyoQGuhAUpk2nFkgHbPIVdF3iQ=.6e9696d9-eabd-4b8c-a2f4-6c0a5eafc01a@github.com>
References: <2jRIfDlPK67GZx-tntyoQGuhAUpk2nFkgHbPIVdF3iQ=.6e9696d9-eabd-4b8c-a2f4-6c0a5eafc01a@github.com>
Message-ID: <s5R3Az6KGsQGVZJZTDueGxht7ifAVVjRWOuRSt7VyqQ=.efdadb59-551d-48fa-9f13-bfe5542b5c8d@github.com>

On Tue, 16 Sep 2025 14:49:34 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> - Examples Improved - FMA Dialect refactored
> - README fixed 
> - Documentation fixed

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/babylon/pull/570

From jfumero at openjdk.org  Thu Sep 18 14:26:45 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Thu, 18 Sep 2025 14:26:45 GMT
Subject: [code-reflection] RFR: Opening Hat Dialect for Handling Barriers and
 Shared/Private Memory
Message-ID: <-mmGLykFSCZpYbVoMA07GH4YWinADKZLc2npKEyTy8M=.e6aac9c2-4bd0-4314-b93e-8497926064ac@github.com>

This patch creates a new dialect for HAT for handling barriers, local (or shared) memory declaration of types, and private memory declariton. It extends the `Op`s provided by code-reflection with a new `HatOp` the dialect.

It is enabled by default. 

TODO: We should move the Hat Config to a common place to be able to use it in the Hat core module, not just in the code gen.

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

Commit messages:
 - minor change
 - Merge branch 'code-reflection' into hat/dialect/ops
 - missing license header added
 - HAT Dialect for declaration of local vars in shared and private memory
 - Merge branch 'code-reflection' into hat/dialect/ops
 - Merge branch 'code-reflection' into hat/dialect/ops
 - Enable 2D conf
 - Cuda Kernel timers disabled
 - fix - cuda events
 - [hat] introduce CUDA timers - just for testing
 - ... and 10 more: https://git.openjdk.org/babylon/compare/0b9a8387...7941306d

Changes: https://git.openjdk.org/babylon/pull/560/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=560&range=00
  Stats: 796 lines in 20 files changed: 679 ins; 78 del; 39 mod
  Patch: https://git.openjdk.org/babylon/pull/560.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/560/head:pull/560

PR: https://git.openjdk.org/babylon/pull/560

From psandoz at openjdk.org  Thu Sep 18 14:26:47 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 18 Sep 2025 14:26:47 GMT
Subject: [code-reflection] RFR: Opening Hat Dialect for Handling Barriers
 and Shared/Private Memory
In-Reply-To: <-mmGLykFSCZpYbVoMA07GH4YWinADKZLc2npKEyTy8M=.e6aac9c2-4bd0-4314-b93e-8497926064ac@github.com>
References: <-mmGLykFSCZpYbVoMA07GH4YWinADKZLc2npKEyTy8M=.e6aac9c2-4bd0-4314-b93e-8497926064ac@github.com>
Message-ID: <4xanuECSL0_GDpq5dNmE5r-OajzUHhoW7_X-ApP2tDo=.299c2c1a-b5f3-40d6-9a0a-a2201daa00f1@github.com>

On Wed, 10 Sep 2025 11:09:18 GMT, Juan Fumero <jfumero at openjdk.org> wrote:

> This patch creates a new dialect for HAT for handling barriers, local (or shared) memory declaration of types, and private memory declariton. It extends the `Op`s provided by code-reflection with a new `HatOp` the dialect.
> 
> It is enabled by default. 
> 
> TODO: We should move the Hat Config to a common place to be able to use it in the Hat core module, not just in the code gen.

hat/core/src/main/java/hat/dialect/HatBarrierOp.java line 60:

> 58:     @Override
> 59:     public TypeElement resultType() {
> 60:         return typeElement;

Suggestion:

        return JavaType.VOID;

hat/core/src/main/java/hat/dialect/HatOP.java line 35:

> 33: import java.util.List;
> 34: 
> 35: public class HatOP extends Op {

Is this intended to be an abstract class that all hat dialect ops extend from? If you you don't need the `typeElement` field and it does not need to implement `transform` nor `resultType`.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/560#discussion_r2337443874
PR Review Comment: https://git.openjdk.org/babylon/pull/560#discussion_r2337450442

From jfumero at openjdk.org  Thu Sep 18 14:26:48 2025
From: jfumero at openjdk.org (Juan Fumero)
Date: Thu, 18 Sep 2025 14:26:48 GMT
Subject: [code-reflection] RFR: Opening Hat Dialect for Handling Barriers
 and Shared/Private Memory
In-Reply-To: <4xanuECSL0_GDpq5dNmE5r-OajzUHhoW7_X-ApP2tDo=.299c2c1a-b5f3-40d6-9a0a-a2201daa00f1@github.com>
References: <-mmGLykFSCZpYbVoMA07GH4YWinADKZLc2npKEyTy8M=.e6aac9c2-4bd0-4314-b93e-8497926064ac@github.com>
 <4xanuECSL0_GDpq5dNmE5r-OajzUHhoW7_X-ApP2tDo=.299c2c1a-b5f3-40d6-9a0a-a2201daa00f1@github.com>
Message-ID: <M59HFrIJWqLqgFCCecexX4VX8rbdrAI9WB2ZoxW_-5U=.dc556af8-aec0-4658-bde7-e30524696d3b@github.com>

On Wed, 10 Sep 2025 17:30:01 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This patch creates a new dialect for HAT for handling barriers, local (or shared) memory declaration of types, and private memory declariton. It extends the `Op`s provided by code-reflection with a new `HatOp` the dialect.
>> 
>> It is enabled by default. 
>> 
>> TODO: We should move the Hat Config to a common place to be able to use it in the Hat core module, not just in the code gen.
>
> hat/core/src/main/java/hat/dialect/HatOP.java line 35:
> 
>> 33: import java.util.List;
>> 34: 
>> 35: public class HatOP extends Op {
> 
> Is this intended to be an abstract class that all hat dialect ops extend from? If you you don't need the `typeElement` field and it does not need to implement `transform` nor `resultType`.

Thanks Paul. Yes, it makes sense.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/560#discussion_r2338566774