From asotona at openjdk.org  Fri Nov  1 07:43:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Nov 2024 07:43:23 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v5]
In-Reply-To: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.734da50c-ae82-423b-829b-9675fd1b64aa@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.734da50c-ae82-423b-829b-9675fd1b64aa@github.com>
Message-ID: <fQhjvL4QnVc90p5u4xmFb-3LK9jegdjLsxakFAKlEb0=.27d732a6-6aec-4ec8-bb1b-3c9d8970f386@github.com>

> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
> 
> Work on `Verifier` revealed bugs in `BytecodeLift`.
> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
> - `SlotOp` is an intermediate model of local variables
> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.

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

 - TestSmallCorpus reached 3rd round 100% stability, no exceptions, no verification errors
 - BytecodeLift fix of followup with unresolved array component types of unknown TypeKind

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/258/files
  - new: https://git.openjdk.org/babylon/pull/258/files/eda4efb0..55d82cc0

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

  Stats: 19 lines in 3 files changed: 13 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/babylon/pull/258.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/258/head:pull/258

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

From asotona at openjdk.org  Fri Nov  1 07:49:49 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Nov 2024 07:49:49 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v5]
In-Reply-To: <fQhjvL4QnVc90p5u4xmFb-3LK9jegdjLsxakFAKlEb0=.27d732a6-6aec-4ec8-bb1b-3c9d8970f386@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.734da50c-ae82-423b-829b-9675fd1b64aa@github.com>
 <fQhjvL4QnVc90p5u4xmFb-3LK9jegdjLsxakFAKlEb0=.27d732a6-6aec-4ec8-bb1b-3c9d8970f386@github.com>
Message-ID: <j0YICtaD4GV2KNj88nSsgRsBZ11cwMg0CNdiTN7hqYI=.2fe5ea80-87aa-4148-8c82-87c9d55ee396@github.com>

On Fri, 1 Nov 2024 07:43:23 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
>> 
>> Work on `Verifier` revealed bugs in `BytecodeLift`.
>> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
>> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
>> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
>> - `SlotOp` is an intermediate model of local variables
>> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
>> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - TestSmallCorpus reached 3rd round 100% stability, no exceptions, no verification errors
>  - BytecodeLift fix of followup with unresolved array component types of unknown TypeKind

TestSmallCorpus just reached 3rd round 100% stability, with no exceptions and no verification errors.

I highly recommend to switch to this decomposed model of BytecodeLift as a new base for the follow-up work.

Thanks,
Adam

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

PR Comment: https://git.openjdk.org/babylon/pull/258#issuecomment-2451451615

From psandoz at openjdk.org  Mon Nov  4 20:49:54 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 4 Nov 2024 20:49:54 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend
In-Reply-To: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
Message-ID: <cY4a7p9cOl1zOtTWwHjioeEjOTS2LA3UvxoJjwo_q1c=.b398befc-606b-4351-b8c3-35f19c8708b7@github.com>

On Wed, 25 Sep 2024 15:32:53 GMT, hanklo6 <duke at openjdk.org> wrote:

> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>  
> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
> 
> ## Usage
> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
> 
> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
> 
> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
> 
> To create a binding for Level Zero, execute the below commands:
> 
> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
> 
> The will generate `levelzero.jar` in the current directory.
> 
> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
> 
> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
> 
> 
> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
> 
> ## Dependencies
> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
> - [Jextract](https://github.com/openjdk/jextract)
> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
> - [JSON-java](https://github.com/stleary/JSON-java)

Keep alive

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

PR Comment: https://git.openjdk.org/babylon/pull/241#issuecomment-2455670228

From mcimadamore at openjdk.org  Tue Nov  5 16:22:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 5 Nov 2024 16:22:44 GMT
Subject: [code-reflection] RFR: Simplify Interpreter invocation
In-Reply-To: <Unhv90vahDyiHyCRU7f7XaMlSf94JmH_398DRMNt-kc=.d5690fd5-af65-466a-ab1c-415457bb0b8e@github.com>
References: <Unhv90vahDyiHyCRU7f7XaMlSf94JmH_398DRMNt-kc=.d5690fd5-af65-466a-ab1c-415457bb0b8e@github.com>
Message-ID: <-jxIVK3311JEOVdZyR6sOxXsUoYmGmc11gzqzEadzkA=.f4add2cc-9497-440d-980c-abef477122f4@github.com>

On Thu, 31 Oct 2024 23:54:16 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The overloaded `Interpreter.invoke` methods are reduced to just two methods. If the invokeable operation captures values then corresponding captured arguments must be appended, in order, to the list of arguments for invocation (those correspond to the invokeable operation's parameter, in order).

Requiring regular params followed by captured params seems like a good simplifying move. Thanks.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/babylon/pull/271#pullrequestreview-2416112442

From psandoz at openjdk.org  Tue Nov  5 17:31:55 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 5 Nov 2024 17:31:55 GMT
Subject: git: openjdk/babylon: code-reflection: Simplify Interpreter invocation
Message-ID: <1c7c7fd6-cc2e-4c92-a96a-d7b65026c7c7@openjdk.org>

Changeset: a40e0f2a
Branch: code-reflection
Author:    Paul Sandoz <psandoz at openjdk.org>
Date:      2024-11-05 17:30:34 +0000
URL:       https://git.openjdk.org/babylon/commit/a40e0f2aabcc90e34f9a2672adc2a369b4ec4415

Simplify Interpreter invocation

Reviewed-by: mcimadamore

! hat/examples/experiments/src/main/java/experiments/PrePostInc.java
! src/java.base/share/classes/java/lang/reflect/code/Quoted.java
! src/java.base/share/classes/java/lang/reflect/code/interpreter/Interpreter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java
! test/jdk/java/lang/reflect/code/TestArrayCreation.java
! test/jdk/java/lang/reflect/code/TestArrayTypes.java
! test/jdk/java/lang/reflect/code/TestBinops.java
! test/jdk/java/lang/reflect/code/TestBlockOp.java
! test/jdk/java/lang/reflect/code/TestBreakContinue.java
! test/jdk/java/lang/reflect/code/TestClosureOps.java
! test/jdk/java/lang/reflect/code/TestConditionalExpression.java
! test/jdk/java/lang/reflect/code/TestConstants.java
! test/jdk/java/lang/reflect/code/TestEnhancedForOp.java
! test/jdk/java/lang/reflect/code/TestForOp.java
! test/jdk/java/lang/reflect/code/TestIfOp.java
! test/jdk/java/lang/reflect/code/TestLambdaOps.java
! test/jdk/java/lang/reflect/code/TestPrimitiveTypePatterns.java
! test/jdk/java/lang/reflect/code/TestRemoveFinalVars.java
! test/jdk/java/lang/reflect/code/TestSSA.java
! test/jdk/java/lang/reflect/code/TestStringConcatTransform.java
! test/jdk/java/lang/reflect/code/TestSwitchExpressionOp.java
! test/jdk/java/lang/reflect/code/TestSwitchStatementOp.java
! test/jdk/java/lang/reflect/code/TestTransitiveInvokeModule.java
! test/jdk/java/lang/reflect/code/TestUninitializedVariable.java
! test/jdk/java/lang/reflect/code/TestWhileOp.java
! test/jdk/java/lang/reflect/code/ad/TestForwardAutoDiff.java
! test/jdk/java/lang/reflect/code/bytecode/TestLiftCustomBytecode.java
! test/jdk/java/lang/reflect/code/expression/TestExpressionElimination.java
! test/jdk/java/lang/reflect/code/stream/TestStream.java
! test/jdk/java/lang/reflect/code/stream/TestStreamUsingQuotable.java
! test/langtools/tools/javac/reflect/quoted/TestCaptureQuotable.java
! test/langtools/tools/javac/reflect/quoted/TestCaptureQuoted.java


From psandoz at openjdk.org  Tue Nov  5 17:33:42 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 5 Nov 2024 17:33:42 GMT
Subject: [code-reflection] Integrated: Simplify Interpreter invocation
In-Reply-To: <Unhv90vahDyiHyCRU7f7XaMlSf94JmH_398DRMNt-kc=.d5690fd5-af65-466a-ab1c-415457bb0b8e@github.com>
References: <Unhv90vahDyiHyCRU7f7XaMlSf94JmH_398DRMNt-kc=.d5690fd5-af65-466a-ab1c-415457bb0b8e@github.com>
Message-ID: <8h4lknA0MRb1NgIagO1QyF9dOj0bK4W3rub5c7SYWlc=.70392fd2-890d-470a-bd80-e98fb544cdbe@github.com>

On Thu, 31 Oct 2024 23:54:16 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The overloaded `Interpreter.invoke` methods are reduced to just two methods. If the invokeable operation captures values then corresponding captured arguments must be appended, in order, to the list of arguments for invocation (those correspond to the invokeable operation's parameter, in order).

This pull request has now been integrated.

Changeset: a40e0f2a
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/a40e0f2aabcc90e34f9a2672adc2a369b4ec4415
Stats:     419 lines in 33 files changed: 153 ins; 68 del; 198 mod

Simplify Interpreter invocation

Reviewed-by: mcimadamore

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

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

From psandoz at openjdk.org  Tue Nov  5 19:27:44 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 5 Nov 2024 19:27:44 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v5]
In-Reply-To: <fQhjvL4QnVc90p5u4xmFb-3LK9jegdjLsxakFAKlEb0=.27d732a6-6aec-4ec8-bb1b-3c9d8970f386@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.734da50c-ae82-423b-829b-9675fd1b64aa@github.com>
 <fQhjvL4QnVc90p5u4xmFb-3LK9jegdjLsxakFAKlEb0=.27d732a6-6aec-4ec8-bb1b-3c9d8970f386@github.com>
Message-ID: <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.62065165-48b3-4ed7-8cdc-ef666509e549@github.com>

On Fri, 1 Nov 2024 07:43:23 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
>> 
>> Work on `Verifier` revealed bugs in `BytecodeLift`.
>> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
>> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
>> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
>> - `SlotOp` is an intermediate model of local variables
>> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
>> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - TestSmallCorpus reached 3rd round 100% stability, no exceptions, no verification errors
>  - BytecodeLift fix of followup with unresolved array component types of unknown TypeKind

The general approach to layering the lifting looks good. Just a few comments, mostly related to the impact outside of the bytecode package.

src/java.base/share/classes/java/lang/reflect/code/TypeElement.java line 114:

> 112:     ExternalizedTypeElement externalize();
> 113: 
> 114:     default TypeElement componentType() {

I think it would be better to introduce new interface e.g., `TypeWithComponent` then we can test or pattern match on that.

src/java.base/share/classes/java/lang/reflect/code/Value.java line 152:

> 150:      * @throws IllegalStateException if the declaring block is partially built
> 151:      */
> 152:     public boolean isDominatedBy(Set<? extends Value> doms) {

It would be better for now to move this method back into the bytecode area as non-public. Currently it's too specialized and not-well defined.

>From reading the specification one might expect it to return true if this value is dominated be all given values. But, it returns true if any given value does. If none dominate then it checks if there is path back from this value's block to the entry block of the same parent body. That is not directly related to dominance, but related dominance frontiers which is a different concept. Returning true in the second cases doe not mean dominance.

src/java.base/share/classes/java/lang/reflect/code/bytecode/UnresolvedType.java line 51:

> 49:         private static final TypeElement.ExternalizedTypeElement UNRESOLVED_REF = new TypeElement.ExternalizedTypeElement("?REF", List.of());
> 50: 
> 51:         private JavaType resolved;

Sneaky mutability :-) Not something i would recommend although i understand the convenience. You could instead use a map of unresolved type to resolved type. But let's consider that later as i think there is a broader issue. More generally the transformation of types is harder than it should be, and this is a good use case to help improve this area. I don't have any solid ideas right now but hopefully we can eventually come up with something better.

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

PR Review: https://git.openjdk.org/babylon/pull/258#pullrequestreview-2416328120
PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1829777860
PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1829798524
PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1829891446

From psandoz at openjdk.org  Tue Nov  5 22:51:45 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 5 Nov 2024 22:51:45 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend
In-Reply-To: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
Message-ID: <pMFaNC7FdA5hZXkEXwFWjiz5sT-3t6-gMMAV_DwRNUk=.2c2c8bfd-47a4-4555-8bc0-281f7fc4a55b@github.com>

On Wed, 25 Sep 2024 15:32:53 GMT, hanklo6 <duke at openjdk.org> wrote:

> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>  
> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
> 
> ## Usage
> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
> 
> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
> 
> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
> 
> To create a binding for Level Zero, execute the below commands:
> 
> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
> 
> The will generate `levelzero.jar` in the current directory.
> 
> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
> 
> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
> 
> 
> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
> 
> ## Dependencies
> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
> - [Jextract](https://github.com/openjdk/jextract)
> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
> - [JSON-java](https://github.com/stleary/JSON-java)

Thank you for this effort. It's not easy to hook this up and you did it without any help!

Initially i have just focused on the code in the triton package.

cr-examples/triton/src/main/java/oracle/code/triton/ArithMathOps.java line 398:

> 396:     public static class CompareOp extends ArithMathOp implements Op.Pure {
> 397:         public static final String NAME = "arith.cmp";
> 398:         public static final String ATTRIBUTE_CONSTANT_VALUE = "predicate";

Suggestion:

        public static final String ATTRIBUTE_PREDICATE = "predicate";

cr-examples/triton/src/main/java/oracle/code/triton/ArithMathOps.java line 401:

> 399: 
> 400:         public enum CompareKind {
> 401:             eq,

Can you link to https://mlir.llvm.org/docs/Dialects/ArithOps/#cmpipredicate ? and also state in the comment the enum ordinal corresponds to the MLIR symbol's value. Further comment that we would need to refine when considering comparisons of floating point numbers which is in a different namespace.

cr-examples/triton/src/main/java/oracle/code/triton/TritonTransformer.java line 1054:

> 1052:             a = block.context().getValue(a);
> 1053:             b = block.context().getValue(b);
> 1054:             Object zero;

Add a comment such as

// Computed result is tensor of floats, regardless of inputs

like when we compute the type. Since the result is hard coded we don't need to use reflection and can directly use the constant expression "0.0".

cr-examples/triton/src/test/java/oracle/code/triton/TestMatrix.java line 264:

> 262:                     LessThan);
> 263:             var b = load(b_ptrs, broadcast(offs_k_m_3, b_ptrs.type()));
> 264:             // We accumulate along the K dimension.

Were these necessary changes because you encountered a bug?

cr-examples/triton/src/test/java/oracle/code/triton/TestMatrix.java line 471:

> 469:             int stride_am, @Constant int stride_ak,
> 470:             int stride_bk, @Constant int stride_bn,
> 471:             int stride_cm, @Constant int stride_cn,

Why the marking as constants?

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

PR Review: https://git.openjdk.org/babylon/pull/241#pullrequestreview-2416747104
PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1830036689
PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1830035724
PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1830100308
PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1830086221
PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1830095437

From mabbay at openjdk.org  Wed Nov  6 10:48:59 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 6 Nov 2024 10:48:59 GMT
Subject: [code-reflection] RFR: Support bytecode generation for invocation of
 varArg method
Message-ID: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>

Support bytecode generation for invocation of varArg method.

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

Commit messages:
 - Support bytecode generation for invocation of varArg method

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

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

From asotona at openjdk.org  Wed Nov  6 11:24:12 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 11:24:12 GMT
Subject: [code-reflection] RFR: Support bytecode generation for invocation
 of varArg method
In-Reply-To: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
References: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
Message-ID: <IMUwzHcG-mrDZCvkpheHhD2Xr4mXYFHxc0QkhV9F98k=.d69ac42e-3089-4653-94f8-67479c53b8e5@github.com>

On Wed, 6 Nov 2024 10:43:58 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Support bytecode generation for invocation of varArg method.

src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 365:

> 363:         } else {
> 364:             processOperands(op.operands());
> 365:         }

There are 19 calls of this helper method and only one is related to InvokeOp operands.
I would suggest to apply this logic where InvokeOp bytecode is generated.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/272#discussion_r1830849765

From asotona at openjdk.org  Wed Nov  6 11:44:42 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 11:44:42 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v5]
In-Reply-To: <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.62065165-48b3-4ed7-8cdc-ef666509e549@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.734da50c-ae82-423b-829b-9675fd1b64aa@github.com>
 <fQhjvL4QnVc90p5u4xmFb-3LK9jegdjLsxakFAKlEb0=.27d732a6-6aec-4ec8-bb1b-3c9d8970f386@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.62065165-48b3-4ed7-8cdc-ef666509e549@github.com>
Message-ID: <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.76773dd7-84cd-4470-8ed1-8d98f424d025@github.com>

On Tue, 5 Nov 2024 18:04:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - TestSmallCorpus reached 3rd round 100% stability, no exceptions, no verification errors
>>  - BytecodeLift fix of followup with unresolved array component types of unknown TypeKind
>
> src/java.base/share/classes/java/lang/reflect/code/Value.java line 152:
> 
>> 150:      * @throws IllegalStateException if the declaring block is partially built
>> 151:      */
>> 152:     public boolean isDominatedBy(Set<? extends Value> doms) {
> 
> It would be better for now to move this method back into the bytecode area as non-public. Currently it's too specialized and not-well defined.
> 
> From reading the specification one might expect it to return true if this value is dominated be all given values. But, it returns true if any given value does. If none dominate then it checks if there is path back from this value's block to the entry block of the same parent body. That is not directly related to dominance, but related dominance frontiers which is a different concept. Returning true in the second cases doe not mean dominance.

This method tests if the given set of values represent a dominating set for the actual value. I hope the implementation matches the "Dominating sets in directed graphs" definition.

I've moved it here because there are already two uses of the method:
- BytecodeGenerator::isDefinitelyAssigned needs to test for the dominance of VarStoreOps set to decide if the VarOp can be deferred 
- SlotToVarTransformer::isDominatedByTheSameVar needs to test dominance of set of SlotOp predecessors to identify initial SlotStoreOps.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1830876466

From asotona at openjdk.org  Wed Nov  6 11:57:42 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 11:57:42 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v5]
In-Reply-To: <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.62065165-48b3-4ed7-8cdc-ef666509e549@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.734da50c-ae82-423b-829b-9675fd1b64aa@github.com>
 <fQhjvL4QnVc90p5u4xmFb-3LK9jegdjLsxakFAKlEb0=.27d732a6-6aec-4ec8-bb1b-3c9d8970f386@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.62065165-48b3-4ed7-8cdc-ef666509e549@github.com>
Message-ID: <ezYMcNRGz5j7RsNNXiVjf1Gi0UqXZzauCl-dOztqvV4=.2bf41ff1-80c2-4f5c-ac71-9d51e8093e2a@github.com>

On Tue, 5 Nov 2024 19:24:05 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - TestSmallCorpus reached 3rd round 100% stability, no exceptions, no verification errors
>>  - BytecodeLift fix of followup with unresolved array component types of unknown TypeKind
>
> src/java.base/share/classes/java/lang/reflect/code/bytecode/UnresolvedType.java line 51:
> 
>> 49:         private static final TypeElement.ExternalizedTypeElement UNRESOLVED_REF = new TypeElement.ExternalizedTypeElement("?REF", List.of());
>> 50: 
>> 51:         private JavaType resolved;
> 
> Sneaky mutability :-) Not something i would recommend although i understand the convenience. You could instead use a map of unresolved type to resolved type. But let's consider that later as i think there is a broader issue. More generally the transformation of types is harder than it should be, and this is a good use case to help improve this area. I don't have any solid ideas right now but hopefully we can eventually come up with something better.

Yes, this is not ideal. Maps can be used later in the transform, however unresolved component of an unresolved array type is something that needs to be at least partially resolved (2-slot long or double vs 1-slot others) in the first stage of BytecodeLift or it causes stack problems with hybrid single and dual slot instructions (dup_x2, dup2, dup2_x1 and dup2_x2).
I'll definitelly look for better solution.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1830893450

From asotona at openjdk.org  Wed Nov  6 12:09:45 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 12:09:45 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v5]
In-Reply-To: <ezYMcNRGz5j7RsNNXiVjf1Gi0UqXZzauCl-dOztqvV4=.2bf41ff1-80c2-4f5c-ac71-9d51e8093e2a@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.734da50c-ae82-423b-829b-9675fd1b64aa@github.com>
 <fQhjvL4QnVc90p5u4xmFb-3LK9jegdjLsxakFAKlEb0=.27d732a6-6aec-4ec8-bb1b-3c9d8970f386@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.62065165-48b3-4ed7-8cdc-ef666509e549@github.com>
 <ezYMcNRGz5j7RsNNXiVjf1Gi0UqXZzauCl-dOztqvV4=.2bf41ff1-80c2-4f5c-ac71-9d51e8093e2a@github.com>
Message-ID: <NTT4kUkyvSnXjqDFhL7JPMYHwQwqKrJwMfHF2pz8fP0=.63749210-3031-465a-9c1f-079bf86a1942@github.com>

On Wed, 6 Nov 2024 11:55:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/bytecode/UnresolvedType.java line 51:
>> 
>>> 49:         private static final TypeElement.ExternalizedTypeElement UNRESOLVED_REF = new TypeElement.ExternalizedTypeElement("?REF", List.of());
>>> 50: 
>>> 51:         private JavaType resolved;
>> 
>> Sneaky mutability :-) Not something i would recommend although i understand the convenience. You could instead use a map of unresolved type to resolved type. But let's consider that later as i think there is a broader issue. More generally the transformation of types is harder than it should be, and this is a good use case to help improve this area. I don't have any solid ideas right now but hopefully we can eventually come up with something better.
>
> Yes, this is not ideal. Maps can be used later in the transform, however unresolved component of an unresolved array type is something that needs to be at least partially resolved (2-slot long or double vs 1-slot others) in the first stage of BytecodeLift or it causes stack problems with hybrid single and dual slot instructions (dup_x2, dup2, dup2_x1 and dup2_x2). The problem here is that I cannot retrospectively change types in the middle of a lift process. 
> 
> I'll definitelly look for better solution.

Maybe I can inject an explicit ConvOp after ArrayLoadOp result of an unresolved type, however it will generate an instability. Or custom ResolveTypeOp, which can be later removed by a transform.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1830907904

From asotona at openjdk.org  Wed Nov  6 12:25:04 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 12:25:04 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and BytecodeLift
 deconstruction
Message-ID: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>

This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.

Work on `Verifier` revealed bugs in `BytecodeLift`.
Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
- `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
- `SlotOp` is an intermediate model of local variables
- `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
- `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.

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

Commit messages:
 - Introduction of TypeWithComponent
 - TestSmallCorpus reached 3rd round 100% stability, no exceptions, no verification errors
 - BytecodeLift fix of followup with unresolved array component types of unknown TypeKind
 - fixed BytecodeLift exception handlers order of nested blocks
 - adjustments to suport unitialized variables
 - TestSmallCorpus update
 - Merge remote-tracking branch 'babylon/code-reflection' into split-lifter
 - BytecodeLift fixed exception region transits
 - BytecodeLift better dealing with exception regions transitions - work in progress
 - BytecodeLift::targetBlockForExceptionHandler work in progress
 - ... and 61 more: https://git.openjdk.org/babylon/compare/fa4dd443...6591d7d8

Changes: https://git.openjdk.org/babylon/pull/258/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=258&range=00
  Stats: 3001 lines in 16 files changed: 1598 ins; 1183 del; 220 mod
  Patch: https://git.openjdk.org/babylon/pull/258.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/258/head:pull/258

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

From psandoz at openjdk.org  Wed Nov  6 12:25:04 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 6 Nov 2024 12:25:04 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction
In-Reply-To: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
Message-ID: <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.71c7ffbc-833e-432e-af34-978c866c7cf0@github.com>

On Fri, 18 Oct 2024 10:06:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
> 
> Work on `Verifier` revealed bugs in `BytecodeLift`.
> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
> - `SlotOp` is an intermediate model of local variables
> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.

The general approach to layering the lifting looks good. Just a few comments, mostly related to the impact outside of the bytecode package.

src/java.base/share/classes/java/lang/reflect/code/TypeElement.java line 114:

> 112:     ExternalizedTypeElement externalize();
> 113: 
> 114:     default TypeElement componentType() {

I think it would be better to introduce new interface e.g., `TypeWithComponent` then we can test or pattern match on that.

src/java.base/share/classes/java/lang/reflect/code/Value.java line 152:

> 150:      * @throws IllegalStateException if the declaring block is partially built
> 151:      */
> 152:     public boolean isDominatedBy(Set<? extends Value> doms) {

It would be better for now to move this method back into the bytecode area as non-public. Currently it's too specialized and not-well defined.

>From reading the specification one might expect it to return true if this value is dominated be all given values. But, it returns true if any given value does. If none dominate then it checks if there is path back from this value's block to the entry block of the same parent body. That is not directly related to dominance, but related dominance frontiers which is a different concept. Returning true in the second cases doe not mean dominance.

src/java.base/share/classes/java/lang/reflect/code/bytecode/UnresolvedType.java line 51:

> 49:         private static final TypeElement.ExternalizedTypeElement UNRESOLVED_REF = new TypeElement.ExternalizedTypeElement("?REF", List.of());
> 50: 
> 51:         private JavaType resolved;

Sneaky mutability :-) Not something i would recommend although i understand the convenience. You could instead use a map of unresolved type to resolved type. But let's consider that later as i think there is a broader issue. More generally the transformation of types is harder than it should be, and this is a good use case to help improve this area. I don't have any solid ideas right now but hopefully we can eventually come up with something better.

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

PR Review: https://git.openjdk.org/babylon/pull/258#pullrequestreview-2416328120
PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1829777860
PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1829798524
PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1829891446

From asotona at openjdk.org  Wed Nov  6 12:25:05 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 12:25:05 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction
In-Reply-To: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
Message-ID: <ySA8B1k0GhnxNeFB3MrlyOLF0CEyFo_Ir9hp62lfayk=.26d6c3d1-9c95-4f72-81c6-5fd6c53693f9@github.com>

On Fri, 18 Oct 2024 10:06:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
> 
> Work on `Verifier` revealed bugs in `BytecodeLift`.
> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
> - `SlotOp` is an intermediate model of local variables
> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.

This is not final state of the `BytecodeLift` conversion nor `Verifier` implementation.
`TestSmallCorpus` actually pass first round without errors, however second round indicates verification errors related to exception regions on the lifted model (Verifier newly checks exception region stack of the model).

Please review proposed changes.

Thanks,
Adam

TestSmallCorpus just reached 3rd round 100% stability, with no exceptions and no verification errors.

I highly recommend to switch to this decomposed model of BytecodeLift as a new base for the follow-up work.

Thanks,
Adam

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

PR Comment: https://git.openjdk.org/babylon/pull/258#issuecomment-2450165187
PR Comment: https://git.openjdk.org/babylon/pull/258#issuecomment-2451451615

From asotona at openjdk.org  Wed Nov  6 12:25:05 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 12:25:05 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction
In-Reply-To: <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.71c7ffbc-833e-432e-af34-978c866c7cf0@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.71c7ffbc-833e-432e-af34-978c866c7cf0@github.com>
Message-ID: <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.a9b9b6e2-9a23-4edf-9d93-518047a09655@github.com>

On Tue, 5 Nov 2024 18:04:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
>> 
>> Work on `Verifier` revealed bugs in `BytecodeLift`.
>> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
>> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
>> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
>> - `SlotOp` is an intermediate model of local variables
>> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
>> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.
>
> src/java.base/share/classes/java/lang/reflect/code/Value.java line 152:
> 
>> 150:      * @throws IllegalStateException if the declaring block is partially built
>> 151:      */
>> 152:     public boolean isDominatedBy(Set<? extends Value> doms) {
> 
> It would be better for now to move this method back into the bytecode area as non-public. Currently it's too specialized and not-well defined.
> 
> From reading the specification one might expect it to return true if this value is dominated be all given values. But, it returns true if any given value does. If none dominate then it checks if there is path back from this value's block to the entry block of the same parent body. That is not directly related to dominance, but related dominance frontiers which is a different concept. Returning true in the second cases doe not mean dominance.

This method tests if the given set of values represent a dominating set for the actual value. I hope the implementation matches the "Dominating sets in directed graphs" definition.

I've moved it here because there are already two uses of the method:
- BytecodeGenerator::isDefinitelyAssigned needs to test for the dominance of VarStoreOps set to decide if the VarOp can be deferred 
- SlotToVarTransformer::isDominatedByTheSameVar needs to test dominance of set of SlotOp predecessors to identify initial SlotStoreOps.

> src/java.base/share/classes/java/lang/reflect/code/bytecode/UnresolvedType.java line 51:
> 
>> 49:         private static final TypeElement.ExternalizedTypeElement UNRESOLVED_REF = new TypeElement.ExternalizedTypeElement("?REF", List.of());
>> 50: 
>> 51:         private JavaType resolved;
> 
> Sneaky mutability :-) Not something i would recommend although i understand the convenience. You could instead use a map of unresolved type to resolved type. But let's consider that later as i think there is a broader issue. More generally the transformation of types is harder than it should be, and this is a good use case to help improve this area. I don't have any solid ideas right now but hopefully we can eventually come up with something better.

Yes, this is not ideal. Maps can be used later in the transform, however unresolved component of an unresolved array type is something that needs to be at least partially resolved (2-slot long or double vs 1-slot others) in the first stage of BytecodeLift or it causes stack problems with hybrid single and dual slot instructions (dup_x2, dup2, dup2_x1 and dup2_x2). The problem here is that I cannot retrospectively change types in the middle of a lift process. 

I'll definitelly look for better solution.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1830876466
PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1830893450

From asotona at openjdk.org  Wed Nov  6 12:25:05 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 12:25:05 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction
In-Reply-To: <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.a9b9b6e2-9a23-4edf-9d93-518047a09655@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.71c7ffbc-833e-432e-af34-978c866c7cf0@github.com>
 <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.a9b9b6e2-9a23-4edf-9d93-518047a09655@github.com>
Message-ID: <NTT4kUkyvSnXjqDFhL7JPMYHwQwqKrJwMfHF2pz8fP0=.66b48a22-833d-4880-b0d2-e91974e80c83@github.com>

On Wed, 6 Nov 2024 11:55:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/bytecode/UnresolvedType.java line 51:
>> 
>>> 49:         private static final TypeElement.ExternalizedTypeElement UNRESOLVED_REF = new TypeElement.ExternalizedTypeElement("?REF", List.of());
>>> 50: 
>>> 51:         private JavaType resolved;
>> 
>> Sneaky mutability :-) Not something i would recommend although i understand the convenience. You could instead use a map of unresolved type to resolved type. But let's consider that later as i think there is a broader issue. More generally the transformation of types is harder than it should be, and this is a good use case to help improve this area. I don't have any solid ideas right now but hopefully we can eventually come up with something better.
>
> Yes, this is not ideal. Maps can be used later in the transform, however unresolved component of an unresolved array type is something that needs to be at least partially resolved (2-slot long or double vs 1-slot others) in the first stage of BytecodeLift or it causes stack problems with hybrid single and dual slot instructions (dup_x2, dup2, dup2_x1 and dup2_x2). The problem here is that I cannot retrospectively change types in the middle of a lift process. 
> 
> I'll definitelly look for better solution.

Maybe I can inject an explicit ConvOp after ArrayLoadOp result of an unresolved type, however it will generate an instability. Or custom ResolveTypeOp, which can be later removed by a transform.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1830907904

From asotona at openjdk.org  Wed Nov  6 13:14:04 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 13:14:04 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v2]
In-Reply-To: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
Message-ID: <C9Uf3USouPZHA3U9sMwmWVLHSRLby0AB51fUblC_kVs=.212177ba-018d-4aa9-a51d-1712e2fa3051@github.com>

> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
> 
> Work on `Verifier` revealed bugs in `BytecodeLift`.
> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
> - `SlotOp` is an intermediate model of local variables
> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.

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

  added javadoc to Value::isDominatedBy(Set<Value>)

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/258/files
  - new: https://git.openjdk.org/babylon/pull/258/files/6591d7d8..fc178e72

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

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

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

From duke at openjdk.org  Wed Nov  6 15:49:45 2024
From: duke at openjdk.org (hanklo6)
Date: Wed, 6 Nov 2024 15:49:45 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend
In-Reply-To: <pMFaNC7FdA5hZXkEXwFWjiz5sT-3t6-gMMAV_DwRNUk=.2c2c8bfd-47a4-4555-8bc0-281f7fc4a55b@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
 <pMFaNC7FdA5hZXkEXwFWjiz5sT-3t6-gMMAV_DwRNUk=.2c2c8bfd-47a4-4555-8bc0-281f7fc4a55b@github.com>
Message-ID: <EWsZy-DeOtyr6y2vW6mkubILO7gAqJ1RLM5oVLKTQBQ=.adadf1c9-bbee-4ba6-a8ef-0fa28deed090@github.com>

On Tue, 5 Nov 2024 22:33:02 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>>  
>> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
>> 
>> ## Usage
>> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
>> 
>> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
>> 
>> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
>> 
>> To create a binding for Level Zero, execute the below commands:
>> 
>> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
>> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
>> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
>> 
>> The will generate `levelzero.jar` in the current directory.
>> 
>> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
>> 
>> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
>> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
>> 
>> 
>> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
>> 
>> ## Dependencies
>> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
>> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
>> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
>> - [Jextract](https://github.com/openjdk/jextract)
>> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
>> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
>> - [JSON-java](https://github.com/stleary/JSON-java)
>
> cr-examples/triton/src/test/java/oracle/code/triton/TestMatrix.java line 264:
> 
>> 262:                     LessThan);
>> 263:             var b = load(b_ptrs, broadcast(offs_k_m_3, b_ptrs.type()));
>> 264:             // We accumulate along the K dimension.
> 
> Were these necessary changes because you encountered a bug?

Because I changed the return type of the `compare` function to `boolean`, It can't match the return type of the `expand` function.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1831274958

From duke at openjdk.org  Wed Nov  6 15:56:48 2024
From: duke at openjdk.org (hanklo6)
Date: Wed, 6 Nov 2024 15:56:48 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend
In-Reply-To: <pMFaNC7FdA5hZXkEXwFWjiz5sT-3t6-gMMAV_DwRNUk=.2c2c8bfd-47a4-4555-8bc0-281f7fc4a55b@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
 <pMFaNC7FdA5hZXkEXwFWjiz5sT-3t6-gMMAV_DwRNUk=.2c2c8bfd-47a4-4555-8bc0-281f7fc4a55b@github.com>
Message-ID: <oAE02NhCWEDfo9kovcY3MrH0RhQkfRseSpSvL7L3rZE=.afe66f50-4e60-4c12-9da6-c34bd9a28d55@github.com>

On Tue, 5 Nov 2024 22:41:38 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>>  
>> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
>> 
>> ## Usage
>> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
>> 
>> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
>> 
>> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
>> 
>> To create a binding for Level Zero, execute the below commands:
>> 
>> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
>> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
>> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
>> 
>> The will generate `levelzero.jar` in the current directory.
>> 
>> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
>> 
>> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
>> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
>> 
>> 
>> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
>> 
>> ## Dependencies
>> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
>> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
>> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
>> - [Jextract](https://github.com/openjdk/jextract)
>> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
>> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
>> - [JSON-java](https://github.com/stleary/JSON-java)
>
> cr-examples/triton/src/test/java/oracle/code/triton/TestMatrix.java line 471:
> 
>> 469:             int stride_am, @Constant int stride_ak,
>> 470:             int stride_bk, @Constant int stride_bn,
>> 471:             int stride_cm, @Constant int stride_cn,
> 
> Why the marking as constants?

Triton will mark these three stride values as constants if they are equal to one at compile time. We mark them as constants directly as our code is not compiled by Triton.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1831286987

From duke at openjdk.org  Wed Nov  6 16:14:21 2024
From: duke at openjdk.org (hanklo6)
Date: Wed, 6 Nov 2024 16:14:21 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v2]
In-Reply-To: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
Message-ID: <2x0fH2IeYnAdUvJ9lQlMeDQF8zORQlpIaHpvhP2vGTs=.0787bd20-a5d7-4561-a5d6-1ccb6c2583c3@github.com>

> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>  
> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
> 
> ## Usage
> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
> 
> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
> 
> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
> 
> To create a binding for Level Zero, execute the below commands:
> 
> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
> 
> The will generate `levelzero.jar` in the current directory.
> 
> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
> 
> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
> 
> 
> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
> 
> ## Dependencies
> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
> - [Jextract](https://github.com/openjdk/jextract)
> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
> - [JSON-java](https://github.com/stleary/JSON-java)

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

  Add comments

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/241/files
  - new: https://git.openjdk.org/babylon/pull/241/files/79696b4e..2dbe2df9

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

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

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

From duke at openjdk.org  Wed Nov  6 16:14:23 2024
From: duke at openjdk.org (hanklo6)
Date: Wed, 6 Nov 2024 16:14:23 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v2]
In-Reply-To: <pMFaNC7FdA5hZXkEXwFWjiz5sT-3t6-gMMAV_DwRNUk=.2c2c8bfd-47a4-4555-8bc0-281f7fc4a55b@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
 <pMFaNC7FdA5hZXkEXwFWjiz5sT-3t6-gMMAV_DwRNUk=.2c2c8bfd-47a4-4555-8bc0-281f7fc4a55b@github.com>
Message-ID: <Ul3K8xYkjeS0Z3n9y6y1-t6zsvmRs7T5UwlNZxL3DQc=.02ec7607-6b5a-49d8-aa64-65eefa46226b@github.com>

On Tue, 5 Nov 2024 21:39:49 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comments
>
> cr-examples/triton/src/main/java/oracle/code/triton/ArithMathOps.java line 398:
> 
>> 396:     public static class CompareOp extends ArithMathOp implements Op.Pure {
>> 397:         public static final String NAME = "arith.cmp";
>> 398:         public static final String ATTRIBUTE_CONSTANT_VALUE = "predicate";
> 
> Suggestion:
> 
>         public static final String ATTRIBUTE_PREDICATE = "predicate";

Fixed.

> cr-examples/triton/src/main/java/oracle/code/triton/ArithMathOps.java line 401:
> 
>> 399: 
>> 400:         public enum CompareKind {
>> 401:             eq,
> 
> Can you link to https://mlir.llvm.org/docs/Dialects/ArithOps/#cmpipredicate ? and also state in the comment the enum ordinal corresponds to the MLIR symbol's value. Further comment that we would need to refine when considering comparisons of floating point numbers which is in a different namespace.

Thanks, fixed.

> cr-examples/triton/src/main/java/oracle/code/triton/TritonTransformer.java line 1054:
> 
>> 1052:             a = block.context().getValue(a);
>> 1053:             b = block.context().getValue(b);
>> 1054:             Object zero;
> 
> Add a comment such as
> 
> // Computed result is tensor of floats, regardless of inputs
> 
> like when we compute the type. Since the result is hard coded we don't need to use reflection and can directly use the constant expression "0.0".

Fixed.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1831333593
PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1831333218
PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1831334498

From asotona at openjdk.org  Wed Nov  6 16:31:46 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 16:31:46 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v2]
In-Reply-To: <NTT4kUkyvSnXjqDFhL7JPMYHwQwqKrJwMfHF2pz8fP0=.66b48a22-833d-4880-b0d2-e91974e80c83@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.71c7ffbc-833e-432e-af34-978c866c7cf0@github.com>
 <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.a9b9b6e2-9a23-4edf-9d93-518047a09655@github.com>
 <NTT4kUkyvSnXjqDFhL7JPMYHwQwqKrJwMfHF2pz8fP0=.66b48a22-833d-4880-b0d2-e91974e80c83@github.com>
Message-ID: <UdYTaa4C6VtKzXCb_qoY-jNZPnELimYIKoBN-XwpURA=.3b1e12b0-0973-4580-a18d-c9d86b2e8c1b@github.com>

On Wed, 6 Nov 2024 12:06:53 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Yes, this is not ideal. Maps can be used later in the transform, however unresolved component of an unresolved array type is something that needs to be at least partially resolved (2-slot long or double vs 1-slot others) in the first stage of BytecodeLift or it causes stack problems with hybrid single and dual slot instructions (dup_x2, dup2, dup2_x1 and dup2_x2). The problem here is that I cannot retrospectively change types in the middle of a lift process. 
>> 
>> I'll definitelly look for better solution.
>
> Maybe I can inject an explicit ConvOp after ArrayLoadOp result of an unresolved type, however it will generate an instability. Or custom ResolveTypeOp, which can be later removed by a transform.

Common solution for `componentType` and `ArrayLoadOp` loosing information during lift would be 
`ArrayLoadOp` accepting result component type as an additional optional argument.
In that case we don't have to add `TypeWithComponent` interface and `BytecodeLift` will inject specific (resolved or unresolved) type as a result of `ArrayLoadOp`. It would allow to remove `UnresolvedType.Comp` and the mutable field and move the type resolution completely to the `UnresolvedTypesTransformer`.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1831364699

From psandoz at openjdk.org  Wed Nov  6 17:19:45 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 6 Nov 2024 17:19:45 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v2]
In-Reply-To: <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.a9b9b6e2-9a23-4edf-9d93-518047a09655@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.71c7ffbc-833e-432e-af34-978c866c7cf0@github.com>
 <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.a9b9b6e2-9a23-4edf-9d93-518047a09655@github.com>
Message-ID: <H2qj80omKHQ3JsK4P4nc_LQvxW90ppperEi6bfN4K3I=.5763a31b-99fc-461c-b3a4-396c08a817b0@github.com>

On Wed, 6 Nov 2024 11:41:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/Value.java line 152:
>> 
>>> 150:      * @throws IllegalStateException if the declaring block is partially built
>>> 151:      */
>>> 152:     public boolean isDominatedBy(Set<? extends Value> doms) {
>> 
>> It would be better for now to move this method back into the bytecode area as non-public. Currently it's too specialized and not-well defined.
>> 
>> From reading the specification one might expect it to return true if this value is dominated be all given values. But, it returns true if any given value does. If none dominate then it checks if there is path back from this value's block to the entry block of the same parent body. That is not directly related to dominance, but related dominance frontiers which is a different concept. Returning true in the second cases doe not mean dominance.
>
> This method tests if the given set of values represent a dominating set for the actual value. I hope the implementation matches the "Dominating sets in directed graphs" definition.
> 
> I've moved it here because there are already two uses of the method:
> - BytecodeGenerator::isDefinitelyAssigned needs to test for the dominance of VarStoreOps set to decide if the VarOp can be deferred 
> - SlotToVarTransformer::isDominatedByTheSameVar needs to test dominance of set of SlotOp predecessors to identify initial SlotStoreOps.

I understand the motivation, and the documentation is appreciated, but for i now i still think it better to let it soak within the bytecode package. I don't think it is ready to have such prominence in the core API, maybe it never will. That's not imply it is not useful for your purposes, but i am skeptical at the moment of its broad use.

The existing `isDominatedBy` methods on code items have quite a precise meaning with regards to nested hierarchy and block dominance. This method is very different and merges the concept of is-dominated-by-any-value with a dominance-like frontier approach, where values are substituted for their blocks (presumably within the same body, otherwise it does not make much sense) and there is some implicit relation between the values in those blocks. Splitting it in two concepts may make more sense.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1831435166

From psandoz at openjdk.org  Wed Nov  6 17:22:44 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 6 Nov 2024 17:22:44 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v2]
In-Reply-To: <UdYTaa4C6VtKzXCb_qoY-jNZPnELimYIKoBN-XwpURA=.3b1e12b0-0973-4580-a18d-c9d86b2e8c1b@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.71c7ffbc-833e-432e-af34-978c866c7cf0@github.com>
 <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.a9b9b6e2-9a23-4edf-9d93-518047a09655@github.com>
 <NTT4kUkyvSnXjqDFhL7JPMYHwQwqKrJwMfHF2pz8fP0=.66b48a22-833d-4880-b0d2-e91974e80c83@github.com>
 <UdYTaa4C6VtKzXCb_qoY-jNZPnELimYIKoBN-XwpURA=.3b1e12b0-0973-4580-a18d-c9d86b2e8c1b@github.com>
Message-ID: <Xyy4IRwxqlzKi-rKnJR1XuvqZB_gjdSrYYQ6fjKWIr8=.fedc70ac-804c-45c9-a706-77bda173a5f3@github.com>

On Wed, 6 Nov 2024 16:29:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Maybe I can inject an explicit ConvOp after ArrayLoadOp result of an unresolved type, however it will generate an instability. Or custom ResolveTypeOp, which can be later removed by a transform.
>
> Common solution for `componentType` and `ArrayLoadOp` loosing information during lift would be 
> `ArrayLoadOp` accepting result component type as an additional optional argument.
> In that case we don't have to add `TypeWithComponent` interface and `BytecodeLift` will inject specific (resolved or unresolved) type as a result of `ArrayLoadOp`. It would allow to remove `UnresolvedType.Comp` and the mutable field and move the type resolution completely to the `UnresolvedTypesTransformer`.

That sounds like a better approach.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1831438538

From asotona at openjdk.org  Wed Nov  6 17:26:43 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 17:26:43 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v2]
In-Reply-To: <H2qj80omKHQ3JsK4P4nc_LQvxW90ppperEi6bfN4K3I=.5763a31b-99fc-461c-b3a4-396c08a817b0@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.71c7ffbc-833e-432e-af34-978c866c7cf0@github.com>
 <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.a9b9b6e2-9a23-4edf-9d93-518047a09655@github.com>
 <H2qj80omKHQ3JsK4P4nc_LQvxW90ppperEi6bfN4K3I=.5763a31b-99fc-461c-b3a4-396c08a817b0@github.com>
Message-ID: <__aQdPDRvyEt-ciV_khCiMnIdbjHFfvASAVqnNTzbNs=.140c49bf-b6c0-4d8f-8390-6060dc9274dd@github.com>

On Wed, 6 Nov 2024 17:17:30 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This method tests if the given set of values represent a dominating set for the actual value. I hope the implementation matches the "Dominating sets in directed graphs" definition.
>> 
>> I've moved it here because there are already two uses of the method:
>> - BytecodeGenerator::isDefinitelyAssigned needs to test for the dominance of VarStoreOps set to decide if the VarOp can be deferred 
>> - SlotToVarTransformer::isDominatedByTheSameVar needs to test dominance of set of SlotOp predecessors to identify initial SlotStoreOps.
>
> I understand the motivation, and the documentation is appreciated, but for i now i still think it better to let it soak within the bytecode package. I don't think it is ready to have such prominence in the core API, maybe it never will. That's not imply it is not useful for your purposes, but i am skeptical at the moment of its broad use.
> 
> The existing `isDominatedBy` methods on code items have quite a precise meaning with regards to nested hierarchy and block dominance. This method is very different and merges the concept of is-dominated-by-any-value with a dominance-like frontier approach, where values are substituted for their blocks (presumably within the same body, otherwise it does not make much sense) and there is some implicit relation between the values in those blocks. Splitting it in two concepts may make more sense.

It has exactly same meaning as `isDominatedBy`. Second part is focused on blocks only because individual dominance test in the first part covers the situations where any member of the tested set precedes the value in the same block (or in the entry block) - so it is individually dominant and the method returns true. If any member of the set is individually dominant, the whole set is dominant.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1831443092

From asotona at openjdk.org  Wed Nov  6 18:21:17 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 18:21:17 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v3]
In-Reply-To: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
Message-ID: <f-Q7BCbfPjhFO5VMn_BTm1P_6bpEevN4yF7M6AQndMI=.679e2d65-efc2-4928-a6e1-deda90a97290@github.com>

> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
> 
> Work on `Verifier` revealed bugs in `BytecodeLift`.
> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
> - `SlotOp` is an intermediate model of local variables
> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.

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

  removal of TypeWithComponent
  added CoreOp.ArrayAccessOp.ArrayLoadOp::arrayLoadOp(Value array, Value index, TypeElement componentType) override

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/258/files
  - new: https://git.openjdk.org/babylon/pull/258/files/fc178e72..05c258eb

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

  Stats: 147 lines in 7 files changed: 57 ins; 72 del; 18 mod
  Patch: https://git.openjdk.org/babylon/pull/258.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/258/head:pull/258

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

From asotona at openjdk.org  Wed Nov  6 18:23:40 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 18:23:40 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v3]
In-Reply-To: <Xyy4IRwxqlzKi-rKnJR1XuvqZB_gjdSrYYQ6fjKWIr8=.fedc70ac-804c-45c9-a706-77bda173a5f3@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.71c7ffbc-833e-432e-af34-978c866c7cf0@github.com>
 <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.a9b9b6e2-9a23-4edf-9d93-518047a09655@github.com>
 <NTT4kUkyvSnXjqDFhL7JPMYHwQwqKrJwMfHF2pz8fP0=.66b48a22-833d-4880-b0d2-e91974e80c83@github.com>
 <UdYTaa4C6VtKzXCb_qoY-jNZPnELimYIKoBN-XwpURA=.3b1e12b0-0973-4580-a18d-c9d86b2e8c1b@github.com>
 <Xyy4IRwxqlzKi-rKnJR1XuvqZB_gjdSrYYQ6fjKWIr8=.fedc70ac-804c-45c9-a706-77bda173a5f3@github.com>
Message-ID: <oebgsMdANFJwRfJGZCwp4F4wSDOZTpdn4acsndn9jvI=.f3e365aa-692d-4536-ad74-b455e67443dc@github.com>

On Wed, 6 Nov 2024 17:20:05 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Common solution for `componentType` and `ArrayLoadOp` loosing information during lift would be 
>> `ArrayLoadOp` accepting result component type as an additional optional argument.
>> In that case we don't have to add `TypeWithComponent` interface and `BytecodeLift` will inject specific (resolved or unresolved) type as a result of `ArrayLoadOp`. It would allow to remove `UnresolvedType.Comp` and the mutable field and move the type resolution completely to the `UnresolvedTypesTransformer`.
>
> That sounds like a better approach.

OK, first step done. Now I can move the resolution field and logic out.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1831515667

From asotona at openjdk.org  Wed Nov  6 20:09:25 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 20:09:25 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v4]
In-Reply-To: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
Message-ID: <T8wR8uXjZmHw8t3iVZrPiv8nf02wA3gmODpb6IEWLWQ=.f957cf9b-50a3-4600-bedf-d1f3f71af3f4@github.com>

> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
> 
> Work on `Verifier` revealed bugs in `BytecodeLift`.
> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
> - `SlotOp` is an intermediate model of local variables
> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.

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

  Types resolution logic moved from UnresolvedType to UnresolvedTypesTransformer

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/258/files
  - new: https://git.openjdk.org/babylon/pull/258/files/05c258eb..4b3a239e

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

  Stats: 225 lines in 2 files changed: 69 ins; 113 del; 43 mod
  Patch: https://git.openjdk.org/babylon/pull/258.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/258/head:pull/258

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

From asotona at openjdk.org  Wed Nov  6 20:19:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 20:19:18 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v5]
In-Reply-To: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
Message-ID: <acDLK_9CyyKIe0u0-6SiFZB5d40qa7G2UM_MCnmrrpQ=.eef5b149-a077-4aed-8a46-bd5655c0fba2@github.com>

> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
> 
> Work on `Verifier` revealed bugs in `BytecodeLift`.
> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
> - `SlotOp` is an intermediate model of local variables
> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.

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

 - use of IdentityHashMap where appropriate
 - Var data moved from SlotOp to SlotToVarTransformer

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/258/files
  - new: https://git.openjdk.org/babylon/pull/258/files/4b3a239e..f2ba92bf

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

  Stats: 76 lines in 5 files changed: 29 ins; 18 del; 29 mod
  Patch: https://git.openjdk.org/babylon/pull/258.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/258/head:pull/258

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

From asotona at openjdk.org  Wed Nov  6 20:19:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 20:19:18 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v5]
In-Reply-To: <oebgsMdANFJwRfJGZCwp4F4wSDOZTpdn4acsndn9jvI=.f3e365aa-692d-4536-ad74-b455e67443dc@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.71c7ffbc-833e-432e-af34-978c866c7cf0@github.com>
 <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.a9b9b6e2-9a23-4edf-9d93-518047a09655@github.com>
 <NTT4kUkyvSnXjqDFhL7JPMYHwQwqKrJwMfHF2pz8fP0=.66b48a22-833d-4880-b0d2-e91974e80c83@github.com>
 <UdYTaa4C6VtKzXCb_qoY-jNZPnELimYIKoBN-XwpURA=.3b1e12b0-0973-4580-a18d-c9d86b2e8c1b@github.com>
 <Xyy4IRwxqlzKi-rKnJR1XuvqZB_gjdSrYYQ6fjKWIr8=.fedc70ac-804c-45c9-a706-77bda173a5f3@github.com>
 <oebgsMdANFJwRfJGZCwp4F4wSDOZTpdn4acsndn9jvI=.f3e365aa-692d-4536-ad74-b455e67443dc@github.com>
Message-ID: <4V6Mo3SeMug5eGZeE1bqsd04xW6TFBn-V9GFW_1lvKc=.2a685d23-1389-4a1f-a70e-259ad009d849@github.com>

On Wed, 6 Nov 2024 18:21:31 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> That sounds like a better approach.
>
> OK, first step done. Now I can move the resolution field and logic out.

All fields and logic moved from UnresolvedType and SlotOp.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1831654937

From asotona at openjdk.org  Wed Nov  6 20:37:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 20:37:11 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v6]
In-Reply-To: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
Message-ID: <cJuCKLNBXi0CDFa0xHKm1r6TcN1jqAuRuVgJkn438zQ=.99366920-8ca8-4b0b-974d-9f60f7bf355f@github.com>

> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
> 
> Work on `Verifier` revealed bugs in `BytecodeLift`.
> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
> - `SlotOp` is an intermediate model of local variables
> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.

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

 - reverted removed line
 - isDominatedBy(Set<Value>) moved from Value to BytecodeUtil

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/258/files
  - new: https://git.openjdk.org/babylon/pull/258/files/f2ba92bf..cbb359f9

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

  Stats: 146 lines in 4 files changed: 90 ins; 54 del; 2 mod
  Patch: https://git.openjdk.org/babylon/pull/258.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/258/head:pull/258

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

From asotona at openjdk.org  Wed Nov  6 20:37:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Nov 2024 20:37:11 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v6]
In-Reply-To: <__aQdPDRvyEt-ciV_khCiMnIdbjHFfvASAVqnNTzbNs=.140c49bf-b6c0-4d8f-8390-6060dc9274dd@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.71c7ffbc-833e-432e-af34-978c866c7cf0@github.com>
 <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.a9b9b6e2-9a23-4edf-9d93-518047a09655@github.com>
 <H2qj80omKHQ3JsK4P4nc_LQvxW90ppperEi6bfN4K3I=.5763a31b-99fc-461c-b3a4-396c08a817b0@github.com>
 <__aQdPDRvyEt-ciV_khCiMnIdbjHFfvASAVqnNTzbNs=.140c49bf-b6c0-4d8f-8390-6060dc9274dd@github.com>
Message-ID: <TFeUxsI6xL1NOKjJXH8AXfdANdzVien1cxTLXreSzfc=.7587a5ac-9a8c-41b1-9a8b-347f7d80ea9d@github.com>

On Wed, 6 Nov 2024 17:23:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I understand the motivation, and the documentation is appreciated, but for i now i still think it better to let it soak within the bytecode package. I don't think it is ready to have such prominence in the core API, maybe it never will. That's not imply it is not useful for your purposes, but i am skeptical at the moment of its broad use.
>> 
>> The existing `isDominatedBy` methods on code items have quite a precise meaning with regards to nested hierarchy and block dominance. This method is very different and merges the concept of is-dominated-by-any-value with a dominance-like frontier approach, where values are substituted for their blocks (presumably within the same body, otherwise it does not make much sense) and there is some implicit relation between the values in those blocks. Splitting it in two concepts may make more sense.
>
> It has exactly same meaning as `isDominatedBy`. Second part is focused on blocks only because individual dominance test in the first part covers the situations where any member of the tested set precedes the value in the same block (or in the entry block) - so it is individually dominant and the method returns true. If any member of the set is individually dominant, the whole set is dominant.

I've moved it to BytecodeUtil.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1831672306

From psandoz at openjdk.org  Wed Nov  6 23:27:54 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 6 Nov 2024 23:27:54 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v6]
In-Reply-To: <TFeUxsI6xL1NOKjJXH8AXfdANdzVien1cxTLXreSzfc=.7587a5ac-9a8c-41b1-9a8b-347f7d80ea9d@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
 <AagEuXt_2twGAEwoNn9njTbs9_iU_XCdKUTKzE7P3MI=.71c7ffbc-833e-432e-af34-978c866c7cf0@github.com>
 <iX7e_EJHXeHdGxz1t2E6vV1k125J_nDmYkbzw0KIi3s=.a9b9b6e2-9a23-4edf-9d93-518047a09655@github.com>
 <H2qj80omKHQ3JsK4P4nc_LQvxW90ppperEi6bfN4K3I=.5763a31b-99fc-461c-b3a4-396c08a817b0@github.com>
 <__aQdPDRvyEt-ciV_khCiMnIdbjHFfvASAVqnNTzbNs=.140c49bf-b6c0-4d8f-8390-6060dc9274dd@github.com>
 <TFeUxsI6xL1NOKjJXH8AXfdANdzVien1cxTLXreSzfc=.7587a5ac-9a8c-41b1-9a8b-347f7d80ea9d@github.com>
Message-ID: <OpeFUKCt3F5FVtrBKrEpmuhCg01XTFw8iuA6F6fgfFw=.eadc1888-b3ef-4b46-b44d-56bf36a1b7cb@github.com>

On Wed, 6 Nov 2024 20:30:54 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> It has exactly same meaning as `isDominatedBy`. Second part is focused on blocks only because individual dominance test in the first part covers the situations where any member of the tested set precedes the value in the same block (or in the entry block) - so it is individually dominant and the method returns true. If any member of the set is individually dominant, the whole set is dominant.
>
> I've moved it to BytecodeUtil.

Thank you. For the record i think it currently stretches the definition of dominance. For the second case consider the blocks connected as follows:

    e
   /  \
  a   b
   \  /
    c
```  
Where `this` value is in block `c` and the given values are in block `a` and `b` respectively. It is stretching the definition to say that `a` and `b` collectively dominate `c`. (FWIW in this case the dominance frontiers of `a` and `b` are the same, the set consisting of `c` i.e., `a` does not strictly dominate `c`, but some predecessor of `c` does, in this case `a`, which dominates itself.)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1831848853

From psandoz at openjdk.org  Thu Nov  7 00:43:20 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 7 Nov 2024 00:43:20 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v2]
In-Reply-To: <EWsZy-DeOtyr6y2vW6mkubILO7gAqJ1RLM5oVLKTQBQ=.adadf1c9-bbee-4ba6-a8ef-0fa28deed090@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
 <pMFaNC7FdA5hZXkEXwFWjiz5sT-3t6-gMMAV_DwRNUk=.2c2c8bfd-47a4-4555-8bc0-281f7fc4a55b@github.com>
 <EWsZy-DeOtyr6y2vW6mkubILO7gAqJ1RLM5oVLKTQBQ=.adadf1c9-bbee-4ba6-a8ef-0fa28deed090@github.com>
Message-ID: <hl4ZZO8Q7yvqSmXo9FZFFBagipIlYJPA7URS6s8sPWQ=.b0c88cf5-782f-450d-ab40-56d6f414f7ed@github.com>

On Wed, 6 Nov 2024 15:46:36 GMT, hanklo6 <duke at openjdk.org> wrote:

>> cr-examples/triton/src/test/java/oracle/code/triton/TestMatrix.java line 264:
>> 
>>> 262:                     LessThan);
>>> 263:             var b = load(b_ptrs, broadcast(offs_k_m_3, b_ptrs.type()));
>>> 264:             // We accumulate along the K dimension.
>> 
>> Were these necessary changes because you encountered a bug?
>
> Because I changed the return type of the `compare` function to `boolean`, It can't match the return type of the `expand` function.

Ah yes, of course.

>> cr-examples/triton/src/test/java/oracle/code/triton/TestMatrix.java line 471:
>> 
>>> 469:             int stride_am, @Constant int stride_ak,
>>> 470:             int stride_bk, @Constant int stride_bn,
>>> 471:             int stride_cm, @Constant int stride_cn,
>> 
>> Why the marking as constants?
>
> Triton will mark these three stride values as constants if they are equal to one at compile time. We mark them as constants directly as our code is not compiled by Triton.

Oh i see, i don't see those equivalent parameters marked as `tl.constexpr` in the Python matmul example. I think we need the concept of optional constants e.g., a boolean on the `@Constant` annotation. An optional constant parameter can be associated with type or a constant type.
(Alternatively we could drop the constant annotation, but it seems useful to distinguish various parameters)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1831864743
PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1831868919

From psandoz at openjdk.org  Thu Nov  7 00:43:19 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 7 Nov 2024 00:43:19 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v2]
In-Reply-To: <2x0fH2IeYnAdUvJ9lQlMeDQF8zORQlpIaHpvhP2vGTs=.0787bd20-a5d7-4561-a5d6-1ccb6c2583c3@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
 <2x0fH2IeYnAdUvJ9lQlMeDQF8zORQlpIaHpvhP2vGTs=.0787bd20-a5d7-4561-a5d6-1ccb6c2583c3@github.com>
Message-ID: <eLcGwUlMD9yRmGe7wYAxiUyNA0ZqyZ87Ja7f7QBU1EM=.00d4fa29-bd5b-471b-a649-e7d016258c34@github.com>

On Wed, 6 Nov 2024 16:14:21 GMT, hanklo6 <duke at openjdk.org> wrote:

>> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>>  
>> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
>> 
>> ## Usage
>> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
>> 
>> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
>> 
>> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
>> 
>> To create a binding for Level Zero, execute the below commands:
>> 
>> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
>> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
>> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
>> 
>> The will generate `levelzero.jar` in the current directory.
>> 
>> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
>> 
>> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
>> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
>> 
>> 
>> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
>> 
>> ## Dependencies
>> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
>> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
>> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
>> - [Jextract](https://github.com/openjdk/jextract)
>> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
>> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
>> - [JSON-java](https://github.com/stleary/JSON-java)
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments

cr-examples/triton/src/main/java/oracle/code/triton/TritonTransformer.java line 1061:

> 1059:             } catch (Throwable e) {
> 1060:                 throw new RuntimeException(e);
> 1061:             }

Suggestion:

            Object zero = 0.0;

cr-examples/triton/src/test/java/oracle/code/triton/TritonTestExtension.java line 114:

> 112:             });
> 113: 
> 114:             String mlirText = MLIRGenerator.transform(actualTritonKernel);

We should write the files to the maven target directory. Add the following to the surefire plugin configuration:

                        <systemPropertyVariables>
                            <project.build.directory>${project.build.directory}</project.build.directory>
                        </systemPropertyVariables>

Then replace the code below with:

            Path buildDir = Path.of(System.getProperty("project.build.directory", ""));
            Path mlirDir = buildDir.resolve("mlir");
            try {
                Files.createDirectories(mlirDir);
                Files.writeString(mlirDir.resolve(javaKernelName + ".mlir"), mlirText, StandardOpenOption.CREATE);
            } catch (IOException e) {
                e.printStackTrace();
            }

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

PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1831864406
PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1831899439

From psandoz at openjdk.org  Thu Nov  7 00:55:01 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 7 Nov 2024 00:55:01 GMT
Subject: [code-reflection] RFR: Support bytecode generation for invocation
 of varArg method
In-Reply-To: <IMUwzHcG-mrDZCvkpheHhD2Xr4mXYFHxc0QkhV9F98k=.d69ac42e-3089-4653-94f8-67479c53b8e5@github.com>
References: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
 <IMUwzHcG-mrDZCvkpheHhD2Xr4mXYFHxc0QkhV9F98k=.d69ac42e-3089-4653-94f8-67479c53b8e5@github.com>
Message-ID: <2EYk-yRUH7SuEfsB2YqRERQN_3A2M6DCzHnVcBdCJg8=.719a11a8-8f18-4f6d-a2ba-16535d205934@github.com>

On Wed, 6 Nov 2024 11:19:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Support bytecode generation for invocation of varArg method.
>
> src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 365:
> 
>> 363:         } else {
>> 364:             processOperands(op.operands());
>> 365:         }
> 
> There are 19 calls of this helper method and only one is related to InvokeOp operands.
> I would suggest to apply this logic where InvokeOp bytecode is generated.

Yes, keep it local to the `InvokeOp` case at line 883.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/272#discussion_r1831905180

From psandoz at openjdk.org  Thu Nov  7 00:55:01 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 7 Nov 2024 00:55:01 GMT
Subject: [code-reflection] RFR: Support bytecode generation for invocation
 of varArg method
In-Reply-To: <2EYk-yRUH7SuEfsB2YqRERQN_3A2M6DCzHnVcBdCJg8=.719a11a8-8f18-4f6d-a2ba-16535d205934@github.com>
References: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
 <IMUwzHcG-mrDZCvkpheHhD2Xr4mXYFHxc0QkhV9F98k=.d69ac42e-3089-4653-94f8-67479c53b8e5@github.com>
 <2EYk-yRUH7SuEfsB2YqRERQN_3A2M6DCzHnVcBdCJg8=.719a11a8-8f18-4f6d-a2ba-16535d205934@github.com>
Message-ID: <uE8k4Dbhjv-nrEXUKn_uTfmDouP5qgffIm5mPK96cIw=.93873f16-2fb1-41e8-ac60-6c0f926a6b19@github.com>

On Thu, 7 Nov 2024 00:49:10 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 365:
>> 
>>> 363:         } else {
>>> 364:             processOperands(op.operands());
>>> 365:         }
>> 
>> There are 19 calls of this helper method and only one is related to InvokeOp operands.
>> I would suggest to apply this logic where InvokeOp bytecode is generated.
>
> Yes, keep it local to the `InvokeOp` case at line 883.

Add a test using double or long.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/272#discussion_r1831908381

From psandoz at openjdk.org  Thu Nov  7 00:55:04 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 7 Nov 2024 00:55:04 GMT
Subject: [code-reflection] RFR: Support bytecode generation for invocation
 of varArg method
In-Reply-To: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
References: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
Message-ID: <kU--zMdkOWs0fTbttAYf6Y_pKpnidkB6pmegehsNjtA=.f686f843-5c08-4651-ad7a-a2ca32d54b2b@github.com>

On Wed, 6 Nov 2024 10:43:58 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Support bytecode generation for invocation of varArg method.

test/jdk/java/lang/reflect/code/bytecode/TestVarArg.java line 42:

> 40: 
> 41:     @CodeReflection
> 42:     static String f() {

Add a call to k or w with zero arguments.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/272#discussion_r1831905710

From asotona at openjdk.org  Thu Nov  7 16:35:42 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 7 Nov 2024 16:35:42 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v7]
In-Reply-To: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
Message-ID: <qlQcpT0o0hAdoUX9BGjPDPrxvEoLxTSFYoB8o8kJb0s=.737081b6-f384-4ea1-b94c-32edce850ec5@github.com>

> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
> 
> Work on `Verifier` revealed bugs in `BytecodeLift`.
> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
> - `SlotOp` is an intermediate model of local variables
> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.

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

  BytecodeGenerator cleanup around unitialized variables + move of isDominatedBy to SlotToVarTransformer

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/258/files
  - new: https://git.openjdk.org/babylon/pull/258/files/cbb359f9..636df09f

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

  Stats: 166 lines in 3 files changed: 56 ins; 105 del; 5 mod
  Patch: https://git.openjdk.org/babylon/pull/258.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/258/head:pull/258

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

From psandoz at openjdk.org  Thu Nov  7 19:02:54 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 7 Nov 2024 19:02:54 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v7]
In-Reply-To: <qlQcpT0o0hAdoUX9BGjPDPrxvEoLxTSFYoB8o8kJb0s=.737081b6-f384-4ea1-b94c-32edce850ec5@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
 <qlQcpT0o0hAdoUX9BGjPDPrxvEoLxTSFYoB8o8kJb0s=.737081b6-f384-4ea1-b94c-32edce850ec5@github.com>
Message-ID: <6484UoG-aeNo9elqHiJotRFdQPyMNdmR4uYWJrY2NPg=.3451fb8c-6ff2-4e92-97c4-ccecf8827a6c@github.com>

On Thu, 7 Nov 2024 16:35:42 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
>> 
>> Work on `Verifier` revealed bugs in `BytecodeLift`.
>> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
>> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
>> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
>> - `SlotOp` is an intermediate model of local variables
>> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
>> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BytecodeGenerator cleanup around unitialized variables + move of isDominatedBy to SlotToVarTransformer

Marked as reviewed by psandoz (Lead).

src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 1945:

> 1943: 
> 1944:             ArrayLoadOp(Value array, Value index) {
> 1945:                 this(array, index, ((ArrayType)array.type()).componentType());

Can you make a note to revisit this when the component type is not explicitly given (see `VarOp.resultType` as an example). The current approach allows for easier transformation of the type because it is a function of inputs (the operand type). I know we are not consistent in this area and need a better general solution.

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

PR Review: https://git.openjdk.org/babylon/pull/258#pullrequestreview-2421886268
PR Review Comment: https://git.openjdk.org/babylon/pull/258#discussion_r1833206418

From mabbay at openjdk.org  Thu Nov  7 20:37:00 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 7 Nov 2024 20:37:00 GMT
Subject: [code-reflection] RFR: Support bytecode generation for invocation
 of varArg method [v2]
In-Reply-To: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
References: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
Message-ID: <PDqSveHXZOGyzD76VJqQFJUWEfhPR-0wmcV7v-UB4GQ=.ad85f43b-b73a-47de-a173-860069e802b5@github.com>

> Support bytecode generation for invocation of varArg method.

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

 - Add test cases for empty var arg, long and double
 - Move code related to InvokeOp from processOperands(Op).

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/272/files
  - new: https://git.openjdk.org/babylon/pull/272/files/8aa9c038..b2a2680f

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

  Stats: 49 lines in 2 files changed: 25 ins; 21 del; 3 mod
  Patch: https://git.openjdk.org/babylon/pull/272.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/272/head:pull/272

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

From duke at openjdk.org  Fri Nov  8 00:08:43 2024
From: duke at openjdk.org (hanklo6)
Date: Fri, 8 Nov 2024 00:08:43 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v3]
In-Reply-To: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
Message-ID: <OBsie9ftf4qusQWKURVIt63gx7CMF9o09fnL03Tm2ls=.437d03d1-0b51-4c3e-8896-8948fee2525d@github.com>

> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>  
> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
> 
> ## Usage
> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
> 
> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
> 
> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
> 
> To create a binding for Level Zero, execute the below commands:
> 
> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
> 
> The will generate `levelzero.jar` in the current directory.
> 
> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
> 
> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
> 
> 
> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
> 
> ## Dependencies
> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
> - [Jextract](https://github.com/openjdk/jextract)
> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
> - [JSON-java](https://github.com/stleary/JSON-java)

hanklo6 has updated the pull request incrementally with three additional commits since the last revision:

 - Simplify zero initialization in dot method
 - Update MLIR output paths
 - Update attribute name

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/241/files
  - new: https://git.openjdk.org/babylon/pull/241/files/2dbe2df9..a91434d4

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

  Stats: 24 lines in 5 files changed: 6 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/babylon/pull/241.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/241/head:pull/241

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

From duke at openjdk.org  Fri Nov  8 00:08:44 2024
From: duke at openjdk.org (hanklo6)
Date: Fri, 8 Nov 2024 00:08:44 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v2]
In-Reply-To: <eLcGwUlMD9yRmGe7wYAxiUyNA0ZqyZ87Ja7f7QBU1EM=.00d4fa29-bd5b-471b-a649-e7d016258c34@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
 <2x0fH2IeYnAdUvJ9lQlMeDQF8zORQlpIaHpvhP2vGTs=.0787bd20-a5d7-4561-a5d6-1ccb6c2583c3@github.com>
 <eLcGwUlMD9yRmGe7wYAxiUyNA0ZqyZ87Ja7f7QBU1EM=.00d4fa29-bd5b-471b-a649-e7d016258c34@github.com>
Message-ID: <iFLxg1yPLPBPvx2Ltzka32Ti_PKjQFDoYeMpnCcZ4QM=.5c10d0eb-9aec-4987-a194-83084a80d198@github.com>

On Wed, 6 Nov 2024 23:48:49 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comments
>
> cr-examples/triton/src/main/java/oracle/code/triton/TritonTransformer.java line 1061:
> 
>> 1059:             } catch (Throwable e) {
>> 1060:                 throw new RuntimeException(e);
>> 1061:             }
> 
> Suggestion:
> 
>             Object zero = 0.0;

Fixed.

> cr-examples/triton/src/test/java/oracle/code/triton/TritonTestExtension.java line 114:
> 
>> 112:             });
>> 113: 
>> 114:             String mlirText = MLIRGenerator.transform(actualTritonKernel);
> 
> We should write the files to the maven target directory. Add the following to the surefire plugin configuration:
> 
>                         <systemPropertyVariables>
>                             <project.build.directory>${project.build.directory}</project.build.directory>
>                         </systemPropertyVariables>
> 
> Then replace the code below with:
> 
>             Path buildDir = Path.of(System.getProperty("project.build.directory", ""));
>             Path mlirDir = buildDir.resolve("mlir");
>             try {
>                 Files.createDirectories(mlirDir);
>                 Files.writeString(mlirDir.resolve(javaKernelName + ".mlir"), mlirText, StandardOpenOption.CREATE);
>             } catch (IOException e) {
>                 e.printStackTrace();
>             }

Thanks, fixed.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1833521448
PR Review Comment: https://git.openjdk.org/babylon/pull/241#discussion_r1833521919

From mabbay at openjdk.org  Fri Nov  8 02:52:43 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Fri, 8 Nov 2024 02:52:43 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model
Message-ID: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>

Experiment with replacing textual representation in classfile with method that builds the model.
Note: This PR is based on changes from #272.

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

Commit messages:
 - Test replacing textual representation with method that builds the code model
 - Add test cases for empty var arg, long and double
 - Move code related to InvokeOp from processOperands(Op).
 - Support bytecode generation for invocation of varArg method

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

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

From asotona at openjdk.org  Fri Nov  8 08:23:55 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 8 Nov 2024 08:23:55 GMT
Subject: git: openjdk/babylon: code-reflection: Aggregated work on Verifier and
 BytecodeLift deconstruction
Message-ID: <ba257b4c-6060-4bb3-b832-ae6f0780333c@openjdk.org>

Changeset: 86dfc369
Branch: code-reflection
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-11-08 08:22:48 +0000
URL:       https://git.openjdk.org/babylon/commit/86dfc369acd6d140a9a8dc6ba05a3664cf8eb8ea

Aggregated work on Verifier and BytecodeLift deconstruction

Reviewed-by: psandoz

! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java
! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeLift.java
- src/java.base/share/classes/java/lang/reflect/code/bytecode/LocalsToVarMapper.java
+ src/java.base/share/classes/java/lang/reflect/code/bytecode/SlotOp.java
+ src/java.base/share/classes/java/lang/reflect/code/bytecode/SlotToVarTransformer.java
+ src/java.base/share/classes/java/lang/reflect/code/bytecode/UnresolvedType.java
+ src/java.base/share/classes/java/lang/reflect/code/bytecode/UnresolvedTypesTransformer.java
! src/java.base/share/classes/java/lang/reflect/code/interpreter/Interpreter.java
! src/java.base/share/classes/java/lang/reflect/code/interpreter/InvokableLeafOps.java
+ src/java.base/share/classes/java/lang/reflect/code/interpreter/Verifier.java
! src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java
! test/jdk/java/lang/reflect/code/bytecode/TestBytecode.java
! test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java


From asotona at openjdk.org  Fri Nov  8 08:26:46 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 8 Nov 2024 08:26:46 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v8]
In-Reply-To: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
Message-ID: <WlVmyyerXbJGx-qB6n0PMbDim9MFcqIyiIq71ySv9xA=.4642e231-fa7f-457a-9429-4c4102b75d30@github.com>

> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
> 
> Work on `Verifier` revealed bugs in `BytecodeLift`.
> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
> - `SlotOp` is an intermediate model of local variables
> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.

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

  Added comment

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/258/files
  - new: https://git.openjdk.org/babylon/pull/258/files/636df09f..883abf8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=258&range=07
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=258&range=06-07

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

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

From asotona at openjdk.org  Fri Nov  8 08:26:47 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 8 Nov 2024 08:26:47 GMT
Subject: [code-reflection] RFR: Aggregated work on Verifier and
 BytecodeLift deconstruction [v7]
In-Reply-To: <qlQcpT0o0hAdoUX9BGjPDPrxvEoLxTSFYoB8o8kJb0s=.737081b6-f384-4ea1-b94c-32edce850ec5@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
 <qlQcpT0o0hAdoUX9BGjPDPrxvEoLxTSFYoB8o8kJb0s=.737081b6-f384-4ea1-b94c-32edce850ec5@github.com>
Message-ID: <sPBxxco8AEI_y8SzruBJHV6vDX-9Gzc3sJnXDbkrEpI=.2be98bae-fd62-45f5-94f5-04b14861487a@github.com>

On Thu, 7 Nov 2024 16:35:42 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
>> 
>> Work on `Verifier` revealed bugs in `BytecodeLift`.
>> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
>> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
>> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
>> - `SlotOp` is an intermediate model of local variables
>> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
>> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BytecodeGenerator cleanup around unitialized variables + move of isDominatedBy to SlotToVarTransformer

Thank you for the review!

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

PR Comment: https://git.openjdk.org/babylon/pull/258#issuecomment-2464102643

From asotona at openjdk.org  Fri Nov  8 08:29:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 8 Nov 2024 08:29:19 GMT
Subject: [code-reflection] Integrated: Aggregated work on Verifier and
 BytecodeLift deconstruction
In-Reply-To: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
References: <jYu57O8ibU0l6S7wOOH6Ozx1lU7oTcOPAPeF3i6wKHA=.c3ea214c-ae05-4b5e-9b71-940d1cb9bafa@github.com>
Message-ID: <C09n31cTLYlj6KSiAyoJMcROcCOOMGXDn2qTVH0raLQ=.1ac46447-7f1b-4b98-9e89-370e6ab2d2cd@github.com>

On Fri, 18 Oct 2024 10:06:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This PR is aggregated continuation of work on `Verifier` #247 and new simplified and deconstructed implementation of `BytecodeLift`.
> 
> Work on `Verifier` revealed bugs in `BytecodeLift`.
> Fixing of the bugs adds more complexity to already very complex `BytecodeLift`.
> The goal of this PR is to deconstruct `BytecodeLift` to its bare bones  and re-introduce a kind of bytecode dialect:
> - `UnresolvedType.Ref` and `UnresolvedType.Int` represent references and int with all its possible sub-types
> - `SlotOp` is an intermediate model of local variables
> - `SlotToVarTransformer` transforms `SlotOp` to `CoreOp.VarOp`
> - `UnresolvedTypesTransformer` transforms `UnresolvedType.Ref` and `UnresolvedType.Int` to `JavaType`.

This pull request has now been integrated.

Changeset: 86dfc369
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/86dfc369acd6d140a9a8dc6ba05a3664cf8eb8ea
Stats:     3017 lines in 13 files changed: 1582 ins; 1215 del; 220 mod

Aggregated work on Verifier and BytecodeLift deconstruction

Reviewed-by: psandoz

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

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

From mabbay at openjdk.org  Fri Nov  8 09:10:12 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Fri, 8 Nov 2024 09:10:12 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v2]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <aMopCdbbsISj5Yh7Tj0RsrqGbDFDoqN11pZ4vA1qEys=.7bd31beb-1d63-44dc-ad9f-da33ea6fe097@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

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

 - Assert on the value of executing builder method
 - Change bytecode generation for NewOp to use constructor type as owner

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/d9e5e196..176108a8

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

  Stats: 51 lines in 2 files changed: 32 ins; 2 del; 17 mod
  Patch: https://git.openjdk.org/babylon/pull/274.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/274/head:pull/274

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

From psandoz at openjdk.org  Fri Nov  8 21:53:51 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 8 Nov 2024 21:53:51 GMT
Subject: [code-reflection] RFR: Support bytecode generation for invocation
 of varArg method [v2]
In-Reply-To: <PDqSveHXZOGyzD76VJqQFJUWEfhPR-0wmcV7v-UB4GQ=.ad85f43b-b73a-47de-a173-860069e802b5@github.com>
References: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
 <PDqSveHXZOGyzD76VJqQFJUWEfhPR-0wmcV7v-UB4GQ=.ad85f43b-b73a-47de-a173-860069e802b5@github.com>
Message-ID: <k6POQrbYVziTozNopLzJeNwTjd7Xs2Z3FBNiAg_sy8k=.0c5f3f18-f9ce-45c9-8cb4-7fa0504fb952@github.com>

On Thu, 7 Nov 2024 20:37:00 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Support bytecode generation for invocation of varArg method.
>
> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add test cases for empty var arg, long and double
>  - Move code related to InvokeOp from processOperands(Op).

src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 864:

> 862:                     case InvokeOp op -> {
> 863:                         if (op.isVarArgs()) {
> 864:                             processOperands(op.operands().subList(0, op.operands().size() - op.varArgOperands().size()));

Suggest we add the compliment to `varArgOperands()`, called say `argOperands()` such that `operands().equals(<argOperands() + varArgOperands()>)`

src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 874:

> 872:                             } else {
> 873:                                 cob.newarray(typeKind);
> 874:                             }

Do this:

var compTypeDesc = compType.toNominalDescriptor();
if (compTypeDesc.isPrimitive()) {
  cob.newarray(TypeKind.from(ctd));
} else {
  cob.anewarray(compTypeDesc);
}

See code for case of NewOp when constructing an array.

src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 876:

> 874:                             }
> 875:                             for (int j = 0; j < varArgOperands.size(); j++) {
> 876:                                 cob.dup();

Add a comment that this is duplicating the array value on the stack for the next loop iteration *and* subsequent the invoke instruction.

test/jdk/java/lang/reflect/code/bytecode/TestVarArg.java line 58:

> 56:         r += k();
> 57: 
> 58:         r += w(11L, 12L);

I meant add another method whose signature is `(double... )` or `(long... )` and test calls against that.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/272#discussion_r1835079373
PR Review Comment: https://git.openjdk.org/babylon/pull/272#discussion_r1835089996
PR Review Comment: https://git.openjdk.org/babylon/pull/272#discussion_r1835083650
PR Review Comment: https://git.openjdk.org/babylon/pull/272#discussion_r1835092267

From duke at openjdk.org  Fri Nov  8 22:03:04 2024
From: duke at openjdk.org (hanklo6)
Date: Fri, 8 Nov 2024 22:03:04 GMT
Subject: [code-reflection] RFR: Integrate Java Triton example with Intel
 Triton Backend [v4]
In-Reply-To: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
References: <NMe-IE1hpqjx8hpUXBRULL1BXqUjM92QzPQLh0weCx4=.a4d5938d-89f5-4a48-ad25-b912367bf429@github.com>
Message-ID: <pVXGQ1LY4daY6IAOZq4dSdOY4AN4r-6JxmWFr8TF0_g=.fa6be527-b69b-41de-bbdc-532a1e7fe122@github.com>

> Babylon Java Triton example translates Java source code with Java Triton API into code model by code reflection.
>  
> In this PR, we traverse the given code model and output Triton MLIR dialect in the generic form, and then inject generated MLIR dialect into the Intel Triton backend. We then utilize Intel Triton backend to compile the Triton MLIR dialect into a SPIR-V module. Use `Jextract` to create Java binding of Intel Level Zero runtime and launch the given kernel function with it on Intel GPUs.
> 
> ## Usage
> Navigate to the `cr-example/triton` directory and execute `mvn clean test`. This will generate multiple MLIR files in the `result` directory ready to be processed by the Triton backend. 
> 
> Next, modify the `compiler.py` file within the `intel-xpu-triton-backend` project by applying the patch `git apply add-mlir-insertion.patch`. Then run the Triton backend by running `python3 translate.py`.
> 
> The Triton backend will generate SPIR-V files, which will be located under `~/.triton/cache/{hash_value}/{kernel_name}/{kernel_name}.spv`.
> 
> To create a binding for Level Zero, execute the below commands:
> 
> $JEXTRACT_DIR/bin/jextract --output src/gen/java -I /usr/include -t oneapi.levelzero level-zero/include/ze_api.h
> $JAVA_HOME/bin/javac -cp target/classes -d target/classes src/gen/java/oneapi/levelzero/*.java
> $JAVA_HOME/bin/jar cf levelzero.jar -C target/classes/ .
> 
> The will generate `levelzero.jar` in the current directory.
> 
> After getting JAR files for Level Zero and `JSON-java`, proceed to compile and run the launcher `LevelZero.java` with the following commands:
> 
> babylon/build/linux-x86_64-server-release/jdk/bin/javac -cp .:levelzero.jar:json-java.jar LevelZero.java
> babylon/build/linux-x86_64-server-release/jdk/bin/java -ea -cp .:levelzero.jar:json-java.jar LevelZero
> 
> 
> Ensure the hash values in`~/.triton/cache` match those used in the `LevelZero.java`.
> 
> ## Dependencies
> - [intel-xpu-backend-for-triton](https://github.com/intel/intel-xpu-backend-for-triton)
> - [intel-extension-for-pytorch](https://github.com/intel/intel-extension-for-pytorch)
> - [Intel oneAPI base Toolkit](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html)
> - [Jextract](https://github.com/openjdk/jextract)
> - [Level Zero loader](https://github.com/oneapi-src/level-zero)
> - [compute-runtime](https://github.com/intel/compute-runtime/releases)
> - [JSON-java](https://github.com/stleary/JSON-java)

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

  Add the test for matrix multiplication with float16

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/241/files
  - new: https://git.openjdk.org/babylon/pull/241/files/a91434d4..f585076b

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

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

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

From psandoz at openjdk.org  Fri Nov  8 22:19:32 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 8 Nov 2024 22:19:32 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v2]
In-Reply-To: <aMopCdbbsISj5Yh7Tj0RsrqGbDFDoqN11pZ4vA1qEys=.7bd31beb-1d63-44dc-ad9f-da33ea6fe097@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
 <aMopCdbbsISj5Yh7Tj0RsrqGbDFDoqN11pZ4vA1qEys=.7bd31beb-1d63-44dc-ad9f-da33ea6fe097@github.com>
Message-ID: <ihxokDFqy8c9-5jGjAJAsINUxcSEozfAS2_lSi8jJac=.43852fe7-b798-4b93-9fdb-0f6d60a03935@github.com>

On Fri, 8 Nov 2024 09:10:12 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Experiment with replacing textual representation in classfile with method that builds the model.
>> Note: This PR is based on changes from #272.
>
> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Assert on the value of executing builder method
>  - Change bytecode generation for NewOp to use constructor type as owner

test/jdk/java/lang/reflect/code/writer/TestOpMethod.java line 67:

> 65: 
> 66:     @Test(dataProvider = "classes")
> 67:     void test(byte[] cd) throws Throwable {

That's a good start, but i suspect what we need here is also a main method, so we can run this over many classes via some script. Thereby we get more (albeit manual) test exposure and can get statistics class file sizes before and after i.e. we can run the script over all the compiled test class files in lang and jdk.

test/jdk/java/lang/reflect/code/writer/TestOpMethod.java line 114:

> 112:                 var lci = (ConstantInstruction.LoadConstantInstruction) prev;
> 113:                 var pe = (StringEntry) lci.constantEntry();
> 114:                 res.add(new OpFieldAndIR(fi.name().stringValue().substring(fi.name().stringValue().indexOf(':') + 2), pe.stringValue()));

Suggest you return pairs of `FieldRefEntry` (or `FieldInstruction`)  and `String`, thereby you retain the full field name for possible reduction later on if needed, and you can reuse later when removing them.

Was there an issue with using the synthetic field name as a synthetic method name?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/274#discussion_r1835109445
PR Review Comment: https://git.openjdk.org/babylon/pull/274#discussion_r1835104311

From mabbay at openjdk.org  Sun Nov 10 03:59:30 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Sun, 10 Nov 2024 03:59:30 GMT
Subject: [code-reflection] RFR: Support bytecode generation for invocation
 of varArg method [v3]
In-Reply-To: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
References: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
Message-ID: <_TAJWgdi1Y8x2Wyco1Ew9oYkaQmoNLrEadRO3XvdD4U=.e0b64acb-ddb4-4f98-863a-0159b46452e9@github.com>

> Support bytecode generation for invocation of varArg method.

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

  Add method CoreOp.InvokeOp.argOperands

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/272/files
  - new: https://git.openjdk.org/babylon/pull/272/files/b2a2680f..885a073d

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

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

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

From mabbay at openjdk.org  Sun Nov 10 04:26:12 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Sun, 10 Nov 2024 04:26:12 GMT
Subject: [code-reflection] RFR: Support bytecode generation for invocation
 of varArg method [v4]
In-Reply-To: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
References: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
Message-ID: <AK1jLJGi-EeG7FuhdE5XgLFkRRPRfn1-sVNM1l5sSbg=.ee9a295b-9e35-4adf-8b7d-f4b85b32cdb8@github.com>

> Support bytecode generation for invocation of varArg method.

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

 - Add test for long and double
 - Apply Suggestions

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/272/files
  - new: https://git.openjdk.org/babylon/pull/272/files/885a073d..0dfc24a2

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

  Stats: 20 lines in 2 files changed: 12 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/babylon/pull/272.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/272/head:pull/272

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

From mabbay at openjdk.org  Mon Nov 11 10:45:30 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 11 Nov 2024 10:45:30 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v3]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <xqXr2zMKSDSaji6Rfg3ei1HMUagZ6f9Jdyna-h3CXFk=.43610249-9541-4914-94ae-f3859be0ab41@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

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

 - Write transformation as ClassTransform
 - Map FieldEntry to textual representation

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/176108a8..d476a93b

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

  Stats: 117 lines in 1 file changed: 47 ins; 53 del; 17 mod
  Patch: https://git.openjdk.org/babylon/pull/274.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/274/head:pull/274

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

From mabbay at openjdk.org  Mon Nov 11 10:49:35 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 11 Nov 2024 10:49:35 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v4]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <YcDWRgsA9tyhdEKeyzObneVQ2WZu6bC1HW98XL3Olys=.4a0fb7f7-ea38-447d-aa1f-b226c6b146f5@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

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

  Refactor

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/d476a93b..d871a21a

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

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

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

From mabbay at openjdk.org  Mon Nov 11 10:49:38 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 11 Nov 2024 10:49:38 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v2]
In-Reply-To: <ihxokDFqy8c9-5jGjAJAsINUxcSEozfAS2_lSi8jJac=.43852fe7-b798-4b93-9fdb-0f6d60a03935@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
 <aMopCdbbsISj5Yh7Tj0RsrqGbDFDoqN11pZ4vA1qEys=.7bd31beb-1d63-44dc-ad9f-da33ea6fe097@github.com>
 <ihxokDFqy8c9-5jGjAJAsINUxcSEozfAS2_lSi8jJac=.43852fe7-b798-4b93-9fdb-0f6d60a03935@github.com>
Message-ID: <eYiQ4hRtpbbCeq3GP9xVHLSWNE5xssnuI5fYjxj6bHc=.2f67bbdd-8a15-43fe-9508-41a584256e19@github.com>

On Fri, 8 Nov 2024 22:07:23 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Assert on the value of executing builder method
>>  - Change bytecode generation for NewOp to use constructor type as owner
>
> test/jdk/java/lang/reflect/code/writer/TestOpMethod.java line 114:
> 
>> 112:                 var lci = (ConstantInstruction.LoadConstantInstruction) prev;
>> 113:                 var pe = (StringEntry) lci.constantEntry();
>> 114:                 res.add(new OpFieldAndIR(fi.name().stringValue().substring(fi.name().stringValue().indexOf(':') + 2), pe.stringValue()));
> 
> Suggest you return pairs of `FieldRefEntry` (or `FieldInstruction`)  and `String`, thereby you retain the full field name for possible reduction later on if needed, and you can reuse later when removing them.
> 
> Was there an issue with using the synthetic field name as a synthetic method name?

For method name, I had to remove the class part.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/274#discussion_r1836457317

From mcimadamore at openjdk.org  Mon Nov 11 14:53:17 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 11 Nov 2024 14:53:17 GMT
Subject: [code-reflection] RFR: Move code reflection API into incubating module
Message-ID: <B8_bPzJ9UWlWKw4zG7hv92Gaz0f_S64Aw9W-lNIojGk=.81a6dd4f-8436-481b-a06c-cb8880078ba2@github.com>

This PR moves the code reflection API into a separate incubating module. In order to do that, Babylon compiler support (`ReflectMethods`) has morphed into a compiler plugin, which is optionally invoked when the user specifies the command line option `--add-modules jdk.incubator.module`.

#### Basic structure

The new module `jdk.incubator.module` has the following structure (starred packages are not exported):


src/jdk.incubator.code/share/classes
??? jdk
    ??? incubator
        ??? code
            ??? analysis
            ??? bytecode
            ??? compiler (*)
            ??? internal (*)
            ??? interpreter
            ??? op
            ??? parser
            ??? ??? impl (*)
            ??? tools
            ??? ??? dot
            ??? ??? renderer
            ??? type
            ??? ??? impl (*)
            ??? writer


In other words, the new module subsumes the sources under `java.base/java.lang.reflect.code` and those under `jdk.code.tools`.

#### Compiler plugin

To decouple the `ReflectMethods` class from `jdk,compiler` we have moved `ReflectMethods` in a new compiler plugin in the new module (see `compiler` package). Compiler plugins are loaded using regular `ServiceLoader` infrastructure. However, here we have an issue: incubator modules are not resolved by default (unless `--add-modules` is used). This means that javac will not look inside `jdk.incubator.code` when finding its plugins.

To workaround this issue, javac will create a new module layer which points at `jdk.incubator.module` and then call `ServiceLoader::load` by passing that layer (see `BasicJavacTask`). This will force the javac plugin to be loaded, and no additional runtime warnings to be displayed when running javac.

Some additional tweaks were needed to avoid the creation of a module layer if the incubator module is not present (e.g. if we're using javac in "boostrap mode") or if we're running javac from an exploded build (in which case the incubator module is part of the module graph).

Note, the `@CodeReflection` annotation has been moved to `jdk.incubator.code`.

#### Symbol constants

All code reflection-related symbol constants have migrated from `Symtab` to the `CodeReflectionSymbols` in the new module. This is necessary because the symbols are now defined in a module other than `java.base` and javac `Symtab` cannot resolve references to symbols outside `java.base` early on (`Symtab` is one of the first classes to be initialized in the compiler).

After some consideration, I've decided to move the creation of these symbols in a separate class, to avoid pesky bootstrapping issues.

#### `Quotable` lambda metafactory changes

Another obstacle is the implementation of the lambda metafactory changes to support the `Quotable` functional interface target. Since now `Quotable` is defined in its own module, the lambda metafactory can no longer resolve class literals in that new module (as `java.base` does not -- and cannot -- depend on the new module).

A similar trick to the one described above was implemented: a new module layer is created, pointing at `jdk.incubator.code` and runtime types for `Quotable` and other relevant classes are obtained from there.

#### Obtaining code models

There are currently two ways to obtain code models:

* At runtime, by calling `Method::getCodeModel`
* At compile-time, by calling `Elements::getBody`

Since neither `java.base` nor `jdk.compiler` can have direct dependencies on the new module, I've decided to move these factories into static methods in the `Op` class:

* `Op::ofMethod(Method)`
* `Op::ofElement(ProcessingEnvironment, ExecutableElement)

(Note: this allowed us to use a sharper signature in `Op::ofElement` which was previously returning `Object`.

#### Build changes

No particular change was required here. However, note that we have eliminated the need for generating copies of the code reflection classes into the jdk.compiler module.

#### Test changes

Most tests required at least one of the following three kinds of updates:

* tweak `import` statements to point at the new module
* add a `@module jdk.incubator.code` to the test header, so that the module is added to the module graph when compiling/running the test
* tweak code that obtains code model, either reflectively, or via an annotation processor.

All tests (in both compiler and jdk) pass.

#### Other dependencies

@PaulSandoz has fixed Hat, and all the various samples to use the new packages/module (thanks!). The only changes required are import statement tweaks.

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

Commit messages:
 - Fix whitespace
 - Fix jshell test
 - Merge branch 'code-reflection' into code_reflection_plugin+merge
 - Merge pull request #1 from PaulSandoz/plugin_updates
 - Updates to module and API changes
 - Make compiler tests more robust when ran in exploded build
 - Improve support for exploded JDK build
 - Fix imports in hat
 - Add missing code reflection classes
 - All jdk tests pass
 - ... and 6 more: https://git.openjdk.org/babylon/compare/86dfc369...7e846d2d

Changes: https://git.openjdk.org/babylon/pull/273/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=273&range=00
  Stats: 4102 lines in 407 files changed: 1510 ins; 951 del; 1641 mod
  Patch: https://git.openjdk.org/babylon/pull/273.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/273/head:pull/273

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

From mabbay at openjdk.org  Tue Nov 12 07:15:20 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 12 Nov 2024 07:15:20 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v5]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <Rp_CbVT5ppTWP43HK6W1W-BEyInua_cimPIfRwl-onU=.632ee301-ef2f-468e-90a1-2662f88a313f@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

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

  Fix a typo

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/d871a21a..f8647056

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

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

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

From psandoz at openjdk.org  Tue Nov 12 19:37:59 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 12 Nov 2024 19:37:59 GMT
Subject: [code-reflection] RFR: Move code reflection API into incubating
 module
In-Reply-To: <B8_bPzJ9UWlWKw4zG7hv92Gaz0f_S64Aw9W-lNIojGk=.81a6dd4f-8436-481b-a06c-cb8880078ba2@github.com>
References: <B8_bPzJ9UWlWKw4zG7hv92Gaz0f_S64Aw9W-lNIojGk=.81a6dd4f-8436-481b-a06c-cb8880078ba2@github.com>
Message-ID: <1tWS5l26ssr9oz5iYE5VHQb8aolBRywwqx7bn8L_1NM=.5f5961ff-763c-4acd-a2e2-61536e76daf9@github.com>

On Thu, 7 Nov 2024 19:20:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR moves the code reflection API into a separate incubating module. In order to do that, Babylon compiler support (`ReflectMethods`) has morphed into a compiler plugin, which is optionally invoked when the user specifies the command line option `--add-modules jdk.incubator.module`.
> 
> #### Basic structure
> 
> The new module `jdk.incubator.module` has the following structure (starred packages are not exported):
> 
> 
> src/jdk.incubator.code/share/classes
> ??? jdk
>     ??? incubator
>         ??? code
>             ??? analysis
>             ??? bytecode
>             ??? compiler (*)
>             ??? internal (*)
>             ??? interpreter
>             ??? op
>             ??? parser
>             ??? ??? impl (*)
>             ??? tools
>             ??? ??? dot
>             ??? ??? renderer
>             ??? type
>             ??? ??? impl (*)
>             ??? writer
> 
> 
> In other words, the new module subsumes the sources under `java.base/java.lang.reflect.code` and those under `jdk.code.tools`.
> 
> #### Compiler plugin
> 
> To decouple the `ReflectMethods` class from `jdk,compiler` we have moved `ReflectMethods` in a new compiler plugin in the new module (see `compiler` package). Compiler plugins are loaded using regular `ServiceLoader` infrastructure. However, here we have an issue: incubator modules are not resolved by default (unless `--add-modules` is used). This means that javac will not look inside `jdk.incubator.code` when finding its plugins.
> 
> To workaround this issue, javac will create a new module layer which points at `jdk.incubator.module` and then call `ServiceLoader::load` by passing that layer (see `BasicJavacTask`). This will force the javac plugin to be loaded, and no additional runtime warnings to be displayed when running javac.
> 
> Some additional tweaks were needed to avoid the creation of a module layer if the incubator module is not present (e.g. if we're using javac in "boostrap mode") or if we're running javac from an exploded build (in which case the incubator module is part of the module graph).
> 
> Note, the `@CodeReflection` annotation has been moved to `jdk.incubator.code`.
> 
> #### Symbol constants
> 
> All code reflection-related symbol constants have migrated from `Symtab` to the `CodeReflectionSymbols` in the new module. This is necessary because the symbols are now defined in a module other than `java.base` and javac `Symtab` cannot resolve references to symbols outside `java.base` early on (`Symtab` is one of the first classes to be initialized in the compiler).
> 
> After ...

Thank you for doing this tricky effort. Overall it looks very good and all but the first comment can be addressed later:
- The test `test/jdk/java/lang/reflect/Method/cr/TreeAccessTest.java` needs updating, but it really does not do anything that other tests already do. I suggest we just remove it.
- We can move the code reflection lang and JDK tests under more appropriate directories, and consolidate any code reflection tests in other areas.
- I am inclined to rethink the name/location of `Op.ofMethod`, in part because I think we should reconsider the design of `Quotable`. It could be a marker interface and we appeal to a reflection-based method to obtain the `Quoted` instance. We can work this out later. (Relatedly the compiler support for structural quoting when targeting lambda expressions to`Quoted` can be revisited to use a specific bootstrap.)

I will give it a quick test run locally.

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

PR Comment: https://git.openjdk.org/babylon/pull/273#issuecomment-2471400904

From psandoz at openjdk.org  Tue Nov 12 21:48:33 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 12 Nov 2024 21:48:33 GMT
Subject: [code-reflection] RFR: Move code reflection API into incubating
 module
In-Reply-To: <B8_bPzJ9UWlWKw4zG7hv92Gaz0f_S64Aw9W-lNIojGk=.81a6dd4f-8436-481b-a06c-cb8880078ba2@github.com>
References: <B8_bPzJ9UWlWKw4zG7hv92Gaz0f_S64Aw9W-lNIojGk=.81a6dd4f-8436-481b-a06c-cb8880078ba2@github.com>
Message-ID: <LeXJ-au-usZTg_LFokmfur2RbbWrtucSAqfCQo1SVJI=.20dfb58c-34c2-446c-b9bc-5b3b281c4901@github.com>

On Thu, 7 Nov 2024 19:20:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR moves the code reflection API into a separate incubating module. In order to do that, Babylon compiler support (`ReflectMethods`) has morphed into a compiler plugin, which is optionally invoked when the user specifies the command line option `--add-modules jdk.incubator.module`.
> 
> #### Basic structure
> 
> The new module `jdk.incubator.module` has the following structure (starred packages are not exported):
> 
> 
> src/jdk.incubator.code/share/classes
> ??? jdk
>     ??? incubator
>         ??? code
>             ??? analysis
>             ??? bytecode
>             ??? compiler (*)
>             ??? internal (*)
>             ??? interpreter
>             ??? op
>             ??? parser
>             ??? ??? impl (*)
>             ??? tools
>             ??? ??? dot
>             ??? ??? renderer
>             ??? type
>             ??? ??? impl (*)
>             ??? writer
> 
> 
> In other words, the new module subsumes the sources under `java.base/java.lang.reflect.code` and those under `jdk.code.tools`.
> 
> #### Compiler plugin
> 
> To decouple the `ReflectMethods` class from `jdk,compiler` we have moved `ReflectMethods` in a new compiler plugin in the new module (see `compiler` package). Compiler plugins are loaded using regular `ServiceLoader` infrastructure. However, here we have an issue: incubator modules are not resolved by default (unless `--add-modules` is used). This means that javac will not look inside `jdk.incubator.code` when finding its plugins.
> 
> To workaround this issue, javac will create a new module layer which points at `jdk.incubator.module` and then call `ServiceLoader::load` by passing that layer (see `BasicJavacTask`). This will force the javac plugin to be loaded, and no additional runtime warnings to be displayed when running javac.
> 
> Some additional tweaks were needed to avoid the creation of a module layer if the incubator module is not present (e.g. if we're using javac in "boostrap mode") or if we're running javac from an exploded build (in which case the incubator module is part of the module graph).
> 
> Note, the `@CodeReflection` annotation has been moved to `jdk.incubator.code`.
> 
> #### Symbol constants
> 
> All code reflection-related symbol constants have migrated from `Symtab` to the `CodeReflectionSymbols` in the new module. This is necessary because the symbols are now defined in a module other than `java.base` and javac `Symtab` cannot resolve references to symbols outside `java.base` early on (`Symtab` is one of the first classes to be initialized in the compiler).
> 
> After ...

Testing good (unit tests, examples, and HAT).

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

Marked as reviewed by psandoz (Lead).

PR Review: https://git.openjdk.org/babylon/pull/273#pullrequestreview-2430762284

From asotona at openjdk.org  Wed Nov 13 10:52:40 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 13 Nov 2024 10:52:40 GMT
Subject: [code-reflection] RFR: Move code reflection API into incubating
 module
In-Reply-To: <B8_bPzJ9UWlWKw4zG7hv92Gaz0f_S64Aw9W-lNIojGk=.81a6dd4f-8436-481b-a06c-cb8880078ba2@github.com>
References: <B8_bPzJ9UWlWKw4zG7hv92Gaz0f_S64Aw9W-lNIojGk=.81a6dd4f-8436-481b-a06c-cb8880078ba2@github.com>
Message-ID: <-uJ7DolDNaxTR8YNiRiT_aJcHjNs3Fs20rWRxvqpLyU=.493468dd-94f7-4571-8188-8c67dcfc63d1@github.com>

On Thu, 7 Nov 2024 19:20:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR moves the code reflection API into a separate incubating module. In order to do that, Babylon compiler support (`ReflectMethods`) has morphed into a compiler plugin, which is optionally invoked when the user specifies the command line option `--add-modules jdk.incubator.module`.
> 
> #### Basic structure
> 
> The new module `jdk.incubator.module` has the following structure (starred packages are not exported):
> 
> 
> src/jdk.incubator.code/share/classes
> ??? jdk
>     ??? incubator
>         ??? code
>             ??? analysis
>             ??? bytecode
>             ??? compiler (*)
>             ??? internal (*)
>             ??? interpreter
>             ??? op
>             ??? parser
>             ??? ??? impl (*)
>             ??? tools
>             ??? ??? dot
>             ??? ??? renderer
>             ??? type
>             ??? ??? impl (*)
>             ??? writer
> 
> 
> In other words, the new module subsumes the sources under `java.base/java.lang.reflect.code` and those under `jdk.code.tools`.
> 
> #### Compiler plugin
> 
> To decouple the `ReflectMethods` class from `jdk,compiler` we have moved `ReflectMethods` in a new compiler plugin in the new module (see `compiler` package). Compiler plugins are loaded using regular `ServiceLoader` infrastructure. However, here we have an issue: incubator modules are not resolved by default (unless `--add-modules` is used). This means that javac will not look inside `jdk.incubator.code` when finding its plugins.
> 
> To workaround this issue, javac will create a new module layer which points at `jdk.incubator.module` and then call `ServiceLoader::load` by passing that layer (see `BasicJavacTask`). This will force the javac plugin to be loaded, and no additional runtime warnings to be displayed when running javac.
> 
> Some additional tweaks were needed to avoid the creation of a module layer if the incubator module is not present (e.g. if we're using javac in "boostrap mode") or if we're running javac from an exploded build (in which case the incubator module is part of the module graph).
> 
> Note, the `@CodeReflection` annotation has been moved to `jdk.incubator.code`.
> 
> #### Symbol constants
> 
> All code reflection-related symbol constants have migrated from `Symtab` to the `CodeReflectionSymbols` in the new module. This is necessary because the symbols are now defined in a module other than `java.base` and javac `Symtab` cannot resolve references to symbols outside `java.base` early on (`Symtab` is one of the first classes to be initialized in the compiler).
> 
> After ...

It looks good to me.
Tests passing, TestSmallCorpus indicates reduced test base as expected. 
?

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/babylon/pull/273#pullrequestreview-2432642749

From mcimadamore at openjdk.org  Wed Nov 13 12:00:43 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 13 Nov 2024 12:00:43 GMT
Subject: [code-reflection] RFR: Move code reflection API into incubating
 module
In-Reply-To: <1tWS5l26ssr9oz5iYE5VHQb8aolBRywwqx7bn8L_1NM=.5f5961ff-763c-4acd-a2e2-61536e76daf9@github.com>
References: <B8_bPzJ9UWlWKw4zG7hv92Gaz0f_S64Aw9W-lNIojGk=.81a6dd4f-8436-481b-a06c-cb8880078ba2@github.com>
 <1tWS5l26ssr9oz5iYE5VHQb8aolBRywwqx7bn8L_1NM=.5f5961ff-763c-4acd-a2e2-61536e76daf9@github.com>
Message-ID: <ImFRmqqjYVvkBSy_K3fju4Bf--dnwTemp90S25_jwqM=.97a6fde3-9247-4c06-944d-650b8616a633@github.com>

On Tue, 12 Nov 2024 19:33:22 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The test `test/jdk/java/lang/reflect/Method/cr/TreeAccessTest.java` needs updating, but it really does not do anything that other tests already do. I suggest we just remove it.

Oof, I didn't run tier1 tests, so didn't see this - good catch. Will remove (and run tier1 tests too :-) ).

> * I am inclined to rethink the name/location of `Op.ofMethod`

I agree this doesn't look "great". As you suggested, let's tackle these issues as follow up PRs. (I have some of my own to simplify the way in which javac and the plugin talk to each other).

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

PR Comment: https://git.openjdk.org/babylon/pull/273#issuecomment-2473399331
PR Comment: https://git.openjdk.org/babylon/pull/273#issuecomment-2473403794

From mcimadamore at openjdk.org  Wed Nov 13 12:12:58 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 13 Nov 2024 12:12:58 GMT
Subject: [code-reflection] RFR: Move code reflection API into incubating
 module [v2]
In-Reply-To: <B8_bPzJ9UWlWKw4zG7hv92Gaz0f_S64Aw9W-lNIojGk=.81a6dd4f-8436-481b-a06c-cb8880078ba2@github.com>
References: <B8_bPzJ9UWlWKw4zG7hv92Gaz0f_S64Aw9W-lNIojGk=.81a6dd4f-8436-481b-a06c-cb8880078ba2@github.com>
Message-ID: <t5bfuCpkk8Zpds_KedwKWBLVay-T1Ih3FZFOblfp9xE=.9f958e66-a11b-44ef-a972-a405c7b526c4@github.com>

> This PR moves the code reflection API into a separate incubating module. In order to do that, Babylon compiler support (`ReflectMethods`) has morphed into a compiler plugin, which is optionally invoked when the user specifies the command line option `--add-modules jdk.incubator.module`.
> 
> #### Basic structure
> 
> The new module `jdk.incubator.module` has the following structure (starred packages are not exported):
> 
> 
> src/jdk.incubator.code/share/classes
> ??? jdk
>     ??? incubator
>         ??? code
>             ??? analysis
>             ??? bytecode
>             ??? compiler (*)
>             ??? internal (*)
>             ??? interpreter
>             ??? op
>             ??? parser
>             ??? ??? impl (*)
>             ??? tools
>             ??? ??? dot
>             ??? ??? renderer
>             ??? type
>             ??? ??? impl (*)
>             ??? writer
> 
> 
> In other words, the new module subsumes the sources under `java.base/java.lang.reflect.code` and those under `jdk.code.tools`.
> 
> #### Compiler plugin
> 
> To decouple the `ReflectMethods` class from `jdk,compiler` we have moved `ReflectMethods` in a new compiler plugin in the new module (see `compiler` package). Compiler plugins are loaded using regular `ServiceLoader` infrastructure. However, here we have an issue: incubator modules are not resolved by default (unless `--add-modules` is used). This means that javac will not look inside `jdk.incubator.code` when finding its plugins.
> 
> To workaround this issue, javac will create a new module layer which points at `jdk.incubator.module` and then call `ServiceLoader::load` by passing that layer (see `BasicJavacTask`). This will force the javac plugin to be loaded, and no additional runtime warnings to be displayed when running javac.
> 
> Some additional tweaks were needed to avoid the creation of a module layer if the incubator module is not present (e.g. if we're using javac in "boostrap mode") or if we're running javac from an exploded build (in which case the incubator module is part of the module graph).
> 
> Note, the `@CodeReflection` annotation has been moved to `jdk.incubator.code`.
> 
> #### Symbol constants
> 
> All code reflection-related symbol constants have migrated from `Symtab` to the `CodeReflectionSymbols` in the new module. This is necessary because the symbols are now defined in a module other than `java.base` and javac `Symtab` cannot resolve references to symbols outside `java.base` early on (`Symtab` is one of the first classes to be initialized in the compiler).
> 
> After ...

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Drop unused test

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/273/files
  - new: https://git.openjdk.org/babylon/pull/273/files/7e846d2d..9049a94a

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

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

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

From mabbay at openjdk.org  Wed Nov 13 14:31:22 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 13 Nov 2024 14:31:22 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v6]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <ADSkl_vsTGey76CotbBqXqNmVG9pZz82qi2B1Jq8WkU=.8606646f-a575-4a55-973d-8cbe1e4ec643@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

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

 - Move record declaration before use
 - Remove some comments
 - Add main method

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/f8647056..8e9e7963

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

  Stats: 100 lines in 1 file changed: 27 ins; 45 del; 28 mod
  Patch: https://git.openjdk.org/babylon/pull/274.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/274/head:pull/274

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

From mcimadamore at openjdk.org  Thu Nov 14 17:24:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Nov 2024 17:24:19 GMT
Subject: git: openjdk/babylon: code-reflection: Move code reflection API into
 incubating module
Message-ID: <ed2b76ae-94fc-4837-9135-164407065482@openjdk.org>

Changeset: 18627a63
Branch: code-reflection
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-11-14 17:21:34 +0000
URL:       https://git.openjdk.org/babylon/commit/18627a637362a70a72d16b5cbe52d07ddb55c6f9

Move code reflection API into incubating module

Reviewed-by: psandoz, asotona

! README.md
! cr-examples/spirv/src/main/java/intel/code/spirv/PointerType.java
! cr-examples/spirv/src/main/java/intel/code/spirv/SpirvModuleGenerator.java
! cr-examples/spirv/src/main/java/intel/code/spirv/SpirvOp.java
! cr-examples/spirv/src/main/java/intel/code/spirv/SpirvOps.java
! cr-examples/spirv/src/main/java/intel/code/spirv/SpirvType.java
! cr-examples/spirv/src/main/java/intel/code/spirv/TranslateToSpirvModel.java
! cr-examples/spirv/src/test/java/intel/code/spirv/ExampleUseTest.java
! cr-examples/triton/src/main/java/oracle/code/triton/ArithMathOps.java
! cr-examples/triton/src/main/java/oracle/code/triton/ConstantType.java
! cr-examples/triton/src/main/java/oracle/code/triton/Float16.java
! cr-examples/triton/src/main/java/oracle/code/triton/Functions.java
! cr-examples/triton/src/main/java/oracle/code/triton/PtrType.java
! cr-examples/triton/src/main/java/oracle/code/triton/SCFOps.java
! cr-examples/triton/src/main/java/oracle/code/triton/SimpleCountedForLoopInfo.java
! cr-examples/triton/src/main/java/oracle/code/triton/TensorType.java
! cr-examples/triton/src/main/java/oracle/code/triton/Triton.java
! cr-examples/triton/src/main/java/oracle/code/triton/TritonOps.java
! cr-examples/triton/src/main/java/oracle/code/triton/TritonTestOps.java
! cr-examples/triton/src/main/java/oracle/code/triton/TritonTransformer.java
! cr-examples/triton/src/main/java/oracle/code/triton/TritonType.java
! cr-examples/triton/src/test/java/oracle/code/triton/TestAddKernel.java
! cr-examples/triton/src/test/java/oracle/code/triton/TestBroadcast.java
! cr-examples/triton/src/test/java/oracle/code/triton/TestCdiv.java
! cr-examples/triton/src/test/java/oracle/code/triton/TestCountedLoop.java
! cr-examples/triton/src/test/java/oracle/code/triton/TestMatrix.java
! cr-examples/triton/src/test/java/oracle/code/triton/TestSoftMax.java
! cr-examples/triton/src/test/java/oracle/code/triton/TestVariables.java
! cr-examples/triton/src/test/java/oracle/code/triton/TestZeros.java
! cr-examples/triton/src/test/java/oracle/code/triton/TritonTestExtension.java
- cr-util/copy-to-compiler.sh
! hat/backends/cuda/src/main/java/hat/backend/CudaHatKernelBuilder.java
! hat/backends/mock/src/main/java/hat/backend/TestIt.java
! hat/backends/opencl/src/main/java/hat/backend/OpenCLHatKernelBuilder.java
! hat/backends/ptx/src/main/java/hat/backend/PTXBackend.java
! hat/backends/ptx/src/main/java/hat/backend/PTXCodeBuilder.java
! hat/backends/ptx/src/main/java/hat/backend/PTXPtrOp.java
! hat/backends/ptx/src/main/java/hat/backend/TestIt.java
! hat/backends/spirv/src/main/java/hat/backend/TestIt.java
! hat/backends/spirv/src/main/java/intel/code/spirv/LevelZero.java
! hat/backends/spirv/src/main/java/intel/code/spirv/PointerType.java
! hat/backends/spirv/src/main/java/intel/code/spirv/SpirvModuleGenerator.java
! hat/backends/spirv/src/main/java/intel/code/spirv/SpirvOp.java
! hat/backends/spirv/src/main/java/intel/code/spirv/SpirvType.java
! hat/backends/spirv/src/main/java/intel/code/spirv/TranslateToSpirvModel.java
! hat/bld
! hat/bldr/args
! hat/docs/hat-01-03-building-hat.md
! hat/docs/hat-01-04-intellij.md
! hat/examples/blackscholes/src/main/java/blackscholes/Main.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/ForTests.java
! hat/examples/experiments/src/main/java/experiments/InvokeToPtr.java
! hat/examples/experiments/src/main/java/experiments/LayoutExample.java
! hat/examples/experiments/src/main/java/experiments/Mesh.java
! hat/examples/experiments/src/main/java/experiments/PointyHat.java
! hat/examples/experiments/src/main/java/experiments/PointyHatArray.java
! hat/examples/experiments/src/main/java/experiments/PrePostInc.java
! hat/examples/experiments/src/main/java/experiments/QuotedTest.java
! hat/examples/experiments/src/main/java/experiments/RawLayout.java
! hat/examples/experiments/src/main/java/experiments/TestQuoted.java
! hat/examples/experiments/src/main/java/experiments/Transform.java
! hat/examples/experiments/src/main/java/experiments/spirv/Bad.java
! hat/examples/experiments/src/main/java/experiments/spirv/GetBackend.java
! hat/examples/experiments/src/main/java/experiments/spirv/MatrixMultiply.java
! hat/examples/heal/src/main/java/heal/Compute.java
! hat/examples/life/src/main/java/life/Main.java
! hat/examples/mandel/src/main/java/mandel/Main.java
! hat/examples/squares/src/main/java/squares/Main.java
! hat/examples/violajones/src/main/java/violajones/ViolaJonesCoreCompute.java
! hat/hat/src/main/java/hat/Accelerator.java
! hat/hat/src/main/java/hat/ComputeContext.java
! hat/hat/src/main/java/hat/OpsAndTypes.java
! hat/hat/src/main/java/hat/backend/DebugBackend.java
! hat/hat/src/main/java/hat/backend/NativeBackend.java
! hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatBuildContext.java
! hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatBuilder.java
! hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatBuilderInterface.java
! hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatComputeBuilder.java
! hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java
! hat/hat/src/main/java/hat/callgraph/CallGraph.java
! hat/hat/src/main/java/hat/callgraph/ComputeCallGraph.java
! hat/hat/src/main/java/hat/callgraph/KernelCallGraph.java
! hat/hat/src/main/java/hat/callgraph/KernelEntrypoint.java
! hat/hat/src/main/java/hat/opcodebuilders/OpCodeBuilder.java
! hat/hat/src/main/java/hat/opcodebuilders/StyledOpCodeBuilder.java
! hat/hat/src/main/java/hat/optools/BinaryArithmeticOrLogicOperation.java
! hat/hat/src/main/java/hat/optools/BinaryLogicalOpWrapper.java
! hat/hat/src/main/java/hat/optools/BinaryOpWrapper.java
! hat/hat/src/main/java/hat/optools/BinaryTestOpWrapper.java
! hat/hat/src/main/java/hat/optools/BlockWrapper.java
! hat/hat/src/main/java/hat/optools/BodyWrapper.java
! hat/hat/src/main/java/hat/optools/CodeElementWrapper.java
! hat/hat/src/main/java/hat/optools/ConstantOpWrapper.java
! hat/hat/src/main/java/hat/optools/ConvOpWrapper.java
! hat/hat/src/main/java/hat/optools/FieldAccessOpWrapper.java
! hat/hat/src/main/java/hat/optools/FieldLoadOpWrapper.java
! hat/hat/src/main/java/hat/optools/FieldStoreOpWrapper.java
! hat/hat/src/main/java/hat/optools/ForOpWrapper.java
! hat/hat/src/main/java/hat/optools/FuncCallOpWrapper.java
! hat/hat/src/main/java/hat/optools/FuncOpWrapper.java
! hat/hat/src/main/java/hat/optools/IfOpWrapper.java
! hat/hat/src/main/java/hat/optools/InvokeOpWrapper.java
! hat/hat/src/main/java/hat/optools/JavaBreakOpWrapper.java
! hat/hat/src/main/java/hat/optools/JavaContinueOpWrapper.java
! hat/hat/src/main/java/hat/optools/JavaLabeledOpWrapper.java
! hat/hat/src/main/java/hat/optools/LambdaOpWrapper.java
! hat/hat/src/main/java/hat/optools/LogicalOpWrapper.java
! hat/hat/src/main/java/hat/optools/LoopOpWrapper.java
! hat/hat/src/main/java/hat/optools/ModuleOpWrapper.java
! hat/hat/src/main/java/hat/optools/OpWrapper.java
! hat/hat/src/main/java/hat/optools/ReturnOpWrapper.java
! hat/hat/src/main/java/hat/optools/RootSet.java
! hat/hat/src/main/java/hat/optools/StructuralOpWrapper.java
! hat/hat/src/main/java/hat/optools/TernaryOpWrapper.java
! hat/hat/src/main/java/hat/optools/TupleOpWrapper.java
! hat/hat/src/main/java/hat/optools/UnaryArithmeticOrLogicOpWrapper.java
! hat/hat/src/main/java/hat/optools/UnaryOpWrapper.java
! hat/hat/src/main/java/hat/optools/VarAccessOpWrapper.java
! hat/hat/src/main/java/hat/optools/VarDeclarationOpWrapper.java
! hat/hat/src/main/java/hat/optools/VarFuncDeclarationOpWrapper.java
! hat/hat/src/main/java/hat/optools/VarLoadOpWrapper.java
! hat/hat/src/main/java/hat/optools/VarOpWrapper.java
! hat/hat/src/main/java/hat/optools/VarStoreOpWrapper.java
! hat/hat/src/main/java/hat/optools/WhileOpWrapper.java
! hat/hat/src/main/java/hat/optools/YieldOpWrapper.java
! hat/hat/src/main/test/hat/CustomOpTest.java
! hat/hat/src/main/test/hat/SquaresTest.java
! hat/pom.xml
! make/conf/docs-modules.conf
! make/conf/module-loader-map.conf
! make/modules/jdk.compiler/Gensrc.gmk
+ make/modules/jdk.incubator.code/Java.gmk
! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java
! src/java.base/share/classes/java/lang/reflect/Method.java
! src/java.base/share/classes/java/lang/reflect/ReflectAccess.java
- src/java.base/share/classes/java/lang/reflect/code/Op.java
- src/java.base/share/classes/java/lang/reflect/code/type/FieldRef.java
- src/java.base/share/classes/java/lang/reflect/code/type/RecordTypeRef.java
! src/java.base/share/classes/jdk/internal/access/JavaLangReflectAccess.java
! src/java.base/share/classes/module-info.java
! src/java.compiler/share/classes/javax/lang/model/util/Elements.java
- src/jdk.code.tools/share/classes/jdk/code/tools/renderer/TerminalColors.java
- src/jdk.code.tools/share/classes/module-info.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CaptureScanner.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnvs.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java
! src/jdk.compiler/share/classes/module-info.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/Block.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/Body.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/CodeElement.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/CodeItem.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/CodeReflection.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/CopyContext.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/CopyContextImpl.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/Location.java
+ src/jdk.incubator.code/share/classes/jdk/incubator/code/Op.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/OpTransformer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/Quotable.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/Quoted.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/TypeElement.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/Value.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/AnfTransformer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/Liveness.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/NormalizeBlocksTransformer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/Patterns.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/SSA.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/SSAConstruction.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/StringConcatTransformer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/analysis/package-info.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/BranchCompactor.java
= 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/bytecode/LocalsCompactor.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/SlotOp.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/SlotToVarTransformer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/UnresolvedType.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/UnresolvedTypesTransformer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/bytecode/package-info.java
+ src/jdk.incubator.code/share/classes/jdk/incubator/code/compiler/CodeReflectionPlugin.java
+ src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/CodeReflectionSymbols.java
+ src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/QuotedHelper.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
= src/jdk.incubator.code/share/classes/jdk/incubator/code/interpreter/InvokableLeafOps.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/interpreter/Verifier.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/interpreter/package-info.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/op/AnfDialect.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/op/CoreOp.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/op/ExtendedOp.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/op/ExternalizableOp.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/op/OpFactory.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/op/package-info.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/package-info.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/parser/OpParser.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/parser/impl/DescParser.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/parser/impl/Errors.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/parser/impl/JavaBasedTokenizer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/parser/impl/Lexer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/parser/impl/Log.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/parser/impl/Position.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/parser/impl/Scanner.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/parser/impl/Tokens.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/parser/impl/UnicodeReader.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/parser/package-info.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/tools/dot/DotGenerator.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/tools/dot/DotRenderer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/tools/dot/DotViewer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/tools/renderer/CStyleRenderer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/tools/renderer/CommonRenderer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/tools/renderer/Diff.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/tools/renderer/GlobalValueBlockNaming.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/tools/renderer/ProcessRunner.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/tools/renderer/SRRenderer.java
+ src/jdk.incubator.code/share/classes/jdk/incubator/code/tools/renderer/TerminalColors.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/tools/renderer/TextRenderer.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/ArrayType.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/ClassType.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/CoreTypeFactory.java
+ src/jdk.incubator.code/share/classes/jdk/incubator/code/type/FieldRef.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/FunctionType.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/JavaType.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/MethodRef.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/PrimitiveType.java
+ src/jdk.incubator.code/share/classes/jdk/incubator/code/type/RecordTypeRef.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/TupleType.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/TypeElementFactory.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/TypeVarRef.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/VarType.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/WildcardType.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/impl/FieldRefImpl.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/impl/MethodRefImpl.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/impl/RecordTypeRefImpl.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/type/package-info.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/writer/OpBuilder.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/writer/OpWriter.java
= src/jdk.incubator.code/share/classes/jdk/incubator/code/writer/package-info.java
+ src/jdk.incubator.code/share/classes/module-info.java
- test/jdk/java/lang/reflect/Method/cr/TreeAccessTest.java
! test/jdk/java/lang/reflect/code/CoreBinaryOpsTest.java
! test/jdk/java/lang/reflect/code/TestArrayCreation.java
! test/jdk/java/lang/reflect/code/TestArrayTypes.java
! test/jdk/java/lang/reflect/code/TestBinops.java
! test/jdk/java/lang/reflect/code/TestBlockIndexes.java
! test/jdk/java/lang/reflect/code/TestBlockOp.java
! test/jdk/java/lang/reflect/code/TestBlockParameters.java
! test/jdk/java/lang/reflect/code/TestBreakContinue.java
! test/jdk/java/lang/reflect/code/TestBuild.java
! test/jdk/java/lang/reflect/code/TestClosureOps.java
! test/jdk/java/lang/reflect/code/TestConcat.java
! test/jdk/java/lang/reflect/code/TestConditionalExpression.java
! test/jdk/java/lang/reflect/code/TestConditionalOp.java
! test/jdk/java/lang/reflect/code/TestConstants.java
! test/jdk/java/lang/reflect/code/TestCopy.java
! test/jdk/java/lang/reflect/code/TestDominate.java
! test/jdk/java/lang/reflect/code/TestEnhancedForOp.java
! test/jdk/java/lang/reflect/code/TestExceptionRegionOps.java
! test/jdk/java/lang/reflect/code/TestExpressionGraphs.java
! test/jdk/java/lang/reflect/code/TestForOp.java
! test/jdk/java/lang/reflect/code/TestIfOp.java
! test/jdk/java/lang/reflect/code/TestInline.java
! test/jdk/java/lang/reflect/code/TestInvokeSuper.java
! test/jdk/java/lang/reflect/code/TestLambdaOps.java
! test/jdk/java/lang/reflect/code/TestLinqUsingQuoted.java
! test/jdk/java/lang/reflect/code/TestLiveness.java
! test/jdk/java/lang/reflect/code/TestLocalTransformationsAdaption.java
! test/jdk/java/lang/reflect/code/TestNormalizeBlocksTransformer.java
! test/jdk/java/lang/reflect/code/TestOverloads.java
! test/jdk/java/lang/reflect/code/TestPatterns.java
! test/jdk/java/lang/reflect/code/TestPatterns2.java
! test/jdk/java/lang/reflect/code/TestPrimitiveCast.java
! test/jdk/java/lang/reflect/code/TestPrimitiveTypePatterns.java
! test/jdk/java/lang/reflect/code/TestRemoveFinalVars.java
! test/jdk/java/lang/reflect/code/TestSSA.java
! test/jdk/java/lang/reflect/code/TestStringConcatTransform.java
! test/jdk/java/lang/reflect/code/TestSwitchExpressionOp.java
! test/jdk/java/lang/reflect/code/TestSwitchStatementOp.java
! test/jdk/java/lang/reflect/code/TestTransitiveInvokeModule.java
! test/jdk/java/lang/reflect/code/TestTraverse.java
! test/jdk/java/lang/reflect/code/TestTry.java
! test/jdk/java/lang/reflect/code/TestTryFinally.java
! test/jdk/java/lang/reflect/code/TestTryNested.java
! test/jdk/java/lang/reflect/code/TestUninitializedVariable.java
! test/jdk/java/lang/reflect/code/TestUsesDependsOn.java
! test/jdk/java/lang/reflect/code/TestVarArgsInvoke.java
! test/jdk/java/lang/reflect/code/TestVarOp.java
! test/jdk/java/lang/reflect/code/TestWhileOp.java
! test/jdk/java/lang/reflect/code/ad/ActiveSet.java
! test/jdk/java/lang/reflect/code/ad/ExpressionElimination.java
! test/jdk/java/lang/reflect/code/ad/ForwardDifferentiation.java
! test/jdk/java/lang/reflect/code/ad/TestForwardAutoDiff.java
! test/jdk/java/lang/reflect/code/anf/TestAnfBasicFuns.java
! test/jdk/java/lang/reflect/code/anf/TestAnfTransform.java
! test/jdk/java/lang/reflect/code/bytecode/TestArrayCreation.java
! test/jdk/java/lang/reflect/code/bytecode/TestBranchCompactor.java
! test/jdk/java/lang/reflect/code/bytecode/TestBytecode.java
! test/jdk/java/lang/reflect/code/bytecode/TestInvokeSuper.java
! test/jdk/java/lang/reflect/code/bytecode/TestLiftCustomBytecode.java
! test/jdk/java/lang/reflect/code/bytecode/TestLiftExample.java
! test/jdk/java/lang/reflect/code/bytecode/TestNestedCapturingLambda.java
! test/jdk/java/lang/reflect/code/bytecode/TestQuoted.java
! test/jdk/java/lang/reflect/code/bytecode/TestSlotOps.java
! test/jdk/java/lang/reflect/code/bytecode/TestSlots.java
! test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java
! test/jdk/java/lang/reflect/code/bytecode/TestSynchronizedOp.java
! test/jdk/java/lang/reflect/code/bytecode/TestTry.java
! test/jdk/java/lang/reflect/code/bytecode/TestTryFinally.java
! test/jdk/java/lang/reflect/code/bytecode/TestTryFinallyNested.java
! test/jdk/java/lang/reflect/code/expression/ExpressionElimination.java
! test/jdk/java/lang/reflect/code/expression/TestExpressionElimination.java
! test/jdk/java/lang/reflect/code/interpreter/TestAssert.java
! test/jdk/java/lang/reflect/code/interpreter/TestThrowing.java
! test/jdk/java/lang/reflect/code/linq/QueryProvider.java
! test/jdk/java/lang/reflect/code/linq/QueryResult.java
! test/jdk/java/lang/reflect/code/linq/Queryable.java
! test/jdk/java/lang/reflect/code/linq/QuotableFunction.java
! test/jdk/java/lang/reflect/code/linq/QuotablePredicate.java
! test/jdk/java/lang/reflect/code/linq/TestLinq.java
! test/jdk/java/lang/reflect/code/linq/TestQueryProvider.java
! test/jdk/java/lang/reflect/code/location/ClassWithReflectedMethod.java
! test/jdk/java/lang/reflect/code/location/TestLocation.java
! test/jdk/java/lang/reflect/code/lower/CodeReflectionTester.java
! test/jdk/java/lang/reflect/code/lower/TestLoop.java
! test/jdk/java/lang/reflect/code/lower/TestSynchronized.java
! test/jdk/java/lang/reflect/code/parser/TestParse.java
! test/jdk/java/lang/reflect/code/parser/TestScanner.java
! test/jdk/java/lang/reflect/code/stream/StreamFuser.java
! test/jdk/java/lang/reflect/code/stream/StreamFuserUsingQuotable.java
! test/jdk/java/lang/reflect/code/stream/TestStream.java
! test/jdk/java/lang/reflect/code/stream/TestStreamUsingQuotable.java
! test/jdk/java/lang/reflect/code/type/TestErasure.java
! test/jdk/java/lang/reflect/code/type/TestJavaType.java
! test/jdk/java/lang/reflect/code/type/TestReferences.java
! test/jdk/java/lang/reflect/code/writer/TestCodeBuilder.java
! test/jdk/java/lang/reflect/code/writer/TestNaming.java
! test/jdk/java/lang/reflect/code/writer/TestOptions.java
! test/langtools/jdk/jshell/ComputeFQNsTest.java
! test/langtools/tools/javac/reflect/ArrayAccessTest.java
! test/langtools/tools/javac/reflect/AssertTest.java
! test/langtools/tools/javac/reflect/BinopTest.java
! test/langtools/tools/javac/reflect/BlockTest.java
! test/langtools/tools/javac/reflect/BoxingConversionTest.java
! test/langtools/tools/javac/reflect/BreakContinueTest.java
! test/langtools/tools/javac/reflect/CastInstanceOfTest.java
! test/langtools/tools/javac/reflect/CodeModelSameInstanceTest.java
! test/langtools/tools/javac/reflect/CodeReflectionTester.java
! test/langtools/tools/javac/reflect/ConditionalAndOrTest.java
! test/langtools/tools/javac/reflect/ConditionalExpressionTest.java
! test/langtools/tools/javac/reflect/ConstantsTest.java
! test/langtools/tools/javac/reflect/DenotableTypesTest.java
! test/langtools/tools/javac/reflect/EnumAccessTest.java
! test/langtools/tools/javac/reflect/FieldAccessTest.java
! test/langtools/tools/javac/reflect/ForLoopTest.java
! test/langtools/tools/javac/reflect/IfTest.java
! test/langtools/tools/javac/reflect/ImplicitConversionTest.java
! test/langtools/tools/javac/reflect/IntersectionTypeTest.java
! test/langtools/tools/javac/reflect/LambdaTest.java
! test/langtools/tools/javac/reflect/LocalClassTest.java
! test/langtools/tools/javac/reflect/LocalVarTest.java
! test/langtools/tools/javac/reflect/MethodCallTest.java
! test/langtools/tools/javac/reflect/MethodReferenceTest.java
! test/langtools/tools/javac/reflect/NewArrayTest.java
! test/langtools/tools/javac/reflect/NewTest.java
! test/langtools/tools/javac/reflect/NullTest.java
! test/langtools/tools/javac/reflect/PatternTest2.java
! test/langtools/tools/javac/reflect/PatternsTest.java
! test/langtools/tools/javac/reflect/PrimitiveCastTest.java
! test/langtools/tools/javac/reflect/QuotableIntersectionTest.java
! test/langtools/tools/javac/reflect/QuotableSubtypeTest.java
! test/langtools/tools/javac/reflect/QuotedSameInstanceTest.java
! test/langtools/tools/javac/reflect/QuotedTest.java
! test/langtools/tools/javac/reflect/StringConcatTest.java
! test/langtools/tools/javac/reflect/SuperTest.java
! test/langtools/tools/javac/reflect/SwitchExpressionTest.java
! test/langtools/tools/javac/reflect/SwitchExpressionTest2.java
! test/langtools/tools/javac/reflect/SwitchStatementTest.java
! test/langtools/tools/javac/reflect/SynchronizedTest.java
! test/langtools/tools/javac/reflect/TestIRFromAnnotation.java
! test/langtools/tools/javac/reflect/TestLocalCapture.java
! test/langtools/tools/javac/reflect/ThrowTest.java
! test/langtools/tools/javac/reflect/TryTest.java
! test/langtools/tools/javac/reflect/UnaryopTest.java
! test/langtools/tools/javac/reflect/UnreachableTest.java
! test/langtools/tools/javac/reflect/WhileLoopTest.java
! test/langtools/tools/javac/reflect/quoted/TestAssignment.java
! test/langtools/tools/javac/reflect/quoted/TestAssignment.out
! test/langtools/tools/javac/reflect/quoted/TestCaptureQuotable.java
! test/langtools/tools/javac/reflect/quoted/TestCaptureQuoted.java
! test/langtools/tools/javac/reflect/quoted/TestGenericMethodCall.java
! test/langtools/tools/javac/reflect/quoted/TestGenericMethodCall.out
! test/langtools/tools/javac/reflect/quoted/TestMethodCall.java
! test/langtools/tools/javac/reflect/quoted/TestMethodCall.out
! test/langtools/tools/javac/reflect/quoted/TestRecovery.java
! test/langtools/tools/javac/reflect/quoted/TestRecovery.out


From mcimadamore at openjdk.org  Thu Nov 14 17:24:49 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Nov 2024 17:24:49 GMT
Subject: [code-reflection] Integrated: Move code reflection API into incubating
 module
In-Reply-To: <B8_bPzJ9UWlWKw4zG7hv92Gaz0f_S64Aw9W-lNIojGk=.81a6dd4f-8436-481b-a06c-cb8880078ba2@github.com>
References: <B8_bPzJ9UWlWKw4zG7hv92Gaz0f_S64Aw9W-lNIojGk=.81a6dd4f-8436-481b-a06c-cb8880078ba2@github.com>
Message-ID: <tyLMrUrLrs7HEPXIb3Q2xsgOuK59-q3qryd4_crTXL0=.f60db3b8-5525-4d16-84b6-83124d0c17c6@github.com>

On Thu, 7 Nov 2024 19:20:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR moves the code reflection API into a separate incubating module. In order to do that, Babylon compiler support (`ReflectMethods`) has morphed into a compiler plugin, which is optionally invoked when the user specifies the command line option `--add-modules jdk.incubator.module`.
> 
> #### Basic structure
> 
> The new module `jdk.incubator.module` has the following structure (starred packages are not exported):
> 
> 
> src/jdk.incubator.code/share/classes
> ??? jdk
>     ??? incubator
>         ??? code
>             ??? analysis
>             ??? bytecode
>             ??? compiler (*)
>             ??? internal (*)
>             ??? interpreter
>             ??? op
>             ??? parser
>             ??? ??? impl (*)
>             ??? tools
>             ??? ??? dot
>             ??? ??? renderer
>             ??? type
>             ??? ??? impl (*)
>             ??? writer
> 
> 
> In other words, the new module subsumes the sources under `java.base/java.lang.reflect.code` and those under `jdk.code.tools`.
> 
> #### Compiler plugin
> 
> To decouple the `ReflectMethods` class from `jdk,compiler` we have moved `ReflectMethods` in a new compiler plugin in the new module (see `compiler` package). Compiler plugins are loaded using regular `ServiceLoader` infrastructure. However, here we have an issue: incubator modules are not resolved by default (unless `--add-modules` is used). This means that javac will not look inside `jdk.incubator.code` when finding its plugins.
> 
> To workaround this issue, javac will create a new module layer which points at `jdk.incubator.module` and then call `ServiceLoader::load` by passing that layer (see `BasicJavacTask`). This will force the javac plugin to be loaded, and no additional runtime warnings to be displayed when running javac.
> 
> Some additional tweaks were needed to avoid the creation of a module layer if the incubator module is not present (e.g. if we're using javac in "boostrap mode") or if we're running javac from an exploded build (in which case the incubator module is part of the module graph).
> 
> Note, the `@CodeReflection` annotation has been moved to `jdk.incubator.code`.
> 
> #### Symbol constants
> 
> All code reflection-related symbol constants have migrated from `Symtab` to the `CodeReflectionSymbols` in the new module. This is necessary because the symbols are now defined in a module other than `java.base` and javac `Symtab` cannot resolve references to symbols outside `java.base` early on (`Symtab` is one of the first classes to be initialized in the compiler).
> 
> After ...

This pull request has now been integrated.

Changeset: 18627a63
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/18627a637362a70a72d16b5cbe52d07ddb55c6f9
Stats:     4204 lines in 407 files changed: 1510 ins; 1058 del; 1636 mod

Move code reflection API into incubating module

Reviewed-by: psandoz, asotona

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

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

From paul.sandoz at oracle.com  Thu Nov 14 19:10:09 2024
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 14 Nov 2024 19:10:09 +0000
Subject: Towards incubation...
Message-ID: <964CEFFC-5F08-4882-A926-0AAA548A1218@oracle.com>

Hi,

Maurizio did some excellent work in PR #273 (https://github.com/openjdk/babylon/pull/273), which moves almost all the code reflection implementation and all the API into an incubating module called jdk.incubator.code. This went much better than we initially anticipated.

Compilation and execution using code reflection now requires that jdk.incubator.code module be visible. This is commonly enabled by the command line argument:

  ?add-modules jdk.incubator.code

While there is still a lot of stuff to work out we are architecturally in a good position with a reasonable working solution from which we can build applications, gather feedback, and grow mindshare. Further, this will also provide a stronger foundation for the Heterogeneous Accelerator Toolkit (HAT).

To do that effectively we think we need to incubate in the JDK. This is the first step in that direction. When will we incubate? Don?t exactly know yet. We need to explore at least the following before being ready doing so:

1. Rearrange the operations and types (as discussed in prior email)
2. Evaluate encoding models in class files as methods that build them (we are currently exploring to obtain data on class file sizes)
3. Update to support new language features
4. Do a thorough review of the API (with a view towards minimalism - the API surface is large!)
5. Specify the behavior in documents and JavaDoc

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20241114/c4b58d94/attachment.htm>

From duke at openjdk.org  Fri Nov 15 19:14:23 2024
From: duke at openjdk.org (iotamudelta)
Date: Fri, 15 Nov 2024 19:14:23 GMT
Subject: [code-reflection] RFR: HIP HAT backend
Message-ID: <ZXonaQ4ND_86IeDYLrVM3DK72387ftgjx0asT8-pN3Q=.f62d85f5-5dad-470f-a794-fecc47ec8c59@github.com>

* Use the C99 code path to generate HIP-compliant kernel code.
* Runtime compilation through hipRTC.
* Use standard HIP malloc/free, device inspection for infrastructure.
* Integrate into HAT compilation and examples.
* Confirmed to work on AMD Radeon RX 68000XT w/ ROCm 6.2.2

hipinfo output:
> Using device 0: AMD Radeon RX 6800 XT
> HIP Device has major=10 minor=3 compute capability
> HIP Device has wave front size 32
> HIP Device has threadsPerBlock 1024
> HIP Cores 36
  Total amount of global memory:   17163091968
  64-bit Memory Address:           YES

mandel example:


                          ......................................
                         .......................................
                       .........................................
                       .........................................
                      ..........................................
                     ...........................................
                    ............................................
                   .............................................
                   .............................................
                  ..............................................
                 ................................. ..,..........
                 .................................,,,,..........
                ..................................,:,...........
                ................................,,: :...........
               ................................::,* :,,.........
               .................................,     ,.........
              .................................,:    -,.........
              ............................,...,,,    :,,.....,..
              ..........................,::,,:: --  -#,,#,...:..
             ...........................,,  ,:           ,,:,:,.
             ...........................,:                ,  ,,.
             ...........................,,:                  :..
            ..........................,::                   ,,..
            ..............,...........,,                     *..
            ...............,...,......,:                     :,,
            ...............,,,,,,,,,,,,                       +:
            ...............,,+,, ,-,,,*                       ,.
           ................,:       ,,                        @.
           ...............,,        #,                        ,.
           ............,,,,:         :                        ,.
           ............,-:,                                   ..
           ...........,::                                    ,..
                                                           :,...
           ...........,::                                    ,..
           ............,-:,                                   ..
           ............,,,,:         :                        ,.
           ...............,,        #,                        ,.
           ................,:       ,,                        @.
            ...............,,+,, ,-,,,*                       ,.
            ...............,,,,,,,,,,,,                       +:
            ...............,...,......,:                     :,,
            ..............,...........,,                     *..
            ..........................,::                   ,,..
             ...........................,,:                  :..
             ...........................,:                ,  ,,.
             ...........................,,  ,:           ,,:,:,.
              ..........................,::,,:: --  -#,,#,...:..
              ............................,...,,,    :,,.....,..
              .................................,:    -,.........
               .................................,     ,.........
               ................................::,* :,,.........
                ................................,,: :...........
                ..................................,:,...........
                 .................................,,,,..........
                 ................................. ..,..........
                  ..............................................
                   .............................................
                   .............................................
                    ............................................
                     ...........................................
                      ..........................................
                       .........................................
                       .........................................
                         .......................................

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

Commit messages:
 - Merge branch 'code-reflection' into hip_backend
 - Fix whitespace.
 - Merge branch 'openjdk:code-reflection' into hip_backend
 - Add a HIP backend.

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

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

From duke at openjdk.org  Fri Nov 15 19:14:23 2024
From: duke at openjdk.org (iotamudelta)
Date: Fri, 15 Nov 2024 19:14:23 GMT
Subject: [code-reflection] RFR: HIP HAT backend
In-Reply-To: <ZXonaQ4ND_86IeDYLrVM3DK72387ftgjx0asT8-pN3Q=.f62d85f5-5dad-470f-a794-fecc47ec8c59@github.com>
References: <ZXonaQ4ND_86IeDYLrVM3DK72387ftgjx0asT8-pN3Q=.f62d85f5-5dad-470f-a794-fecc47ec8c59@github.com>
Message-ID: <ppPqdvgsXMHQy4wDMIeeYe5NXd9RVFIyQZd1ktHhSSk=.ac13c47e-7fdb-469f-9c69-b95dbd695655@github.com>

On Mon, 14 Oct 2024 18:53:25 GMT, iotamudelta <duke at openjdk.org> wrote:

> * Use the C99 code path to generate HIP-compliant kernel code.
> * Runtime compilation through hipRTC.
> * Use standard HIP malloc/free, device inspection for infrastructure.
> * Integrate into HAT compilation and examples.
> * Confirmed to work on AMD Radeon RX 68000XT w/ ROCm 6.2.2
> 
> hipinfo output:
>> Using device 0: AMD Radeon RX 6800 XT
>> HIP Device has major=10 minor=3 compute capability
>> HIP Device has wave front size 32
>> HIP Device has threadsPerBlock 1024
>> HIP Cores 36
>   Total amount of global memory:   17163091968
>   64-bit Memory Address:           YES
> 
> mandel example:
> 
> 
>                           ......................................
>                          .......................................
>                        .........................................
>                        .........................................
>                       ..........................................
>                      ...........................................
>                     ............................................
>                    .............................................
>                    .............................................
>                   ..............................................
>                  ................................. ..,..........
>                  .................................,,,,..........
>                 ..................................,:,...........
>                 ................................,,: :...........
>                ................................::,* :,,.........
>                .................................,     ,.........
>               .................................,:    -,.........
>               ............................,...,,,    :,,.....,..
>               ..........................,::,,:: --  -#,,#,...:..
>              ...........................,,  ,:           ,,:,:,.
>              ...........................,:                ,  ,,.
>              ...........................,,:                  :..
>             ..........................,::                   ,,..
>             ..............,...........,,                     *..
>             ...............,...,......,:                     :,,
>             ...............,,,,,,,,,,,,                       +:
>             ...............,,+,, ,-,,,*                       ,.
>            ................,:       ,,                        @.
>            ...............,,        #,                        ,.
>            ............,,,,:      ...

Still waiting on OCA.

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

PR Comment: https://git.openjdk.org/babylon/pull/254#issuecomment-2468987377

From psandoz at openjdk.org  Fri Nov 15 22:16:27 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 15 Nov 2024 22:16:27 GMT
Subject: [code-reflection] RFR: Support bytecode generation for invocation
 of varArg method [v4]
In-Reply-To: <AK1jLJGi-EeG7FuhdE5XgLFkRRPRfn1-sVNM1l5sSbg=.ee9a295b-9e35-4adf-8b7d-f4b85b32cdb8@github.com>
References: <uYto4n_V0XZ07xtLfBJbz9h4JgnTGfu08B6tPAqC8WM=.84bb32d5-517b-40a0-a486-693e7071eaca@github.com>
 <AK1jLJGi-EeG7FuhdE5XgLFkRRPRfn1-sVNM1l5sSbg=.ee9a295b-9e35-4adf-8b7d-f4b85b32cdb8@github.com>
Message-ID: <8erYH9GUr1-p2jOM7G0p0VfCG9bEr8rL3nCrd2O1-4w=.2744f525-797c-4b4b-978a-3dd0bc6a22a0@github.com>

On Sun, 10 Nov 2024 04:26:12 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Support bytecode generation for invocation of varArg method.
>
> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add test for long and double
>  - Apply Suggestions

Marked as reviewed by psandoz (Lead).

src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 1564:

> 1562: 
> 1563:         public List<Value> argOperands() {
> 1564:             if (!isVarArgs()){

Suggestion:

            if (!isVarArgs) {

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

PR Review: https://git.openjdk.org/babylon/pull/272#pullrequestreview-2439804067
PR Review Comment: https://git.openjdk.org/babylon/pull/272#discussion_r1844581019

From mcimadamore at openjdk.org  Mon Nov 18 14:24:28 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 18 Nov 2024 14:24:28 GMT
Subject: [code-reflection] RFR: Turn compiler plugin into simple SPI
Message-ID: <odwQC32bzvuQnaT2b1E3F5T_dyTurx5Nqv_SVAk_Q-0=.0ac39e94-acc7-4a3a-b560-63db65ef4907@github.com>

This PR is a small followup to the changes to turn compiler code reflection support into a compiler plugin.
Turns out that the new plugin required several hacks and workaround, to make sure that the plugin would only run when strictly required (not to affect outcome of compilation if the plugin was disabled). We can get rid of all such workarounds by turning the plugin into a plain and simple SPI. There is a new `ReflectMethodsProxy` interface, which is implemented by the new module (see `ReflectMethods.Provider`). This allows javac to more or less call into the new pipeline step as it did before the incubating change, which leads to code that is much simpler to maintain.

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

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/babylon/pull/275/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=275&range=00
  Stats: 289 lines in 8 files changed: 103 ins; 181 del; 5 mod
  Patch: https://git.openjdk.org/babylon/pull/275.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/275/head:pull/275

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

From psandoz at openjdk.org  Mon Nov 18 17:16:22 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 18 Nov 2024 17:16:22 GMT
Subject: [code-reflection] RFR: Turn compiler plugin into simple SPI
In-Reply-To: <odwQC32bzvuQnaT2b1E3F5T_dyTurx5Nqv_SVAk_Q-0=.0ac39e94-acc7-4a3a-b560-63db65ef4907@github.com>
References: <odwQC32bzvuQnaT2b1E3F5T_dyTurx5Nqv_SVAk_Q-0=.0ac39e94-acc7-4a3a-b560-63db65ef4907@github.com>
Message-ID: <aji5TgBN5MyqN4mZLe-gmwK_7bgGwjmjTiuEJ2DGFoc=.0623629b-21ac-45f9-8e28-fe6af7a64dfd@github.com>

On Mon, 18 Nov 2024 14:18:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR is a small followup to the changes to turn compiler code reflection support into a compiler plugin.
> Turns out that the new plugin required several hacks and workaround, to make sure that the plugin would only run when strictly required (not to affect outcome of compilation if the plugin was disabled). We can get rid of all such workarounds by turning the plugin into a plain and simple SPI. There is a new `ReflectMethodsProxy` interface, which is implemented by the new module (see `ReflectMethods.Provider`). This allows javac to more or less call into the new pipeline step as it did before the incubating change, which leads to code that is much simpler to maintain.

Perhaps we should rename `ReflectMethodsProxy` to `CodeReflectionTransformer` use similar naming?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethodsProxy.java line 39:

> 37: public interface ReflectMethodsProxy {
> 38:     /**
> 39:      * Analyze the {@code CodeReflection} annotations in the method of the provided class.

And quotable/quoted lambda expressions.

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

Marked as reviewed by psandoz (Lead).

PR Review: https://git.openjdk.org/babylon/pull/275#pullrequestreview-2443229554
PR Review Comment: https://git.openjdk.org/babylon/pull/275#discussion_r1846961380

From mcimadamore at openjdk.org  Mon Nov 18 18:49:49 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 18 Nov 2024 18:49:49 GMT
Subject: [code-reflection] RFR: Turn compiler plugin into simple SPI [v2]
In-Reply-To: <odwQC32bzvuQnaT2b1E3F5T_dyTurx5Nqv_SVAk_Q-0=.0ac39e94-acc7-4a3a-b560-63db65ef4907@github.com>
References: <odwQC32bzvuQnaT2b1E3F5T_dyTurx5Nqv_SVAk_Q-0=.0ac39e94-acc7-4a3a-b560-63db65ef4907@github.com>
Message-ID: <1A2QSAZQhdV-QaZ7yPQg6_ErV-tXac3xxAsj5SBWnuA=.3d5b907f-ac12-4186-b326-d7ba4873900d@github.com>

> This PR is a small followup to the changes to turn compiler code reflection support into a compiler plugin.
> Turns out that the new plugin required several hacks and workaround, to make sure that the plugin would only run when strictly required (not to affect outcome of compilation if the plugin was disabled). We can get rid of all such workarounds by turning the plugin into a plain and simple SPI. There is a new `ReflectMethodsProxy` interface, which is implemented by the new module (see `ReflectMethods.Provider`). This allows javac to more or less call into the new pipeline step as it did before the incubating change, which leads to code that is much simpler to maintain.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/275/files
  - new: https://git.openjdk.org/babylon/pull/275/files/016323db..f9ed4ac2

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

  Stats: 106 lines in 6 files changed: 49 ins; 49 del; 8 mod
  Patch: https://git.openjdk.org/babylon/pull/275.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/275/head:pull/275

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

From mcimadamore at openjdk.org  Mon Nov 18 18:51:54 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 18 Nov 2024 18:51:54 GMT
Subject: git: openjdk/babylon: code-reflection: Turn compiler plugin into
 simple SPI
Message-ID: <5d066d99-70d5-4a7c-b595-c59947f875b9@openjdk.org>

Changeset: 152f4678
Branch: code-reflection
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-11-18 18:50:34 +0000
URL:       https://git.openjdk.org/babylon/commit/152f4678c2ec50d5bbff04d76be7b007676b39e7

Turn compiler plugin into simple SPI

Reviewed-by: psandoz

! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java
+ src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CodeReflectionTransformer.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/jdk.compiler/share/classes/module-info.java
! src/jdk.incubator.code/share/classes/jdk/incubator/code/Op.java
- src/jdk.incubator.code/share/classes/jdk/incubator/code/compiler/CodeReflectionPlugin.java
! src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java
! src/jdk.incubator.code/share/classes/module-info.java


From mcimadamore at openjdk.org  Mon Nov 18 18:53:57 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 18 Nov 2024 18:53:57 GMT
Subject: [code-reflection] Integrated: Turn compiler plugin into simple SPI
In-Reply-To: <odwQC32bzvuQnaT2b1E3F5T_dyTurx5Nqv_SVAk_Q-0=.0ac39e94-acc7-4a3a-b560-63db65ef4907@github.com>
References: <odwQC32bzvuQnaT2b1E3F5T_dyTurx5Nqv_SVAk_Q-0=.0ac39e94-acc7-4a3a-b560-63db65ef4907@github.com>
Message-ID: <xNUWJULaHrBAWt9z8sLdpNfUcZlrj2Lxjo5FlvT9Hng=.d1b46fee-1988-457a-b1ba-3ba80c89b3f6@github.com>

On Mon, 18 Nov 2024 14:18:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR is a small followup to the changes to turn compiler code reflection support into a compiler plugin.
> Turns out that the new plugin required several hacks and workaround, to make sure that the plugin would only run when strictly required (not to affect outcome of compilation if the plugin was disabled). We can get rid of all such workarounds by turning the plugin into a plain and simple SPI. There is a new `ReflectMethodsProxy` interface, which is implemented by the new module (see `ReflectMethods.Provider`). This allows javac to more or less call into the new pipeline step as it did before the incubating change, which leads to code that is much simpler to maintain.

This pull request has now been integrated.

Changeset: 152f4678
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/152f4678c2ec50d5bbff04d76be7b007676b39e7
Stats:     296 lines in 8 files changed: 106 ins; 184 del; 6 mod

Turn compiler plugin into simple SPI

Reviewed-by: psandoz

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

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

From mabbay at openjdk.org  Tue Nov 19 15:32:00 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 19 Nov 2024 15:32:00 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v7]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <m4V9pyKJyPi8gx2e2xTw1OVrMSRsAp-88NZFjzq_xMM=.4745f9ae-2598-46a3-b407-d0ecb146e9ba@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

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

 - Modify the script to run on all compiler tests classes one by one
 - Box value before invoking Map.put

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/8e9e7963..80ee7f84

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

  Stats: 297 lines in 4 files changed: 158 ins; 139 del; 0 mod
  Patch: https://git.openjdk.org/babylon/pull/274.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/274/head:pull/274

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

From mabbay at openjdk.org  Wed Nov 20 19:18:10 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 20 Nov 2024 19:18:10 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v8]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <3JAq_b-gPVK1K7HwTIliUo3z8HgG2OiemAeAJntd9KI=.9f32d801-4288-4b66-bb13-5835f04c30d0@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

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

  Write data to csv file

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/80ee7f84..b714c13a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=07
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=06-07

  Stats: 9 lines in 2 files changed: 6 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/babylon/pull/274.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/274/head:pull/274

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

From mabbay at openjdk.org  Wed Nov 20 19:47:31 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 20 Nov 2024 19:47:31 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v9]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <9_-rjmxSOHQJHgbULOaubUGFa1zUlaOKkTx1AqD3Hu0=.10179211-457f-4d66-8976-e500277554f5@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

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

  Write the columns names after all processing is done

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/b714c13a..c42b2b0e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=08
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=07-08

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

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

From asotona at openjdk.org  Thu Nov 21 10:07:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Nov 2024 10:07:37 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v9]
In-Reply-To: <9_-rjmxSOHQJHgbULOaubUGFa1zUlaOKkTx1AqD3Hu0=.10179211-457f-4d66-8976-e500277554f5@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
 <9_-rjmxSOHQJHgbULOaubUGFa1zUlaOKkTx1AqD3Hu0=.10179211-457f-4d66-8976-e500277554f5@github.com>
Message-ID: <SklHlWtb8J6a3jlzWW_klIZfa7-9FhnLTb0wGuAWS7Q=.023cabc5-514f-4e05-b31d-d0df52b1298f@github.com>

On Wed, 20 Nov 2024 19:47:31 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Experiment with replacing textual representation in classfile with method that builds the model.
>> Note: This PR is based on changes from #272.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Write the columns names after all processing is done

src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 198:

> 196:     }
> 197: 
> 198:     public static byte[] addOpByteCodeToClassFile(MethodHandles.Lookup lookup, ClassModel cm, String methodName, FuncOp builderOp) {

Is this method still used?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/274#discussion_r1851733294

From gfrost at openjdk.org  Thu Nov 21 12:43:42 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 21 Nov 2024 12:43:42 GMT
Subject: git: openjdk/babylon: code-reflection: Fixed race condition in
 C99HatKernelBuilder.java and cleaned build
Message-ID: <52a4746c-6157-4c6a-8fa7-53eba7d40a46@openjdk.org>

Changeset: ec24b9bd
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-11-21 12:40:57 +0000
URL:       https://git.openjdk.org/babylon/commit/ec24b9bd771db1bda445b2ce2196d62cadcc591a

Fixed race condition in C99HatKernelBuilder.java and cleaned build

! hat/bld
! hat/bldr/Bldr.java
+ hat/bldr/MavenStyleRepository.java
+ hat/bldr/XMLNode.java
+ hat/bldr/bld
+ hat/bldr/hatrun
+ hat/bldr/java
+ hat/bldr/opencl
+ hat/bldr/sanity
! hat/hat/src/main/java/hat/backend/c99codebuilders/C99HatKernelBuilder.java
+ hat/hat/src/main/test/logger/HATTestNGLogger.java
! hat/hatrun
! hat/sanity


From gfrost at openjdk.org  Thu Nov 21 12:44:18 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 21 Nov 2024 12:44:18 GMT
Subject: [code-reflection] Integrated: Fixed race condition in
 C99HatKernelBuilder.java and cleaned build
Message-ID: <5X7WUVLQxM5cZGvOSWp0XHXKrQVvzXGfQZekFUfXpNo=.174d5b09-4a01-4006-9e41-8c4eb64db5ab@github.com>

Apparently we have been generating OpenCL+CUDA code with a race condition..

Bizarely code works just fine on Mac + OpenCL/Metal. 

Failed on linux. 

This includes a fix for that, and some build cleanup

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

Commit messages:
 - Fixed race condition in C99HatKernelBuilder.java and cleaned build scripts whitespace
 - Merge branch 'code-reflection' into hat-remove-race-condition-in-c99-codegen
 - Fixed race condition in C99HatKernelBuilder.java and cleaned build scripts whitespace
 - Fixed race condition in C99HatKernelBuilder.java and cleaned build scripts whitespace
 - Fixed race condition in C99HatKernelBuilder.java and cleaned build scripts

Changes: https://git.openjdk.org/babylon/pull/277/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=277&range=00
  Stats: 2471 lines in 13 files changed: 1740 ins; 284 del; 447 mod
  Patch: https://git.openjdk.org/babylon/pull/277.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/277/head:pull/277

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

From gfrost at openjdk.org  Thu Nov 21 12:44:20 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 21 Nov 2024 12:44:20 GMT
Subject: [code-reflection] Integrated: Fixed race condition in
 C99HatKernelBuilder.java and cleaned build
In-Reply-To: <5X7WUVLQxM5cZGvOSWp0XHXKrQVvzXGfQZekFUfXpNo=.174d5b09-4a01-4006-9e41-8c4eb64db5ab@github.com>
References: <5X7WUVLQxM5cZGvOSWp0XHXKrQVvzXGfQZekFUfXpNo=.174d5b09-4a01-4006-9e41-8c4eb64db5ab@github.com>
Message-ID: <k6MQVZ-wiR1oMXrDFMjZT8UvZelFRjVqKcuFrNteucE=.6fd1e744-3ff7-47ee-afee-b9635283330d@github.com>

On Thu, 21 Nov 2024 12:22:14 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Apparently we have been generating OpenCL+CUDA code with a race condition..
> 
> Bizarely code works just fine on Mac + OpenCL/Metal. 
> 
> Failed on linux. 
> 
> This includes a fix for that, and some build cleanup

This pull request has now been integrated.

Changeset: ec24b9bd
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/ec24b9bd771db1bda445b2ce2196d62cadcc591a
Stats:     2471 lines in 13 files changed: 1740 ins; 284 del; 447 mod

Fixed race condition in C99HatKernelBuilder.java and cleaned build

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

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

From mabbay at openjdk.org  Thu Nov 21 17:12:04 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 21 Nov 2024 17:12:04 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v10]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <qnAPiuUJz8F47KDeHJcUdWzUQUE2Vcu_OjdBaAgl-tk=.9e7ea553-d3c4-4b9f-b9e8-05ea4e0e35c5@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

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

  Remove unused method.

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/c42b2b0e..0819eaa6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=09
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=08-09

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

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

From mabbay at openjdk.org  Thu Nov 21 17:12:04 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 21 Nov 2024 17:12:04 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v9]
In-Reply-To: <SklHlWtb8J6a3jlzWW_klIZfa7-9FhnLTb0wGuAWS7Q=.023cabc5-514f-4e05-b31d-d0df52b1298f@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
 <9_-rjmxSOHQJHgbULOaubUGFa1zUlaOKkTx1AqD3Hu0=.10179211-457f-4d66-8976-e500277554f5@github.com>
 <SklHlWtb8J6a3jlzWW_klIZfa7-9FhnLTb0wGuAWS7Q=.023cabc5-514f-4e05-b31d-d0df52b1298f@github.com>
Message-ID: <VZp58rBIGEGGFluvnVMN2MNnnun4A-7jCV5FQeLFmKY=.7526b43c-904f-4f6d-a8d0-8fe09a1db783@github.com>

On Thu, 21 Nov 2024 10:05:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Write the columns names after all processing is done
>
> src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 198:
> 
>> 196:     }
>> 197: 
>> 198:     public static byte[] addOpByteCodeToClassFile(MethodHandles.Lookup lookup, ClassModel cm, String methodName, FuncOp builderOp) {
> 
> Is this method still used?

No it's not used, I will remove it.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/274#discussion_r1852542843

From mcimadamore at openjdk.org  Thu Nov 21 22:00:45 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 21 Nov 2024 22:00:45 GMT
Subject: [code-reflection] RFR: Regression: compiler SPI does not work with
 exploded build
Message-ID: <4uzCetQaMBfcE5C-McjCom4w_RFizAMtw2hANLeM8mo=.4d9738d4-d4f0-4f78-b8e8-fec0d74dbf9c@github.com>

The recent refactoring from compiler plugin to simple SPI introduced a regression.
With compiler plugins, the code-reflection extension was effectively loaded in two steps:
* if the code reflection module was not available in the boot layer, then an attempt was made to load it from a fresh layer created on the fly
* otherwise, plugins were searched in the boot layer (like for any other regular plugin)

When running in exploded mode, incubating modules are part of the boot layer, so they are loaded normally (w/o the need of an extra layer).
Unfortunately, the recent refactoring from plugin to SPI removed the second kind of lookup, meaning that now javac will no longer look for an extension in the boot layer.

The solution is simple: javac should look in the fresh layer if it has created one (meaning the incubating module is not part of the boot layer); otherwise, it should just look for the extension in the boot layer.

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

Commit messages:
 - Fix issue with exploded build

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

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

From psandoz at openjdk.org  Thu Nov 21 23:21:32 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 21 Nov 2024 23:21:32 GMT
Subject: [code-reflection] RFR: Regression: compiler SPI does not work with
 exploded build
In-Reply-To: <4uzCetQaMBfcE5C-McjCom4w_RFizAMtw2hANLeM8mo=.4d9738d4-d4f0-4f78-b8e8-fec0d74dbf9c@github.com>
References: <4uzCetQaMBfcE5C-McjCom4w_RFizAMtw2hANLeM8mo=.4d9738d4-d4f0-4f78-b8e8-fec0d74dbf9c@github.com>
Message-ID: <ZNWBGwqFJSN2NjN8cWgp264-L-0m9w36QFAYZoUDe74=.92f0eaca-a280-428d-97ce-f79538e4e580@github.com>

On Thu, 21 Nov 2024 21:55:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The recent refactoring from compiler plugin to simple SPI introduced a regression.
> With compiler plugins, the code-reflection extension was effectively loaded in two steps:
> * if the code reflection module was not available in the boot layer, then an attempt was made to load it from a fresh layer created on the fly
> * otherwise, plugins were searched in the boot layer (like for any other regular plugin)
> 
> When running in exploded mode, incubating modules are part of the boot layer, so they are loaded normally (w/o the need of an extra layer).
> Unfortunately, the recent refactoring from plugin to SPI removed the second kind of lookup, meaning that now javac will no longer look for an extension in the boot layer.
> 
> The solution is simple: javac should look in the fresh layer if it has created one (meaning the incubating module is not part of the boot layer); otherwise, it should just look for the extension in the boot layer.

To be on the safe side should we do it like the following?

            if (ModuleLayer.boot().findModule("jdk.incubator.code").isPresent()) {
                CODE_LAYER = ModuleLayer.boot();
            } else if (java.lang.module.ModuleFinder.ofSystem().find("jdk.incubator.code").isPresent()) {
            ...
            } else {
                // if we run javac in bootstrap mode, there might be no jdk.incubator.code
                CODE_LAYER = null;
            }

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

PR Comment: https://git.openjdk.org/babylon/pull/278#issuecomment-2492548919

From mcimadamore at openjdk.org  Fri Nov 22 11:06:52 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Nov 2024 11:06:52 GMT
Subject: [code-reflection] RFR: Regression: compiler SPI does not work with
 exploded build
In-Reply-To: <ZNWBGwqFJSN2NjN8cWgp264-L-0m9w36QFAYZoUDe74=.92f0eaca-a280-428d-97ce-f79538e4e580@github.com>
References: <4uzCetQaMBfcE5C-McjCom4w_RFizAMtw2hANLeM8mo=.4d9738d4-d4f0-4f78-b8e8-fec0d74dbf9c@github.com>
 <ZNWBGwqFJSN2NjN8cWgp264-L-0m9w36QFAYZoUDe74=.92f0eaca-a280-428d-97ce-f79538e4e580@github.com>
Message-ID: <0-KGdce79suc5rR3pt1JDunA4IIcvtlOAXYg7DBEJzw=.91e804da-674f-4438-97f6-bbc88dbec567@github.com>

On Thu, 21 Nov 2024 23:18:30 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> To be on the safe side should we do it like the following?
> 
> ```
>             if (ModuleLayer.boot().findModule("jdk.incubator.code").isPresent()) {
>                 CODE_LAYER = ModuleLayer.boot();
>             } else if (java.lang.module.ModuleFinder.ofSystem().find("jdk.incubator.code").isPresent()) {
>             ...
>             } else {
>                 // if we run javac in bootstrap mode, there might be no jdk.incubator.code
>                 CODE_LAYER = null;
>             }
> ```

Yeah, this might be a good idea.

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

PR Comment: https://git.openjdk.org/babylon/pull/278#issuecomment-2493494140

From mcimadamore at openjdk.org  Fri Nov 22 12:17:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Nov 2024 12:17:11 GMT
Subject: [code-reflection] RFR: Regression: compiler SPI does not work with
 exploded build [v2]
In-Reply-To: <4uzCetQaMBfcE5C-McjCom4w_RFizAMtw2hANLeM8mo=.4d9738d4-d4f0-4f78-b8e8-fec0d74dbf9c@github.com>
References: <4uzCetQaMBfcE5C-McjCom4w_RFizAMtw2hANLeM8mo=.4d9738d4-d4f0-4f78-b8e8-fec0d74dbf9c@github.com>
Message-ID: <ERbNjL_-HH0dNfIkL-zhKSL3wzsQmhZ-jm6GlGrklUY=.2fecf265-0f76-4b47-8e81-5a662de11bd6@github.com>

> The recent refactoring from compiler plugin to simple SPI introduced a regression.
> With compiler plugins, the code-reflection extension was effectively loaded in two steps:
> * if the code reflection module was not available in the boot layer, then an attempt was made to load it from a fresh layer created on the fly
> * otherwise, plugins were searched in the boot layer (like for any other regular plugin)
> 
> When running in exploded mode, incubating modules are part of the boot layer, so they are loaded normally (w/o the need of an extra layer).
> Unfortunately, the recent refactoring from plugin to SPI removed the second kind of lookup, meaning that now javac will no longer look for an extension in the boot layer.
> 
> The solution is simple: javac should look in the fresh layer if it has created one (meaning the incubating module is not part of the boot layer); otherwise, it should just look for the extension in the boot layer.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Improve reliability of module layer lookup

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/278/files
  - new: https://git.openjdk.org/babylon/pull/278/files/af8e4160..87da6699

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

  Stats: 33 lines in 2 files changed: 21 ins; 5 del; 7 mod
  Patch: https://git.openjdk.org/babylon/pull/278.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/278/head:pull/278

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

From mcimadamore at openjdk.org  Fri Nov 22 14:20:26 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Nov 2024 14:20:26 GMT
Subject: git: openjdk/babylon: code-reflection: Regression: compiler SPI does
 not work with exploded build
Message-ID: <dd25e525-80b2-46c3-98b6-1615096d1a0e@openjdk.org>

Changeset: f266110c
Branch: code-reflection
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-11-22 14:19:04 +0000
URL:       https://git.openjdk.org/babylon/commit/f266110ce1394c2a98cfe5aa01bb37a2d21a0bef

Regression: compiler SPI does not work with exploded build

! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java


From mcimadamore at openjdk.org  Fri Nov 22 14:22:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Nov 2024 14:22:34 GMT
Subject: [code-reflection] Integrated: Regression: compiler SPI does not work
 with exploded build
In-Reply-To: <4uzCetQaMBfcE5C-McjCom4w_RFizAMtw2hANLeM8mo=.4d9738d4-d4f0-4f78-b8e8-fec0d74dbf9c@github.com>
References: <4uzCetQaMBfcE5C-McjCom4w_RFizAMtw2hANLeM8mo=.4d9738d4-d4f0-4f78-b8e8-fec0d74dbf9c@github.com>
Message-ID: <4lUrpELbGUhF5v_LEvDM0yxnLFasV-a8nw7SNpnhzMw=.11111148-a687-4fc8-bd0d-a2f2d6fc209b@github.com>

On Thu, 21 Nov 2024 21:55:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The recent refactoring from compiler plugin to simple SPI introduced a regression.
> With compiler plugins, the code-reflection extension was effectively loaded in two steps:
> * if the code reflection module was not available in the boot layer, then an attempt was made to load it from a fresh layer created on the fly
> * otherwise, plugins were searched in the boot layer (like for any other regular plugin)
> 
> When running in exploded mode, incubating modules are part of the boot layer, so they are loaded normally (w/o the need of an extra layer).
> Unfortunately, the recent refactoring from plugin to SPI removed the second kind of lookup, meaning that now javac will no longer look for an extension in the boot layer.
> 
> The solution is simple: javac should look in the fresh layer if it has created one (meaning the incubating module is not part of the boot layer); otherwise, it should just look for the extension in the boot layer.

This pull request has now been integrated.

Changeset: f266110c
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/f266110ce1394c2a98cfe5aa01bb37a2d21a0bef
Stats:     35 lines in 2 files changed: 20 ins; 8 del; 7 mod

Regression: compiler SPI does not work with exploded build

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

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

From gfrost at openjdk.org  Fri Nov 22 14:49:09 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 22 Nov 2024 14:49:09 GMT
Subject: git: openjdk/babylon: code-reflection: bld/hatrun fixes after PR 278
Message-ID: <ddf9f958-99da-4f15-8e96-9bdf3cc5ad6c@openjdk.org>

Changeset: b185abaf
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-11-22 14:46:31 +0000
URL:       https://git.openjdk.org/babylon/commit/b185abaf7a677dd5e42d1ef531e2d74badf7fed1

bld/hatrun fixes after PR 278

! hat/bld
! hat/bldr/Bldr.java
! hat/examples/pom.xml
! hat/hat/src/main/test/hat/CustomOpTest.java
! hat/hat/src/main/test/hat/SquaresTest.java
! hat/hatrun
! hat/hatrun.bash
! hat/intellij/.idea/compiler.xml
! hat/intellij/.idea/vcs.xml
! hat/maven-build.bash


From gfrost at openjdk.org  Fri Nov 22 14:50:03 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 22 Nov 2024 14:50:03 GMT
Subject: [code-reflection] Integrated: bld/hatrun fixes after PR 278
Message-ID: <awQ_qJ2CWzCLIRRKvVjkBFknSu5tfwJx_k-LIr44G88=.c76e30e7-bf7f-4941-9bfa-875157922604@github.com>

I messed up the bld/hatrun launcher scripts on my previous push 

Here I added back in the --add-modules jdk.incubator.code needed for compiling and running

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

Commit messages:
 - don't include my pom changes
 - bld/hatrun fixes after PR 278

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

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

From gfrost at openjdk.org  Fri Nov 22 14:50:03 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 22 Nov 2024 14:50:03 GMT
Subject: [code-reflection] Integrated: bld/hatrun fixes after PR 278
In-Reply-To: <awQ_qJ2CWzCLIRRKvVjkBFknSu5tfwJx_k-LIr44G88=.c76e30e7-bf7f-4941-9bfa-875157922604@github.com>
References: <awQ_qJ2CWzCLIRRKvVjkBFknSu5tfwJx_k-LIr44G88=.c76e30e7-bf7f-4941-9bfa-875157922604@github.com>
Message-ID: <GBzwKJBTvP2BomnHvouNcSxKJFN-jarppDfsvO7BSas=.762497e2-f54a-4285-9cc9-6660bf4dd3ae@github.com>

On Fri, 22 Nov 2024 14:42:18 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> I messed up the bld/hatrun launcher scripts on my previous push 
> 
> Here I added back in the --add-modules jdk.incubator.code needed for compiling and running

This pull request has now been integrated.

Changeset: b185abaf
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/b185abaf7a677dd5e42d1ef531e2d74badf7fed1
Stats:     20 lines in 10 files changed: 11 ins; 3 del; 6 mod

bld/hatrun fixes after PR 278

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

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

From gfrost at openjdk.org  Sun Nov 24 12:43:55 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 24 Nov 2024 12:43:55 GMT
Subject: git: openjdk/babylon: code-reflection: Simplify pom.xml and maven
 build doc
Message-ID: <eba015e4-b4fc-4592-9670-ab565296de20@openjdk.org>

Changeset: 9afe3b74
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-11-24 12:43:19 +0000
URL:       https://git.openjdk.org/babylon/commit/9afe3b74500b44a915687a19dbcea4f86f00b31e

Simplify pom.xml and maven build doc

! hat/docs/hat-01-03-building-hat-with-maven.md
! hat/pom.xml


From gfrost at openjdk.org  Sun Nov 24 12:46:40 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 24 Nov 2024 12:46:40 GMT
Subject: [code-reflection] Integrated: Simplify pom.xml and maven build doc
Message-ID: <6sjlJgiAknd1sqiCylGpLrVoWhm9xnXiWngDaOWMiug=.a91bbe02-f95b-4bc3-ad7c-98e1bda1722b@github.com>

Simplified root pom.xml (no github vars needed) + maven build docs.

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

Commit messages:
 - Simplify pom.xml and maven build doc

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

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

From gfrost at openjdk.org  Sun Nov 24 12:46:40 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Sun, 24 Nov 2024 12:46:40 GMT
Subject: [code-reflection] Integrated: Simplify pom.xml and maven build doc
In-Reply-To: <6sjlJgiAknd1sqiCylGpLrVoWhm9xnXiWngDaOWMiug=.a91bbe02-f95b-4bc3-ad7c-98e1bda1722b@github.com>
References: <6sjlJgiAknd1sqiCylGpLrVoWhm9xnXiWngDaOWMiug=.a91bbe02-f95b-4bc3-ad7c-98e1bda1722b@github.com>
Message-ID: <tw3w14C2-U6Cd81kxW4w1NLyybtD9AnwEv6i_Ue77qA=.35446d7e-fffa-4586-9bab-6907fe683123@github.com>

On Sun, 24 Nov 2024 12:41:32 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Simplified root pom.xml (no github vars needed) + maven build docs.

This pull request has now been integrated.

Changeset: 9afe3b74
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/9afe3b74500b44a915687a19dbcea4f86f00b31e
Stats:     24 lines in 2 files changed: 0 ins; 21 del; 3 mod

Simplify pom.xml and maven build doc

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

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

From mabbay at openjdk.org  Mon Nov 25 15:37:20 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 25 Nov 2024 15:37:20 GMT
Subject: [code-reflection] RFR: Experiment with replacing textual
 representation in classfile with method that builds the model [v11]
In-Reply-To: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
References: <MKKUFFqx8QD4oeYrdiHHwhZALd_6ovjoNaIFnnEwrXc=.cb2aa1a0-7c60-4517-b753-aa474edfe25e@github.com>
Message-ID: <cfl6Vp493gN2u9D9sea9Tk1Bc5IMJPUq9w4DkVwIxCc=.2e8c7895-59df-43d0-9d40-afd082f9ab2a@github.com>

> Experiment with replacing textual representation in classfile with method that builds the model.
> Note: This PR is based on changes from #272.

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

  Add script for running text to code builder on hat examples

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/274/files
  - new: https://git.openjdk.org/babylon/pull/274/files/0819eaa6..f54adb7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=10
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=274&range=09-10

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

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

From gfrost at openjdk.org  Tue Nov 26 11:40:57 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 26 Nov 2024 11:40:57 GMT
Subject: git: openjdk/babylon: code-reflection: using auto generated poms also
 a fix for CustomOpTest
Message-ID: <ad1a7e72-7064-40c7-8458-bb54cf393a10@openjdk.org>

Changeset: 0101fa45
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-11-26 11:38:38 +0000
URL:       https://git.openjdk.org/babylon/commit/0101fa45570850a5991bf18943ad07b295f28dfb

using auto generated poms also a fix for CustomOpTest

! hat/backends/opencl/pom.xml
! hat/backends/pom.xml
! hat/backends/ptx/pom.xml
+ hat/bldr/clean
+ hat/clean
! hat/examples/blackscholes/pom.xml
! hat/examples/heal/pom.xml
! hat/examples/life/pom.xml
! hat/examples/mandel/pom.xml
! hat/examples/pom.xml
! hat/examples/squares/pom.xml
! hat/examples/violajones/pom.xml
! hat/hat/pom.xml
! hat/hat/src/main/test/hat/CustomOpTest.java
! hat/pom.xml


From gfrost at openjdk.org  Tue Nov 26 11:41:51 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 26 Nov 2024 11:41:51 GMT
Subject: [code-reflection] Integrated: using auto generated poms also a fix for
 CustomOpTest
Message-ID: <5Z3skGSpPmw3GdadxP3aMY_-DMtR8_Lc2knbtTyfs3k=.3b569e8b-68de-468e-906a-338f333b01c3@github.com>

As many pom.xml files are similar.  We now autogenerate them (I will check in the code for generating them next), this greatly simplifies maintenance. 

I also found that the CustomOpTest was failing after the transition to jdk.incubator.code so we have that fix

Added bldr/clean and clean, so now we can 


java @bldr/clean 
java @bldr/bld
java @bldr/hatrun opencl heal

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

Commit messages:
 - using auto generated poms also a fix for CustomOpTest

Changes: https://git.openjdk.org/babylon/pull/281/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=281&range=00
  Stats: 535 lines in 15 files changed: 158 ins; 207 del; 170 mod
  Patch: https://git.openjdk.org/babylon/pull/281.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/281/head:pull/281

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

From gfrost at openjdk.org  Tue Nov 26 11:41:52 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 26 Nov 2024 11:41:52 GMT
Subject: [code-reflection] Integrated: using auto generated poms also a fix for
 CustomOpTest
In-Reply-To: <5Z3skGSpPmw3GdadxP3aMY_-DMtR8_Lc2knbtTyfs3k=.3b569e8b-68de-468e-906a-338f333b01c3@github.com>
References: <5Z3skGSpPmw3GdadxP3aMY_-DMtR8_Lc2knbtTyfs3k=.3b569e8b-68de-468e-906a-338f333b01c3@github.com>
Message-ID: <oTzY3QNAbg9XTEmP6mvQQVvH7LxQCswIeC2bkiuOhbo=.d65bed6a-b44f-4beb-b920-c72a20b12f98@github.com>

On Tue, 26 Nov 2024 11:36:12 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> As many pom.xml files are similar.  We now autogenerate them (I will check in the code for generating them next), this greatly simplifies maintenance. 
> 
> I also found that the CustomOpTest was failing after the transition to jdk.incubator.code so we have that fix
> 
> Added bldr/clean and clean, so now we can 
> 
> 
> java @bldr/clean 
> java @bldr/bld
> java @bldr/hatrun opencl heal

This pull request has now been integrated.

Changeset: 0101fa45
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/0101fa45570850a5991bf18943ad07b295f28dfb
Stats:     535 lines in 15 files changed: 158 ins; 207 del; 170 mod

using auto generated poms also a fix for CustomOpTest

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

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

From duke at openjdk.org  Tue Nov 26 17:11:35 2024
From: duke at openjdk.org (iotamudelta)
Date: Tue, 26 Nov 2024 17:11:35 GMT
Subject: [code-reflection] RFR: HIP HAT backend [v2]
In-Reply-To: <ZXonaQ4ND_86IeDYLrVM3DK72387ftgjx0asT8-pN3Q=.f62d85f5-5dad-470f-a794-fecc47ec8c59@github.com>
References: <ZXonaQ4ND_86IeDYLrVM3DK72387ftgjx0asT8-pN3Q=.f62d85f5-5dad-470f-a794-fecc47ec8c59@github.com>
Message-ID: <PghyOV4oNdfDIma0QCfAl_91-u1vi72bW7jT9bT7vKA=.c39571bf-f2d2-4c23-a8da-3b1fe56c4626@github.com>

> * Use the C99 code path to generate HIP-compliant kernel code.
> * Runtime compilation through hipRTC.
> * Use standard HIP malloc/free, device inspection for infrastructure.
> * Integrate into HAT compilation and examples.
> * Confirmed to work on AMD Radeon RX 68000XT w/ ROCm 6.2.2
> 
> hipinfo output:
>> Using device 0: AMD Radeon RX 6800 XT
>> HIP Device has major=10 minor=3 compute capability
>> HIP Device has wave front size 32
>> HIP Device has threadsPerBlock 1024
>> HIP Cores 36
>   Total amount of global memory:   17163091968
>   64-bit Memory Address:           YES
> 
> mandel example:
> 
> 
>                           ......................................
>                          .......................................
>                        .........................................
>                        .........................................
>                       ..........................................
>                      ...........................................
>                     ............................................
>                    .............................................
>                    .............................................
>                   ..............................................
>                  ................................. ..,..........
>                  .................................,,,,..........
>                 ..................................,:,...........
>                 ................................,,: :...........
>                ................................::,* :,,.........
>                .................................,     ,.........
>               .................................,:    -,.........
>               ............................,...,,,    :,,.....,..
>               ..........................,::,,:: --  -#,,#,...:..
>              ...........................,,  ,:           ,,:,:,.
>              ...........................,:                ,  ,,.
>              ...........................,,:                  :..
>             ..........................,::                   ,,..
>             ..............,...........,,                     *..
>             ...............,...,......,:                     :,,
>             ...............,,,,,,,,,,,,                       +:
>             ...............,,+,, ,-,,,*                       ,.
>            ................,:       ,,                        @.
>            ...............,,        #,                        ,.
>            ............,,,,:      ...

iotamudelta 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 hip_backend
 - Merge branch 'code-reflection' into hip_backend
 - Fix whitespace.
 - Merge branch 'openjdk:code-reflection' into hip_backend
 - Add a HIP backend.
   
   * Use the C99 code path to generate HIP-compliant kernel code.
   * Compile code using runtime compilation through hipRTC.
   * Use standard HIP malloc/free, device inspection for infrastructure.
   * Integrate into HAT compilation and examples.
   * Confirmed to work on AMD Radeon RX 68000XT w/ ROCm 6.2.2
   
   hipinfo output:
   > Using device 0: AMD Radeon RX 6800 XT
   > HIP Device has major=10 minor=3 compute capability
   > HIP Device has wave front size 32
   > HIP Device has threadsPerBlock 1024
   > HIP Cores 36
     Total amount of global memory:   17163091968
     64-bit Memory Address:           YES
   
   mandel example:
   
                             ......................................
                            .......................................
                          .........................................
                          .........................................
                         ..........................................
                        ...........................................
                       ............................................
                      .............................................
                      .............................................
                     ..............................................
                    ................................. ..,..........
                    .................................,,,,..........
                   ..................................,:,...........
                   ................................,,: :...........
                  ................................::,* :,,.........
                  .................................,     ,.........
                 .................................,:    -,.........
                 ............................,...,,,    :,,.....,..
                 ..........................,::,,:: --  -#,,#,...:..
                ...........................,,  ,:           ,,:,:,.
                ...........................,:                ,  ,,.
                ...........................,,:                  :..
               ..........................,::                   ,,..
               ..............,...........,,                     *..
               ...............,...,......,:                     :,,
               ...............,,,,,,,,,,,,                       +:
               ...............,,+,, ,-,,,*                       ,.
              ................,:       ,,                        @.
              ...............,,        #,                        ,.
              ............,,,,:         :                        ,.
              ............,-:,                                   ..
              ...........,::                                    ,..
                                                              :,...
              ...........,::                                    ,..
              ............,-:,                                   ..
              ............,,,,:         :                        ,.
              ...............,,        #,                        ,.
              ................,:       ,,                        @.
               ...............,,+,, ,-,,,*                       ,.
               ...............,,,,,,,,,,,,                       +:
               ...............,...,......,:                     :,,
               ..............,...........,,                     *..
               ..........................,::                   ,,..
                ...........................,,:                  :..
                ...........................,:                ,  ,,.
                ...........................,,  ,:           ,,:,:,.
                 ..........................,::,,:: --  -#,,#,...:..
                 ............................,...,,,    :,,.....,..
                 .................................,:    -,.........
                  .................................,     ,.........
                  ................................::,* :,,.........
                   ................................,,: :...........
                   ..................................,:,...........
                    .................................,,,,..........
                    ................................. ..,..........
                     ..............................................
                      .............................................
                      .............................................
                       ............................................
                        ...........................................
                         ..........................................
                          .........................................
                          .........................................
                            .......................................

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

Changes: https://git.openjdk.org/babylon/pull/254/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=254&range=01
  Stats: 688 lines in 13 files changed: 686 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/babylon/pull/254.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/254/head:pull/254

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

From asotona at openjdk.org  Tue Nov 26 18:18:25 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 26 Nov 2024 18:18:25 GMT
Subject: [code-reflection] RFR: Code model attribute
Message-ID: <4DTu5qIAm7hkWSrw0rRyDA_nBPpM1FFPsXIF0lk1wTk=.73d926df-53eb-4565-861e-2d0a9ba03574@github.com>

This is experimental serialization of code model into a custom method attribute.

I've performed brief comparison on `BytecodeTest` as a representant of class with majority of methods annotated with `@CodeReflection`.

Compiled size of the `BytecodeTest` class (with text-encoded code models) is 121288 bytes, CP contains 1612 entries.
Cleaned size of the class (removed text-encoded code models and their static initialization) is 32801 bytes, CP contains 1277 entries.
Size with models encoded in custom attributes is 74541 bytes, CP contains 1435 entries.

Proportional size of the custom attributes vs. text-encoded fields is 37% (47% of the CP entries).

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

Commit messages:
 - custom serialization of location attribute
 - fixed types serialization
 - CodeModelAttribute work in progress
 - CodeModelAttribute work in progress
 - CodeModelAttribute work in progress
 - merge into CodeModelAttribute
 - Initial draft of CodeModelAttribute and CodeModelAttributeMapper

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

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

From asotona at openjdk.org  Tue Nov 26 18:46:22 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 26 Nov 2024 18:46:22 GMT
Subject: [code-reflection] RFR: Code model attribute [v2]
In-Reply-To: <4DTu5qIAm7hkWSrw0rRyDA_nBPpM1FFPsXIF0lk1wTk=.73d926df-53eb-4565-861e-2d0a9ba03574@github.com>
References: <4DTu5qIAm7hkWSrw0rRyDA_nBPpM1FFPsXIF0lk1wTk=.73d926df-53eb-4565-861e-2d0a9ba03574@github.com>
Message-ID: <9M_jfFNqKKYhOq8QbnIrIhHlHUFDWUVgS0lvv3CjZ6g=.81deeff3-8d7c-4586-b918-7988ab1edd0c@github.com>

> This is experimental serialization of code model into a custom method attribute.
> 
> I've performed brief comparison on `BytecodeTest` as a representant of class with majority of methods annotated with `@CodeReflection`.
> 
> Compiled size of the `BytecodeTest` class (with text-encoded code models) is 121288 bytes, CP contains 1612 entries.
> Cleaned size of the class (removed text-encoded code models and their static initialization) is 32801 bytes, CP contains 1277 entries.
> Size with models encoded in custom attributes is 74541 bytes, CP contains 1435 entries.
> 
> Proportional size of the custom attributes vs. text-encoded fields is 37% (47% of the CP entries).

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

  CodeModeAtrtribute documentation work in progress

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/282/files
  - new: https://git.openjdk.org/babylon/pull/282/files/e8a63d84..ea9ebccb

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

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

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

From asotona at openjdk.org  Wed Nov 27 08:50:10 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 27 Nov 2024 08:50:10 GMT
Subject: [code-reflection] RFR: Code model attribute [v3]
In-Reply-To: <4DTu5qIAm7hkWSrw0rRyDA_nBPpM1FFPsXIF0lk1wTk=.73d926df-53eb-4565-861e-2d0a9ba03574@github.com>
References: <4DTu5qIAm7hkWSrw0rRyDA_nBPpM1FFPsXIF0lk1wTk=.73d926df-53eb-4565-861e-2d0a9ba03574@github.com>
Message-ID: <YEVhkRRsKPJ4TpMB5YdEsAiYKORWIQtLT2vKpG26olo=.2f06178a-574a-4b6f-8795-a4aa34c92831@github.com>

> This is experimental serialization of code model into a custom method attribute.
> 
> I've performed brief comparison on `BytecodeTest` as a representant of class with majority of methods annotated with `@CodeReflection`.
> 
> Compiled size of the `BytecodeTest` class (with text-encoded code models) is 121288 bytes, CP contains 1612 entries.
> Cleaned size of the class (removed text-encoded code models and their static initialization) is 32801 bytes, CP contains 1277 entries.
> Size with models encoded in custom attributes is 74541 bytes, CP contains 1435 entries.
> 
> Proportional size of the custom attributes vs. text-encoded fields is 37% (47% of the CP entries).

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

  CodeModelAttribute structure cleanup + javadoc work in progress

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/282/files
  - new: https://git.openjdk.org/babylon/pull/282/files/ea9ebccb..72721a9b

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

  Stats: 70 lines in 1 file changed: 31 ins; 2 del; 37 mod
  Patch: https://git.openjdk.org/babylon/pull/282.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/282/head:pull/282

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

From asotona at openjdk.org  Wed Nov 27 08:53:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 27 Nov 2024 08:53:39 GMT
Subject: [code-reflection] RFR: Code model attribute [v4]
In-Reply-To: <4DTu5qIAm7hkWSrw0rRyDA_nBPpM1FFPsXIF0lk1wTk=.73d926df-53eb-4565-861e-2d0a9ba03574@github.com>
References: <4DTu5qIAm7hkWSrw0rRyDA_nBPpM1FFPsXIF0lk1wTk=.73d926df-53eb-4565-861e-2d0a9ba03574@github.com>
Message-ID: <YtTPIbKQa6BpQcygZJ88ehpEaowbdiktLs2yLJaQwRI=.cc35e50c-503e-44b5-8def-28b286db09c5@github.com>

> This is experimental serialization of code model into a custom method attribute.
> 
> I've performed brief comparison on `BytecodeTest` as a representant of class with majority of methods annotated with `@CodeReflection`.
> 
> Compiled size of the `BytecodeTest` class (with text-encoded code models) is 121288 bytes, CP contains 1612 entries.
> Cleaned size of the class (removed text-encoded code models and their static initialization) is 32801 bytes, CP contains 1277 entries.
> Size with models encoded in custom attributes is 74541 bytes, CP contains 1435 entries.
> 
> Proportional size of the custom attributes vs. text-encoded fields is 37% (47% of the CP entries).

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

  typo

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/282/files
  - new: https://git.openjdk.org/babylon/pull/282/files/72721a9b..e8dcde54

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

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

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

From duke at openjdk.org  Wed Nov 27 13:14:54 2024
From: duke at openjdk.org (duke)
Date: Wed, 27 Nov 2024 13:14:54 GMT
Subject: [code-reflection] RFR: HIP HAT backend [v2]
In-Reply-To: <PghyOV4oNdfDIma0QCfAl_91-u1vi72bW7jT9bT7vKA=.c39571bf-f2d2-4c23-a8da-3b1fe56c4626@github.com>
References: <ZXonaQ4ND_86IeDYLrVM3DK72387ftgjx0asT8-pN3Q=.f62d85f5-5dad-470f-a794-fecc47ec8c59@github.com>
 <PghyOV4oNdfDIma0QCfAl_91-u1vi72bW7jT9bT7vKA=.c39571bf-f2d2-4c23-a8da-3b1fe56c4626@github.com>
Message-ID: <PsD747IJ0hWgrjLRi7YKyTPWbuGS6P49-p3j5jc8CZo=.c7db475f-e92e-4827-bce1-fbb920eb3b7c@github.com>

On Tue, 26 Nov 2024 17:11:35 GMT, iotamudelta <duke at openjdk.org> wrote:

>> * Use the C99 code path to generate HIP-compliant kernel code.
>> * Runtime compilation through hipRTC.
>> * Use standard HIP malloc/free, device inspection for infrastructure.
>> * Integrate into HAT compilation and examples.
>> * Confirmed to work on AMD Radeon RX 68000XT w/ ROCm 6.2.2
>> 
>> hipinfo output:
>>> Using device 0: AMD Radeon RX 6800 XT
>>> HIP Device has major=10 minor=3 compute capability
>>> HIP Device has wave front size 32
>>> HIP Device has threadsPerBlock 1024
>>> HIP Cores 36
>>   Total amount of global memory:   17163091968
>>   64-bit Memory Address:           YES
>> 
>> mandel example:
>> 
>> 
>>                           ......................................
>>                          .......................................
>>                        .........................................
>>                        .........................................
>>                       ..........................................
>>                      ...........................................
>>                     ............................................
>>                    .............................................
>>                    .............................................
>>                   ..............................................
>>                  ................................. ..,..........
>>                  .................................,,,,..........
>>                 ..................................,:,...........
>>                 ................................,,: :...........
>>                ................................::,* :,,.........
>>                .................................,     ,.........
>>               .................................,:    -,.........
>>               ............................,...,,,    :,,.....,..
>>               ..........................,::,,:: --  -#,,#,...:..
>>              ...........................,,  ,:           ,,:,:,.
>>              ...........................,:                ,  ,,.
>>              ...........................,,:                  :..
>>             ..........................,::                   ,,..
>>             ..............,...........,,                     *..
>>             ...............,...,......,:                     :,,
>>             ...............,,,,,,,,,,,,                       +:
>>             ...............,,+,, ,-,,,*                       ,.
>>            ................,:       ,,                        @.
>>           ...
>
> iotamudelta 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 hip_backend
>  - Merge branch 'code-reflection' into hip_backend
>  - Fix whitespace.
>  - Merge branch 'openjdk:code-reflection' into hip_backend
>  - Add a HIP backend.
>    
>    * Use the C99 code path to generate HIP-compliant kernel code.
>    * Compile code using runtime compilation through hipRTC.
>    * Use standard HIP malloc/free, device inspection for infrastructure.
>    * Integrate into HAT compilation and examples.
>    * Confirmed to work on AMD Radeon RX 68000XT w/ ROCm 6.2.2
>    
>    hipinfo output:
>    > Using device 0: AMD Radeon RX 6800 XT
>    > HIP Device has major=10 minor=3 compute capability
>    > HIP Device has wave front size 32
>    > HIP Device has threadsPerBlock 1024
>    > HIP Cores 36
>      Total amount of global memory:   17163091968
>      64-bit Memory Address:           YES
>    
>    mandel example:
>    
>                              ......................................
>                             .......................................
>                           .........................................
>                           .........................................
>                          ..........................................
>                         ...........................................
>                        ............................................
>                       .............................................
>                       .............................................
>                      ..............................................
>                     ................................. ..,..........
>                     .................................,,,,..........
>                    ..................................,:,...........
>                    ................................,,: :...........
>                   ................................::,* :,,.........
>                   .................................,     ,.........
>                  .................................,:    -,.........
>                  ............................,...,,,    :,,.....,..
>                  ..........................,::,,:: --  -#,,#,...:..
>                 ...........................,,  ,:           ,,:,:,.
>                 ...........................,:                ,  ,,.
>                 ...........................,,:                  :..
>            ...

@iotamudelta 
Your change (at version 8e043969f0ffbc45d4d26cc0bbd1554b0fac0d7b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/babylon/pull/254#issuecomment-2503846511

From gfrost at openjdk.org  Wed Nov 27 13:38:17 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 27 Nov 2024 13:38:17 GMT
Subject: git: openjdk/babylon: code-reflection: HIP HAT backend
Message-ID: <1a7c35af-7925-4ee3-bf94-196dfb4257ce@openjdk.org>

Changeset: 95445c8d
Branch: code-reflection
Author:    iotamudelta <dieterich at ogolem.org>
Committer: Gary Frost <gfrost at openjdk.org>
Date:      2024-11-27 13:37:06 +0000
URL:       https://git.openjdk.org/babylon/commit/95445c8dae988843aee678fbec358cfe3664caf5

HIP HAT backend

! hat/README.md
! hat/backends/CMakeLists.txt
+ hat/backends/hip/CMakeLists.txt
+ hat/backends/hip/cpp/hip_backend.cpp
+ hat/backends/hip/cpp/info.cpp
+ hat/backends/hip/include/hip_backend.h
+ hat/backends/hip/pom.xml
+ hat/backends/hip/src/main/java/hat/backend/HIPBackend.java
+ hat/backends/hip/src/main/java/hat/backend/HIPDeviceInfo.java
+ hat/backends/hip/src/main/java/hat/backend/HIPHatKernelBuilder.java
+ hat/backends/hip/src/main/resources/META-INF/services/hat.backend.Backend
! hat/backends/pom.xml
! hat/hatrun.bash


From duke at openjdk.org  Wed Nov 27 13:39:54 2024
From: duke at openjdk.org (iotamudelta)
Date: Wed, 27 Nov 2024 13:39:54 GMT
Subject: [code-reflection] Integrated: HIP HAT backend
In-Reply-To: <ZXonaQ4ND_86IeDYLrVM3DK72387ftgjx0asT8-pN3Q=.f62d85f5-5dad-470f-a794-fecc47ec8c59@github.com>
References: <ZXonaQ4ND_86IeDYLrVM3DK72387ftgjx0asT8-pN3Q=.f62d85f5-5dad-470f-a794-fecc47ec8c59@github.com>
Message-ID: <noIuVnnq8oOo30Mu49ew1rFh9q0oWzjXM55YnsG-7vo=.e4fc1996-158e-48f6-be5c-2388b6d962bc@github.com>

On Mon, 14 Oct 2024 18:53:25 GMT, iotamudelta <duke at openjdk.org> wrote:

> * Use the C99 code path to generate HIP-compliant kernel code.
> * Runtime compilation through hipRTC.
> * Use standard HIP malloc/free, device inspection for infrastructure.
> * Integrate into HAT compilation and examples.
> * Confirmed to work on AMD Radeon RX 68000XT w/ ROCm 6.2.2
> 
> hipinfo output:
>> Using device 0: AMD Radeon RX 6800 XT
>> HIP Device has major=10 minor=3 compute capability
>> HIP Device has wave front size 32
>> HIP Device has threadsPerBlock 1024
>> HIP Cores 36
>   Total amount of global memory:   17163091968
>   64-bit Memory Address:           YES
> 
> mandel example:
> 
> 
>                           ......................................
>                          .......................................
>                        .........................................
>                        .........................................
>                       ..........................................
>                      ...........................................
>                     ............................................
>                    .............................................
>                    .............................................
>                   ..............................................
>                  ................................. ..,..........
>                  .................................,,,,..........
>                 ..................................,:,...........
>                 ................................,,: :...........
>                ................................::,* :,,.........
>                .................................,     ,.........
>               .................................,:    -,.........
>               ............................,...,,,    :,,.....,..
>               ..........................,::,,:: --  -#,,#,...:..
>              ...........................,,  ,:           ,,:,:,.
>              ...........................,:                ,  ,,.
>              ...........................,,:                  :..
>             ..........................,::                   ,,..
>             ..............,...........,,                     *..
>             ...............,...,......,:                     :,,
>             ...............,,,,,,,,,,,,                       +:
>             ...............,,+,, ,-,,,*                       ,.
>            ................,:       ,,                        @.
>            ...............,,        #,                        ,.
>            ............,,,,:      ...

This pull request has now been integrated.

Changeset: 95445c8d
Author:    iotamudelta <dieterich at ogolem.org>
Committer: Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/95445c8dae988843aee678fbec358cfe3664caf5
Stats:     688 lines in 13 files changed: 686 ins; 0 del; 2 mod

HIP HAT backend

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

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

From gfrost at openjdk.org  Wed Nov 27 14:12:28 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 27 Nov 2024 14:12:28 GMT
Subject: git: openjdk/babylon: code-reflection: Some build fixups after merging
 hip backend
Message-ID: <497ef932-8b5c-44b0-b629-8173f38392f8@openjdk.org>

Changeset: 52eba9dd
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-11-27 14:11:57 +0000
URL:       https://git.openjdk.org/babylon/commit/52eba9dd968e0bc0aa374cfebae393ce34f1c066

Some build fixups after merging hip backend

! hat/backends/cuda/pom.xml
! hat/backends/hip/pom.xml
! hat/backends/mock/pom.xml
! hat/backends/pom.xml
! hat/backends/spirv/pom.xml
! hat/bld


From gfrost at openjdk.org  Wed Nov 27 14:15:40 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 27 Nov 2024 14:15:40 GMT
Subject: [code-reflection] Integrated: Some build fixups after merging hip
 backend
Message-ID: <C8fixn3BtwwNAzhfumhCWwcezgv2q0sQF_tBLz1hCdk=.70285ee3-82b9-4774-9ae7-4bc6161e6c17@github.com>

After merging HIP backend I had to add hip to pom.xml files and to bldr. 

Although at this point we 'skip' the build by default (sadly we need to work out how to stage SPIRV beehive) 

Comments in the `bld` file show how to include hip. For those with appropriate build infra.

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

Commit messages:
 - Some build fixups after merging hip backend

Changes: https://git.openjdk.org/babylon/pull/283/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=283&range=00
  Stats: 194 lines in 6 files changed: 47 ins; 95 del; 52 mod
  Patch: https://git.openjdk.org/babylon/pull/283.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/283/head:pull/283

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

From gfrost at openjdk.org  Wed Nov 27 14:15:40 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 27 Nov 2024 14:15:40 GMT
Subject: [code-reflection] Integrated: Some build fixups after merging hip
 backend
In-Reply-To: <C8fixn3BtwwNAzhfumhCWwcezgv2q0sQF_tBLz1hCdk=.70285ee3-82b9-4774-9ae7-4bc6161e6c17@github.com>
References: <C8fixn3BtwwNAzhfumhCWwcezgv2q0sQF_tBLz1hCdk=.70285ee3-82b9-4774-9ae7-4bc6161e6c17@github.com>
Message-ID: <f4AmmGfuFpkNgMMUXMb_hG6HDgkNZ-vMSVysdLER-RM=.70e52ae3-4ca1-4b84-90d1-9b4490c0e49f@github.com>

On Wed, 27 Nov 2024 14:09:35 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> After merging HIP backend I had to add hip to pom.xml files and to bldr. 
> 
> Although at this point we 'skip' the build by default (sadly we need to work out how to stage SPIRV beehive) 
> 
> Comments in the `bld` file show how to include hip. For those with appropriate build infra.

This pull request has now been integrated.

Changeset: 52eba9dd
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/52eba9dd968e0bc0aa374cfebae393ce34f1c066
Stats:     194 lines in 6 files changed: 47 ins; 95 del; 52 mod

Some build fixups after merging hip backend

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

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

From gfrost at openjdk.org  Thu Nov 28 14:05:05 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 28 Nov 2024 14:05:05 GMT
Subject: git: openjdk/babylon: code-reflection: Added mkpoms script - updated
 bldr/XMLNode
Message-ID: <621e0255-dd7e-4036-b5e9-284ff70f9436@openjdk.org>

Changeset: 2f2d7d6c
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-11-28 14:02:50 +0000
URL:       https://git.openjdk.org/babylon/commit/2f2d7d6c68b8b105a34db02938fea0d0707a1b9f

Added mkpoms script - updated bldr/XMLNode

! hat/backends/cuda/pom.xml
! hat/backends/mock/pom.xml
! hat/backends/opencl/pom.xml
! hat/backends/pom.xml
! hat/backends/ptx/pom.xml
! hat/bldr/XMLNode.java
+ hat/bldr/mkpoms
! hat/bldr/opencl
! hat/examples/blackscholes/pom.xml
! hat/examples/heal/pom.xml
! hat/examples/life/pom.xml
! hat/examples/mandel/pom.xml
! hat/examples/pom.xml
! hat/examples/squares/pom.xml
! hat/examples/violajones/pom.xml
! hat/hat/pom.xml
+ hat/mkpoms
! hat/pom.xml


From gfrost at openjdk.org  Thu Nov 28 14:06:11 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 28 Nov 2024 14:06:11 GMT
Subject: [code-reflection] Integrated: Added mkpoms script - updated
 bldr/XMLNode
Message-ID: <-wTpwU-NdgxgKUwHOB9XUxMYIDM4h4dTZCrP3bz0vcY=.652fc8d0-8ce3-43ca-8301-eb98be8ad27f@github.com>

Added the script I have been using to create pom files. 

Also the autogenerated pom.xml files themselves.  We may remove these in future once we prove the above script is good enough


. ./env.bash
java bldr/mkpoms 
bash maven-build.bash

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

Commit messages:
 - Added mkpoms script - updated bldr/XMLNode

Changes: https://git.openjdk.org/babylon/pull/284/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=284&range=00
  Stats: 666 lines in 18 files changed: 597 ins; 41 del; 28 mod
  Patch: https://git.openjdk.org/babylon/pull/284.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/284/head:pull/284

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

From gfrost at openjdk.org  Thu Nov 28 14:06:12 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 28 Nov 2024 14:06:12 GMT
Subject: [code-reflection] Integrated: Added mkpoms script - updated
 bldr/XMLNode
In-Reply-To: <-wTpwU-NdgxgKUwHOB9XUxMYIDM4h4dTZCrP3bz0vcY=.652fc8d0-8ce3-43ca-8301-eb98be8ad27f@github.com>
References: <-wTpwU-NdgxgKUwHOB9XUxMYIDM4h4dTZCrP3bz0vcY=.652fc8d0-8ce3-43ca-8301-eb98be8ad27f@github.com>
Message-ID: <PI1eK7f2ZtR6cutPmU31vTz7alpMK6hfUq8KECZ557g=.9b09384c-68f6-40ca-86ab-55083098d542@github.com>

On Thu, 28 Nov 2024 13:59:57 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Added the script I have been using to create pom files. 
> 
> Also the autogenerated pom.xml files themselves.  We may remove these in future once we prove the above script is good enough
> 
> 
> . ./env.bash
> java bldr/mkpoms 
> bash maven-build.bash

This pull request has now been integrated.

Changeset: 2f2d7d6c
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/2f2d7d6c68b8b105a34db02938fea0d0707a1b9f
Stats:     666 lines in 18 files changed: 597 ins; 41 del; 28 mod

Added mkpoms script - updated bldr/XMLNode

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

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

From gfrost at openjdk.org  Thu Nov 28 14:51:03 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 28 Nov 2024 14:51:03 GMT
Subject: git: openjdk/babylon: code-reflection: mkpoms cleanup + .gitignore
 target dirs
Message-ID: <8a74d5ba-313d-40c8-8609-0d10a856c2b0@openjdk.org>

Changeset: 54f1b927
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-11-28 14:48:54 +0000
URL:       https://git.openjdk.org/babylon/commit/54f1b9279a326e3344e3fc4f5bff22b7a855312b

mkpoms cleanup + .gitignore target dirs

+ hat/backends/.gitignore
+ hat/backends/cuda/.gitignore
+ hat/backends/mock/.gitignore
+ hat/backends/opencl/.gitignore
+ hat/backends/ptx/.gitignore
! hat/bldr/Bldr.java
+ hat/examples/.gitignore
+ hat/examples/blackscholes/.gitignore
+ hat/examples/heal/.gitignore
+ hat/examples/life/.gitignore
+ hat/examples/mandel/.gitignore
+ hat/examples/squares/.gitignore
+ hat/examples/violajones/.gitignore
! hat/mkpoms


From gfrost at openjdk.org  Thu Nov 28 14:52:03 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 28 Nov 2024 14:52:03 GMT
Subject: [code-reflection] Integrated: mkpoms cleanup + .gitignore target dirs
Message-ID: <8q-Umh3TGko7cOfRYR9D3hnRYv6L0wYhuIxhdWYG1w4=.83a5bd17-2eb0-4a3a-9795-3784991757b9@github.com>

Cleanup mkpoms script. 

Also added all intermediate maven target dirs to `.gitignores`

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

Commit messages:
 - mkpoms cleanup + .gitignore target dirs

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

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

From gfrost at openjdk.org  Thu Nov 28 14:52:03 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 28 Nov 2024 14:52:03 GMT
Subject: [code-reflection] Integrated: mkpoms cleanup + .gitignore target dirs
In-Reply-To: <8q-Umh3TGko7cOfRYR9D3hnRYv6L0wYhuIxhdWYG1w4=.83a5bd17-2eb0-4a3a-9795-3784991757b9@github.com>
References: <8q-Umh3TGko7cOfRYR9D3hnRYv6L0wYhuIxhdWYG1w4=.83a5bd17-2eb0-4a3a-9795-3784991757b9@github.com>
Message-ID: <87eADjQ-Je8-_00XmoXREzuJMZ2pdW5Iz3y4dZkJtLo=.01e8e735-38d2-4034-9665-192e1921467d@github.com>

On Thu, 28 Nov 2024 14:46:31 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Cleanup mkpoms script. 
> 
> Also added all intermediate maven target dirs to `.gitignores`

This pull request has now been integrated.

Changeset: 54f1b927
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/54f1b9279a326e3344e3fc4f5bff22b7a855312b
Stats:     35 lines in 14 files changed: 20 ins; 3 del; 12 mod

mkpoms cleanup + .gitignore target dirs

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

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

From gfrost at openjdk.org  Fri Nov 29 11:28:41 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 29 Nov 2024 11:28:41 GMT
Subject: git: openjdk/babylon: code-reflection: More bld simplifications. Prep
 for adding jextract
Message-ID: <5ad9afbe-47ef-4e13-a63e-001b55a32c1f@openjdk.org>

Changeset: ae52afec
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-11-29 11:27:55 +0000
URL:       https://git.openjdk.org/babylon/commit/ae52afec058d23f115a61d414ae45691d0cc49ee

More bld simplifications.  Prep for adding jextract

! hat/.gitignore
! hat/backends/cuda/pom.xml
! hat/backends/mock/pom.xml
! hat/backends/opencl/pom.xml
! hat/backends/pom.xml
! hat/backends/ptx/pom.xml
! hat/bldr/Bldr.java
! hat/bldr/XMLNode.java
! hat/examples/blackscholes/pom.xml
! hat/examples/heal/pom.xml
! hat/examples/life/pom.xml
! hat/examples/mandel/pom.xml
! hat/examples/pom.xml
! hat/examples/squares/pom.xml
! hat/examples/violajones/pom.xml
! hat/hat/.gitignore
! hat/hat/pom.xml
! hat/mkpoms
! hat/pom.xml


From gfrost at openjdk.org  Fri Nov 29 11:31:23 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 29 Nov 2024 11:31:23 GMT
Subject: [code-reflection] Integrated: More bld simplifications.  Prep for
 adding jextract
Message-ID: <Ygg1gms9kyjuoEpYQxfTkizoLK7Ct2U_hi3xWUI8-i4=.847aeda7-188f-4e01-a147-dfa8f3ff4f31@github.com>

Preparing for addition of jextract to bld and mkpoms. 

Mostly bld cleanup and additional .gitignores

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

Commit messages:
 - More bld simplifications.  Prep for adding jextract

Changes: https://git.openjdk.org/babylon/pull/286/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=286&range=00
  Stats: 334 lines in 19 files changed: 70 ins; 67 del; 197 mod
  Patch: https://git.openjdk.org/babylon/pull/286.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/286/head:pull/286

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

From gfrost at openjdk.org  Fri Nov 29 11:31:23 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Fri, 29 Nov 2024 11:31:23 GMT
Subject: [code-reflection] Integrated: More bld simplifications.  Prep for
 adding jextract
In-Reply-To: <Ygg1gms9kyjuoEpYQxfTkizoLK7Ct2U_hi3xWUI8-i4=.847aeda7-188f-4e01-a147-dfa8f3ff4f31@github.com>
References: <Ygg1gms9kyjuoEpYQxfTkizoLK7Ct2U_hi3xWUI8-i4=.847aeda7-188f-4e01-a147-dfa8f3ff4f31@github.com>
Message-ID: <as3kxadwQMMniyTwFv2SitCABfZfkb3AF54UvyQXJZg=.bceac918-44a8-44ae-9f68-443f07f0e31e@github.com>

On Fri, 29 Nov 2024 11:25:30 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Preparing for addition of jextract to bld and mkpoms. 
> 
> Mostly bld cleanup and additional .gitignores

This pull request has now been integrated.

Changeset: ae52afec
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/ae52afec058d23f115a61d414ae45691d0cc49ee
Stats:     334 lines in 19 files changed: 70 ins; 67 del; 197 mod

More bld simplifications.  Prep for adding jextract

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

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