From asotona at openjdk.org  Mon Sep  2 06:00:32 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Sep 2024 06:00:32 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v3]
In-Reply-To: <du0zv0mdILef68Z65c3SjjCxx8UU-yPUhOB96lr2HK0=.33a2fb7d-fe7a-4088-9f56-335542ccfc2d@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
 <QIQmLRgZ4XDoHMyy9SR5s2lrYAykrA92OtLo3w0rUM0=.92c22d43-6801-44f3-918d-0e6437a89612@github.com>
 <du0zv0mdILef68Z65c3SjjCxx8UU-yPUhOB96lr2HK0=.33a2fb7d-fe7a-4088-9f56-335542ccfc2d@github.com>
Message-ID: <5JcjWpvkDGxg1CBaBT4AIPCZZjKwf34Vw88ZcfAfdkQ=.85a6ed38-9efe-4e6e-9c12-15c087351fa8@github.com>

On Fri, 30 Aug 2024 20:11:41 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor corrections
>
> test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java line 171:
> 
>> 169:     private void verify(String category, CoreOp.FuncOp func) {
>> 170:         OpWriter.CodeItemNamerOption naming = null;
>> 171:         for (Body body : func.bodies()) {
> 
> It's possible to collapse all the loops by traversing the operations, passing in `naming` as the argument e.g.,
> 
> naming = func.traverse(naming, opVisitor((n, op) -> {
>     for (Value v : op.operands()) {
>         if (!op.result().isDominatedBy(v)) {
>             if (n == null) { n = ... }
>             ...
>         }
>     }
>     return n;
> }));

Yes, I'll change it. Original idea was that more verifications will hook also on Body and Block level, however Op-level verification seem to be enough.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/219#discussion_r1740361325

From asotona at openjdk.org  Mon Sep  2 06:10:40 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Sep 2024 06:10:40 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v3]
In-Reply-To: <du0zv0mdILef68Z65c3SjjCxx8UU-yPUhOB96lr2HK0=.33a2fb7d-fe7a-4088-9f56-335542ccfc2d@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
 <QIQmLRgZ4XDoHMyy9SR5s2lrYAykrA92OtLo3w0rUM0=.92c22d43-6801-44f3-918d-0e6437a89612@github.com>
 <du0zv0mdILef68Z65c3SjjCxx8UU-yPUhOB96lr2HK0=.33a2fb7d-fe7a-4088-9f56-335542ccfc2d@github.com>
Message-ID: <2EbvGENjbXpsocN1I2QvnMyP3PO-wYzs1vbP6pff8PU=.61c6d2ff-2e58-4317-a0f0-cb36b5a83027@github.com>

On Fri, 30 Aug 2024 20:43:58 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor corrections
>
> src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 399:
> 
>> 397:         }
>> 398: 
>> 399:         Set<Block> stopBlocks = new HashSet<>();
> 
> If i got this right, we are dealing with an equivalent of an uninitialized variable, of a primitive type, in source that will be assigned in divergent code paths, and the compiler will check it's DA. In the model we currently require the modelling var op be initialized with a default constant value for the primitive type. We don't currently have a concept of an uninitialized value (which might help?), so we have to detect that all loads are dominated by stores, some of which are initializing stores (which detects the uninitialized case or a redundant initialization).
> 
> This specific bit of code after the dominated by checks determines if there is a path from `n`'s declaring block to the entry block that does not pass through any of `dom`'s declaring blocks? Why is that is important?

Yes, this is about uninitialized variables (of any type), where there are two or more assignments in divergent paths. Concept of uninitialized variable will definitely help to avoid obsolete default constants declaration. This is a detection of such situation, so the default initialization is skipped and the roundtrip is stable.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/219#discussion_r1740365979

From asotona at openjdk.org  Mon Sep  2 06:10:40 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Sep 2024 06:10:40 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v3]
In-Reply-To: <2EbvGENjbXpsocN1I2QvnMyP3PO-wYzs1vbP6pff8PU=.61c6d2ff-2e58-4317-a0f0-cb36b5a83027@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
 <QIQmLRgZ4XDoHMyy9SR5s2lrYAykrA92OtLo3w0rUM0=.92c22d43-6801-44f3-918d-0e6437a89612@github.com>
 <du0zv0mdILef68Z65c3SjjCxx8UU-yPUhOB96lr2HK0=.33a2fb7d-fe7a-4088-9f56-335542ccfc2d@github.com>
 <2EbvGENjbXpsocN1I2QvnMyP3PO-wYzs1vbP6pff8PU=.61c6d2ff-2e58-4317-a0f0-cb36b5a83027@github.com>
Message-ID: <LZdxQvUThVCH8IUICG56pHAtWpKgsOt6pDNjEd07cls=.a7141ae7-db4f-43c8-94f8-d542229a413c@github.com>

On Mon, 2 Sep 2024 06:04:31 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 399:
>> 
>>> 397:         }
>>> 398: 
>>> 399:         Set<Block> stopBlocks = new HashSet<>();
>> 
>> If i got this right, we are dealing with an equivalent of an uninitialized variable, of a primitive type, in source that will be assigned in divergent code paths, and the compiler will check it's DA. In the model we currently require the modelling var op be initialized with a default constant value for the primitive type. We don't currently have a concept of an uninitialized value (which might help?), so we have to detect that all loads are dominated by stores, some of which are initializing stores (which detects the uninitialized case or a redundant initialization).
>> 
>> This specific bit of code after the dominated by checks determines if there is a path from `n`'s declaring block to the entry block that does not pass through any of `dom`'s declaring blocks? Why is that is important?
>
> Yes, this is about uninitialized variables (of any type), where there are two or more assignments in divergent paths. Concept of uninitialized variable will definitely help to avoid obsolete default constants declaration. This is a detection of such situation, so the default initialization is skipped and the roundtrip is stable.

This code detect there is no path from a VarLoadOp to the entry block that does not pass any of the VarStoreOps. The default initialization is necessary if there is such path. I've just made it more abstract to a dominance test of dominant set.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/219#discussion_r1740367865

From asotona at openjdk.org  Mon Sep  2 06:15:49 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Sep 2024 06:15:49 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v3]
In-Reply-To: <du0zv0mdILef68Z65c3SjjCxx8UU-yPUhOB96lr2HK0=.33a2fb7d-fe7a-4088-9f56-335542ccfc2d@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
 <QIQmLRgZ4XDoHMyy9SR5s2lrYAykrA92OtLo3w0rUM0=.92c22d43-6801-44f3-918d-0e6437a89612@github.com>
 <du0zv0mdILef68Z65c3SjjCxx8UU-yPUhOB96lr2HK0=.33a2fb7d-fe7a-4088-9f56-335542ccfc2d@github.com>
Message-ID: <nsObKpTN54G_O0iOmKuBXAWs9NbXwN8hdMZwrpgxogE=.ebb41cb2-d164-4b7e-bdc4-bc8c19aefc9f@github.com>

On Fri, 30 Aug 2024 20:48:12 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> It's good to see the value-based `isDominatedBy`method being used, probably the first time in anger (not much prior testing on that).
> 
> How fastidious are you being about round trip stability? Given the following chain of events, where B == bytecode and M == code mode,
> 
> B1 -> M1 -> B2 -> M2 -> B3 -> M3
> 
> Do you want M1, M2 and M3 to be the same or just M2 and M3?

Actually I'm testing only M2 vs M3. The first round is affected by strong stack use in the original code and BytecodeLift reflects that. BytecodeGenerator is not capable of complex predictive stack manipulations, it is limited to the one known value on stack. Second lift is then very different from the first one and all subsequent lifts should be already stable.

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

PR Comment: https://git.openjdk.org/babylon/pull/219#issuecomment-2323893254

From asotona at openjdk.org  Mon Sep  2 07:03:13 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Sep 2024 07:03:13 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v4]
In-Reply-To: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
Message-ID: <psf_67wAVhrvvI_lJce5lNffGR9J9Dlag_h0_nL6llY=.56aef105-3e08-4f34-b598-5aec7376a85f@github.com>

> - Added test for operand values dominance revealed a bug in the BytecodeLift.
> - Fixed BytecodeLift revealed regression in the roundtrip stability.
> - Roundtrip instability was caused by a bug in the LocalsTypeMapper.
> 
> All the above is fixed and the roundtrip stability is restored.
> 
> Please review.
> 
> Thanks,
> Adam

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

  applied the suggested changes

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/219/files
  - new: https://git.openjdk.org/babylon/pull/219/files/60e3d36d..58dbaf5a

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

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

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

From asotona at openjdk.org  Mon Sep  2 07:23:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Sep 2024 07:23:20 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v5]
In-Reply-To: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
Message-ID: <hwC0NjXdgmFjTebhTk00T62arniy8K8Xd9m8ZCSV7-o=.4b77d1ef-d4d6-4295-8d58-c2df9ddc3cd6@github.com>

> - Added test for operand values dominance revealed a bug in the BytecodeLift.
> - Fixed BytecodeLift revealed regression in the roundtrip stability.
> - Roundtrip instability was caused by a bug in the LocalsTypeMapper.
> 
> All the above is fixed and the roundtrip stability is restored.
> 
> Please review.
> 
> Thanks,
> Adam

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

  minor adjustments

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/219/files
  - new: https://git.openjdk.org/babylon/pull/219/files/58dbaf5a..6a730b02

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

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

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

From psandoz at openjdk.org  Tue Sep  3 19:56:51 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 3 Sep 2024 19:56:51 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v3]
In-Reply-To: <LZdxQvUThVCH8IUICG56pHAtWpKgsOt6pDNjEd07cls=.a7141ae7-db4f-43c8-94f8-d542229a413c@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
 <QIQmLRgZ4XDoHMyy9SR5s2lrYAykrA92OtLo3w0rUM0=.92c22d43-6801-44f3-918d-0e6437a89612@github.com>
 <du0zv0mdILef68Z65c3SjjCxx8UU-yPUhOB96lr2HK0=.33a2fb7d-fe7a-4088-9f56-335542ccfc2d@github.com>
 <2EbvGENjbXpsocN1I2QvnMyP3PO-wYzs1vbP6pff8PU=.61c6d2ff-2e58-4317-a0f0-cb36b5a83027@github.com>
 <LZdxQvUThVCH8IUICG56pHAtWpKgsOt6pDNjEd07cls=.a7141ae7-db4f-43c8-94f8-d542229a413c@github.com>
Message-ID: <WmPQwPZhl0paWB2KLJiI7cwxfv1lXOeuOTIhUi4cE3g=.bed42c13-79f4-4be5-b2aa-479362221db8@github.com>

On Mon, 2 Sep 2024 06:07:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Yes, this is about uninitialized variables (of any type), where there are two or more assignments in divergent paths. Concept of uninitialized variable will definitely help to avoid obsolete default constants declaration. This is a detection of such situation, so the default initialization is skipped and the roundtrip is stable.
>
> This code detect there is no path from a VarLoadOp to the entry block that bypass the VarStoreOps. The default initialization is necessary if there is such path. I've just made it more abstract as a dominance test of a dominant set.

I still don't understand why the second check is needed, traversing the predecessors of `n`'s declaring block. If `n` is not dominated by any values in set `doms` then presumably such traversal has to encounter the entry block? 

The implementation of `Value::isDominatedBy` defers to block domination:

    public boolean isDominatedBy(Value dom) {
        if (this == dom) {
            return true;
        }

        if (declaringBlock() != dom.declaringBlock()) {
            return declaringBlock().isDominatedBy(dom.declaringBlock());
        }
...

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

PR Review Comment: https://git.openjdk.org/babylon/pull/219#discussion_r1742604589

From mabbay at openjdk.org  Wed Sep  4 03:25:58 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 4 Sep 2024 03:25:58 GMT
Subject: [code-reflection] RFR: Unify code that generates code model of switch
 statement and expression
Message-ID: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>

Unify code that generates code model of switch statement and expression

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

Commit messages:
 - Refactor

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

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

From mabbay at openjdk.org  Wed Sep  4 03:50:08 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 4 Sep 2024 03:50:08 GMT
Subject: [code-reflection] RFR: Unify code that generates code model of
 switch statement and expression [v2]
In-Reply-To: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
References: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
Message-ID: <ShIT7YMW6sQ3NWytHFOfJESdm-cmj85ehIOnNfQls8M=.7eab7f68-1012-4c5e-aa0d-fc0a20e35d8b@github.com>

> Unify code that generates code model of switch statement and expression

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/220/files
  - new: https://git.openjdk.org/babylon/pull/220/files/0a37833f..2be94f11

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

  Stats: 76 lines in 1 file changed: 23 ins; 37 del; 16 mod
  Patch: https://git.openjdk.org/babylon/pull/220.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/220/head:pull/220

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

From asotona at openjdk.org  Wed Sep  4 06:37:36 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Sep 2024 06:37:36 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v3]
In-Reply-To: <WmPQwPZhl0paWB2KLJiI7cwxfv1lXOeuOTIhUi4cE3g=.bed42c13-79f4-4be5-b2aa-479362221db8@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
 <QIQmLRgZ4XDoHMyy9SR5s2lrYAykrA92OtLo3w0rUM0=.92c22d43-6801-44f3-918d-0e6437a89612@github.com>
 <du0zv0mdILef68Z65c3SjjCxx8UU-yPUhOB96lr2HK0=.33a2fb7d-fe7a-4088-9f56-335542ccfc2d@github.com>
 <2EbvGENjbXpsocN1I2QvnMyP3PO-wYzs1vbP6pff8PU=.61c6d2ff-2e58-4317-a0f0-cb36b5a83027@github.com>
 <LZdxQvUThVCH8IUICG56pHAtWpKgsOt6pDNjEd07cls=.a7141ae7-db4f-43c8-94f8-d542229a413c@github.com>
 <WmPQwPZhl0paWB2KLJiI7cwxfv1lXOeuOTIhUi4cE3g=.bed42c13-79f4-4be5-b2aa-479362221db8@github.com>
Message-ID: <fXuVJwbr0S-_qYsVpqI9pjOKhzJRUrPDWAuxaRYDEGo=.c1fbabe1-ad19-4ec3-94c5-9b13581fa643@github.com>

On Tue, 3 Sep 2024 19:53:29 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This code detect there is no path from a VarLoadOp to the entry block that bypass the VarStoreOps. The default initialization is necessary if there is such path. I've just made it more abstract as a dominance test of a dominant set.
>
> I still don't understand why the second check is needed, traversing the predecessors of `n`'s declaring block. If `n` is not dominated by any values in set `doms` then presumably such traversal has to encounter the entry block? 
> 
> The implementation of `Value::isDominatedBy` defers to block domination:
> 
>     public boolean isDominatedBy(Value dom) {
>         if (this == dom) {
>             return true;
>         }
> 
>         if (declaringBlock() != dom.declaringBlock()) {
>             return declaringBlock().isDominatedBy(dom.declaringBlock());
>         }
> ...

Individual dominations are handled as you describe. It applies for cases like this:

entry -> var -> var store -> var load
            \
              > var store -> var load 


However following case needs a test for dominant set:

entry -> var -> var store -> var load
            \             /
              > var store

The var load is not dominated by any individual var store, however it is dominated by them.

The test should fail for example on following case:

entry -> var -> var store -> var load
             \            /     
                ---------


The reason why the second part is focused on blocks only is because ops cannot form a bypass inside one block.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/219#discussion_r1743149575

From psandoz at openjdk.org  Wed Sep  4 15:24:43 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 4 Sep 2024 15:24:43 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v3]
In-Reply-To: <fXuVJwbr0S-_qYsVpqI9pjOKhzJRUrPDWAuxaRYDEGo=.c1fbabe1-ad19-4ec3-94c5-9b13581fa643@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
 <QIQmLRgZ4XDoHMyy9SR5s2lrYAykrA92OtLo3w0rUM0=.92c22d43-6801-44f3-918d-0e6437a89612@github.com>
 <du0zv0mdILef68Z65c3SjjCxx8UU-yPUhOB96lr2HK0=.33a2fb7d-fe7a-4088-9f56-335542ccfc2d@github.com>
 <2EbvGENjbXpsocN1I2QvnMyP3PO-wYzs1vbP6pff8PU=.61c6d2ff-2e58-4317-a0f0-cb36b5a83027@github.com>
 <LZdxQvUThVCH8IUICG56pHAtWpKgsOt6pDNjEd07cls=.a7141ae7-db4f-43c8-94f8-d542229a413c@github.com>
 <WmPQwPZhl0paWB2KLJiI7cwxfv1lXOeuOTIhUi4cE3g=.bed42c13-79f4-4be5-b2aa-479362221db8@github.com>
 <fXuVJwbr0S-_qYsVpqI9pjOKhzJRUrPDWAuxaRYDEGo=.c1fbabe1-ad19-4ec3-94c5-9b13581fa643@github.com>
Message-ID: <K-tbwjIZxGQLSmN95RpVX8xvTYMf26-OQ_ssFTxrEjM=.fa8fed7b-65ec-445a-bd23-e3ae5e7edbd1@github.com>

On Wed, 4 Sep 2024 06:35:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I still don't understand why the second check is needed, traversing the predecessors of `n`'s declaring block. If `n` is not dominated by any values in set `doms` then presumably such traversal has to encounter the entry block? 
>> 
>> The implementation of `Value::isDominatedBy` defers to block domination:
>> 
>>     public boolean isDominatedBy(Value dom) {
>>         if (this == dom) {
>>             return true;
>>         }
>> 
>>         if (declaringBlock() != dom.declaringBlock()) {
>>             return declaringBlock().isDominatedBy(dom.declaringBlock());
>>         }
>> ...
>
> Individual dominations are handled as you describe. It applies for cases like this:
> 
> entry -> var -> var store -> var load
>             \
>               > var store -> var load 
> 
> 
> However following case needs a test for dominant set:
> 
> entry -> var -> var store -> var load
>             \             /
>               > var store
> 
> The var load is not dominated by any individual var store, however it is dominated by them.
> 
> The test should fail for example on following case:
> 
> entry -> var -> var store -> var load
>              \            /     
>                 ---------
> 
> 
> The reason why the second part is focused on blocks only is because ops cannot form a bypass inside one block.

Thanks! Doh, of course, i get it now. I think what you are doing is the equivalent of DA analysis. Perhaps we can rename the method accordingly? e.g., `isDefinitelyAssigned` (noting it does not distinguish between assignment with a default value or non-assignment in source because we don't currently make that distinction in the model).

What does the bytecode verifier do when it encounters bytecode in the last case? I expect the verifier will be enhanced to support the new object initialization protocol.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/219#discussion_r1743998501

From asotona at openjdk.org  Wed Sep  4 16:28:30 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Sep 2024 16:28:30 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v3]
In-Reply-To: <K-tbwjIZxGQLSmN95RpVX8xvTYMf26-OQ_ssFTxrEjM=.fa8fed7b-65ec-445a-bd23-e3ae5e7edbd1@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
 <QIQmLRgZ4XDoHMyy9SR5s2lrYAykrA92OtLo3w0rUM0=.92c22d43-6801-44f3-918d-0e6437a89612@github.com>
 <du0zv0mdILef68Z65c3SjjCxx8UU-yPUhOB96lr2HK0=.33a2fb7d-fe7a-4088-9f56-335542ccfc2d@github.com>
 <2EbvGENjbXpsocN1I2QvnMyP3PO-wYzs1vbP6pff8PU=.61c6d2ff-2e58-4317-a0f0-cb36b5a83027@github.com>
 <LZdxQvUThVCH8IUICG56pHAtWpKgsOt6pDNjEd07cls=.a7141ae7-db4f-43c8-94f8-d542229a413c@github.com>
 <WmPQwPZhl0paWB2KLJiI7cwxfv1lXOeuOTIhUi4cE3g=.bed42c13-79f4-4be5-b2aa-479362221db8@github.com>
 <fXuVJwbr0S-_qYsVpqI9pjOKhzJRUrPDWAuxaRYDEGo=.c1fbabe1-ad19-4ec3-94c5-9b13581fa643@github.com>
 <K-tbwjIZxGQLSmN95RpVX8xvTYMf26-OQ_ssFTxrEjM=.fa8fed7b-65ec-445a-bd23-e3ae5e7edbd1@github.com>
Message-ID: <bMGolNKKeEwRKC5AGCor79eYjC-COPA2nzSmy5heBA8=.f78adb5c-dec1-4265-a12b-c44ab48df780@github.com>

On Wed, 4 Sep 2024 15:21:31 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Individual dominations are handled as you describe. It applies for cases like this:
>> 
>> entry -> var -> var store -> var load
>>             \
>>               > var store -> var load 
>> 
>> 
>> However following case needs a test for dominant set:
>> 
>> entry -> var -> var store -> var load
>>             \             /
>>               > var store
>> 
>> The var load is not dominated by any individual var store, however it is dominated by them.
>> 
>> The test should fail for example on following case:
>> 
>> entry -> var -> var store -> var load
>>              \            /     
>>                 ---------
>> 
>> 
>> The reason why the second part is focused on blocks only is because ops cannot form a bypass inside one block.
>
> Thanks! Doh, of course, i get it now. I think what you are doing is the equivalent of DA analysis. Perhaps we can rename the method accordingly? e.g., `isDefinitelyAssigned` (noting it does not distinguish between assignment with a default value or non-assignment in source because we don't currently make that distinction in the model).
> 
> What does the bytecode verifier do when it encounters bytecode in the last case? I expect the verifier will be enhanced to support the new object initialization protocol.

Code with redundant default value assignment is valid, it just causes instability (the code grows with each round).

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

PR Review Comment: https://git.openjdk.org/babylon/pull/219#discussion_r1744092091

From asotona at openjdk.org  Wed Sep  4 16:34:07 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Sep 2024 16:34:07 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v6]
In-Reply-To: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
Message-ID: <Y8L6IBR-z-j3D4zfOsVKMHrrorKstLIGzUs22mSSDB4=.bf56eed1-9761-4898-b88a-1bdd3e15ec77@github.com>

> - Added test for operand values dominance revealed a bug in the BytecodeLift.
> - Fixed BytecodeLift revealed regression in the roundtrip stability.
> - Roundtrip instability was caused by a bug in the LocalsTypeMapper.
> 
> All the above is fixed and the roundtrip stability is restored.
> 
> Please review.
> 
> Thanks,
> Adam

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

  suggested rename

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/219/files
  - new: https://git.openjdk.org/babylon/pull/219/files/6a730b02..69866f47

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

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

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

From psandoz at openjdk.org  Wed Sep  4 16:56:33 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 4 Sep 2024 16:56:33 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v6]
In-Reply-To: <Y8L6IBR-z-j3D4zfOsVKMHrrorKstLIGzUs22mSSDB4=.bf56eed1-9761-4898-b88a-1bdd3e15ec77@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
 <Y8L6IBR-z-j3D4zfOsVKMHrrorKstLIGzUs22mSSDB4=.bf56eed1-9761-4898-b88a-1bdd3e15ec77@github.com>
Message-ID: <KBBOHpsgxj-a89KDfsgPlMj2uUOBI2p6xlAYRsnM5LE=.77a9895b-46f8-44d2-82ac-9879a75fc7b5@github.com>

On Wed, 4 Sep 2024 16:34:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> - Added test for operand values dominance revealed a bug in the BytecodeLift.
>> - Fixed BytecodeLift revealed regression in the roundtrip stability.
>> - Roundtrip instability was caused by a bug in the LocalsTypeMapper.
>> 
>> All the above is fixed and the roundtrip stability is restored.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested rename

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/219#pullrequestreview-2280777513

From psandoz at openjdk.org  Wed Sep  4 17:05:36 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 4 Sep 2024 17:05:36 GMT
Subject: [code-reflection] RFR: Unify code that generates code model of
 switch statement and expression [v2]
In-Reply-To: <ShIT7YMW6sQ3NWytHFOfJESdm-cmj85ehIOnNfQls8M=.7eab7f68-1012-4c5e-aa0d-fc0a20e35d8b@github.com>
References: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
 <ShIT7YMW6sQ3NWytHFOfJESdm-cmj85ehIOnNfQls8M=.7eab7f68-1012-4c5e-aa0d-fc0a20e35d8b@github.com>
Message-ID: <_PX5CdvYfRAPhTLV7nXNXGk2zRN2mh29mlAkElGvlXk=.1e82dd19-680a-454e-af05-5fa9dca71b63@github.com>

On Wed, 4 Sep 2024 03:50:08 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Unify code that generates code model of switch statement and expression
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1522:

> 1520:             if (tree instanceof JCTree.JCSwitch sw) {
> 1521:                 selector = sw.selector;
> 1522:                 cases = sw.cases;

Pass these in as arguments, then you can pass the selector to visitCaseLabel.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1695:

> 1693:                 Type switchType = adaptBottom(tree.type);
> 1694:                 caseBodyType = FunctionType.functionType(typeToTypeElement(switchType));
> 1695:                 yieldType = adaptBottom(tree.type);

Are we not already passing the FunctionType to visitSwitchStatAndExpr? So the only difference would be the yieldType.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/220#discussion_r1744137542
PR Review Comment: https://git.openjdk.org/babylon/pull/220#discussion_r1744139436

From mabbay at openjdk.org  Thu Sep  5 01:49:24 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 5 Sep 2024 01:49:24 GMT
Subject: [code-reflection] RFR: Unify code that generates code model of
 switch statement and expression [v3]
In-Reply-To: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
References: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
Message-ID: <gF2c002S-qBfnd3terqsunTljnrU8Ivj9cIuZKY2tqk=.e12401bb-7ccc-4ded-be55-b0876865b536@github.com>

> Unify code that generates code model of switch statement and expression

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/220/files
  - new: https://git.openjdk.org/babylon/pull/220/files/2be94f11..784670c7

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

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

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

From asotona at openjdk.org  Thu Sep  5 06:06:05 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 5 Sep 2024 06:06:05 GMT
Subject: git: openjdk/babylon: code-reflection: Bytecode round 12
Message-ID: <d7a0e640-2d57-4f97-8f3b-ed8298d0b4e8@openjdk.org>

Changeset: 445a57f8
Branch: code-reflection
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-09-05 06:04:50 +0000
URL:       https://git.openjdk.org/babylon/commit/445a57f874c91e342fbc644a36d97861d56a49db

Bytecode round 12

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/LocalsTypeMapper.java
! test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java


From asotona at openjdk.org  Thu Sep  5 06:08:02 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 5 Sep 2024 06:08:02 GMT
Subject: [code-reflection] RFR: Bytecode round 12 [v6]
In-Reply-To: <Y8L6IBR-z-j3D4zfOsVKMHrrorKstLIGzUs22mSSDB4=.bf56eed1-9761-4898-b88a-1bdd3e15ec77@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
 <Y8L6IBR-z-j3D4zfOsVKMHrrorKstLIGzUs22mSSDB4=.bf56eed1-9761-4898-b88a-1bdd3e15ec77@github.com>
Message-ID: <Qgqh5r8uxReIcqKuS_TEPo2FQUAxNKPRUtNmJEUNeOw=.27af95c7-1657-4eb3-83fb-4226ad30b08f@github.com>

On Wed, 4 Sep 2024 16:34:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> - Added test for operand values dominance revealed a bug in the BytecodeLift.
>> - Fixed BytecodeLift revealed regression in the roundtrip stability.
>> - Roundtrip instability was caused by a bug in the LocalsTypeMapper.
>> 
>> All the above is fixed and the roundtrip stability is restored.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested rename

Thank you for the review!

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

PR Comment: https://git.openjdk.org/babylon/pull/219#issuecomment-2330671586

From asotona at openjdk.org  Thu Sep  5 06:08:02 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 5 Sep 2024 06:08:02 GMT
Subject: [code-reflection] Integrated: Bytecode round 12
In-Reply-To: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
References: <YwXHccdko7LZo6accIeRnzHqOTKzjgAbZ-a4_AhEoW4=.a1f04bff-2329-4e53-ae78-42b2bfe30b8b@github.com>
Message-ID: <Q2AhYJNxUxRzomKn983bkWIyis8qECgvibdghKE0d2U=.07c7902e-9027-4597-9051-935f95d9c896@github.com>

On Fri, 30 Aug 2024 09:15:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> - Added test for operand values dominance revealed a bug in the BytecodeLift.
> - Fixed BytecodeLift revealed regression in the roundtrip stability.
> - Roundtrip instability was caused by a bug in the LocalsTypeMapper.
> 
> All the above is fixed and the roundtrip stability is restored.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 445a57f8
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/445a57f874c91e342fbc644a36d97861d56a49db
Stats:     150 lines in 4 files changed: 129 ins; 0 del; 21 mod

Bytecode round 12

Reviewed-by: psandoz

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

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

From mcimadamore at openjdk.org  Thu Sep  5 12:37:14 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 12:37:14 GMT
Subject: [code-reflection] RFR: Unify code that generates code model of
 switch statement and expression [v3]
In-Reply-To: <gF2c002S-qBfnd3terqsunTljnrU8Ivj9cIuZKY2tqk=.e12401bb-7ccc-4ded-be55-b0876865b536@github.com>
References: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
 <gF2c002S-qBfnd3terqsunTljnrU8Ivj9cIuZKY2tqk=.e12401bb-7ccc-4ded-be55-b0876865b536@github.com>
Message-ID: <bXwA0sDup_-RD1i0tK8ORmVQqQ0LeCzPWzbuRjjXTtw=.851b9574-23d0-45ba-8698-44174ca51962@github.com>

On Thu, 5 Sep 2024 01:49:24 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Unify code that generates code model of switch statement and expression
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1533:

> 1531:                 Body.Builder caseBody = visitCaseBody(c, caseBodyType);
> 1532: 
> 1533:                 if (c.labels.head instanceof JCTree.JCDefaultCaseLabel) {

I'm not sure this is optimal - can't we add all labels and bodies (even default ones) and then, after the loop, only add a synthetic default label if `isDefaultCaseNeeded` is set? Or, if there are cases where the flag is set, but there is already a real default label, can we maybe just unset the flag if we see a default label in the loop?

In other words, I don't see what adding the "regular" default body after the loop buys us.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/220#discussion_r1745400613

From mabbay at openjdk.org  Thu Sep  5 16:46:05 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 5 Sep 2024 16:46:05 GMT
Subject: [code-reflection] RFR: Unify code that generates code model of
 switch statement and expression [v3]
In-Reply-To: <bXwA0sDup_-RD1i0tK8ORmVQqQ0LeCzPWzbuRjjXTtw=.851b9574-23d0-45ba-8698-44174ca51962@github.com>
References: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
 <gF2c002S-qBfnd3terqsunTljnrU8Ivj9cIuZKY2tqk=.e12401bb-7ccc-4ded-be55-b0876865b536@github.com>
 <bXwA0sDup_-RD1i0tK8ORmVQqQ0LeCzPWzbuRjjXTtw=.851b9574-23d0-45ba-8698-44174ca51962@github.com>
Message-ID: <5grtzQ9vO7xUnu2-1jA25sWFcCe-f-fbSBm4W2SzusU=.8855b183-f3d9-472d-8bec-d5f1717ac170@github.com>

On Thu, 5 Sep 2024 12:32:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1533:
> 
>> 1531:                 Body.Builder caseBody = visitCaseBody(c, caseBodyType);
>> 1532: 
>> 1533:                 if (c.labels.head instanceof JCTree.JCDefaultCaseLabel) {
> 
> I'm not sure this is optimal - can't we add all labels and bodies (even default ones) and then, after the loop, only add a synthetic default label if `isDefaultCaseNeeded` is set? Or, if there are cases where the flag is set, but there is already a real default label, can we maybe just unset the flag if we see a default label in the loop?
> 
> In other words, I don't see what adding the "regular" default body after the loop buys us.

We want to have the default body as the last one.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/220#discussion_r1745866356

From mcimadamore at openjdk.org  Thu Sep  5 16:52:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 16:52:12 GMT
Subject: [code-reflection] RFR: Unify code that generates code model of
 switch statement and expression [v3]
In-Reply-To: <gF2c002S-qBfnd3terqsunTljnrU8Ivj9cIuZKY2tqk=.e12401bb-7ccc-4ded-be55-b0876865b536@github.com>
References: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
 <gF2c002S-qBfnd3terqsunTljnrU8Ivj9cIuZKY2tqk=.e12401bb-7ccc-4ded-be55-b0876865b536@github.com>
Message-ID: <7qsxUZgXKSmveEf7GI8NjE5cMJVPBlooMFMiNG0Y_y4=.327156cd-0654-45f6-9056-7ce43e1f7d2d@github.com>

On Thu, 5 Sep 2024 01:49:24 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Unify code that generates code model of switch statement and expression
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/babylon/pull/220#pullrequestreview-2283608950

From mcimadamore at openjdk.org  Thu Sep  5 16:52:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 16:52:12 GMT
Subject: [code-reflection] RFR: Unify code that generates code model of
 switch statement and expression [v3]
In-Reply-To: <5grtzQ9vO7xUnu2-1jA25sWFcCe-f-fbSBm4W2SzusU=.8855b183-f3d9-472d-8bec-d5f1717ac170@github.com>
References: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
 <gF2c002S-qBfnd3terqsunTljnrU8Ivj9cIuZKY2tqk=.e12401bb-7ccc-4ded-be55-b0876865b536@github.com>
 <bXwA0sDup_-RD1i0tK8ORmVQqQ0LeCzPWzbuRjjXTtw=.851b9574-23d0-45ba-8698-44174ca51962@github.com>
 <5grtzQ9vO7xUnu2-1jA25sWFcCe-f-fbSBm4W2SzusU=.8855b183-f3d9-472d-8bec-d5f1717ac170@github.com>
Message-ID: <V3L26Xcfhbg0L862b86oawIafxx5cAwgEeYHWCgrSHc=.9827e390-fc8f-4654-b89b-f47520a9a3f8@github.com>

On Thu, 5 Sep 2024 16:43:21 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1533:
>> 
>>> 1531:                 Body.Builder caseBody = visitCaseBody(c, caseBodyType);
>>> 1532: 
>>> 1533:                 if (c.labels.head instanceof JCTree.JCDefaultCaseLabel) {
>> 
>> I'm not sure this is optimal - can't we add all labels and bodies (even default ones) and then, after the loop, only add a synthetic default label if `isDefaultCaseNeeded` is set? Or, if there are cases where the flag is set, but there is already a real default label, can we maybe just unset the flag if we see a default label in the loop?
>> 
>> In other words, I don't see what adding the "regular" default body after the loop buys us.
>
> We want the regular default body to be in the last position.

ok

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

PR Review Comment: https://git.openjdk.org/babylon/pull/220#discussion_r1745873447

From mabbay at openjdk.org  Thu Sep  5 16:52:12 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 5 Sep 2024 16:52:12 GMT
Subject: [code-reflection] RFR: Unify code that generates code model of
 switch statement and expression [v3]
In-Reply-To: <V3L26Xcfhbg0L862b86oawIafxx5cAwgEeYHWCgrSHc=.9827e390-fc8f-4654-b89b-f47520a9a3f8@github.com>
References: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
 <gF2c002S-qBfnd3terqsunTljnrU8Ivj9cIuZKY2tqk=.e12401bb-7ccc-4ded-be55-b0876865b536@github.com>
 <bXwA0sDup_-RD1i0tK8ORmVQqQ0LeCzPWzbuRjjXTtw=.851b9574-23d0-45ba-8698-44174ca51962@github.com>
 <5grtzQ9vO7xUnu2-1jA25sWFcCe-f-fbSBm4W2SzusU=.8855b183-f3d9-472d-8bec-d5f1717ac170@github.com>
 <V3L26Xcfhbg0L862b86oawIafxx5cAwgEeYHWCgrSHc=.9827e390-fc8f-4654-b89b-f47520a9a3f8@github.com>
Message-ID: <dtbNSSGCiQW-EqQ1TX4lPwTIfRSUW3NyhEaRg9hfp0I=.d6781b68-6b92-408a-bf5d-eeae0a1fc4b6@github.com>

On Thu, 5 Sep 2024 16:49:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> We want the regular default body to be in the last position.
>
> ok

This simplifies the lowering as example.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/220#discussion_r1745873546

From psandoz at openjdk.org  Thu Sep  5 18:08:02 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 5 Sep 2024 18:08:02 GMT
Subject: [code-reflection] RFR: Unify code that generates code model of
 switch statement and expression [v3]
In-Reply-To: <gF2c002S-qBfnd3terqsunTljnrU8Ivj9cIuZKY2tqk=.e12401bb-7ccc-4ded-be55-b0876865b536@github.com>
References: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
 <gF2c002S-qBfnd3terqsunTljnrU8Ivj9cIuZKY2tqk=.e12401bb-7ccc-4ded-be55-b0876865b536@github.com>
Message-ID: <QqEzc6qY_INsThjVCsRoC-FaFBvUH_2MOcfFirZnIbg=.2705d633-4471-467b-a7f6-44f0cf2142c0@github.com>

On Thu, 5 Sep 2024 01:49:24 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Unify code that generates code model of switch statement and expression
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor

Marked as reviewed by psandoz (Lead).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1674:

> 1672: 
> 1673:             JCTree.JCCaseLabel headCl = c.labels.head;
> 1674:             switch (c.caseKind) {

Suggestion, up to you. You can make this a switch expression yielding the body builder and directly return the result

return switch (c.caseKind) {
...

  try {
    yield stack.body;
  } finally {
    popBody();
  }
...

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

PR Review: https://git.openjdk.org/babylon/pull/220#pullrequestreview-2283759177
PR Review Comment: https://git.openjdk.org/babylon/pull/220#discussion_r1745962614

From psandoz at openjdk.org  Thu Sep  5 22:57:38 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 5 Sep 2024 22:57:38 GMT
Subject: [code-reflection] RFR: Super expressions
Message-ID: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>

Support super expressions.

The work in the bytecode generator is not complete, and a disabled test has been added. Currently when it encounters an invoke super operation it will throw. We cannot generate invokespecial instructions as this will create invalid bytecode (the calling class is not related to the referenced class). Instead, in a subsequent PR, we need to dynamically generate method handles, pass them as class data to the defined hidden class, so they can be loaded as constants and invoked (and therefore emulating the invokespecial instruction). That subsequent PR should also address the lifting of invokespecial instructions.

This work has shown deficiencies in the modeling of invocation expressions and the resolution of `MethodRef`s. The latter has been partially addressed by providing additional information for resolution, namely the kind of invocation.

Invocation operations do not fully model invocation to vararg methods and this means we cannot reliably determine in all cases if the invocation has a receiver operand or not (a class or instance invocation). This should be fixed in a subsequent PR. The fix might require the following:
- explicit modeling of class and instance and invocation; and
- modeling var args as a prefix (sublist) of the operand list

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

Commit messages:
 - update
 - Updates
 - Super expressions

Changes: https://git.openjdk.org/babylon/pull/221/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=221&range=00
  Stats: 636 lines in 16 files changed: 494 ins; 93 del; 49 mod
  Patch: https://git.openjdk.org/babylon/pull/221.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/221/head:pull/221

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

From psandoz at openjdk.org  Fri Sep  6 00:06:39 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 00:06:39 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
Message-ID: <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>

> Support super expressions.
> 
> The work in the bytecode generator is not complete, and a disabled test has been added. Currently when it encounters an invoke super operation it will throw. We cannot generate invokespecial instructions as this will create invalid bytecode (the calling class is not related to the referenced class). Instead, in a subsequent PR, we need to dynamically generate method handles, pass them as class data to the defined hidden class, so they can be loaded as constants and invoked (and therefore emulating the invokespecial instruction). That subsequent PR should also address the lifting of invokespecial instructions.
> 
> This work has shown deficiencies in the modeling of invocation expressions and the resolution of `MethodRef`s. The latter has been partially addressed by providing additional information for resolution, namely the kind of invocation.
> 
> Invocation operations do not fully model invocation to vararg methods and this means we cannot reliably determine in all cases if the invocation has a receiver operand or not (a class or instance invocation). This should be fixed in a subsequent PR. The fix might require the following:
> - explicit modeling of class and instance and invocation; and
> - modeling var args as a prefix (sublist) of the operand list

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

  Remove comment.

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/221/files
  - new: https://git.openjdk.org/babylon/pull/221/files/9e419b38..e1e1e0ed

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

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

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

From mabbay at openjdk.org  Fri Sep  6 03:05:46 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Fri, 6 Sep 2024 03:05:46 GMT
Subject: git: openjdk/babylon: code-reflection: Unify code that generates code
 model of switch statement and expression
Message-ID: <efaf92f6-cf64-4ccf-a818-c836f4fa574f@openjdk.org>

Changeset: 962d313c
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2024-09-06 03:04:44 +0000
URL:       https://git.openjdk.org/babylon/commit/962d313c85e16d62b1d69a70490e6d7611017a95

Unify code that generates code model of switch statement and expression

Reviewed-by: mcimadamore, psandoz

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java


From mabbay at openjdk.org  Fri Sep  6 03:08:01 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Fri, 6 Sep 2024 03:08:01 GMT
Subject: [code-reflection] Integrated: Unify code that generates code model of
 switch statement and expression
In-Reply-To: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
References: <VuJYZBveWTvI98AVU9tkl8PYKyZ3Sxv9cYAUX97K25g=.1f4713ca-d26b-4ae6-ae03-c9e5dbae814e@github.com>
Message-ID: <d9cKl2qWnzfn2J2dGgEdfSjvuRiQLuYkvxCqPWxwnOM=.eb0ee2c1-0b3d-4536-9121-d2d9e9c10089@github.com>

On Wed, 4 Sep 2024 03:21:29 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Unify code that generates code model of switch statement and expression

This pull request has now been integrated.

Changeset: 962d313c
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/962d313c85e16d62b1d69a70490e6d7611017a95
Stats:     356 lines in 1 file changed: 70 ins; 204 del; 82 mod

Unify code that generates code model of switch statement and expression

Reviewed-by: mcimadamore, psandoz

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

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

From mabbay at openjdk.org  Fri Sep  6 04:33:39 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Fri, 6 Sep 2024 04:33:39 GMT
Subject: [code-reflection] RFR: Unify common code of SwitchStatementOp and
 SwitchExpressionOp
Message-ID: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>

Unify common code of SwitchStatementOp and SwitchExpressionOp.

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

Commit messages:
 - Refactor

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

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

From mcimadamore at openjdk.org  Fri Sep  6 07:55:03 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 07:55:03 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
Message-ID: <LY9_xxF5dN6HgV_8d0xqmqPs8WkgRB4VOfroWW1YIFs=.617eca3a-7991-48d3-9636-5076b51bcd49@github.com>

On Fri, 6 Sep 2024 00:06:39 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Support super expressions.
>> 
>> The work in the bytecode generator is not complete, and a disabled test has been added. Currently when it encounters an invoke super operation it will throw. We cannot generate invokespecial instructions as this will create invalid bytecode (the calling class is not related to the referenced class). Instead, in a subsequent PR, we need to dynamically generate method handles, pass them as class data to the defined hidden class, so they can be loaded as constants and invoked (and therefore emulating the invokespecial instruction). That subsequent PR should also address the lifting of invokespecial instructions.
>> 
>> This work has shown deficiencies in the modeling of invocation expressions and the resolution of `MethodRef`s. The latter has been partially addressed by providing additional information for resolution, namely the kind of invocation.
>> 
>> Invocation operations do not fully model invocation to vararg methods and this means we cannot reliably determine in all cases if the invocation has a receiver operand or not (a class or instance invocation). This should be fixed in a subsequent PR. The fix might require the following:
>> - explicit modeling of class and instance and invocation; and
>> - modeling var args as a prefix (sublist) of the operand list
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment.

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

> 1461:          */
> 1462:         @OpFactory.OpDeclaration(InvokeInstanceClassOp.NAME)
> 1463:         public static final class InvokeInstanceClassOp extends InvokeOp {

Unsure whether this is just a kind - e.g. whether to split or lump. So I'm ok with what you did for now.

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

> 3719:      * @return the invoke operation
> 3720:      */
> 3721:     public static InvokeOp.InvokeSuperOp invokeSuper(TypeElement returnType, MethodRef invokeDescriptor, List<Value> args) {

The split here hits hard - as you need M * K overloads (in the general case) where M is the number of overloads per kind, and K is the number of kinds we end up supporting.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1746663631
PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1746665408

From mcimadamore at openjdk.org  Fri Sep  6 07:59:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 07:59:11 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
Message-ID: <dhBo3Il9MY0F7vDqXFS_VY8lgH7Kume0v-Ssai9W4Q0=.eb60b118-4e39-4b13-85c4-0c37ef5036fc@github.com>

On Fri, 6 Sep 2024 00:06:39 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Support super expressions.
>> 
>> The work in the bytecode generator is not complete, and a disabled test has been added. Currently when it encounters an invoke super operation it will throw. We cannot generate invokespecial instructions as this will create invalid bytecode (the calling class is not related to the referenced class). Instead, in a subsequent PR, we need to dynamically generate method handles, pass them as class data to the defined hidden class, so they can be loaded as constants and invoked (and therefore emulating the invokespecial instruction). That subsequent PR should also address the lifting of invokespecial instructions.
>> 
>> This work has shown deficiencies in the modeling of invocation expressions and the resolution of `MethodRef`s. The latter has been partially addressed by providing additional information for resolution, namely the kind of invocation.
>> 
>> Invocation operations do not fully model invocation to vararg methods and this means we cannot reliably determine in all cases if the invocation has a receiver operand or not (a class or instance invocation). This should be fixed in a subsequent PR. The fix might require the following:
>> - explicit modeling of class and instance and invocation; and
>> - modeling var args as a prefix (sublist) of the operand list
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment.

src/java.base/share/classes/java/lang/reflect/code/type/TypeVarRef.java line 54:

> 52:         TypeVariable<?>[] typeVariables = switch (owner) {
> 53:             case MethodRef methodRef -> {
> 54:                 // @@@ resolves to class or instance method

ouch :-)
The thing here is: to go to a `j.l.r.Method` you don't really need to know the kind, do you? E.g. a method handle is kind-sensitive, but a reflective method is not?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1746669631

From mcimadamore at openjdk.org  Fri Sep  6 07:59:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 07:59:11 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <dhBo3Il9MY0F7vDqXFS_VY8lgH7Kume0v-Ssai9W4Q0=.eb60b118-4e39-4b13-85c4-0c37ef5036fc@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
 <dhBo3Il9MY0F7vDqXFS_VY8lgH7Kume0v-Ssai9W4Q0=.eb60b118-4e39-4b13-85c4-0c37ef5036fc@github.com>
Message-ID: <9P7rK8oG0rEonA4veEj4v7DgsZAKUUwx__f1yEsb1i0=.62ee09f4-06c3-4c0c-82d4-86d50944b497@github.com>

On Fri, 6 Sep 2024 07:55:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove comment.
>
> src/java.base/share/classes/java/lang/reflect/code/type/TypeVarRef.java line 54:
> 
>> 52:         TypeVariable<?>[] typeVariables = switch (owner) {
>> 53:             case MethodRef methodRef -> {
>> 54:                 // @@@ resolves to class or instance method
> 
> ouch :-)
> The thing here is: to go to a `j.l.r.Method` you don't really need to know the kind, do you? E.g. a method handle is kind-sensitive, but a reflective method is not?

Problem is we're doing the method lookup using the method handle lookup and then cracking open the method handle - perhaps reflective methods should be looked-up in a separate way.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1746670741

From mabbay at openjdk.org  Fri Sep  6 08:02:38 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Fri, 6 Sep 2024 08:02:38 GMT
Subject: [code-reflection] RFR: Change the model of the default label of switch
Message-ID: <nk2B-u0jdwUovVQrLz8LtQvmuBsu3G0g12l3q6KDFtE=.e66679e3-1248-48db-b18f-9ec64c5996d8@github.com>

Model default label of switch as a body that yield true, this makes the modeling consistent for all labels.

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

Commit messages:
 - Change the model of the default label of switch

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

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

From mcimadamore at openjdk.org  Fri Sep  6 08:06:08 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 08:06:08 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
Message-ID: <SAjI7kpXVOyrVOObSDIdTc9dM5C3oKm_nyOgAVMRVaM=.b619a855-935b-4547-bd29-0a822f410830@github.com>

On Fri, 6 Sep 2024 00:06:39 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Support super expressions.
>> 
>> The work in the bytecode generator is not complete, and a disabled test has been added. Currently when it encounters an invoke super operation it will throw. We cannot generate invokespecial instructions as this will create invalid bytecode (the calling class is not related to the referenced class). Instead, in a subsequent PR, we need to dynamically generate method handles, pass them as class data to the defined hidden class, so they can be loaded as constants and invoked (and therefore emulating the invokespecial instruction). That subsequent PR should also address the lifting of invokespecial instructions.
>> 
>> This work has shown deficiencies in the modeling of invocation expressions and the resolution of `MethodRef`s. The latter has been partially addressed by providing additional information for resolution, namely the kind of invocation.
>> 
>> Invocation operations do not fully model invocation to vararg methods and this means we cannot reliably determine in all cases if the invocation has a receiver operand or not (a class or instance invocation). This should be fixed in a subsequent PR. The fix might require the following:
>> - explicit modeling of class and instance and invocation; and
>> - modeling var args as a prefix (sublist) of the operand list
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1023:

> 1021:                 switch (sym.getKind()) {
> 1022:                     case FIELD, ENUM_CONSTANT -> {
> 1023:                         if (sym.name.equals(names._this) || sym.name.equals(names._super)) {

Not sure: don't we need super also for field access? E.g.


class A {
   Object o;
}
class B extends A {
    int o; // shadows A.o
    Object superO() { return super.o; }
}

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1746676423

From mcimadamore at openjdk.org  Fri Sep  6 08:06:08 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 08:06:08 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <SAjI7kpXVOyrVOObSDIdTc9dM5C3oKm_nyOgAVMRVaM=.b619a855-935b-4547-bd29-0a822f410830@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
 <SAjI7kpXVOyrVOObSDIdTc9dM5C3oKm_nyOgAVMRVaM=.b619a855-935b-4547-bd29-0a822f410830@github.com>
Message-ID: <igqC_dzZv7RW3LRvlPDZcP89bS3sL8M2VkWtESMYSZ0=.79155b2e-ba7c-47df-8762-dbdb978a0b72@github.com>

On Fri, 6 Sep 2024 08:01:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove comment.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1023:
> 
>> 1021:                 switch (sym.getKind()) {
>> 1022:                     case FIELD, ENUM_CONSTANT -> {
>> 1023:                         if (sym.name.equals(names._this) || sym.name.equals(names._super)) {
> 
> Not sure: don't we need super also for field access? E.g.
> 
> 
> class A {
>    Object o;
> }
> class B extends A {
>     int o; // shadows A.o
>     Object superO() { return super.o; }
> }

I wonder if a modelling where `super` is its own expression would be beneficial. E.g. like some kind of "virtual field" on `this`. E.g. one would load `this` and then access `super` onto it (and maybe there's a core op for _that_). Then the result is used for either a method receiver, or field access expression.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1746679296

From mcimadamore at openjdk.org  Fri Sep  6 08:15:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 08:15:10 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
Message-ID: <t35NxYDps4o_ZYBXxEdBRCj-ZSzhHwtu8B_1u20Mj0Q=.cfcce8ae-32b2-4b1d-b9ea-87330c044317@github.com>

On Fri, 6 Sep 2024 00:06:39 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Support super expressions.
>> 
>> The work in the bytecode generator is not complete, and a disabled test has been added. Currently when it encounters an invoke super operation it will throw. We cannot generate invokespecial instructions as this will create invalid bytecode (the calling class is not related to the referenced class). Instead, in a subsequent PR, we need to dynamically generate method handles, pass them as class data to the defined hidden class, so they can be loaded as constants and invoked (and therefore emulating the invokespecial instruction). That subsequent PR should also address the lifting of invokespecial instructions.
>> 
>> This work has shown deficiencies in the modeling of invocation expressions and the resolution of `MethodRef`s. The latter has been partially addressed by providing additional information for resolution, namely the kind of invocation.
>> 
>> Invocation operations do not fully model invocation to vararg methods and this means we cannot reliably determine in all cases if the invocation has a receiver operand or not (a class or instance invocation). This should be fixed in a subsequent PR. The fix might require the following:
>> - explicit modeling of class and instance and invocation; and
>> - modeling var args as a prefix (sublist) of the operand list
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment.

javac and model changes look solid. I've left some comments/questions for your consideration.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1095:

> 1093:                     if (!sym.isStatic()) {
> 1094:                         args.add(receiver);
> 1095:                         isSuper = switch (access.selected) {

Note for later - `expr.super(...)` for inner class super constructor calls. Perhaps add a `@@@` comment now?

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/babylon/pull/221#pullrequestreview-2285340981
PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1746683997

From mcimadamore at openjdk.org  Fri Sep  6 08:15:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 08:15:10 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <igqC_dzZv7RW3LRvlPDZcP89bS3sL8M2VkWtESMYSZ0=.79155b2e-ba7c-47df-8762-dbdb978a0b72@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
 <SAjI7kpXVOyrVOObSDIdTc9dM5C3oKm_nyOgAVMRVaM=.b619a855-935b-4547-bd29-0a822f410830@github.com>
 <igqC_dzZv7RW3LRvlPDZcP89bS3sL8M2VkWtESMYSZ0=.79155b2e-ba7c-47df-8762-dbdb978a0b72@github.com>
Message-ID: <E0W0K2ZG9Tm6Ylu9qH8J9ke9R1UlxANJp6siGBLovF8=.16135bcf-3869-4f24-b8b8-7690679845c4@github.com>

On Fri, 6 Sep 2024 08:03:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1023:
>> 
>>> 1021:                 switch (sym.getKind()) {
>>> 1022:                     case FIELD, ENUM_CONSTANT -> {
>>> 1023:                         if (sym.name.equals(names._this) || sym.name.equals(names._super)) {
>> 
>> Not sure: don't we need super also for field access? E.g.
>> 
>> 
>> class A {
>>    Object o;
>> }
>> class B extends A {
>>     int o; // shadows A.o
>>     Object superO() { return super.o; }
>> }
>
> I wonder if a modelling where `super` is its own expression would be beneficial. E.g. like some kind of "virtual field" on `this`. E.g. one would load `this` and then access `super` onto it (and maybe there's a core op for _that_). Then the result is used for either a method receiver, or field access expression.

Although I suppose in my example, we still generate a `getfield` for `super.o`, just with a different symbolic description - so the generated model ends up being fine. I suppose I'm not 100% comfortable with the fact that the model here seems to capture a bytecode distinction (e.g. super calls use a special invocation mode, but super field access do not, so we only model the former), rather than a syntactic difference in the original source (e.g. for both method and field access, the `super` keyword is there).

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1746682715

From mcimadamore at openjdk.org  Fri Sep  6 08:15:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 08:15:10 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <t35NxYDps4o_ZYBXxEdBRCj-ZSzhHwtu8B_1u20Mj0Q=.cfcce8ae-32b2-4b1d-b9ea-87330c044317@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
 <t35NxYDps4o_ZYBXxEdBRCj-ZSzhHwtu8B_1u20Mj0Q=.cfcce8ae-32b2-4b1d-b9ea-87330c044317@github.com>
Message-ID: <Q8jGmV3GoETbReLfoPhiqMdAcCEsexguhzq-45gu5v0=.d5a7f57e-9723-4e09-8d82-d3e006ad1115@github.com>

On Fri, 6 Sep 2024 08:07:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove comment.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1095:
> 
>> 1093:                     if (!sym.isStatic()) {
>> 1094:                         args.add(receiver);
>> 1095:                         isSuper = switch (access.selected) {
> 
> Note for later - `expr.super(...)` for inner class super constructor calls. Perhaps add a `@@@` comment now?

But... bonus points for having handled `Foo.super.xyz` and `Foo.this.xyz` :-)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1746687555

From mabbay at openjdk.org  Fri Sep  6 08:35:32 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Fri, 6 Sep 2024 08:35:32 GMT
Subject: [code-reflection] RFR: Change the model of the default label of
 switch [v2]
In-Reply-To: <nk2B-u0jdwUovVQrLz8LtQvmuBsu3G0g12l3q6KDFtE=.e66679e3-1248-48db-b18f-9ec64c5996d8@github.com>
References: <nk2B-u0jdwUovVQrLz8LtQvmuBsu3G0g12l3q6KDFtE=.e66679e3-1248-48db-b18f-9ec64c5996d8@github.com>
Message-ID: <uQ3kulToTfaqxgcyd1uT0mxfW3s2tYL0AbpNSahrVEs=.8c111b15-81bd-48d2-a6e7-9dd93febbf1c@github.com>

> Model the default label of switch as a body that yield true, this makes the modeling consistent for all labels.

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

  Fix NullTest

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/223/files
  - new: https://git.openjdk.org/babylon/pull/223/files/0a332309..c0f04b79

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

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

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

From mcimadamore at openjdk.org  Fri Sep  6 08:48:00 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 08:48:00 GMT
Subject: [code-reflection] RFR: Change the model of the default label of
 switch [v2]
In-Reply-To: <uQ3kulToTfaqxgcyd1uT0mxfW3s2tYL0AbpNSahrVEs=.8c111b15-81bd-48d2-a6e7-9dd93febbf1c@github.com>
References: <nk2B-u0jdwUovVQrLz8LtQvmuBsu3G0g12l3q6KDFtE=.e66679e3-1248-48db-b18f-9ec64c5996d8@github.com>
 <uQ3kulToTfaqxgcyd1uT0mxfW3s2tYL0AbpNSahrVEs=.8c111b15-81bd-48d2-a6e7-9dd93febbf1c@github.com>
Message-ID: <Mdz3QhX275vrN7ah2T5-wJTeE0Np_6gnEppLriPmpQY=.13c5a00f-07b2-4c8a-8105-f491489d2d2c@github.com>

On Fri, 6 Sep 2024 08:35:32 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Model the default label of switch as a body that yield true, this makes the modeling consistent for all labels.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix NullTest

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1671:

> 1669: 
> 1670:             Body.Builder body = null;
> 1671:             Type yieldType = tree.type != null ? adaptBottom(tree.type) : null;

Why the change here?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/223#discussion_r1746731819

From erikj at openjdk.org  Fri Sep  6 14:19:50 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 6 Sep 2024 14:19:50 GMT
Subject: [code-reflection] RFR: 8337158: Modeling and lowering of switch
 statement [v17]
In-Reply-To: <qY8nBOyXnGHReiuCWepur01xdCfhAV5WIuIflQlhJro=.18c5c6da-2ef0-4993-8481-5c36e4f524a6@github.com>
References: <o5R-OgIICxCPtCF3kVtJ7jEo7HVcWTYsnMx2SI42DGw=.238cf2ed-735f-4781-947e-2e347e5ae4ab@github.com>
 <qY8nBOyXnGHReiuCWepur01xdCfhAV5WIuIflQlhJro=.18c5c6da-2ef0-4993-8481-5c36e4f524a6@github.com>
Message-ID: <JHHgx5FM4jUDE80HDtneaeO3Ko-dMAfaoxbsTJHD_AE=.d46419af-ef95-4e56-baab-5bef1818e1f4@github.com>

On Mon, 19 Aug 2024 14:37:38 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Modeling and lowering of switch statement.
>
> Mourad Abbay has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove outdated comment
>  - Correct the arguments passed in a switch expression test
>  - Always have the case default as last bodies

Touch to trigger skara.

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

PR Comment: https://git.openjdk.org/babylon/pull/211#issuecomment-2334165332

From mabbay at openjdk.org  Fri Sep  6 14:54:23 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Fri, 6 Sep 2024 14:54:23 GMT
Subject: [code-reflection] RFR: Change the model of the default label of
 switch [v2]
In-Reply-To: <Mdz3QhX275vrN7ah2T5-wJTeE0Np_6gnEppLriPmpQY=.13c5a00f-07b2-4c8a-8105-f491489d2d2c@github.com>
References: <nk2B-u0jdwUovVQrLz8LtQvmuBsu3G0g12l3q6KDFtE=.e66679e3-1248-48db-b18f-9ec64c5996d8@github.com>
 <uQ3kulToTfaqxgcyd1uT0mxfW3s2tYL0AbpNSahrVEs=.8c111b15-81bd-48d2-a6e7-9dd93febbf1c@github.com>
 <Mdz3QhX275vrN7ah2T5-wJTeE0Np_6gnEppLriPmpQY=.13c5a00f-07b2-4c8a-8105-f491489d2d2c@github.com>
Message-ID: <VBkAx_9p_P7-UvMaYXy8XvvzQJz4_BRVVZb27KMH_j8=.e67c3fb8-a686-42b5-b363-f928b0529df8@github.com>

On Fri, 6 Sep 2024 08:45:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix NullTest
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1671:
> 
>> 1669: 
>> 1670:             Body.Builder body = null;
>> 1671:             Type yieldType = tree.type != null ? adaptBottom(tree.type) : null;
> 
> Why the change here?

`typeElementToType(javaType.STRING)` returns `none`

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

PR Review Comment: https://git.openjdk.org/babylon/pull/223#discussion_r1747251090

From mabbay at openjdk.org  Fri Sep  6 15:09:13 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Fri, 6 Sep 2024 15:09:13 GMT
Subject: [code-reflection] RFR: Change the model of the default label of
 switch [v2]
In-Reply-To: <VBkAx_9p_P7-UvMaYXy8XvvzQJz4_BRVVZb27KMH_j8=.e67c3fb8-a686-42b5-b363-f928b0529df8@github.com>
References: <nk2B-u0jdwUovVQrLz8LtQvmuBsu3G0g12l3q6KDFtE=.e66679e3-1248-48db-b18f-9ec64c5996d8@github.com>
 <uQ3kulToTfaqxgcyd1uT0mxfW3s2tYL0AbpNSahrVEs=.8c111b15-81bd-48d2-a6e7-9dd93febbf1c@github.com>
 <Mdz3QhX275vrN7ah2T5-wJTeE0Np_6gnEppLriPmpQY=.13c5a00f-07b2-4c8a-8105-f491489d2d2c@github.com>
 <VBkAx_9p_P7-UvMaYXy8XvvzQJz4_BRVVZb27KMH_j8=.e67c3fb8-a686-42b5-b363-f928b0529df8@github.com>
Message-ID: <03sOswrNqSNP9kI74nqSKTD2OFH9jPskXUKLiWlBe8w=.9491002a-bdad-4e89-878c-ab26b3b8f408@github.com>

On Fri, 6 Sep 2024 14:51:26 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1671:
>> 
>>> 1669: 
>>> 1670:             Body.Builder body = null;
>>> 1671:             Type yieldType = tree.type != null ? adaptBottom(tree.type) : null;
>> 
>> Why the change here?
>
> `typeElementToType(javaType.STRING)` returns `none`

I need to update `primitiveAndBoxTypeMap`

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

PR Review Comment: https://git.openjdk.org/babylon/pull/223#discussion_r1747275034

From mcimadamore at openjdk.org  Fri Sep  6 16:39:28 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 16:39:28 GMT
Subject: [code-reflection] RFR: Change the model of the default label of
 switch [v2]
In-Reply-To: <03sOswrNqSNP9kI74nqSKTD2OFH9jPskXUKLiWlBe8w=.9491002a-bdad-4e89-878c-ab26b3b8f408@github.com>
References: <nk2B-u0jdwUovVQrLz8LtQvmuBsu3G0g12l3q6KDFtE=.e66679e3-1248-48db-b18f-9ec64c5996d8@github.com>
 <uQ3kulToTfaqxgcyd1uT0mxfW3s2tYL0AbpNSahrVEs=.8c111b15-81bd-48d2-a6e7-9dd93febbf1c@github.com>
 <Mdz3QhX275vrN7ah2T5-wJTeE0Np_6gnEppLriPmpQY=.13c5a00f-07b2-4c8a-8105-f491489d2d2c@github.com>
 <VBkAx_9p_P7-UvMaYXy8XvvzQJz4_BRVVZb27KMH_j8=.e67c3fb8-a686-42b5-b363-f928b0529df8@github.com>
 <03sOswrNqSNP9kI74nqSKTD2OFH9jPskXUKLiWlBe8w=.9491002a-bdad-4e89-878c-ab26b3b8f408@github.com>
Message-ID: <GKw6ZIQhXY3u94GogcHWGPuT1JwCC6ausM-igVV17uc=.d832bd75-b801-4072-b6e4-978c97233316@github.com>

On Fri, 6 Sep 2024 15:06:32 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> `typeElementToType(javaType.STRING)` returns `none`
>
> I need to update `primitiveAndBoxTypeMap`

Uhm - I see. `typeElementToType` only works for simple types - but in this case I believe the case body can return any type - e.g. with patterns you can switch on any reference type.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/223#discussion_r1747417270

From mabbay at openjdk.org  Fri Sep  6 17:06:27 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Fri, 6 Sep 2024 17:06:27 GMT
Subject: [code-reflection] RFR: Change the model of the default label of
 switch [v2]
In-Reply-To: <GKw6ZIQhXY3u94GogcHWGPuT1JwCC6ausM-igVV17uc=.d832bd75-b801-4072-b6e4-978c97233316@github.com>
References: <nk2B-u0jdwUovVQrLz8LtQvmuBsu3G0g12l3q6KDFtE=.e66679e3-1248-48db-b18f-9ec64c5996d8@github.com>
 <uQ3kulToTfaqxgcyd1uT0mxfW3s2tYL0AbpNSahrVEs=.8c111b15-81bd-48d2-a6e7-9dd93febbf1c@github.com>
 <Mdz3QhX275vrN7ah2T5-wJTeE0Np_6gnEppLriPmpQY=.13c5a00f-07b2-4c8a-8105-f491489d2d2c@github.com>
 <VBkAx_9p_P7-UvMaYXy8XvvzQJz4_BRVVZb27KMH_j8=.e67c3fb8-a686-42b5-b363-f928b0529df8@github.com>
 <03sOswrNqSNP9kI74nqSKTD2OFH9jPskXUKLiWlBe8w=.9491002a-bdad-4e89-878c-ab26b3b8f408@github.com>
 <GKw6ZIQhXY3u94GogcHWGPuT1JwCC6ausM-igVV17uc=.d832bd75-b801-4072-b6e4-978c97233316@github.com>
Message-ID: <gXEbik9jKXJknOU_MEkGbVVdv_PZ7Nf3TxFOCqhwgQ0=.fe5002a4-2f51-45a5-8aa5-ab651f1687a5@github.com>

On Fri, 6 Sep 2024 16:37:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I need to update `primitiveAndBoxTypeMap`
>
> Uhm - I see. `typeElementToType` only works for simple types - but in this case I believe the case body can return any type - e.g. with patterns you can switch on any reference type.

yes, switch expression can yield a result of any type.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/223#discussion_r1747453643

From psandoz at openjdk.org  Fri Sep  6 17:13:15 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 17:13:15 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <LY9_xxF5dN6HgV_8d0xqmqPs8WkgRB4VOfroWW1YIFs=.617eca3a-7991-48d3-9636-5076b51bcd49@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
 <LY9_xxF5dN6HgV_8d0xqmqPs8WkgRB4VOfroWW1YIFs=.617eca3a-7991-48d3-9636-5076b51bcd49@github.com>
Message-ID: <rHsfvuKVXuw8nGjhWUNMzz2NVrX00B9hsRRvopamAn0=.ee94efca-c5cd-4082-b025-f901b2b3b139@github.com>

On Fri, 6 Sep 2024 07:52:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove comment.
>
> src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 3721:
> 
>> 3719:      * @return the invoke operation
>> 3720:      */
>> 3721:     public static InvokeOp.InvokeSuperOp invokeSuper(TypeElement returnType, MethodRef invokeDescriptor, List<Value> args) {
> 
> The split here hits hard - as you need M * K overloads (in the general case) where M is the number of overloads per kind, and K is the number of kinds we end up supporting.

Indeed. Varargs support will also increase the complexity and might motivate a change in the splitting/lumping.

For the majority of the cases so far it just so happens we don't need the kind of invocation and it all works out and one does not need to think too much about it, similar to how `Class::getMethod/getDeclaredMethod` works out. I think it is because of the language rules regarding methods declarations, and all declared methods in a class file are required to have unique name + descriptor regardless of their access flags and attributes ([jvms-4.6](https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-4.html#jvms-4.6))

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1747461051

From psandoz at openjdk.org  Fri Sep  6 17:34:25 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 17:34:25 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <9P7rK8oG0rEonA4veEj4v7DgsZAKUUwx__f1yEsb1i0=.62ee09f4-06c3-4c0c-82d4-86d50944b497@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
 <dhBo3Il9MY0F7vDqXFS_VY8lgH7Kume0v-Ssai9W4Q0=.eb60b118-4e39-4b13-85c4-0c37ef5036fc@github.com>
 <9P7rK8oG0rEonA4veEj4v7DgsZAKUUwx__f1yEsb1i0=.62ee09f4-06c3-4c0c-82d4-86d50944b497@github.com>
Message-ID: <yb6ijeYyv3C8Z6z580KJqBwuu4Rt3ROFWMfnYITyFTs=.3808162f-d7cc-4e8b-9a24-a87a6b76111b@github.com>

On Fri, 6 Sep 2024 07:56:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/type/TypeVarRef.java line 54:
>> 
>>> 52:         TypeVariable<?>[] typeVariables = switch (owner) {
>>> 53:             case MethodRef methodRef -> {
>>> 54:                 // @@@ resolves to class or instance method
>> 
>> ouch :-)
>> The thing here is: to go to a `j.l.r.Method` you don't really need to know the kind, do you? E.g. a method handle is kind-sensitive, but a reflective method is not?
>
> Problem is we're doing the method lookup using the method handle lookup and then cracking open the method handle - perhaps reflective methods should be looked-up in a separate way.

Perhaps it's an implementation detail and does not matter? I was unsure.

Can we presume in this case that a `MethodRef` directly refers to the method? i.e., the method is declared on the referencing class.
    
Resolving a `MethodRef` to a `MethodHandle` naturally retains the referencing type since that is where the invocation occurs. When we reveal the method handle information (crack open) and reflect as a method we potentially loose the referencing type. In this case should we expect the following to hold?


MethodHandle mh = ...;
MethodHandleInfo mhi = MethodHandles.lookup().revealDirect(mh);
Method m = mhireflectAs(Method.class, MethodHandles.lookup()));
assert mhi.getDeclaringClass() == m.getDeclaringClass();
 ```

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1747486908

From psandoz at openjdk.org  Fri Sep  6 17:51:27 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 17:51:27 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <E0W0K2ZG9Tm6Ylu9qH8J9ke9R1UlxANJp6siGBLovF8=.16135bcf-3869-4f24-b8b8-7690679845c4@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
 <SAjI7kpXVOyrVOObSDIdTc9dM5C3oKm_nyOgAVMRVaM=.b619a855-935b-4547-bd29-0a822f410830@github.com>
 <igqC_dzZv7RW3LRvlPDZcP89bS3sL8M2VkWtESMYSZ0=.79155b2e-ba7c-47df-8762-dbdb978a0b72@github.com>
 <E0W0K2ZG9Tm6Ylu9qH8J9ke9R1UlxANJp6siGBLovF8=.16135bcf-3869-4f24-b8b8-7690679845c4@github.com>
Message-ID: <jpE0B9hF8l9uDHmB7ImfdGJZ6Vw-bUcW5hDq9IzOZZY=.dbe836be-08ef-4071-a47e-4a0e85378442@github.com>

On Fri, 6 Sep 2024 08:06:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I wonder if a modelling where `super` is its own expression would be beneficial. E.g. like some kind of "virtual field" on `this`. E.g. one would load `this` and then access `super` onto it (and maybe there's a core op for _that_). Then the result is used for either a method receiver, or field access expression.
>
> Although I suppose in my example, we still generate a `getfield` for `super.o`, just with a different symbolic description - so the generated model ends up being fine. I suppose I'm not 100% comfortable with the fact that the model here seems to capture a bytecode distinction (e.g. super calls use a special invocation mode, but super field access do not, so we only model the former), rather than a syntactic difference in the original source (e.g. for both method and field access, the `super` keyword is there).

Right, well spotted. AFAICT the expression `super.o` is the same as `((A) this).o`, there is nothing "special" about it i suppose. The same operations/bytecode are generated for either expression. So it does not seem necessary to make the syntactic distinction as this level of modeling.

If someone wanted to lift back up to syntactically equivalent source it might be tricky bit not impossible, although we loose the distinction between the two expressions. Fernflower lifts the bytecode of both expressions to `super.o` :-)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1747505721

From psandoz at openjdk.org  Fri Sep  6 17:51:27 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 17:51:27 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <Q8jGmV3GoETbReLfoPhiqMdAcCEsexguhzq-45gu5v0=.d5a7f57e-9723-4e09-8d82-d3e006ad1115@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
 <t35NxYDps4o_ZYBXxEdBRCj-ZSzhHwtu8B_1u20Mj0Q=.cfcce8ae-32b2-4b1d-b9ea-87330c044317@github.com>
 <Q8jGmV3GoETbReLfoPhiqMdAcCEsexguhzq-45gu5v0=.d5a7f57e-9723-4e09-8d82-d3e006ad1115@github.com>
Message-ID: <WFLCa8vScHjenMpqXD5PmzKimkeawPz214cxeROti9k=.255054ef-9617-4861-9c97-2e8129d2e14c@github.com>

On Fri, 6 Sep 2024 08:10:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1095:
>> 
>>> 1093:                     if (!sym.isStatic()) {
>>> 1094:                         args.add(receiver);
>>> 1095:                         isSuper = switch (access.selected) {
>> 
>> Note for later - `expr.super(...)` for inner class super constructor calls. Perhaps add a `@@@` comment now?
>
> But... bonus points for having handled `Foo.super.xyz` and `Foo.this.xyz` :-)

Memo to self - we don't currently support reflecting over the body of a constructor.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1747508311

From psandoz at openjdk.org  Fri Sep  6 19:31:46 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 19:31:46 GMT
Subject: [code-reflection] RFR: Super expressions [v3]
In-Reply-To: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
Message-ID: <txi0ouBdGsNYsHbNtD1afIt7CvAXNnTf6KnpK4fMqyQ=.439d0ae6-2bd5-4153-ae3c-6ff0c3fea7da@github.com>

> Support super expressions.
> 
> The work in the bytecode generator is not complete, and a disabled test has been added. Currently when it encounters an invoke super operation it will throw. We cannot generate invokespecial instructions as this will create invalid bytecode (the calling class is not related to the referenced class). Instead, in a subsequent PR, we need to dynamically generate method handles, pass them as class data to the defined hidden class, so they can be loaded as constants and invoked (and therefore emulating the invokespecial instruction). That subsequent PR should also address the lifting of invokespecial instructions.
> 
> This work has shown deficiencies in the modeling of invocation expressions and the resolution of `MethodRef`s. The latter has been partially addressed by providing additional information for resolution, namely the kind of invocation.
> 
> Invocation operations do not fully model invocation to vararg methods and this means we cannot reliably determine in all cases if the invocation has a receiver operand or not (a class or instance invocation). This should be fixed in a subsequent PR. The fix might require the following:
> - explicit modeling of class and instance and invocation; and
> - modeling var args as a prefix (sublist) of the operand list

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

  Add comment

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/221/files
  - new: https://git.openjdk.org/babylon/pull/221/files/e1e1e0ed..59b8f4a4

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

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

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

From psandoz at openjdk.org  Fri Sep  6 19:38:23 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 19:38:23 GMT
Subject: [code-reflection] RFR: Change the model of the default label of
 switch [v2]
In-Reply-To: <uQ3kulToTfaqxgcyd1uT0mxfW3s2tYL0AbpNSahrVEs=.8c111b15-81bd-48d2-a6e7-9dd93febbf1c@github.com>
References: <nk2B-u0jdwUovVQrLz8LtQvmuBsu3G0g12l3q6KDFtE=.e66679e3-1248-48db-b18f-9ec64c5996d8@github.com>
 <uQ3kulToTfaqxgcyd1uT0mxfW3s2tYL0AbpNSahrVEs=.8c111b15-81bd-48d2-a6e7-9dd93febbf1c@github.com>
Message-ID: <qYJXmrQYd8BUAymWVnY34wAMyi4x_eJHIQLmZPjxXXQ=.c8fb8371-ca61-4b0d-9d32-0d0dd2672187@github.com>

On Fri, 6 Sep 2024 08:35:32 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Model the default label of switch as a body that yield true, this makes the modeling consistent for all labels.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix NullTest

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/223#pullrequestreview-2287034530

From psandoz at openjdk.org  Fri Sep  6 20:05:33 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 20:05:33 GMT
Subject: git: openjdk/babylon: code-reflection: Super expressions
Message-ID: <372335ae-c134-4069-9de6-48614459948d@openjdk.org>

Changeset: 4603f6d5
Branch: code-reflection
Author:    Paul Sandoz <psandoz at openjdk.org>
Date:      2024-09-06 20:02:59 +0000
URL:       https://git.openjdk.org/babylon/commit/4603f6d574edea0999f55bf8d501ff16583721e1

Super expressions

Reviewed-by: mcimadamore

! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java
! src/java.base/share/classes/java/lang/reflect/code/interpreter/Interpreter.java
! src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java
! src/java.base/share/classes/java/lang/reflect/code/parser/impl/Tokens.java
! src/java.base/share/classes/java/lang/reflect/code/type/MethodRef.java
! src/java.base/share/classes/java/lang/reflect/code/type/TypeVarRef.java
! src/java.base/share/classes/java/lang/reflect/code/type/impl/MethodRefImpl.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java
+ test/jdk/java/lang/reflect/code/TestInvokeSuper.java
! test/jdk/java/lang/reflect/code/TestTransitiveInvokeModule.java
+ test/jdk/java/lang/reflect/code/bytecode/TestInvokeSuper.java
! test/jdk/java/lang/reflect/code/type/TestReferences.java
! test/langtools/tools/javac/reflect/FieldAccessTest.java
! test/langtools/tools/javac/reflect/MethodCallTest.java
+ test/langtools/tools/javac/reflect/SuperTest.java
! test/langtools/tools/javac/reflect/TestIRFromAnnotation.java


From psandoz at openjdk.org  Fri Sep  6 20:06:23 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 20:06:23 GMT
Subject: [code-reflection] Integrated: Super expressions
In-Reply-To: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
Message-ID: <euRJn_wrdgVld_O4zJWb3rKwwui9TWHbxuReHFvPglI=.cfaa332d-10a5-4df3-97ec-14b8acfe62ec@github.com>

On Thu, 5 Sep 2024 20:24:51 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Support super expressions.
> 
> The work in the bytecode generator is not complete, and a disabled test has been added. Currently when it encounters an invoke super operation it will throw. We cannot generate invokespecial instructions as this will create invalid bytecode (the calling class is not related to the referenced class). Instead, in a subsequent PR, we need to dynamically generate method handles, pass them as class data to the defined hidden class, so they can be loaded as constants and invoked (and therefore emulating the invokespecial instruction). That subsequent PR should also address the lifting of invokespecial instructions.
> 
> This work has shown deficiencies in the modeling of invocation expressions and the resolution of `MethodRef`s. The latter has been partially addressed by providing additional information for resolution, namely the kind of invocation.
> 
> Invocation operations do not fully model invocation to vararg methods and this means we cannot reliably determine in all cases if the invocation has a receiver operand or not (a class or instance invocation). This should be fixed in a subsequent PR. The fix might require the following:
> - explicit modeling of class and instance and invocation; and
> - modeling var args as a prefix (sublist) of the operand list

This pull request has now been integrated.

Changeset: 4603f6d5
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/4603f6d574edea0999f55bf8d501ff16583721e1
Stats:     641 lines in 16 files changed: 495 ins; 97 del; 49 mod

Super expressions

Reviewed-by: mcimadamore

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

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

From psandoz at openjdk.org  Fri Sep  6 20:22:31 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 20:22:31 GMT
Subject: [code-reflection] RFR: Change the model of the default label of
 switch [v2]
In-Reply-To: <gXEbik9jKXJknOU_MEkGbVVdv_PZ7Nf3TxFOCqhwgQ0=.fe5002a4-2f51-45a5-8aa5-ab651f1687a5@github.com>
References: <nk2B-u0jdwUovVQrLz8LtQvmuBsu3G0g12l3q6KDFtE=.e66679e3-1248-48db-b18f-9ec64c5996d8@github.com>
 <uQ3kulToTfaqxgcyd1uT0mxfW3s2tYL0AbpNSahrVEs=.8c111b15-81bd-48d2-a6e7-9dd93febbf1c@github.com>
 <Mdz3QhX275vrN7ah2T5-wJTeE0Np_6gnEppLriPmpQY=.13c5a00f-07b2-4c8a-8105-f491489d2d2c@github.com>
 <VBkAx_9p_P7-UvMaYXy8XvvzQJz4_BRVVZb27KMH_j8=.e67c3fb8-a686-42b5-b363-f928b0529df8@github.com>
 <03sOswrNqSNP9kI74nqSKTD2OFH9jPskXUKLiWlBe8w=.9491002a-bdad-4e89-878c-ab26b3b8f408@github.com>
 <GKw6ZIQhXY3u94GogcHWGPuT1JwCC6ausM-igVV17uc=.d832bd75-b801-4072-b6e4-978c97233316@github.com>
 <gXEbik9jKXJknOU_MEkGbVVdv_PZ7Nf3TxFOCqhwgQ0=.fe5002a4-2f51-45a5-8aa5-ab651f1687a5@github.com>
Message-ID: <YejkAjodPKZEoGEp_fUIF2vi2tWTIYxqLZODVpXyZWU=.c8126e5d-6b22-4ea3-8621-d3fe78a73998@github.com>

On Fri, 6 Sep 2024 17:03:41 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Uhm - I see. `typeElementToType` only works for simple types - but in this case I believe the case body can return any type - e.g. with patterns you can switch on any reference type.
>
> yes, switch expression can yield a result of any type.

I think the last PR unifying code on `ReflectMethods` introduce a regression causing failures in `NullTest`. This should should fix it.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/223#discussion_r1747671524

From mcimadamore at openjdk.org  Fri Sep  6 21:02:18 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 21:02:18 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <yb6ijeYyv3C8Z6z580KJqBwuu4Rt3ROFWMfnYITyFTs=.3808162f-d7cc-4e8b-9a24-a87a6b76111b@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
 <dhBo3Il9MY0F7vDqXFS_VY8lgH7Kume0v-Ssai9W4Q0=.eb60b118-4e39-4b13-85c4-0c37ef5036fc@github.com>
 <9P7rK8oG0rEonA4veEj4v7DgsZAKUUwx__f1yEsb1i0=.62ee09f4-06c3-4c0c-82d4-86d50944b497@github.com>
 <yb6ijeYyv3C8Z6z580KJqBwuu4Rt3ROFWMfnYITyFTs=.3808162f-d7cc-4e8b-9a24-a87a6b76111b@github.com>
Message-ID: <J7lFMBaYNPQ4-eV-pNqYiIFQPgjXLeybz_3uQFwtrRg=.b615fd77-7b2e-4971-b688-dcd0bf1fa613@github.com>

On Fri, 6 Sep 2024 17:31:48 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Perhaps it's an implementation detail and does not matter? I was unsure.

Sorry, perhaps I was getting too ahead of myself. But it seems to me that `resolveToMember(lookup)` will pass the `InvokeClass` kind by default. This will cause (if I'm correct) a `findStatic` lookup, which might fail if the type-variable has a non-static method owner?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1747710762

From mcimadamore at openjdk.org  Fri Sep  6 21:09:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Sep 2024 21:09:15 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <J7lFMBaYNPQ4-eV-pNqYiIFQPgjXLeybz_3uQFwtrRg=.b615fd77-7b2e-4971-b688-dcd0bf1fa613@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
 <dhBo3Il9MY0F7vDqXFS_VY8lgH7Kume0v-Ssai9W4Q0=.eb60b118-4e39-4b13-85c4-0c37ef5036fc@github.com>
 <9P7rK8oG0rEonA4veEj4v7DgsZAKUUwx__f1yEsb1i0=.62ee09f4-06c3-4c0c-82d4-86d50944b497@github.com>
 <yb6ijeYyv3C8Z6z580KJqBwuu4Rt3ROFWMfnYITyFTs=.3808162f-d7cc-4e8b-9a24-a87a6b76111b@github.com>
 <J7lFMBaYNPQ4-eV-pNqYiIFQPgjXLeybz_3uQFwtrRg=.b615fd77-7b2e-4971-b688-dcd0bf1fa613@github.com>
Message-ID: <pbmVTOnFhDD14IuPujnIZyEGvqh3qz8czPWKWtTOBPs=.50275d9f-f5ed-47c9-a334-11421fde1c47@github.com>

On Fri, 6 Sep 2024 20:59:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Perhaps it's an implementation detail and does not matter? I was unsure.
>> 
>> Can we presume in this case that a `MethodRef` directly refers to the method? i.e., the method is declared on the referencing class.
>>     
>> Resolving a `MethodRef` to a `MethodHandle` naturally retains the referencing type since that is where the invocation occurs. When we reveal the method handle information (crack open) and reflect as a method we potentially loose the referencing type. In this case should we expect the following to hold?
>> 
>> 
>> MethodHandle mh = ...;
>> MethodHandleInfo mhi = MethodHandles.lookup().revealDirect(mh);
>> Method m = mhireflectAs(Method.class, MethodHandles.lookup()));
>> assert mhi.getDeclaringClass() == m.getDeclaringClass();
>>  ```
>
>> Perhaps it's an implementation detail and does not matter? I was unsure.
> 
> Sorry, perhaps I was getting too ahead of myself. But it seems to me that `resolveToMember(lookup)` will pass the `InvokeClass` kind by default. This will cause (if I'm correct) a `findStatic` lookup, which might fail if the type-variable has a non-static method owner?

Ah! I missed that the code is trying `static` first and then follows up with a `virtual` lookup if that one fails. I wonder if that could lead to a situation where we resolve to the wrong method e.g. if we have something like this:


class A {
    static void m() { }
}

class B extends A {
    <X> void m() { }
}


But this seems disallowed by the overriding/hiding rules. (it's probably possible to have classfiles like that though - e.g. when generated via classfile API).

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1747716582

From psandoz at openjdk.org  Fri Sep  6 21:53:35 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Sep 2024 21:53:35 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <pbmVTOnFhDD14IuPujnIZyEGvqh3qz8czPWKWtTOBPs=.50275d9f-f5ed-47c9-a334-11421fde1c47@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
 <dhBo3Il9MY0F7vDqXFS_VY8lgH7Kume0v-Ssai9W4Q0=.eb60b118-4e39-4b13-85c4-0c37ef5036fc@github.com>
 <9P7rK8oG0rEonA4veEj4v7DgsZAKUUwx__f1yEsb1i0=.62ee09f4-06c3-4c0c-82d4-86d50944b497@github.com>
 <yb6ijeYyv3C8Z6z580KJqBwuu4Rt3ROFWMfnYITyFTs=.3808162f-d7cc-4e8b-9a24-a87a6b76111b@github.com>
 <J7lFMBaYNPQ4-eV-pNqYiIFQPgjXLeybz_3uQFwtrRg=.b615fd77-7b2e-4971-b688-dcd0bf1fa613@github.com>
 <pbmVTOnFhDD14IuPujnIZyEGvqh3qz8czPWKWtTOBPs=.50275d9f-f5ed-47c9-a334-11421fde1c47@github.com>
Message-ID: <LbSArDXuxfa9qYERG7Xv23P-Xr_nLyK87b6RY3btI04=.b0c3130f-6c80-4e97-9c48-9c7c4ec89767@github.com>

On Fri, 6 Sep 2024 21:06:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Perhaps it's an implementation detail and does not matter? I was unsure.
>> 
>> Sorry, perhaps I was getting too ahead of myself. But it seems to me that `resolveToMember(lookup)` will pass the `InvokeClass` kind by default. This will cause (if I'm correct) a `findStatic` lookup, which might fail if the type-variable has a non-static method owner?
>
> Ah! I missed that the code is trying `static` first and then follows up with a `virtual` lookup if that one fails. I wonder if that could lead to a situation where we resolve to the wrong method e.g. if we have something like this:
> 
> 
> class A {
>     static void m() { }
> }
> 
> class B extends A {
>     <X> void m() { }
> }
> 
> 
> But this seems disallowed by the overriding/hiding rules. (it's probably possible to have classfiles like that though - e.g. when generated via classfile API).

In general this behavior is probably too sneaky :-) I think we would need to resolve using class and instance kinds and if both resolve successfully pick the most specific.

For this `TypeVarRef` case i believe the method reference should refer to a declared method on the referencing class, it's the owner. If so we can constrain the resolution. (I realize my prior code example wrong, it should compare the resolved class of the method ref's referencing class.)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1747753312

From mabbay at openjdk.org  Sat Sep  7 02:36:25 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Sat, 7 Sep 2024 02:36:25 GMT
Subject: git: openjdk/babylon: code-reflection: Change the model of the default
 label of switch
Message-ID: <cbe2d575-92c1-4a79-beda-5f741d55269e@openjdk.org>

Changeset: b836dba3
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2024-09-07 02:34:54 +0000
URL:       https://git.openjdk.org/babylon/commit/b836dba369084c7458d8f4fcb37e07982b15c666

Change the model of the default label of switch

Reviewed-by: psandoz

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java
! test/langtools/tools/javac/reflect/BoxingConversionTest.java
! test/langtools/tools/javac/reflect/ImplicitConversionTest.java
! test/langtools/tools/javac/reflect/NullTest.java
! test/langtools/tools/javac/reflect/SwitchExpressionTest.java
! test/langtools/tools/javac/reflect/SwitchExpressionTest2.java
! test/langtools/tools/javac/reflect/SwitchStatementTest.java


From mabbay at openjdk.org  Sat Sep  7 02:40:17 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Sat, 7 Sep 2024 02:40:17 GMT
Subject: [code-reflection] Integrated: Change the model of the default label of
 switch
In-Reply-To: <nk2B-u0jdwUovVQrLz8LtQvmuBsu3G0g12l3q6KDFtE=.e66679e3-1248-48db-b18f-9ec64c5996d8@github.com>
References: <nk2B-u0jdwUovVQrLz8LtQvmuBsu3G0g12l3q6KDFtE=.e66679e3-1248-48db-b18f-9ec64c5996d8@github.com>
Message-ID: <m5myQdS1yqfvQJZVJIzXsT2InhVEBTn5bzb4UJ5B-Qg=.afada374-6259-4a83-b0ff-fb39dee079ce@github.com>

On Fri, 6 Sep 2024 07:58:44 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Model the default label of switch as a body that yield true, this makes the modeling consistent for all labels.

This pull request has now been integrated.

Changeset: b836dba3
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/b836dba369084c7458d8f4fcb37e07982b15c666
Stats:     196 lines in 7 files changed: 63 ins; 0 del; 133 mod

Change the model of the default label of switch

Reviewed-by: psandoz

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

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

From mabbay at openjdk.org  Sat Sep  7 02:41:57 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Sat, 7 Sep 2024 02:41:57 GMT
Subject: [code-reflection] RFR: Unify common code of SwitchStatementOp and
 SwitchExpressionOp [v2]
In-Reply-To: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
References: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
Message-ID: <qadOAZfHK6_CgEPNEEM6h3KklRLZifplG-X2ILE5Kew=.5c600485-2245-47b0-a2eb-67b71cb7d390@github.com>

> Unify common code of SwitchStatementOp and SwitchExpressionOp.

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

 - Merge branch 'code-reflection' into unify-sw-op
 - Refactor

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/222/files
  - new: https://git.openjdk.org/babylon/pull/222/files/16816326..6d49a8dc

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

  Stats: 837 lines in 22 files changed: 558 ins; 97 del; 182 mod
  Patch: https://git.openjdk.org/babylon/pull/222.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/222/head:pull/222

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

From mcimadamore at openjdk.org  Mon Sep  9 09:43:24 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 09:43:24 GMT
Subject: [code-reflection] RFR: Super expressions [v2]
In-Reply-To: <LbSArDXuxfa9qYERG7Xv23P-Xr_nLyK87b6RY3btI04=.b0c3130f-6c80-4e97-9c48-9c7c4ec89767@github.com>
References: <K_YeNM_UbOdThjoJCj7i6haDYP7woogZpl-Y-oT-m-k=.8a6b2a30-f1a8-4a4a-9628-18a0d977fd2d@github.com>
 <oJGjNPPgfY2qn_qMH4i3VjKEZWjPsd7_unqFXpGDBAM=.b1d5557e-bc80-4112-9bc9-9c78c8b5a1b7@github.com>
 <dhBo3Il9MY0F7vDqXFS_VY8lgH7Kume0v-Ssai9W4Q0=.eb60b118-4e39-4b13-85c4-0c37ef5036fc@github.com>
 <9P7rK8oG0rEonA4veEj4v7DgsZAKUUwx__f1yEsb1i0=.62ee09f4-06c3-4c0c-82d4-86d50944b497@github.com>
 <yb6ijeYyv3C8Z6z580KJqBwuu4Rt3ROFWMfnYITyFTs=.3808162f-d7cc-4e8b-9a24-a87a6b76111b@github.com>
 <J7lFMBaYNPQ4-eV-pNqYiIFQPgjXLeybz_3uQFwtrRg=.b615fd77-7b2e-4971-b688-dcd0bf1fa613@github.com>
 <pbmVTOnFhDD14IuPujnIZyEGvqh3qz8czPWKWtTOBPs=.50275d9f-f5ed-47c9-a334-11421fde1c47@github.com>
 <LbSArDXuxfa9qYERG7Xv23P-Xr_nLyK87b6RY3btI04=.b0c3130f-6c80-4e97-9c48-9c7c4ec89767@github.com>
Message-ID: <IDUN4ld09c1l3e4pgS03Pqv0f9v9M_NLVMFu-VC9ew0=.f7bf67f4-a571-40fc-9b2a-443370baaeb8@github.com>

On Fri, 6 Sep 2024 21:50:30 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> For this `TypeVarRef` case i believe the method reference should refer to a declared method on the referencing class, it's the owner.

Yes, the `TypeVarRef` case only cares about the declaration - e.g. the TypeElement IR will put the correct owner class, method name and erased sig in there, so it should be possible to do a reflective lookup w/o going through method handles. That's mostly what I was trying to say. I'm not sure if there are visible differences with what you have now - as the examples I came up with seem to fall in the "esoteric" category :-)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1749936562

From psandoz at openjdk.org  Mon Sep  9 16:30:25 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 9 Sep 2024 16:30:25 GMT
Subject: [code-reflection] RFR: Unify common code of SwitchStatementOp and
 SwitchExpressionOp [v2]
In-Reply-To: <qadOAZfHK6_CgEPNEEM6h3KklRLZifplG-X2ILE5Kew=.5c600485-2245-47b0-a2eb-67b71cb7d390@github.com>
References: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
 <qadOAZfHK6_CgEPNEEM6h3KklRLZifplG-X2ILE5Kew=.5c600485-2245-47b0-a2eb-67b71cb7d390@github.com>
Message-ID: <dM4c_XWQF_vpeVFYgLNXOtn0Wx1K7Y6mA0c9P_mnbnY=.a0dbafe1-a125-4b22-aa5f-2c848d1e0a93@github.com>

On Sat, 7 Sep 2024 02:41:57 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Unify common code of SwitchStatementOp and SwitchExpressionOp.
>
> Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'code-reflection' into unify-sw-op
>  - Refactor

src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 898:

> 896:     }
> 897: 
> 898:     abstract static sealed class JavaSwitch extends ExtendedOp implements Op.Nested, Op.Lowerable

Rename to `JavaSwitchOp` and make it public.

src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 973:

> 971:             } else {
> 972:                 exit = b.block(resultType());
> 973:                 if (result() != null) { // i.e. resultType not void

All operations in a built model have a result value, even if it's a void value. So this expression will always be true. Use a `this instanceof ...` test?

src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 1009:

> 1007:                         switch (op) {
> 1008:                             case YieldOp yop when yop.operands().isEmpty() -> block.op(branch(exit.successor()));
> 1009:                             case YieldOp yop -> block.op(branch(exit.successor(block.context().getValue(yop.yieldValue()))));

It might be clearer to test against the concrete switch class e.g., `case YieldOp yop when this instanceof ...`.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/222#discussion_r1750548469
PR Review Comment: https://git.openjdk.org/babylon/pull/222#discussion_r1750566611
PR Review Comment: https://git.openjdk.org/babylon/pull/222#discussion_r1750562530

From mabbay at openjdk.org  Tue Sep 10 00:53:18 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Sep 2024 00:53:18 GMT
Subject: [code-reflection] RFR: Unify common code of SwitchStatementOp and
 SwitchExpressionOp [v2]
In-Reply-To: <dM4c_XWQF_vpeVFYgLNXOtn0Wx1K7Y6mA0c9P_mnbnY=.a0dbafe1-a125-4b22-aa5f-2c848d1e0a93@github.com>
References: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
 <qadOAZfHK6_CgEPNEEM6h3KklRLZifplG-X2ILE5Kew=.5c600485-2245-47b0-a2eb-67b71cb7d390@github.com>
 <dM4c_XWQF_vpeVFYgLNXOtn0Wx1K7Y6mA0c9P_mnbnY=.a0dbafe1-a125-4b22-aa5f-2c848d1e0a93@github.com>
Message-ID: <-vQTwghYoI14eu6zaJRLkSa7LEwCxL8lwZiwZjptZQM=.9a749280-e095-4ee8-9626-260a4225a17b@github.com>

On Mon, 9 Sep 2024 16:27:05 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'code-reflection' into unify-sw-op
>>  - Refactor
>
> src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 973:
> 
>> 971:             } else {
>> 972:                 exit = b.block(resultType());
>> 973:                 if (result() != null) { // i.e. resultType not void
> 
> All operations in a built model have a result value, even if it's a void value. So this expression will always be true. Use a `this instanceof ...` test?

The default value of the `result` field is null

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

PR Review Comment: https://git.openjdk.org/babylon/pull/222#discussion_r1751100828

From psandoz at openjdk.org  Tue Sep 10 01:21:34 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Sep 2024 01:21:34 GMT
Subject: [code-reflection] RFR: Invocation to vararg methods
Message-ID: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>

Re-consolidate to one invocation operation that explicitly declares its invoke kind and whether it is an invocation to a varargs method.

Resolution of a method reference accepts an invoke kind. The ambiguity when resolving a method reference without an invoke kind has been cleared up, in these cases we can only resolve to a direct method, one in which the referencing class is the class that declares the method.

I managed to avoid numerous changes to update the text models in language tests. Creating an invoke operation from external form is permissive in the attributes that are present. It makes the same assumptions as the invoke factory method in determining the invocation kind from the argument count and invoke descriptor count, and assumes the method is not a varargs method (the common case).

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

Commit messages:
 - Undo edits.
 - Avoid generating attributes
 - Invocation to vararg methods.

Changes: https://git.openjdk.org/babylon/pull/225/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=225&range=00
  Stats: 636 lines in 15 files changed: 421 ins; 118 del; 97 mod
  Patch: https://git.openjdk.org/babylon/pull/225.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/225/head:pull/225

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

From mabbay at openjdk.org  Tue Sep 10 01:26:06 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Sep 2024 01:26:06 GMT
Subject: [code-reflection] RFR: Unify common code of SwitchStatementOp and
 SwitchExpressionOp [v3]
In-Reply-To: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
References: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
Message-ID: <T_SDebf6eJdsj3Mm0eSYcAE5JolPQt8tQICKkew8r8w=.64ed9e57-4662-4ec7-b2ac-1fd5d1b3ac7b@github.com>

> Unify common code of SwitchStatementOp and SwitchExpressionOp.

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

 - Apply suggestions
 - Apply suggestions
 - Apply suggestions

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/222/files
  - new: https://git.openjdk.org/babylon/pull/222/files/6d49a8dc..4a35d1eb

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

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

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

From mabbay at openjdk.org  Tue Sep 10 01:26:07 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Sep 2024 01:26:07 GMT
Subject: [code-reflection] RFR: Unify common code of SwitchStatementOp and
 SwitchExpressionOp [v2]
In-Reply-To: <dM4c_XWQF_vpeVFYgLNXOtn0Wx1K7Y6mA0c9P_mnbnY=.a0dbafe1-a125-4b22-aa5f-2c848d1e0a93@github.com>
References: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
 <qadOAZfHK6_CgEPNEEM6h3KklRLZifplG-X2ILE5Kew=.5c600485-2245-47b0-a2eb-67b71cb7d390@github.com>
 <dM4c_XWQF_vpeVFYgLNXOtn0Wx1K7Y6mA0c9P_mnbnY=.a0dbafe1-a125-4b22-aa5f-2c848d1e0a93@github.com>
Message-ID: <ed5kmZg0WUHwKsAiAqM9QXLgnzfGU2x359MiMvZBxDw=.8505a13c-f14f-4fe2-8339-1940a1d9b5e6@github.com>

On Mon, 9 Sep 2024 16:27:05 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'code-reflection' into unify-sw-op
>>  - Refactor
>
> src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 973:
> 
>> 971:             } else {
>> 972:                 exit = b.block(resultType());
>> 973:                 if (result() != null) { // i.e. resultType not void
> 
> All operations in a built model have a result value, even if it's a void value. So this expression will always be true. Use a `this instanceof ...` test?

I see. Or we can test if resultType isn't void

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

PR Review Comment: https://git.openjdk.org/babylon/pull/222#discussion_r1751118298

From psandoz at openjdk.org  Tue Sep 10 01:26:08 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Sep 2024 01:26:08 GMT
Subject: [code-reflection] RFR: Unify common code of SwitchStatementOp and
 SwitchExpressionOp [v2]
In-Reply-To: <ed5kmZg0WUHwKsAiAqM9QXLgnzfGU2x359MiMvZBxDw=.8505a13c-f14f-4fe2-8339-1940a1d9b5e6@github.com>
References: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
 <qadOAZfHK6_CgEPNEEM6h3KklRLZifplG-X2ILE5Kew=.5c600485-2245-47b0-a2eb-67b71cb7d390@github.com>
 <dM4c_XWQF_vpeVFYgLNXOtn0Wx1K7Y6mA0c9P_mnbnY=.a0dbafe1-a125-4b22-aa5f-2c848d1e0a93@github.com>
 <ed5kmZg0WUHwKsAiAqM9QXLgnzfGU2x359MiMvZBxDw=.8505a13c-f14f-4fe2-8339-1940a1d9b5e6@github.com>
Message-ID: <ycMSPYUXU6bL9NUiVlevtrvNOHKGkKswtspRDc7jiPc=.a03ff78f-5582-4b64-9ce9-34e08074dcc3@github.com>

On Tue, 10 Sep 2024 01:20:00 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 973:
>> 
>>> 971:             } else {
>>> 972:                 exit = b.block(resultType());
>>> 973:                 if (result() != null) { // i.e. resultType not void
>> 
>> All operations in a built model have a result value, even if it's a void value. So this expression will always be true. Use a `this instanceof ...` test?
>
> I see. Or we can test if resultType isn't void

It cannot be:

    /**
     * Returns the operation's result, otherwise {@code null} if the operation is not assigned to a block.
     *
     * @return the operation's result, or {@code null} if not assigned to a block.
     */
    public final Result result() {
        return result;
    }


The field is only null if the operation is not assigned (or bound) to a block, otherwise it has a value even if the type of that value is the void type. An operation is assigned to a block when it is appended via building, so any non-top-level operation in a model must have a result.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/222#discussion_r1751119610

From psandoz at openjdk.org  Tue Sep 10 01:34:15 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Sep 2024 01:34:15 GMT
Subject: [code-reflection] RFR: Unify common code of SwitchStatementOp and
 SwitchExpressionOp [v2]
In-Reply-To: <ycMSPYUXU6bL9NUiVlevtrvNOHKGkKswtspRDc7jiPc=.a03ff78f-5582-4b64-9ce9-34e08074dcc3@github.com>
References: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
 <qadOAZfHK6_CgEPNEEM6h3KklRLZifplG-X2ILE5Kew=.5c600485-2245-47b0-a2eb-67b71cb7d390@github.com>
 <dM4c_XWQF_vpeVFYgLNXOtn0Wx1K7Y6mA0c9P_mnbnY=.a0dbafe1-a125-4b22-aa5f-2c848d1e0a93@github.com>
 <ed5kmZg0WUHwKsAiAqM9QXLgnzfGU2x359MiMvZBxDw=.8505a13c-f14f-4fe2-8339-1940a1d9b5e6@github.com>
 <ycMSPYUXU6bL9NUiVlevtrvNOHKGkKswtspRDc7jiPc=.a03ff78f-5582-4b64-9ce9-34e08074dcc3@github.com>
Message-ID: <piYG2SMDWdEGLVHJs7DBR4UJ01Fl3-ip8qp1xlxSFvU=.49eb3b81-f8cd-4da7-bd8e-50f8fb8896e5@github.com>

On Tue, 10 Sep 2024 01:22:21 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> I see. Or we can test if resultType isn't void
>
> It cannot be:
> 
>     /**
>      * Returns the operation's result, otherwise {@code null} if the operation is not assigned to a block.
>      *
>      * @return the operation's result, or {@code null} if not assigned to a block.
>      */
>     public final Result result() {
>         return result;
>     }
> 
> 
> The field is only null if the operation is not assigned (or bound) to a block, otherwise it has a value even if the type of that value is the void type. An operation is assigned to a block when it is appended via building, so any non-top-level operation in a model must have a result.

Yes, you can check if its not equal e.g. `!JavaType.VOID.equals(result())`, but you could also check the `this` instance, since a switch expression yields a non-void value, its arguably clearer in the code.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/222#discussion_r1751125048

From mabbay at openjdk.org  Tue Sep 10 02:20:52 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Sep 2024 02:20:52 GMT
Subject: [code-reflection] RFR: Unify common code of SwitchStatementOp and
 SwitchExpressionOp [v4]
In-Reply-To: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
References: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
Message-ID: <F78Hz56o5Ogp744jrNn-9BeWKmC4Np2j9zSNMmCOaXo=.81096a99-8f09-411c-8ca9-055267227095@github.com>

> Unify common code of SwitchStatementOp and SwitchExpressionOp.

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

 - Update JavaSwitchOp.lower
 - Apply suggestions

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/222/files
  - new: https://git.openjdk.org/babylon/pull/222/files/4a35d1eb..461609ae

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

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

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

From mabbay at openjdk.org  Tue Sep 10 03:50:50 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Sep 2024 03:50:50 GMT
Subject: [code-reflection] RFR: Avoid boxing when concatenating a string with a
 primitive
Message-ID: <sBSYyO-DyhQCBWNiMoeqoSB02oajXte4N5frWj1BMkY=.a41345c6-60ba-44ca-a65e-984439cacd73@github.com>

Avoid boxing when concatenating a string with a primitive.

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

Commit messages:
 - Avoid boxing when concatenating a string with a primitive

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

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

From mabbay at openjdk.org  Tue Sep 10 07:12:55 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Sep 2024 07:12:55 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore
Message-ID: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>

Update the generated code model of pattern matching when pattern variable identifier is "_"

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

Commit messages:
 - Update the model of pattern matching when pattern variable identifier is "_"

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

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

From mabbay at openjdk.org  Tue Sep 10 07:19:51 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Sep 2024 07:19:51 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v2]
In-Reply-To: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
Message-ID: <_gZDKeeX8rs574_c1qCvOIkgGfZcoy-TimcwyUC9224=.18a7b284-b7d4-4cd1-ae9a-70b5cd6890c5@github.com>

> Update the generated code model of pattern matching when pattern variable identifier is "_"

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

  Update effected tests

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/227/files
  - new: https://git.openjdk.org/babylon/pull/227/files/4c1c4169..17545115

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

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

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

From asotona at openjdk.org  Tue Sep 10 14:41:30 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 10 Sep 2024 14:41:30 GMT
Subject: [code-reflection] RFR: Bytecode locals compaction
Message-ID: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>

`LocalsCompactor` is a bytecode transformation reducing generated method `maxLocals` by re-using local slots.
Roundtrip of lift and bytecode generation doubles the `maxLocals` value, while `LocalsCompactor` reduces the regression by 50%.

Lifting of compacted locals revealed bugs in `LocalsTypeMapper` variables graph construction. This patch includes significantly  refactored `LocalsTypeMapper` to support lifting of compacted locals.

`BytecodeGenerator` has slightly improved performance (so `TestSmallCorpus` finishes in a reasonable time). However performance has not been main focus of this PR.

`TestSmallCorpus` has been slightly refactored to provide better debugging feedback and compaction statistics. Overall stability is still >99%.

Please review.

Thanks,
Adam

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

Commit messages:
 - LocalsCompactor re-mapping also double slots
 - LocalsCompactor improvements
 - typo
 - disabled TestSmallCorpus
 - LocalsCompactor improvements
 - TestSmallCorpus fixes
 - TestSmallCorpus fixes
 - fixed -0 iinc index :)
 - Merge remote-tracking branch 'babylon/code-reflection' into bytecode-locals-compaction
 - Enabled slots compaction for all generated bytecode
 - ... and 18 more: https://git.openjdk.org/babylon/compare/b836dba3...d4c0b594

Changes: https://git.openjdk.org/babylon/pull/224/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=224&range=00
  Stats: 680 lines in 5 files changed: 479 ins; 102 del; 99 mod
  Patch: https://git.openjdk.org/babylon/pull/224.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/224/head:pull/224

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

From asotona at openjdk.org  Tue Sep 10 14:49:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 10 Sep 2024 14:49:39 GMT
Subject: [code-reflection] RFR: Bytecode locals compaction [v2]
In-Reply-To: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
References: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
Message-ID: <eWb5c8fnjXZ95jieXtL0kZwt7P19vxHi_ff4iRjASFI=.a3c1ced3-b749-45eb-9992-64e4db7b4731@github.com>

> `LocalsCompactor` is a bytecode transformation reducing generated method `maxLocals` by re-using local slots.
> Roundtrip of lift and bytecode generation doubles the `maxLocals` value, while `LocalsCompactor` reduces the regression by 50%.
> 
> Lifting of compacted locals revealed bugs in `LocalsTypeMapper` variables graph construction. This patch includes significantly  refactored `LocalsTypeMapper` to support lifting of compacted locals.
> 
> `BytecodeGenerator` has slightly improved performance (so `TestSmallCorpus` finishes in a reasonable time). However performance has not been main focus of this PR.
> 
> `TestSmallCorpus` has been slightly refactored to provide better debugging feedback and compaction statistics. Overall stability is still >99%.
> 
> Please review.
> 
> Thanks,
> Adam

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

  added comments

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/224/files
  - new: https://git.openjdk.org/babylon/pull/224/files/d4c0b594..6f71c8ed

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

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

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

From mcimadamore at openjdk.org  Tue Sep 10 14:53:28 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Sep 2024 14:53:28 GMT
Subject: [code-reflection] RFR: Invocation to vararg methods
In-Reply-To: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
References: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
Message-ID: <PqgdUxUZ1nw0KnRhi-doDg7lIApxA-tI83ma2MlT8Qw=.5a450504-5a63-4cc9-9e52-c2086ecbcad8@github.com>

On Tue, 10 Sep 2024 01:06:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Re-consolidate to one invocation operation that explicitly declares its invoke kind and whether it is an invocation to a varargs method.
> 
> Resolution of a method reference accepts an invoke kind. The ambiguity when resolving a method reference without an invoke kind has been cleared up, in these cases we can only resolve to a direct method, one in which the referencing class is the class that declares the method.
> 
> I managed to avoid numerous changes to update the text models in language tests. Creating an invoke operation from external form is permissive in the attributes that are present. It makes the same assumptions as the invoke factory method in determining the invocation kind from the argument count and invoke descriptor count, and assumes the method is not a varargs method (the common case).

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

> 1543:         }
> 1544: 
> 1545:         public List<Value> varArgOperands() {

I suspect having the varargs type would also be useful

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

> 3787:      */
> 3788:     public static InvokeOp invoke(TypeElement returnType, MethodRef invokeDescriptor, List<Value> args) {
> 3789:         int paramCount = invokeDescriptor.type().parameterTypes().size();

I wonder if, for clients, it would be easier to use a descriptor for the non-varargs part, then specify a TypeElement for the varargs type, and let the API figure out how to wield those together. In a way the fact that "varargs are methods whose last parameter is an array" seems an impl detail?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/225#discussion_r1752136485
PR Review Comment: https://git.openjdk.org/babylon/pull/225#discussion_r1752139580

From mcimadamore at openjdk.org  Tue Sep 10 15:00:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Sep 2024 15:00:25 GMT
Subject: [code-reflection] RFR: Invocation to vararg methods
In-Reply-To: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
References: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
Message-ID: <LQANNekU6tx5RjcowsivPT2ZbC_StYNSn3_2ffl7Ie4=.09d60372-2c96-4a8b-b4e3-7fb2f3fe83cc@github.com>

On Tue, 10 Sep 2024 01:06:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Re-consolidate to one invocation operation that explicitly declares its invoke kind and whether it is an invocation to a varargs method.
> 
> Resolution of a method reference accepts an invoke kind. The ambiguity when resolving a method reference without an invoke kind has been cleared up, in these cases we can only resolve to a direct method, one in which the referencing class is the class that declares the method.
> 
> I managed to avoid numerous changes to update the text models in language tests. Creating an invoke operation from external form is permissive in the attributes that are present. It makes the same assumptions as the invoke factory method in determining the invocation kind from the argument count and invoke descriptor count, and assumes the method is not a varargs method (the common case).

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

> 1517:             HashMap<String, Object> m = new HashMap<>(super.attributes());
> 1518:             m.put("", invokeDescriptor);
> 1519:             if (isVarArgs) {

This seems a bit of an arbitrary cut - e.g. we only generate as few attributes as possible, given we know how to infer some of those. I understand why: we don't want invoke ops to look to scary in the string representation...

Why do we need to emit the invokekind for variadic calls?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/225#discussion_r1752151021

From mcimadamore at openjdk.org  Tue Sep 10 15:02:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Sep 2024 15:02:25 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v2]
In-Reply-To: <_gZDKeeX8rs574_c1qCvOIkgGfZcoy-TimcwyUC9224=.18a7b284-b7d4-4cd1-ae9a-70b5cd6890c5@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <_gZDKeeX8rs574_c1qCvOIkgGfZcoy-TimcwyUC9224=.18a7b284-b7d4-4cd1-ae9a-70b5cd6890c5@github.com>
Message-ID: <HSq9xDakTE_Z64WuG6TatHv6axshtV8D7PGW60lpD_Y=.26b5955b-5a18-46a1-8842-68166792925a@github.com>

On Tue, 10 Sep 2024 07:19:51 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Update the generated code model of pattern matching when pattern variable identifier is "_"
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update effected tests

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1229:

> 1227: 
> 1228:                     String varName = var.name.isEmpty() ? "_" : var.name.toString();
> 1229:                     result = append(ExtendedOp.bindingPattern(typeToTypeElement(var.type), varName));

Note sure about this - it's not like the variable has name `_`. The variable does **not** have a name. Which means there should be a way to build a pattern binding (and, more generally, `Var`) that do not have a name (I think?)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1752155132

From mcimadamore at openjdk.org  Tue Sep 10 15:03:17 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Sep 2024 15:03:17 GMT
Subject: [code-reflection] RFR: Avoid boxing when concatenating a string
 with a primitive
In-Reply-To: <sBSYyO-DyhQCBWNiMoeqoSB02oajXte4N5frWj1BMkY=.a41345c6-60ba-44ca-a65e-984439cacd73@github.com>
References: <sBSYyO-DyhQCBWNiMoeqoSB02oajXte4N5frWj1BMkY=.a41345c6-60ba-44ca-a65e-984439cacd73@github.com>
Message-ID: <c-2siojaKJhTT3DaBVMar9tCkejvZu_KSfC8L3gsXqM=.90f4a888-1702-412c-9663-bf2c6b1b8567@github.com>

On Tue, 10 Sep 2024 03:45:29 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Avoid boxing when concatenating a string with a primitive.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/babylon/pull/226#pullrequestreview-2292801817

From mabbay at openjdk.org  Tue Sep 10 15:11:18 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Sep 2024 15:11:18 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v2]
In-Reply-To: <HSq9xDakTE_Z64WuG6TatHv6axshtV8D7PGW60lpD_Y=.26b5955b-5a18-46a1-8842-68166792925a@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <_gZDKeeX8rs574_c1qCvOIkgGfZcoy-TimcwyUC9224=.18a7b284-b7d4-4cd1-ae9a-70b5cd6890c5@github.com>
 <HSq9xDakTE_Z64WuG6TatHv6axshtV8D7PGW60lpD_Y=.26b5955b-5a18-46a1-8842-68166792925a@github.com>
Message-ID: <L5NcU9q_CVP9BuRfy4F-ah6c-gqVYdaWv_9r4jP8NQQ=.b265d0c8-65c6-40d8-a27f-9f08ec7bb60f@github.com>

On Tue, 10 Sep 2024 14:59:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update effected tests
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1229:
> 
>> 1227: 
>> 1228:                     String varName = var.name.isEmpty() ? "_" : var.name.toString();
>> 1229:                     result = append(ExtendedOp.bindingPattern(typeToTypeElement(var.type), varName));
> 
> Note sure about this - it's not like the variable has name `_`. The variable does **not** have a name. Which means there should be a way to build a pattern binding (and, more generally, `Var`) that do not have a name (I think?)

Type pattern can't use var

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1752170920

From asotona at openjdk.org  Tue Sep 10 15:16:35 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 10 Sep 2024 15:16:35 GMT
Subject: [code-reflection] RFR: Bytecode locals compaction [v3]
In-Reply-To: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
References: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
Message-ID: <CHAjdrpG-93loWkrfyFl-bpbTbwP8ARuR2kilJiI8tY=.b39ce312-4652-4029-aeee-7ada4696f192@github.com>

> `LocalsCompactor` is a bytecode transformation reducing generated method `maxLocals` by re-using local slots.
> Roundtrip of lift and bytecode generation doubles the `maxLocals` value, while `LocalsCompactor` reduces the regression by 50%.
> 
> Lifting of compacted locals revealed bugs in `LocalsTypeMapper` variables graph construction. This patch includes significantly  refactored `LocalsTypeMapper` to support lifting of compacted locals.
> 
> `BytecodeGenerator` has slightly improved performance (so `TestSmallCorpus` finishes in a reasonable time). However performance has not been main focus of this PR.
> 
> `TestSmallCorpus` has been slightly refactored to provide better debugging feedback and compaction statistics. Overall stability is still >99%.
> 
> Please review.
> 
> Thanks,
> Adam

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

  added comments

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/224/files
  - new: https://git.openjdk.org/babylon/pull/224/files/6f71c8ed..cadb3669

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

  Stats: 11 lines in 2 files changed: 7 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/babylon/pull/224.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/224/head:pull/224

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

From psandoz at openjdk.org  Tue Sep 10 15:23:16 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Sep 2024 15:23:16 GMT
Subject: [code-reflection] RFR: Invocation to vararg methods
In-Reply-To: <LQANNekU6tx5RjcowsivPT2ZbC_StYNSn3_2ffl7Ie4=.09d60372-2c96-4a8b-b4e3-7fb2f3fe83cc@github.com>
References: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
 <LQANNekU6tx5RjcowsivPT2ZbC_StYNSn3_2ffl7Ie4=.09d60372-2c96-4a8b-b4e3-7fb2f3fe83cc@github.com>
Message-ID: <QH38WSo8-6hAbpzTHHdh-2LyUF1N7i3_sbXcVvP7oxM=.fa81ff9d-3415-48af-b893-023dfba6a300@github.com>

On Tue, 10 Sep 2024 14:57:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Re-consolidate to one invocation operation that explicitly declares its invoke kind and whether it is an invocation to a varargs method.
>> 
>> Resolution of a method reference accepts an invoke kind. The ambiguity when resolving a method reference without an invoke kind has been cleared up, in these cases we can only resolve to a direct method, one in which the referencing class is the class that declares the method.
>> 
>> I managed to avoid numerous changes to update the text models in language tests. Creating an invoke operation from external form is permissive in the attributes that are present. It makes the same assumptions as the invoke factory method in determining the invocation kind from the argument count and invoke descriptor count, and assumes the method is not a varargs method (the common case).
>
> src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 1519:
> 
>> 1517:             HashMap<String, Object> m = new HashMap<>(super.attributes());
>> 1518:             m.put("", invokeDescriptor);
>> 1519:             if (isVarArgs) {
> 
> This seems a bit of an arbitrary cut - e.g. we only generate as few attributes as possible, given we know how to infer some of those. I understand why: we don't want invoke ops to look to scary in the string representation...
> 
> Why do we need to emit the invokekind for variadic calls?

We don't need to in all cases - only required for super invocations. I just chose a path of least resistance when hacking it together. My main motivation was to avoid updating all the tests! Varargs calls are less common so I was not overly concerned about the scary strings.

But, for consistency I think it is worth addressing this. If `invoke.varargs` is present and `invoke.kind` is not we can infer static or instance invocation.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/225#discussion_r1752189695

From psandoz at openjdk.org  Tue Sep 10 15:43:20 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Sep 2024 15:43:20 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v2]
In-Reply-To: <L5NcU9q_CVP9BuRfy4F-ah6c-gqVYdaWv_9r4jP8NQQ=.b265d0c8-65c6-40d8-a27f-9f08ec7bb60f@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <_gZDKeeX8rs574_c1qCvOIkgGfZcoy-TimcwyUC9224=.18a7b284-b7d4-4cd1-ae9a-70b5cd6890c5@github.com>
 <HSq9xDakTE_Z64WuG6TatHv6axshtV8D7PGW60lpD_Y=.26b5955b-5a18-46a1-8842-68166792925a@github.com>
 <L5NcU9q_CVP9BuRfy4F-ah6c-gqVYdaWv_9r4jP8NQQ=.b265d0c8-65c6-40d8-a27f-9f08ec7bb60f@github.com>
Message-ID: <zo_BLEV8jXhlXwrjIrlI5J84pDj_OowQA5BcuOb1Iuw=.ddbd08e0-325a-42d4-8b15-b1c571bf6a6c@github.com>

On Tue, 10 Sep 2024 15:08:43 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1229:
>> 
>>> 1227: 
>>> 1228:                     String varName = var.name.isEmpty() ? "_" : var.name.toString();
>>> 1229:                     result = append(ExtendedOp.bindingPattern(typeToTypeElement(var.type), varName));
>> 
>> Note sure about this - it's not like the variable has name `_`. The variable does **not** have a name. Which means there should be a way to build a pattern binding (and, more generally, `Var`) that do not have a name (I think?)
>
> Type pattern can't use var

In the JLS there is the `MatchAllPattern` in the grammar. I think it would be clearer to model this explicitly as a distinct pattern operation e.g. a `MatchAllPatternOp`, rather than model as a `BindingPatternOp` with a special name. For `_` there will be no binding to a pattern variable on a successful match (which is always successful and never partial) as there is no variable to bind to.

Separately, we probably should rename `BindingPatternOp` to `TypePatternOp` to be consistent with the names in the JLS.

@mcimadamore the current way the modeling works for `BindingPatternOp` (modelling a `TypePattern`) is the `Var` modeling the pattern variable only comes into existence when lowered, and it may be in a broader scope than in the source (since we currently don't do flow analysis and represent that in the model).

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1752221807

From psandoz at openjdk.org  Tue Sep 10 15:50:21 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Sep 2024 15:50:21 GMT
Subject: [code-reflection] RFR: Invocation to vararg methods
In-Reply-To: <PqgdUxUZ1nw0KnRhi-doDg7lIApxA-tI83ma2MlT8Qw=.5a450504-5a63-4cc9-9e52-c2086ecbcad8@github.com>
References: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
 <PqgdUxUZ1nw0KnRhi-doDg7lIApxA-tI83ma2MlT8Qw=.5a450504-5a63-4cc9-9e52-c2086ecbcad8@github.com>
Message-ID: <ijTMWAjY_z3CaTGCyh6BnL7d-zdo7O7jGe-Wl2uhd-U=.160c9bb3-6838-48f7-b854-c8e139f7692f@github.com>

On Tue, 10 Sep 2024 14:50:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Re-consolidate to one invocation operation that explicitly declares its invoke kind and whether it is an invocation to a varargs method.
>> 
>> Resolution of a method reference accepts an invoke kind. The ambiguity when resolving a method reference without an invoke kind has been cleared up, in these cases we can only resolve to a direct method, one in which the referencing class is the class that declares the method.
>> 
>> I managed to avoid numerous changes to update the text models in language tests. Creating an invoke operation from external form is permissive in the attributes that are present. It makes the same assumptions as the invoke factory method in determining the invocation kind from the argument count and invoke descriptor count, and assumes the method is not a varargs method (the common case).
>
> src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 3789:
> 
>> 3787:      */
>> 3788:     public static InvokeOp invoke(TypeElement returnType, MethodRef invokeDescriptor, List<Value> args) {
>> 3789:         int paramCount = invokeDescriptor.type().parameterTypes().size();
> 
> I wonder if, for clients, it would be easier to use a descriptor for the non-varargs part, then specify a TypeElement for the varargs type, and let the API figure out how to wield those together. In a way the fact that "varargs are methods whose last parameter is an array" seems an impl detail?

So split out the currently method reference into two parts? How would we resolve a varargs method from such a reference?

I was thinking, even though it makes no sense from a JLS perspective, that someone could interpret a method say `m(String s, List<String> more)` as a varargs method, where the variable arguments would somehow be "boxed" into a list rather than an array. That is possible to represent in the current design while the method reference is still resolvable.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/225#discussion_r1752231908

From psandoz at openjdk.org  Tue Sep 10 15:55:18 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Sep 2024 15:55:18 GMT
Subject: [code-reflection] RFR: Avoid boxing when concatenating a string
 with a primitive
In-Reply-To: <sBSYyO-DyhQCBWNiMoeqoSB02oajXte4N5frWj1BMkY=.a41345c6-60ba-44ca-a65e-984439cacd73@github.com>
References: <sBSYyO-DyhQCBWNiMoeqoSB02oajXte4N5frWj1BMkY=.a41345c6-60ba-44ca-a65e-984439cacd73@github.com>
Message-ID: <i-OYIYBuHx8lfd96yW1Zn0r_1CkUmpcwLciw-igPK0E=.12521e8a-5937-4905-8ad2-79a13b1f4a18@github.com>

On Tue, 10 Sep 2024 03:45:29 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Avoid boxing when concatenating a string with a primitive.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 833:

> 831:             Function<Value, Value> scanRhs = (lhs) -> {
> 832:                 Type unboxedType = types.unboxedTypeOrType(tree.type);
> 833:                 // if string concat and rhs is primitive, toValue(rhs)

Remove the comment at line 847

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

PR Review Comment: https://git.openjdk.org/babylon/pull/226#discussion_r1752239573

From mabbay at openjdk.org  Tue Sep 10 16:57:44 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 10 Sep 2024 16:57:44 GMT
Subject: [code-reflection] RFR: Avoid boxing when concatenating a string
 with a primitive [v2]
In-Reply-To: <sBSYyO-DyhQCBWNiMoeqoSB02oajXte4N5frWj1BMkY=.a41345c6-60ba-44ca-a65e-984439cacd73@github.com>
References: <sBSYyO-DyhQCBWNiMoeqoSB02oajXte4N5frWj1BMkY=.a41345c6-60ba-44ca-a65e-984439cacd73@github.com>
Message-ID: <w6EiLRhNRiXu7Jt8LSNIr6ERZGNnitU6hYOuMOQyHCw=.e6b08c9c-656a-4c19-bd3c-59eca4fc68de@github.com>

> Avoid boxing when concatenating a string with a primitive.

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

 - remove comment
 - remove outdated comment

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/226/files
  - new: https://git.openjdk.org/babylon/pull/226/files/bf55c1c0..51550f88

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

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

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

From psandoz at openjdk.org  Tue Sep 10 16:57:44 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Sep 2024 16:57:44 GMT
Subject: [code-reflection] RFR: Avoid boxing when concatenating a string
 with a primitive [v2]
In-Reply-To: <w6EiLRhNRiXu7Jt8LSNIr6ERZGNnitU6hYOuMOQyHCw=.e6b08c9c-656a-4c19-bd3c-59eca4fc68de@github.com>
References: <sBSYyO-DyhQCBWNiMoeqoSB02oajXte4N5frWj1BMkY=.a41345c6-60ba-44ca-a65e-984439cacd73@github.com>
 <w6EiLRhNRiXu7Jt8LSNIr6ERZGNnitU6hYOuMOQyHCw=.e6b08c9c-656a-4c19-bd3c-59eca4fc68de@github.com>
Message-ID: <vzvSKLNnBbGNDXP1e_TvagJAsVyavREwLzWFcjJLi_g=.7dd3f604-af82-4d05-b770-156596c3a2ec@github.com>

On Tue, 10 Sep 2024 16:54:47 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Avoid boxing when concatenating a string with a primitive.
>
> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove comment
>  - remove outdated comment

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/226#pullrequestreview-2293103490

From psandoz at openjdk.org  Tue Sep 10 20:03:33 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Sep 2024 20:03:33 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v2]
In-Reply-To: <zo_BLEV8jXhlXwrjIrlI5J84pDj_OowQA5BcuOb1Iuw=.ddbd08e0-325a-42d4-8b15-b1c571bf6a6c@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <_gZDKeeX8rs574_c1qCvOIkgGfZcoy-TimcwyUC9224=.18a7b284-b7d4-4cd1-ae9a-70b5cd6890c5@github.com>
 <HSq9xDakTE_Z64WuG6TatHv6axshtV8D7PGW60lpD_Y=.26b5955b-5a18-46a1-8842-68166792925a@github.com>
 <L5NcU9q_CVP9BuRfy4F-ah6c-gqVYdaWv_9r4jP8NQQ=.b265d0c8-65c6-40d8-a27f-9f08ec7bb60f@github.com>
 <zo_BLEV8jXhlXwrjIrlI5J84pDj_OowQA5BcuOb1Iuw=.ddbd08e0-325a-42d4-8b15-b1c571bf6a6c@github.com>
Message-ID: <_5nnry_Cb5qC0alWHjpRMebQs6BMxyL25h2h5UgBga4=.8633499c-28fb-485d-83de-cda10f560d3f@github.com>

On Tue, 10 Sep 2024 15:40:36 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Type pattern can't use var
>
> In the JLS there is the `MatchAllPattern` in the grammar. I think it would be clearer to model this explicitly as a distinct pattern operation e.g. a `MatchAllPatternOp`, rather than model as a `BindingPatternOp` with a special name. For `_` there will be no binding to a pattern variable on a successful match (which is always successful and never partial) as there is no variable to bind to.
> 
> Separately, we probably should rename `BindingPatternOp` to `TypePatternOp` to be consistent with the names in the JLS.
> 
> @mcimadamore the current way the modeling works for `BindingPatternOp` (modelling a `TypePattern`) is the `Var` modeling the pattern variable only comes into existence when lowered, and it may be in a broader scope than in the source (since we currently don't do flow analysis and represent that in the model).

I realized i was confusing use of `_` in a type pattern `o instanceof T _` and a record pattern `R(_)`. The former is a type pattern but it has no binding of its match result. The name `BindingPatternOp` follows the naming in the compiler (`JCBindingPattern` and `BindingPatternTree`) ,which is confusing when there is no binding. We should rename `BindingPatternOp` to `TypePatternOp` and then we make it clearer whether there is a binding to a variable or not. (Mourad I and discussed this off-line.)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1752654034

From psandoz at openjdk.org  Tue Sep 10 20:58:00 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Sep 2024 20:58:00 GMT
Subject: [code-reflection] RFR: Invocation to vararg methods [v2]
In-Reply-To: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
References: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
Message-ID: <0vLTYb4WJW7WqUPBLcF2TphrwiFKHI1ybyZfry3nRK4=.e1d6d7e6-1b0e-469d-abfa-77bc11f04879@github.com>

> Re-consolidate to one invocation operation that explicitly declares its invoke kind and whether it is an invocation to a varargs method.
> 
> Resolution of a method reference accepts an invoke kind. The ambiguity when resolving a method reference without an invoke kind has been cleared up, in these cases we can only resolve to a direct method, one in which the referencing class is the class that declares the method.
> 
> I managed to avoid numerous changes to update the text models in language tests. Creating an invoke operation from external form is permissive in the attributes that are present. It makes the same assumptions as the invoke factory method in determining the invocation kind from the argument count and invoke descriptor count, and assumes the method is not a varargs method (the common case).

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

  Comments.

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/225/files
  - new: https://git.openjdk.org/babylon/pull/225/files/c1f488ae..762488fe

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

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

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

From psandoz at openjdk.org  Tue Sep 10 20:58:01 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Sep 2024 20:58:01 GMT
Subject: [code-reflection] RFR: Invocation to vararg methods [v2]
In-Reply-To: <QH38WSo8-6hAbpzTHHdh-2LyUF1N7i3_sbXcVvP7oxM=.fa81ff9d-3415-48af-b893-023dfba6a300@github.com>
References: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
 <LQANNekU6tx5RjcowsivPT2ZbC_StYNSn3_2ffl7Ie4=.09d60372-2c96-4a8b-b4e3-7fb2f3fe83cc@github.com>
 <QH38WSo8-6hAbpzTHHdh-2LyUF1N7i3_sbXcVvP7oxM=.fa81ff9d-3415-48af-b893-023dfba6a300@github.com>
Message-ID: <TDej177YIXVeCghzF_PmP1jDw0zU5geXI0Q3cMX5XRE=.7581ff3a-bb01-4d15-b94d-012b2d341f39@github.com>

On Tue, 10 Sep 2024 15:20:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 1519:
>> 
>>> 1517:             HashMap<String, Object> m = new HashMap<>(super.attributes());
>>> 1518:             m.put("", invokeDescriptor);
>>> 1519:             if (isVarArgs) {
>> 
>> This seems a bit of an arbitrary cut - e.g. we only generate as few attributes as possible, given we know how to infer some of those. I understand why: we don't want invoke ops to look to scary in the string representation...
>> 
>> Why do we need to emit the invokekind for variadic calls?
>
> We don't need to in all cases - only required for super invocations. I just chose a path of least resistance when hacking it together. My main motivation was to avoid updating all the tests! Varargs calls are less common so I was not overly concerned about the scary strings.
> 
> But, for consistency I think it is worth addressing this. If `invoke.varargs` is present and `invoke.kind` is not we can infer static or instance invocation.

Actually there was a reason, that i forgot about. Let's say we have a method `A::m(A... more)` we know it is varargs but don't know if it's a static or instance method. Given one operand we cannot differentiate between `a.m()` and `m(a)`.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/225#discussion_r1752709116

From psandoz at openjdk.org  Tue Sep 10 23:30:32 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Sep 2024 23:30:32 GMT
Subject: [code-reflection] RFR: Bytecode locals compaction [v3]
In-Reply-To: <CHAjdrpG-93loWkrfyFl-bpbTbwP8ARuR2kilJiI8tY=.b39ce312-4652-4029-aeee-7ada4696f192@github.com>
References: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
 <CHAjdrpG-93loWkrfyFl-bpbTbwP8ARuR2kilJiI8tY=.b39ce312-4652-4029-aeee-7ada4696f192@github.com>
Message-ID: <o5WFoss2NMIqLBDWQM5oubRYwQvFAYRtEOzuGoQ2p2E=.bee9ce88-2a27-4df8-8b57-296b83a0efd7@github.com>

On Tue, 10 Sep 2024 15:16:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> `LocalsCompactor` is a bytecode transformation reducing generated method `maxLocals` by re-using local slots.
>> Roundtrip of lift and bytecode generation doubles the `maxLocals` value, while `LocalsCompactor` reduces the regression by 50%.
>> 
>> Lifting of compacted locals revealed bugs in `LocalsTypeMapper` variables graph construction. This patch includes significantly  refactored `LocalsTypeMapper` to support lifting of compacted locals.
>> 
>> `BytecodeGenerator` has slightly improved performance (so `TestSmallCorpus` finishes in a reasonable time). However performance has not been main focus of this PR.
>> 
>> `TestSmallCorpus` has been slightly refactored to provide better debugging feedback and compaction statistics. Overall stability is still >99%.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments

This is getting to a level of complexity that i cannot provide a useful review on the algorithmic details as I don't fully comprehend them. Once you reach a stable point it will be very useful to describe the approach.

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

> 353:     // Some of the operations can be deferred
> 354:     private boolean canDefer(Op op) {
> 355:         Boolean can = deferCache.get(op);

Use `computeIfAbsent`?

src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeLift.java line 275:

> 273:     }
> 274: 
> 275:     public static CoreOp.FuncOp lift(MethodModel methodModel, MethodHandles.Lookup lookup) {

Place the lookup as the first parameter, like for the bytecode generator and the interpreter

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

Marked as reviewed by psandoz (Lead).

PR Review: https://git.openjdk.org/babylon/pull/224#pullrequestreview-2294105665
PR Review Comment: https://git.openjdk.org/babylon/pull/224#discussion_r1752899280
PR Review Comment: https://git.openjdk.org/babylon/pull/224#discussion_r1752905979

From mcimadamore at openjdk.org  Tue Sep 10 23:56:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Sep 2024 23:56:13 GMT
Subject: [code-reflection] RFR: Invocation to vararg methods [v2]
In-Reply-To: <TDej177YIXVeCghzF_PmP1jDw0zU5geXI0Q3cMX5XRE=.7581ff3a-bb01-4d15-b94d-012b2d341f39@github.com>
References: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
 <LQANNekU6tx5RjcowsivPT2ZbC_StYNSn3_2ffl7Ie4=.09d60372-2c96-4a8b-b4e3-7fb2f3fe83cc@github.com>
 <QH38WSo8-6hAbpzTHHdh-2LyUF1N7i3_sbXcVvP7oxM=.fa81ff9d-3415-48af-b893-023dfba6a300@github.com>
 <TDej177YIXVeCghzF_PmP1jDw0zU5geXI0Q3cMX5XRE=.7581ff3a-bb01-4d15-b94d-012b2d341f39@github.com>
Message-ID: <E_VLT-wedFjOUf3QXPlc1oAAjvtNJSOtZD9z43GAeW0=.1d4e6f89-87a8-4066-b360-54440020e31c@github.com>

On Tue, 10 Sep 2024 20:54:48 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> We don't need to in all cases - only required for super invocations. I just chose a path of least resistance when hacking it together. My main motivation was to avoid updating all the tests! Varargs calls are less common so I was not overly concerned about the scary strings.
>> 
>> But, for consistency I think it is worth addressing this. If `invoke.varargs` is present and `invoke.kind` is not we can infer static or instance invocation.
>
> Actually there was a reason, that i forgot about. Let's say we have a method `A::m(A... more)` we know it is varargs but don't know if it's a static or instance method. Given one operand we cannot differentiate between `a.m()` and `m(a)`.

ugh - ok :-)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/225#discussion_r1752943820

From mcimadamore at openjdk.org  Tue Sep 10 23:56:14 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 10 Sep 2024 23:56:14 GMT
Subject: [code-reflection] RFR: Invocation to vararg methods [v2]
In-Reply-To: <ijTMWAjY_z3CaTGCyh6BnL7d-zdo7O7jGe-Wl2uhd-U=.160c9bb3-6838-48f7-b854-c8e139f7692f@github.com>
References: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
 <PqgdUxUZ1nw0KnRhi-doDg7lIApxA-tI83ma2MlT8Qw=.5a450504-5a63-4cc9-9e52-c2086ecbcad8@github.com>
 <ijTMWAjY_z3CaTGCyh6BnL7d-zdo7O7jGe-Wl2uhd-U=.160c9bb3-6838-48f7-b854-c8e139f7692f@github.com>
Message-ID: <mx4n2BKVTS-oRtK0xCYBIx-yeMIu5yJmJVKEh9D84Uw=.e9663397-c26b-4315-b007-087622910e98@github.com>

On Tue, 10 Sep 2024 15:47:25 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 3789:
>> 
>>> 3787:      */
>>> 3788:     public static InvokeOp invoke(TypeElement returnType, MethodRef invokeDescriptor, List<Value> args) {
>>> 3789:         int paramCount = invokeDescriptor.type().parameterTypes().size();
>> 
>> I wonder if, for clients, it would be easier to use a descriptor for the non-varargs part, then specify a TypeElement for the varargs type, and let the API figure out how to wield those together. In a way the fact that "varargs are methods whose last parameter is an array" seems an impl detail?
>
> So split out the currently method reference into two parts? How would we resolve a varargs method from such a reference?
> 
> I was thinking, even though it makes no sense from a JLS perspective, that someone could interpret a method say `m(String s, List<String> more)` as a varargs method, where the variable arguments would somehow be "boxed" into a list rather than an array. That is possible to represent in the current design while the method reference is still resolvable.

Yeah - the fact that a `MethodRef` is basically bound to a symbolic reference is quite constraining here, as implementation details (varargs are arrays) end up leaking in the method ref. But that seems to be unavoidable to some extent.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/225#discussion_r1752945306

From mcimadamore at openjdk.org  Wed Sep 11 00:26:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Sep 2024 00:26:12 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v2]
In-Reply-To: <_5nnry_Cb5qC0alWHjpRMebQs6BMxyL25h2h5UgBga4=.8633499c-28fb-485d-83de-cda10f560d3f@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <_gZDKeeX8rs574_c1qCvOIkgGfZcoy-TimcwyUC9224=.18a7b284-b7d4-4cd1-ae9a-70b5cd6890c5@github.com>
 <HSq9xDakTE_Z64WuG6TatHv6axshtV8D7PGW60lpD_Y=.26b5955b-5a18-46a1-8842-68166792925a@github.com>
 <L5NcU9q_CVP9BuRfy4F-ah6c-gqVYdaWv_9r4jP8NQQ=.b265d0c8-65c6-40d8-a27f-9f08ec7bb60f@github.com>
 <zo_BLEV8jXhlXwrjIrlI5J84pDj_OowQA5BcuOb1Iuw=.ddbd08e0-325a-42d4-8b15-b1c571bf6a6c@github.com>
 <_5nnry_Cb5qC0alWHjpRMebQs6BMxyL25h2h5UgBga4=.8633499c-28fb-485d-83de-cda10f560d3f@github.com>
Message-ID: <HjocgGa_-QuM063jgh28RFos03NU1A_T0fZr-JonqSQ=.5f37fd68-3115-4c50-bdb7-a42e4e9d41b4@github.com>

On Tue, 10 Sep 2024 20:01:19 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> In the JLS there is the `MatchAllPattern` in the grammar. I think it would be clearer to model this explicitly as a distinct pattern operation e.g. a `MatchAllPatternOp`, rather than model as a `BindingPatternOp` with a special name. For `_` there will be no binding to a pattern variable on a successful match (which is always successful and never partial) as there is no variable to bind to.
>> 
>> Separately, we probably should rename `BindingPatternOp` to `TypePatternOp` to be consistent with the names in the JLS.
>> 
>> @mcimadamore the current way the modeling works for `BindingPatternOp` (modelling a `TypePattern`) is the `Var` modeling the pattern variable only comes into existence when lowered, and it may be in a broader scope than in the source (since we currently don't do flow analysis and represent that in the model).
>
> I realized i was confusing use of `_` in a type pattern `o instanceof T _` and a record pattern `R(_)`. The former is a type pattern but it has no binding of its match result. The name `BindingPatternOp` follows the naming in the compiler (`JCBindingPattern` and `BindingPatternTree`) ,which is confusing when there is no binding. We should rename `BindingPatternOp` to `TypePatternOp` and then we make it clearer whether there is a binding to a variable or not. (Mourad and I discussed this off-line.)

Yep - this PR is about a type test pattern whose binding name is left unspecified (`_`). I was observing that unspecified names can occur in many places (method parameters, local var decls, etc.) so we probably need some uniform way to handle with "missing names" ? What I'm objecting to, in this PR, is that we're creating a binding, where the binding name is `_` - which strikes me as incorrect. The name is missing/absent, `_` is just the Java way of denoting missing names.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1752961089

From psandoz at openjdk.org  Wed Sep 11 00:27:18 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 11 Sep 2024 00:27:18 GMT
Subject: [code-reflection] RFR: Unify common code of SwitchStatementOp and
 SwitchExpressionOp [v4]
In-Reply-To: <F78Hz56o5Ogp744jrNn-9BeWKmC4Np2j9zSNMmCOaXo=.81096a99-8f09-411c-8ca9-055267227095@github.com>
References: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
 <F78Hz56o5Ogp744jrNn-9BeWKmC4Np2j9zSNMmCOaXo=.81096a99-8f09-411c-8ca9-055267227095@github.com>
Message-ID: <c6voFyHx8Ci7RELMAfm-AWdFhdZSu1XtZPtOO6SBruc=.70c693a6-65ff-400f-8a99-e1867eeb210e@github.com>

On Tue, 10 Sep 2024 02:20:52 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Unify common code of SwitchStatementOp and SwitchExpressionOp.
>
> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update JavaSwitchOp.lower
>  - Apply suggestions

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/222#pullrequestreview-2294504005

From psandoz at openjdk.org  Wed Sep 11 01:02:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 11 Sep 2024 01:02:17 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v2]
In-Reply-To: <HjocgGa_-QuM063jgh28RFos03NU1A_T0fZr-JonqSQ=.5f37fd68-3115-4c50-bdb7-a42e4e9d41b4@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <_gZDKeeX8rs574_c1qCvOIkgGfZcoy-TimcwyUC9224=.18a7b284-b7d4-4cd1-ae9a-70b5cd6890c5@github.com>
 <HSq9xDakTE_Z64WuG6TatHv6axshtV8D7PGW60lpD_Y=.26b5955b-5a18-46a1-8842-68166792925a@github.com>
 <L5NcU9q_CVP9BuRfy4F-ah6c-gqVYdaWv_9r4jP8NQQ=.b265d0c8-65c6-40d8-a27f-9f08ec7bb60f@github.com>
 <zo_BLEV8jXhlXwrjIrlI5J84pDj_OowQA5BcuOb1Iuw=.ddbd08e0-325a-42d4-8b15-b1c571bf6a6c@github.com>
 <_5nnry_Cb5qC0alWHjpRMebQs6BMxyL25h2h5UgBga4=.8633499c-28fb-485d-83de-cda10f560d3f@github.com>
 <HjocgGa_-QuM063jgh28RFos03NU1A_T0fZr-JonqSQ=.5f37fd68-3115-4c50-bdb7-a42e4e9d41b4@github.com>
Message-ID: <Cp74GUA8X9sXiuk_WLMWWpvEs-PPyDxNcIIiFCl1oVE=.16cd95a3-120f-4347-bf44-8b4d51835dd1@github.com>

On Wed, 11 Sep 2024 00:21:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I realized i was confusing use of `_` in a type pattern `o instanceof T _` and a record pattern `R(_)`. The former is a type pattern but it has no binding of its match result. The name `BindingPatternOp` follows the naming in the compiler (`JCBindingPattern` and `BindingPatternTree`) ,which is confusing when there is no binding. We should rename `BindingPatternOp` to `TypePatternOp` and then we make it clearer whether there is a binding to a variable or not. (Mourad and I discussed this off-line.)
>
> Yep - this PR is about a type test pattern whose binding name is left unspecified (`_`). I was observing that unspecified names can occur in many places (method parameters, local var decls, etc.) so we probably need some uniform way to handle with "missing names" ? What I'm objecting to, in this PR, is that we're creating a binding, where the binding name is `_` - which strikes me as incorrect. The name is missing/absent, `_` is just the Java way of denoting missing names.

Right, they are interconnected. I proposed to Mourad we should use `null` to signal no binding/name. The corresponding Var modeling the pattern variable can have `null` for its name, which we can do generally for variables with no name.

For example for:

`boolean x = o instanceof String s`

the model is:


    %4 : java.lang.String = constant @null;
    %5 : Var<java.lang.String> = var %4 @"s";
    %6 : boolean = pattern.match %3
        ()java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> -> {
            %7 : java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> = pattern.binding @"s";
            yield %7;
        }
        (%8 : java.lang.String)void -> {
            var.store %5 %8;
            yield;
        };
    %9 : Var<boolean> = var %6 @"x";


For:

`boolean _ = o instanceof String _`

we could generate:


    %4 : java.lang.String = constant @null;
    %5 : Var<java.lang.String> = var %4;
    %6 : boolean = pattern.match %3
        ()java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> -> {
            %7 : java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> = pattern.binding;
            yield %7;
        }
        (%8 : java.lang.String)void -> {
            var.store %5 %8;
            yield;
        };
    %9 : Var<boolean> = var %6;


When lowering it might be possible to remove unnamed variables, they are never loaded.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1752979908

From mabbay at openjdk.org  Wed Sep 11 02:37:33 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 11 Sep 2024 02:37:33 GMT
Subject: git: openjdk/babylon: code-reflection: Unify common code of
 SwitchStatementOp and SwitchExpressionOp
Message-ID: <721c0bf3-d8fb-4810-aaf5-c44097a01d73@openjdk.org>

Changeset: b8657f4c
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2024-09-11 02:36:10 +0000
URL:       https://git.openjdk.org/babylon/commit/b8657f4c0e408743b749b8e2c2c40e1129f5fc7b

Unify common code of SwitchStatementOp and SwitchExpressionOp

Reviewed-by: psandoz

! src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java


From mabbay at openjdk.org  Wed Sep 11 02:39:15 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 11 Sep 2024 02:39:15 GMT
Subject: [code-reflection] Integrated: Unify common code of SwitchStatementOp
 and SwitchExpressionOp
In-Reply-To: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
References: <ClIogiXyPeynzlvskNilmLR01ZqwfyAQg3k2ETw8z2M=.42321ba7-3904-4415-b6d9-15800b8d4148@github.com>
Message-ID: <aXDyrm0MVFkPUKTlazFtYKEs_XEa8sSya2at1Ft9Hjo=.2a8e7128-4e49-40ad-a9a6-0b9b9a1bfc21@github.com>

On Fri, 6 Sep 2024 04:28:32 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Unify common code of SwitchStatementOp and SwitchExpressionOp.

This pull request has now been integrated.

Changeset: b8657f4c
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/b8657f4c0e408743b749b8e2c2c40e1129f5fc7b
Stats:     277 lines in 1 file changed: 76 ins; 190 del; 11 mod

Unify common code of SwitchStatementOp and SwitchExpressionOp

Reviewed-by: psandoz

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

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

From mabbay at openjdk.org  Wed Sep 11 02:39:18 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 11 Sep 2024 02:39:18 GMT
Subject: git: openjdk/babylon: code-reflection: Avoid boxing when concatenating
 a string with a primitive
Message-ID: <905540c1-a345-4f19-9774-9685581a344b@openjdk.org>

Changeset: 5ffaf946
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2024-09-11 02:37:39 +0000
URL:       https://git.openjdk.org/babylon/commit/5ffaf946c249a74f253b64df77250cad86c66075

Avoid boxing when concatenating a string with a primitive

Reviewed-by: mcimadamore, psandoz

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java
+ test/langtools/tools/javac/reflect/StringConcatTest.java


From mabbay at openjdk.org  Wed Sep 11 02:40:20 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 11 Sep 2024 02:40:20 GMT
Subject: [code-reflection] Integrated: Avoid boxing when concatenating a string
 with a primitive
In-Reply-To: <sBSYyO-DyhQCBWNiMoeqoSB02oajXte4N5frWj1BMkY=.a41345c6-60ba-44ca-a65e-984439cacd73@github.com>
References: <sBSYyO-DyhQCBWNiMoeqoSB02oajXte4N5frWj1BMkY=.a41345c6-60ba-44ca-a65e-984439cacd73@github.com>
Message-ID: <-Rw8T7V3l-Yx3wCoNW6yvIY-ENQXjT3iOH5xBe5dZmE=.9c6a5e02-3fbf-41d5-ba06-f534365f0782@github.com>

On Tue, 10 Sep 2024 03:45:29 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Avoid boxing when concatenating a string with a primitive.

This pull request has now been integrated.

Changeset: 5ffaf946
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/5ffaf946c249a74f253b64df77250cad86c66075
Stats:     68 lines in 2 files changed: 66 ins; 1 del; 1 mod

Avoid boxing when concatenating a string with a primitive

Reviewed-by: mcimadamore, psandoz

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

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

From mabbay at openjdk.org  Wed Sep 11 03:22:41 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 11 Sep 2024 03:22:41 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v3]
In-Reply-To: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
Message-ID: <n9CrpGvWYHu-Qr1pXQ3R2GqgyFsXLSmmrGqjGdlAgYY=.3e1e4c28-a354-4e3b-901c-3a5e7ba1284b@github.com>

> Update the generated code model of pattern matching when pattern variable identifier is "_"

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

  Pass null as binding-name when type pattern variable unnamed

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/227/files
  - new: https://git.openjdk.org/babylon/pull/227/files/17545115..fc6aa507

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

  Stats: 17 lines in 4 files changed: 4 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/babylon/pull/227.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/227/head:pull/227

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

From mabbay at openjdk.org  Wed Sep 11 03:22:41 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 11 Sep 2024 03:22:41 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v2]
In-Reply-To: <Cp74GUA8X9sXiuk_WLMWWpvEs-PPyDxNcIIiFCl1oVE=.16cd95a3-120f-4347-bf44-8b4d51835dd1@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <_gZDKeeX8rs574_c1qCvOIkgGfZcoy-TimcwyUC9224=.18a7b284-b7d4-4cd1-ae9a-70b5cd6890c5@github.com>
 <HSq9xDakTE_Z64WuG6TatHv6axshtV8D7PGW60lpD_Y=.26b5955b-5a18-46a1-8842-68166792925a@github.com>
 <L5NcU9q_CVP9BuRfy4F-ah6c-gqVYdaWv_9r4jP8NQQ=.b265d0c8-65c6-40d8-a27f-9f08ec7bb60f@github.com>
 <zo_BLEV8jXhlXwrjIrlI5J84pDj_OowQA5BcuOb1Iuw=.ddbd08e0-325a-42d4-8b15-b1c571bf6a6c@github.com>
 <_5nnry_Cb5qC0alWHjpRMebQs6BMxyL25h2h5UgBga4=.8633499c-28fb-485d-83de-cda10f560d3f@github.com>
 <HjocgGa_-QuM063jgh28RFos03NU1A_T0fZr-JonqSQ=.5f37fd68-3115-4c50-bdb7-a42e4e9d41b4@github.com>
 <Cp74GUA8X9sXiuk_WLMWWpvEs-PPyDxNcIIiFCl1oVE=.16cd95a3-120f-4347-bf44-8b4d51835dd1@github.com>
Message-ID: <Wwa0UXJM0fHlMiN2n7m8vHJsOWTvzNphUWg-MOjDvhE=.5398cf2f-aa42-41c1-b0b3-87b0cbf24220@github.com>

On Wed, 11 Sep 2024 00:59:30 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Yep - this PR is about a type test pattern whose binding name is left unspecified (`_`). I was observing that unspecified names can occur in many places (method parameters, local var decls, etc.) so we probably need some uniform way to handle with "missing names" ? What I'm objecting to, in this PR, is that we're creating a binding, where the binding name is `_` - which strikes me as incorrect. The name is missing/absent, `_` is just the Java way of denoting missing names.
>
> Right, they are interconnected. I proposed to Mourad we should use `null` to signal no binding/name. The corresponding Var modeling the pattern variable can have `null` for its name, which we can do generally for variables with no name.
> 
> For example for:
> 
> `boolean x = o instanceof String s`
> 
> the model is:
> 
> 
>     %4 : java.lang.String = constant @null;
>     %5 : Var<java.lang.String> = var %4 @"s";
>     %6 : boolean = pattern.match %3
>         ()java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> -> {
>             %7 : java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> = pattern.binding @"s";
>             yield %7;
>         }
>         (%8 : java.lang.String)void -> {
>             var.store %5 %8;
>             yield;
>         };
>     %9 : Var<boolean> = var %6 @"x";
> 
> 
> For:
> 
> `boolean _ = o instanceof String _`
> 
> we could generate:
> 
> 
>     %4 : java.lang.String = constant @null;
>     %5 : Var<java.lang.String> = var %4;
>     %6 : boolean = pattern.match %3
>         ()java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> -> {
>             %7 : java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> = pattern.binding;
>             yield %7;
>         }
>         (%8 : java.lang.String)void -> {
>             var.store %5 %8;
>             yield;
>         };
>     %9 : Var<boolean> = var %6;
> 
> 
> When lowering it might be possible to remove unnamed variables, they are never loaded.

I suggest to not have Var that correspond to unnamed pattern variable

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1753065370

From mabbay at openjdk.org  Wed Sep 11 06:06:26 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 11 Sep 2024 06:06:26 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v4]
In-Reply-To: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
Message-ID: <9mMkO0DCM98OOoiNv8bTTQozBFD0GumfzRThUsWorJs=.c7419e05-3211-4adf-ab07-80de3504e142@github.com>

> Update the generated code model of pattern matching when pattern variable identifier is "_"

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

  Rename BindingPatternOp to TypePatternOp

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/227/files
  - new: https://git.openjdk.org/babylon/pull/227/files/fc6aa507..616e17e7

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

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

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

From asotona at openjdk.org  Wed Sep 11 08:10:22 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Sep 2024 08:10:22 GMT
Subject: [code-reflection] RFR: Bytecode locals compaction [v3]
In-Reply-To: <o5WFoss2NMIqLBDWQM5oubRYwQvFAYRtEOzuGoQ2p2E=.bee9ce88-2a27-4df8-8b57-296b83a0efd7@github.com>
References: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
 <CHAjdrpG-93loWkrfyFl-bpbTbwP8ARuR2kilJiI8tY=.b39ce312-4652-4029-aeee-7ada4696f192@github.com>
 <o5WFoss2NMIqLBDWQM5oubRYwQvFAYRtEOzuGoQ2p2E=.bee9ce88-2a27-4df8-8b57-296b83a0efd7@github.com>
Message-ID: <PC-gw7JOIwPFkSOITnYPLobOnaPu34vW9g0Z_LsbWqU=.00439d90-3458-4038-9d1d-1b6b79401326@github.com>

On Tue, 10 Sep 2024 22:53:36 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added comments
>
> src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 355:
> 
>> 353:     // Some of the operations can be deferred
>> 354:     private boolean canDefer(Op op) {
>> 355:         Boolean can = deferCache.get(op);
> 
> Use `computeIfAbsent`?

Unfortunately `computeIfAbsent` throws `ConcurrentModificationException` in this case. This method is not usable when the computation causes more additions to the map.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/224#discussion_r1753518849

From asotona at openjdk.org  Wed Sep 11 08:18:56 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Sep 2024 08:18:56 GMT
Subject: [code-reflection] RFR: Bytecode locals compaction [v4]
In-Reply-To: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
References: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
Message-ID: <e5jO2sMHy9YXDVU3tT5q7whEBVwXWbz7na4zqyTJllM=.e118e8bc-e39d-4df0-a52a-782cadc7677a@github.com>

> `LocalsCompactor` is a bytecode transformation reducing generated method `maxLocals` by re-using local slots.
> Roundtrip of lift and bytecode generation doubles the `maxLocals` value, while `LocalsCompactor` reduces the regression by 50%.
> 
> Lifting of compacted locals revealed bugs in `LocalsTypeMapper` variables graph construction. This patch includes significantly  refactored `LocalsTypeMapper` to support lifting of compacted locals.
> 
> `BytecodeGenerator` has slightly improved performance (so `TestSmallCorpus` finishes in a reasonable time). However performance has not been main focus of this PR.
> 
> `TestSmallCorpus` has been slightly refactored to provide better debugging feedback and compaction statistics. Overall stability is still >99%.
> 
> Please review.
> 
> Thanks,
> Adam

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

  Removed oboslete lookup argument.

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/224/files
  - new: https://git.openjdk.org/babylon/pull/224/files/cadb3669..015b1c7f

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

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

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

From asotona at openjdk.org  Wed Sep 11 08:18:57 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Sep 2024 08:18:57 GMT
Subject: [code-reflection] RFR: Bytecode locals compaction [v3]
In-Reply-To: <o5WFoss2NMIqLBDWQM5oubRYwQvFAYRtEOzuGoQ2p2E=.bee9ce88-2a27-4df8-8b57-296b83a0efd7@github.com>
References: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
 <CHAjdrpG-93loWkrfyFl-bpbTbwP8ARuR2kilJiI8tY=.b39ce312-4652-4029-aeee-7ada4696f192@github.com>
 <o5WFoss2NMIqLBDWQM5oubRYwQvFAYRtEOzuGoQ2p2E=.bee9ce88-2a27-4df8-8b57-296b83a0efd7@github.com>
Message-ID: <GVHONflBMy1-2ap18TOgJx_9Nhe2fZ32Zg9y560ZVno=.e36c641a-4a70-4226-a144-d0d18e945c82@github.com>

On Tue, 10 Sep 2024 23:28:09 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Once you reach a stable point it will be very useful to describe the approach.

Yes, absolutely.

Thank you!

> src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeLift.java line 275:
> 
>> 273:     }
>> 274: 
>> 275:     public static CoreOp.FuncOp lift(MethodModel methodModel, MethodHandles.Lookup lookup) {
> 
> Place the lookup as the first parameter, like for the bytecode generator and the interpreter

Oh, this is leftover from an experiment. I'll remove it, the lookup is not needed.

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

PR Comment: https://git.openjdk.org/babylon/pull/224#issuecomment-2342964168
PR Review Comment: https://git.openjdk.org/babylon/pull/224#discussion_r1753532848

From asotona at openjdk.org  Wed Sep 11 08:32:59 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Sep 2024 08:32:59 GMT
Subject: [code-reflection] RFR: Bytecode locals compaction [v5]
In-Reply-To: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
References: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
Message-ID: <DRA8oHFkEKibfvR2zJpspefpbMhZCZZG_glWTLSCVI0=.92d518ff-cc84-4a4f-a1b4-c87faff3de93@github.com>

> `LocalsCompactor` is a bytecode transformation reducing generated method `maxLocals` by re-using local slots.
> Roundtrip of lift and bytecode generation doubles the `maxLocals` value, while `LocalsCompactor` reduces the regression by 50%.
> 
> Lifting of compacted locals revealed bugs in `LocalsTypeMapper` variables graph construction. This patch includes significantly  refactored `LocalsTypeMapper` to support lifting of compacted locals.
> 
> `BytecodeGenerator` has slightly improved performance (so `TestSmallCorpus` finishes in a reasonable time). However performance has not been main focus of this PR.
> 
> `TestSmallCorpus` has been slightly refactored to provide better debugging feedback and compaction statistics. Overall stability is still >99%.
> 
> Please review.
> 
> Thanks,
> Adam

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

  minor cleanup

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/224/files
  - new: https://git.openjdk.org/babylon/pull/224/files/015b1c7f..0989c963

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

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

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

From asotona at openjdk.org  Wed Sep 11 08:46:14 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Sep 2024 08:46:14 GMT
Subject: git: openjdk/babylon: code-reflection: Bytecode locals compaction
Message-ID: <80e1649e-174b-4150-92e0-bac8c55f432c@openjdk.org>

Changeset: 15e8b6e4
Branch: code-reflection
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-09-11 08:43:52 +0000
URL:       https://git.openjdk.org/babylon/commit/15e8b6e48a1c799f420583d69988e822fb047164

Bytecode locals compaction

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/LocalsCompactor.java
! src/java.base/share/classes/java/lang/reflect/code/bytecode/LocalsTypeMapper.java
! test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java


From asotona at openjdk.org  Wed Sep 11 08:46:38 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Sep 2024 08:46:38 GMT
Subject: [code-reflection] RFR: Bytecode locals compaction [v6]
In-Reply-To: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
References: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
Message-ID: <vi7UGPL_jvEgjqKX70bq6r1cnGLrC6ZOsfbPcvyoD2s=.fc0fbc47-40f4-4240-ac1f-23fb5952c0af@github.com>

> `LocalsCompactor` is a bytecode transformation reducing generated method `maxLocals` by re-using local slots.
> Roundtrip of lift and bytecode generation doubles the `maxLocals` value, while `LocalsCompactor` reduces the regression by 50%.
> 
> Lifting of compacted locals revealed bugs in `LocalsTypeMapper` variables graph construction. This patch includes significantly  refactored `LocalsTypeMapper` to support lifting of compacted locals.
> 
> `BytecodeGenerator` has slightly improved performance (so `TestSmallCorpus` finishes in a reasonable time). However performance has not been main focus of this PR.
> 
> `TestSmallCorpus` has been slightly refactored to provide better debugging feedback and compaction statistics. Overall stability is still >99%.
> 
> Please review.
> 
> Thanks,
> Adam

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

  fixed typo

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/224/files
  - new: https://git.openjdk.org/babylon/pull/224/files/0989c963..32938a98

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

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

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

From asotona at openjdk.org  Wed Sep 11 08:46:38 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Sep 2024 08:46:38 GMT
Subject: [code-reflection] Integrated: Bytecode locals compaction
In-Reply-To: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
References: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
Message-ID: <ca3sWDhAZE0ea94VPKHqo8vF_BdVssTeB5lWHhaK9Xo=.8f4b6ab8-450b-4bda-a192-d9f9cfb0506e@github.com>

On Mon, 9 Sep 2024 17:35:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> `LocalsCompactor` is a bytecode transformation reducing generated method `maxLocals` by re-using local slots.
> Roundtrip of lift and bytecode generation doubles the `maxLocals` value, while `LocalsCompactor` reduces the regression by 50%.
> 
> Lifting of compacted locals revealed bugs in `LocalsTypeMapper` variables graph construction. This patch includes significantly  refactored `LocalsTypeMapper` to support lifting of compacted locals.
> 
> `BytecodeGenerator` has slightly improved performance (so `TestSmallCorpus` finishes in a reasonable time). However performance has not been main focus of this PR.
> 
> `TestSmallCorpus` has been slightly refactored to provide better debugging feedback and compaction statistics. Overall stability is still >99%.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 15e8b6e4
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/15e8b6e48a1c799f420583d69988e822fb047164
Stats:     684 lines in 5 files changed: 483 ins; 102 del; 99 mod

Bytecode locals compaction

Reviewed-by: psandoz

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

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

From psandoz at openjdk.org  Wed Sep 11 15:07:24 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 11 Sep 2024 15:07:24 GMT
Subject: [code-reflection] RFR: Bytecode locals compaction [v3]
In-Reply-To: <PC-gw7JOIwPFkSOITnYPLobOnaPu34vW9g0Z_LsbWqU=.00439d90-3458-4038-9d1d-1b6b79401326@github.com>
References: <gjKuGC3k_Cw3MMi7EEICWa0xlu-DxIdy502z4U-2TeI=.b09643fa-65b6-4224-9b1c-1801470779cc@github.com>
 <CHAjdrpG-93loWkrfyFl-bpbTbwP8ARuR2kilJiI8tY=.b39ce312-4652-4029-aeee-7ada4696f192@github.com>
 <o5WFoss2NMIqLBDWQM5oubRYwQvFAYRtEOzuGoQ2p2E=.bee9ce88-2a27-4df8-8b57-296b83a0efd7@github.com>
 <PC-gw7JOIwPFkSOITnYPLobOnaPu34vW9g0Z_LsbWqU=.00439d90-3458-4038-9d1d-1b6b79401326@github.com>
Message-ID: <M5x5wMcfJTWZAB0WTDmYe3jrAz_wAqLyLbY6NBCHzj8=.25edbeeb-4cbe-4622-89e8-bc1307739ddd@github.com>

On Wed, 11 Sep 2024 08:07:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeGenerator.java line 355:
>> 
>>> 353:     // Some of the operations can be deferred
>>> 354:     private boolean canDefer(Op op) {
>>> 355:         Boolean can = deferCache.get(op);
>> 
>> Use `computeIfAbsent`?
>
> Unfortunately `computeIfAbsent` throws `ConcurrentModificationException` in this case. This method is not usable when the computation causes more additions to the map.

Ah of course, its recursive.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/224#discussion_r1754877042

From psandoz at openjdk.org  Wed Sep 11 15:14:19 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 11 Sep 2024 15:14:19 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v2]
In-Reply-To: <Wwa0UXJM0fHlMiN2n7m8vHJsOWTvzNphUWg-MOjDvhE=.5398cf2f-aa42-41c1-b0b3-87b0cbf24220@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <_gZDKeeX8rs574_c1qCvOIkgGfZcoy-TimcwyUC9224=.18a7b284-b7d4-4cd1-ae9a-70b5cd6890c5@github.com>
 <HSq9xDakTE_Z64WuG6TatHv6axshtV8D7PGW60lpD_Y=.26b5955b-5a18-46a1-8842-68166792925a@github.com>
 <L5NcU9q_CVP9BuRfy4F-ah6c-gqVYdaWv_9r4jP8NQQ=.b265d0c8-65c6-40d8-a27f-9f08ec7bb60f@github.com>
 <zo_BLEV8jXhlXwrjIrlI5J84pDj_OowQA5BcuOb1Iuw=.ddbd08e0-325a-42d4-8b15-b1c571bf6a6c@github.com>
 <_5nnry_Cb5qC0alWHjpRMebQs6BMxyL25h2h5UgBga4=.8633499c-28fb-485d-83de-cda10f560d3f@github.com>
 <HjocgGa_-QuM063jgh28RFos03NU1A_T0fZr-JonqSQ=.5f37fd68-3115-4c50-bdb7-a42e4e9d41b4@github.com>
 <Cp74GUA8X9sXiuk_WLMWWpvEs-PPyDxNcIIiFCl1oVE=.16cd95a3-120f-4347-bf44-8b4d51835dd1@github.com>
 <Wwa0UXJM0fHlMiN2n7m8vHJsOWTvzNphUWg-MOjDvhE=.5398cf2f-aa42-41c1-b0b3-87b0cbf24220@github.com>
Message-ID: <JELO8TUMLowfMegXWUC6iyDWiA2MVnQCQqlAU9JIHjU=.0835085b-78ae-4c6c-9b05-fe09a6f64429@github.com>

On Wed, 11 Sep 2024 03:19:06 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Right, they are interconnected. I proposed to Mourad we should use `null` to signal no binding/name. The corresponding Var modeling the pattern variable can have `null` for its name, which we can do generally for variables with no name.
>> 
>> For example for:
>> 
>> `boolean x = o instanceof String s`
>> 
>> the model is:
>> 
>> 
>>     %4 : java.lang.String = constant @null;
>>     %5 : Var<java.lang.String> = var %4 @"s";
>>     %6 : boolean = pattern.match %3
>>         ()java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> -> {
>>             %7 : java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> = pattern.binding @"s";
>>             yield %7;
>>         }
>>         (%8 : java.lang.String)void -> {
>>             var.store %5 %8;
>>             yield;
>>         };
>>     %9 : Var<boolean> = var %6 @"x";
>> 
>> 
>> For:
>> 
>> `boolean _ = o instanceof String _`
>> 
>> we could generate:
>> 
>> 
>>     %4 : java.lang.String = constant @null;
>>     %5 : Var<java.lang.String> = var %4;
>>     %6 : boolean = pattern.match %3
>>         ()java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> -> {
>>             %7 : java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> = pattern.binding;
>>             yield %7;
>>         }
>>         (%8 : java.lang.String)void -> {
>>             var.store %5 %8;
>>             yield;
>>         };
>>     %9 : Var<boolean> = var %6;
>> 
>> 
>> When lowering it might be possible to remove unnamed variables, they are never loaded.
>
> I suggest to not have Var that correspond to unnamed pattern variable

That's another option, but a likely a more complicated change. Perhaps consider that when you get to support record patterns like `R(_)` as there may be stronger motivation to do so?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1754900428

From psandoz at openjdk.org  Wed Sep 11 18:58:41 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 11 Sep 2024 18:58:41 GMT
Subject: [code-reflection] RFR: Invocation to vararg methods [v3]
In-Reply-To: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
References: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
Message-ID: <VfJwMyWC60-cx-aDVjGaI_oj8NfqXe9nD2OE-rK2-NI=.d9969b1c-9f4f-486b-81c7-03669f5c6ec8@github.com>

> Re-consolidate to one invocation operation that explicitly declares its invoke kind and whether it is an invocation to a varargs method.
> 
> Resolution of a method reference accepts an invoke kind. The ambiguity when resolving a method reference without an invoke kind has been cleared up, in these cases we can only resolve to a direct method, one in which the referencing class is the class that declares the method.
> 
> I managed to avoid numerous changes to update the text models in language tests. Creating an invoke operation from external form is permissive in the attributes that are present. It makes the same assumptions as the invoke factory method in determining the invocation kind from the argument count and invoke descriptor count, and assumes the method is not a varargs method (the common case).

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

 - Merge remote-tracking branch 'upstream/code-reflection' into varargs
 - Comments.
 - Undo edits.
 - Avoid generating attributes
 - Invocation to vararg methods.

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/225/files
  - new: https://git.openjdk.org/babylon/pull/225/files/762488fe..7ff659b4

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

  Stats: 1029 lines in 8 files changed: 625 ins; 293 del; 111 mod
  Patch: https://git.openjdk.org/babylon/pull/225.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/225/head:pull/225

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

From mabbay at openjdk.org  Thu Sep 12 03:31:48 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 12 Sep 2024 03:31:48 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v5]
In-Reply-To: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
Message-ID: <dGXLb4H6Jm0NTLgIlWq8C-QQ24BGxKL-RNWJR2l7AoM=.2efdd5b9-aec5-469b-9da3-784b0c6f7151@github.com>

> Update the generated code model of pattern matching when pattern variable identifier is "_"

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

  Keep Var that correspond to unnamed pattern variable

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/227/files
  - new: https://git.openjdk.org/babylon/pull/227/files/616e17e7..fd979437

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

  Stats: 163 lines in 4 files changed: 19 ins; 3 del; 141 mod
  Patch: https://git.openjdk.org/babylon/pull/227.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/227/head:pull/227

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

From mabbay at openjdk.org  Thu Sep 12 07:00:47 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 12 Sep 2024 07:00:47 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v6]
In-Reply-To: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
Message-ID: <KubSeuzT8ox1574rJ8hj1x-gKaf7r88p7KugHJLoZOs=.60ab6c70-7144-4cec-ab44-4d8ba0302f0d@github.com>

> Update the generated code model of pattern matching when pattern variable identifier is "_"

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

  Update the result type of TypePatternOp

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/227/files
  - new: https://git.openjdk.org/babylon/pull/227/files/fd979437..6e240c23

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

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

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

From mabbay at openjdk.org  Thu Sep 12 07:57:50 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 12 Sep 2024 07:57:50 GMT
Subject: [code-reflection] RFR: Support match all pattern
Message-ID: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>

Support match all pattern.
This PR is based on [227](https://github.com/openjdk/babylon/pull/227).

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

Commit messages:
 - Support match all pattern for non-generic records
 - Update the result type of TypePatternOp
 - Keep Var that correspond to unnamed pattern variable
 - Rename BindingPatternOp to TypePatternOp
 - Pass null as binding-name when type pattern variable unnamed
 - Update effected tests
 - Update the model of pattern matching when pattern variable identifier is "_"

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

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

From psandoz at openjdk.org  Thu Sep 12 16:20:20 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 12 Sep 2024 16:20:20 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v6]
In-Reply-To: <KubSeuzT8ox1574rJ8hj1x-gKaf7r88p7KugHJLoZOs=.60ab6c70-7144-4cec-ab44-4d8ba0302f0d@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <KubSeuzT8ox1574rJ8hj1x-gKaf7r88p7KugHJLoZOs=.60ab6c70-7144-4cec-ab44-4d8ba0302f0d@github.com>
Message-ID: <6jZZLfmcCac9S52g1VaXQWvZi1LWpqxzc4GbT7CMfTE=.600c610f-654c-41f1-9132-b4a224bda44c@github.com>

On Thu, 12 Sep 2024 07:00:47 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Update the generated code model of pattern matching when pattern variable identifier is "_"
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the result type of TypePatternOp

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

> 2169:             super(NAME, List.of(init));
> 2170: 
> 2171:             this.varName = varName == null || varName.isEmpty() ? null : varName;

Was there is a reason why you check for an empty string?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1757192828

From gfrost at openjdk.org  Thu Sep 12 16:32:08 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 12 Sep 2024 16:32:08 GMT
Subject: git: openjdk/babylon: code-reflection: Hat fixes to support chess
Message-ID: <b4f74e55-a652-44a0-bd94-586b8903a163@openjdk.org>

Changeset: 5265d256
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-09-12 16:30:20 +0000
URL:       https://git.openjdk.org/babylon/commit/5265d256c675a6876e3362ea4a316955dba3fa15

Hat fixes to support chess

! hat/docs/hat-03-programming-model.md
! hat/docs/hat-06-kernel-analysis.md
! hat/docs/hat-notes-and-links.md
! hat/examples/experiments/src/main/java/experiments/Chess.java
- hat/examples/life/DEMO.html
! hat/hat/src/main/java/hat/optools/FieldLoadOpWrapper.java
! hat/hatrun.bash
! hat/intellij/.idea/modules.xml
+ hat/intellij/chess.iml


From gfrost at openjdk.org  Thu Sep 12 16:33:55 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 12 Sep 2024 16:33:55 GMT
Subject: [code-reflection] Integrated: Hat fixes to support chess
Message-ID: <bOsg4yFnYwtfxbHnZJ_7rl4mO5_DPu2rgofgyewzFAk=.e38da881-4223-4feb-9428-bb5310e79fea@github.com>

Mainly some doc updates and the changes to support JVML demos. 

We added the start of the HAT chess engine here.  It is not ready to be pulled into this tree yet.

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

Commit messages:
 - Doc changes and infra to support JVMLS demos and chess
 - Doc changes and infra to support JVMLS demos and chess

Changes: https://git.openjdk.org/babylon/pull/231/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=231&range=00
  Stats: 294 lines in 9 files changed: 27 ins; 248 del; 19 mod
  Patch: https://git.openjdk.org/babylon/pull/231.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/231/head:pull/231

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

From gfrost at openjdk.org  Thu Sep 12 16:33:56 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 12 Sep 2024 16:33:56 GMT
Subject: [code-reflection] Integrated: Hat fixes to support chess
In-Reply-To: <bOsg4yFnYwtfxbHnZJ_7rl4mO5_DPu2rgofgyewzFAk=.e38da881-4223-4feb-9428-bb5310e79fea@github.com>
References: <bOsg4yFnYwtfxbHnZJ_7rl4mO5_DPu2rgofgyewzFAk=.e38da881-4223-4feb-9428-bb5310e79fea@github.com>
Message-ID: <1EWtBcfQJJaRDMdqlwMT3yKQ8pV8hYT-zs5oEL8VwXw=.f6f7f5e9-1f5d-4e26-8f38-c51ec413bd6a@github.com>

On Thu, 12 Sep 2024 16:28:21 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Mainly some doc updates and the changes to support JVML demos. 
> 
> We added the start of the HAT chess engine here.  It is not ready to be pulled into this tree yet.

This pull request has now been integrated.

Changeset: 5265d256
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/5265d256c675a6876e3362ea4a316955dba3fa15
Stats:     294 lines in 9 files changed: 27 ins; 248 del; 19 mod

Hat fixes to support chess

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

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

From psandoz at openjdk.org  Thu Sep 12 16:50:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 12 Sep 2024 16:50:17 GMT
Subject: [code-reflection] RFR: Support match all pattern
In-Reply-To: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
References: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
Message-ID: <c2iB5w0Epw6m2ZapSePNY63XnivC4LSpe4WithbXAlE=.d34ea955-3e0a-4c58-82d0-8c1f85fa3e29@github.com>

On Thu, 12 Sep 2024 07:52:28 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Support match all pattern.
> This PR is based on [227](https://github.com/openjdk/babylon/pull/227).

I think you should model as an explicit op, `match.all`, that encapsulates the type (in effect the upper bound). If you reuse `pattern.type` op then a type test (instance of check) will be generated when lowering. Instead, when lowering a `match.all` we can just add the target value to the list of bindings and return the current block.

When this PR is completed we can step back and decide how to manage bindings to unnamed variables.

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

PR Review: https://git.openjdk.org/babylon/pull/230#pullrequestreview-2300890382

From sdohrmann at openjdk.org  Thu Sep 12 22:52:40 2024
From: sdohrmann at openjdk.org (Steve Dohrmann)
Date: Thu, 12 Sep 2024 22:52:40 GMT
Subject: [code-reflection] RFR: Implementation of a HAT Spirv backend
Message-ID: <FfGTMsL7dvSDFSIzwPxrxVf4EhW5UrmjHUuOZO6wjvA=.5c002e46-64b9-4e34-aa84-d5624bcb58f1@github.com>

## A HAT SPIR-V backend 

Implements an initial version of a HAT SPIR-V backend. It extends JavaBackend and includes no native code. It is complete enough to run the HAT Mandel example and some other simple examples.  It lacks generalized data structure support and so will not yet run, e.g., the BlackScholes or ViolaJones examples.

The backend currently only supports Linux and requires an Intel GPU to run.  Examples of compatible Intel GPU hardware are:

  * Integrated Intel GPU such as:
    * Iris Xe or UHD graphics in 11th generation or later CPUs (Rocket Lake, Alder Lake, Raptor Lake, ...) 
    * Arc graphics available with the latest CPUs, e.g., Meteor Lake
  * Discrete Intel GPU such as Arc 580, 750, 770
    * these are available on Amazon, search, e.g., "Intel Arc 580" or "Intel Arc 770"

Linux drivers for the above hardware have been included in some major Linux distros (e.g. Ubuntu) in time corresponding to the release of the hardware.  Drivers for the discrete Arc cards are included in, e.g., Ubuntu 23.10.  Ubuntu drivers for Arc discrete GPUs can also be downloaded separately.  See https://www.intel.com/content/www/us/en/download/747008/intel-arc-graphics-driver-ubuntu.html 

## Dependencies
Software-wise, the backend has several dependencies outside of the Babylon repo:

	1. The Intel Level Zero library, a low level native library used to access the GPU
	2. A Java binding to the Level Zero library, generated using the OpenJDK jextract tool
	3. The Beehive Labs Java SPIR-V toolkit, used to construct a SPIR-V binary module

Currently these dependencies are not automatically built.  Below is information on how to build and install the three items above.


### Intel Level Zero library 

A build-levelzero.sh script is included in the hat/backends/spirv/scripts directory.  Superuser privileges may be required when running this script.  Execute the script with the scripts directory as the current directory:

cd backends/spirv/scripts
sh build-level-zero.sh

This will build and install the Level Zero ze_loader.so to /usr/local/lib.  This path must be include in java.library.path or LD_LIBRARY_PATH when running using the spirv backend.

### OpenJDK jextract tool and generated binding to Level Zero

An early-access binary of the jextract tool can be found at: 

	https://jdk.java.net/jextract/

- expand the archive 
- set a JEXTRACT_DIR environment variable to point at the jextract directory.

A generate-level-zero-binding.sh script is included in the hat/backends/spirv/scripts directory.  The script will reference the JEXTRACT_DIR variable set earlier.  Execute the script with the scripts directory as the current directory:


cd backends/spirv/scripts
sh generate-level-zero-binding.sh


This will generate a Java FFM-based binding to LevelZero, as levelzero.jar, and install the jar in your local Maven repo to satisfy a Maven dependency in the spirv backend pom file.  This jar must be on the Java classpath when running using the spirv backend.


### Beehive Labs Java SPIR-V toolkit

A build-beehive-spirv-toolkit.sh script is included in the hat/backends/spirv/scripts directory.   Note that this project will not currently compile with the babylon JDK, please temporarily set your JAVA_HOME to JDK 22.  Execute the script with the scripts directory as the current directory:


cd backends/spirv/scripts
export JAVA_HOME = <path to JDK 22>
sh build-beehive-spirv-toolkit.sh


This will build a beehive_spirv_lib.0.0.4.jar and install it in your local maven repo to satisfy a Maven dependency in the spirv backend pom file.  This jar must be on the Java classpath when running the spirv backend.

## Note:

These three dependencies (Level Zero library, Level Zero Java binding, Beehive SPIR-V Toolkit) must be built and installed prior to building and using the 'spirv' backend.  Because these dependencies are not yet built automatically, the spirv backend is current not built by default.  To enable building and use of the spirv backend, after manually running these scripts, change one line of the 'modules' section in hat/backends/pom.xml:


<modules>
     <module>opencl</module>
     <module>cuda</module>
     <module>mock</module>
     <module>ptx</module>
     
</modules>


to: 


<modules>
     <module>opencl</module>
     <module>cuda</module>
     <module>mock</module>
     <module>ptx</module>
     <module>spirv</module>
</modules>

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

Commit messages:
 - bug fixes, scripts copy jars now
 - Implementation of a HAT Spirv backend

Changes: https://git.openjdk.org/babylon/pull/229/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=229&range=00
  Stats: 3095 lines in 15 files changed: 3052 ins; 26 del; 17 mod
  Patch: https://git.openjdk.org/babylon/pull/229.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/229/head:pull/229

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

From asotona at openjdk.org  Fri Sep 13 11:23:33 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 13 Sep 2024 11:23:33 GMT
Subject: [code-reflection] RFR: Bytecode cleanup, renames and javadoc
Message-ID: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>

This PR introduces only minimal functional changes, it is mainly focused on the bytecode package cleanup and documentation.

Any comments and suggestions are welcome.

Thanks,
Adam

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

Commit messages:
 - javadoc fix
 - minor refactoring + javadoc
 - javadoc format change
 - Renames + javadoc
 - Renames + javadoc
 - removed debug code
 - LocalsTypeMapper refactored and detached from BytecodeLift
 - table fix
 - fixed MD table
 - typo
 - ... and 1 more: https://git.openjdk.org/babylon/compare/15e8b6e4...547e7782

Changes: https://git.openjdk.org/babylon/pull/228/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=228&range=00
  Stats: 1640 lines in 4 files changed: 955 ins; 659 del; 26 mod
  Patch: https://git.openjdk.org/babylon/pull/228.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/228/head:pull/228

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

From asotona at openjdk.org  Fri Sep 13 11:28:50 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 13 Sep 2024 11:28:50 GMT
Subject: [code-reflection] RFR: Bytecode cleanup, renames and javadoc [v2]
In-Reply-To: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
References: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
Message-ID: <wgUHB-dng-tsUoBZlkkAydUH9XOuAkPdG7KqsTDh3Fo=.94d834b2-0940-4ff7-b2cc-e3c1edec4492@github.com>

> This PR introduces only minimal functional changes, it is mainly focused on the bytecode package cleanup and documentation.
> 
> Any comments and suggestions are welcome.
> 
> Thanks,
> Adam

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

  javadoc fix

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/228/files
  - new: https://git.openjdk.org/babylon/pull/228/files/547e7782..0b9be550

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

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

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

From asotona at openjdk.org  Fri Sep 13 15:26:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 13 Sep 2024 15:26:19 GMT
Subject: [code-reflection] RFR: Bytecode cleanup, renames and javadoc [v3]
In-Reply-To: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
References: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
Message-ID: <AN1lGCM9MVKTVmvDkvUEwxcii8eZsDz1KtN2FMjb-_0=.38372489-a758-4440-9610-648e2e4082f6@github.com>

> This PR introduces only minimal functional changes, it is mainly focused on the bytecode package cleanup and documentation.
> 
> Any comments and suggestions are welcome.
> 
> Thanks,
> Adam

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

  BytecodeGenerator optimized for BinaryTestOp comparing with 0 or null + BytecodeLift minor fix

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/228/files
  - new: https://git.openjdk.org/babylon/pull/228/files/0b9be550..62fbbd19

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

  Stats: 105 lines in 2 files changed: 68 ins; 27 del; 10 mod
  Patch: https://git.openjdk.org/babylon/pull/228.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/228/head:pull/228

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

From asotona at openjdk.org  Fri Sep 13 16:00:36 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 13 Sep 2024 16:00:36 GMT
Subject: [code-reflection] RFR: Bytecode cleanup, renames and javadoc [v4]
In-Reply-To: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
References: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
Message-ID: <jTqqWdlIsyPcCiTE-7vocV1RE2fHYBSvURtUANKqkLk=.5ff72bc5-2ec1-45db-b767-074b44c92c74@github.com>

> This PR introduces only minimal functional changes, it is mainly focused on the bytecode package cleanup and documentation.
> 
> Any comments and suggestions are welcome.
> 
> Thanks,
> Adam

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

  added more statistics to TestSmallCorpus

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/228/files
  - new: https://git.openjdk.org/babylon/pull/228/files/62fbbd19..052ae605

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

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

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

From rotanolexandr842 at gmail.com  Fri Sep 13 21:44:12 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Sat, 14 Sep 2024 00:44:12 +0300
Subject: Feedback on Code Reflection API
Message-ID: <CAL5bRt_5swCKNdudrbK1nkMdpuU-Mt=u+bF3KEmAMMhrBMY5Wg@mail.gmail.com>

Hello to everyone on the mailing list. I would love to share some feedback
with you regarding the Code Reflection API used to implement LINQ in java.

Unfortunately, I found myself in the situation where I don't have much time
to work on a project and probably will not have it in the
foreseeable future, so I will have to speak based on limited
experience using the API. Firstly, I will talk about the problems I
encountered, then mark some positive features and finish with general
thoughts on the direction of the project and jdk in general.

The problems started earlier than expected, particularly on extending the
Quotable interface. When I just built jdk from Babylon and created a new
project, the quoted() method, to my surprise, has been throwing
UnsupportedOperationException. I spent multiple hours trying to figure out
whats wrong, unit finally I stumbled onto following rows in babylon repo:

A subset of code in java.base is copied with package renaming into the
jdk.compiler module.

This gave me a hint to add "requires jdk.compiler" to module-info, and it
finally worked! I am not sure if this is how it intended to work, but if
so, this topic could use more clarification.

Moving to API itself, there are a few points I would like to address. I
would like to emphasize that I am speaking as a person that builds API to
reach out from one high-level language to another, so my feedback is
obviously biased. That said, I found an API containing too many low level
details.I didn't even get to know what is dominatedBy and other methods
related to this "domination". The difference between body and block is also
not clear, I didn't find a case during work on a project where the body
just had one block.

Naming could also use some improvement. Specifically, the uses() method,
due to word meaning both that it uses something and that it is used by
something is unclear to me. capturedValues() name also was really
misleading to me, since it seems like it should return a map of values of
expressions inside the OP, while it, as I understand, just includes some
part underlying ops. It also is really similar to capturedValues() of
LambdaOp which in fact contains captured values. AAnd just generally,
having VarAccessOp to contain its captured value would be really helpful
since it would spare from passing down Map of captured values through a
long chain of methods.

I also did not find a particular use for the transform method. I initially
thought it could be used to translate a tree into another language tree,
but it instead transforms op into another op. I'm not sure if it replaces
one node with another (which would make the tree mutable), or if it just
produces a new one and then I don't really know what's the use of it.

Lastly, what was particularly strange is the fact that composite condition
ops do not contain their operands and are not in their operands() method,
but instead in bodies() method. Not sure if its intended, but for me it was
extremely counterintuitive.


Now let's talk about positive sides. Generally, I really liked that API is
(if all low-level methods are ignored), pretty simple yet powerful. I
managed to get everything that I required using just a few simple methods
like operands(), resolveTOHandle(), result() and other once situatively. By
the way, talking about result(), I didn't find a case where it returns
something other than Op.Result, and I guess for many op types result()
return type could be narrowed.

I also found it really pleasant that Quotable is implemented by default, so
I don't have to do any additional steps to start working with
Quotable-extending interfaces. Though, it would be really helpful if
java.util.function interfaces can become Quotable (unless there is a
conversion between equivalent functional interfaces), so LINQ and other
querying apis could become interchangeable with streams.


And lastly, a few thoughts about the general direction of Babylon
development. I am obviously biased, but I found the API too low level. I
would also argue that most of the use cases for java developers will
interact with code reflection api would involve reaching out to other
high-level languages, so it would make sense to make api a little more
abstracted. Generally speaking, the jdk approach to "shoot in the middle"
seems wrong to me. Generally, some particular use case takes up like 95% of
demand for features. This is not particularly the case here, but
accumulatively high-level languages would be, I guess, the most
common target. Currently, on the other hand, API aims at middle-level
languages (if those even exist), and lowering tree is used for low-level
interactions. I would argue that non-lowered API should aim for high level
languages, while lowered for low level. Middle-level models could be
produced as a high level tree + some details from a lowered one.

That's all for now. I hope in future I could spare some more time and
contribute something more than currently, maybe providing feedback also on
API evolution.

PS: github repo if you are interested: https://github.com/Evemose/linq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20240914/0df8b6ca/attachment-0001.htm>

From paul.sandoz at oracle.com  Fri Sep 13 23:38:28 2024
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 13 Sep 2024 23:38:28 +0000
Subject: Feedback on Code Reflection API
In-Reply-To: <CAL5bRt_5swCKNdudrbK1nkMdpuU-Mt=u+bF3KEmAMMhrBMY5Wg@mail.gmail.com>
References: <CAL5bRt_5swCKNdudrbK1nkMdpuU-Mt=u+bF3KEmAMMhrBMY5Wg@mail.gmail.com>
Message-ID: <3522A073-3365-4F00-A663-DEA7A86D7DBA@oracle.com>

Hi Olexandr,

Thank you for the feedback. Some comments in line below.

Paul.


> On Sep 13, 2024, at 2:44 PM, Olexandr Rotan <rotanolexandr842 at gmail.com> wrote:
> 
> Hello to everyone on the mailing list. I would love to share some feedback with you regarding the Code Reflection API used to implement LINQ in java.
> 
> Unfortunately, I found myself in the situation where I don't have much time to work on a project and probably will not have it in the foreseeable future, so I will have to speak based on limited experience using the API.

Ok, appreciate the time you have spent.


> Firstly, I will talk about the problems I encountered, then mark some positive features and finish with general thoughts on the direction of the project and jdk in general.
> 
> The problems started earlier than expected, particularly on extending the Quotable interface. When I just built jdk from Babylon and created a new project, the quoted() method, to my surprise, has been throwing UnsupportedOperationException. I spent multiple hours trying to figure out whats wrong, unit finally I stumbled onto following rows in babylon repo:
> 
> A subset of code in java.base is copied with package renaming into the jdk.compiler module.
> 
> This gave me a hint to add "requires jdk.compiler" to module-info, and it finally worked! I am not sure if this is how it intended to work, but if so, this topic could use more clarification.
> 

That?s odd. At runtime you should not need to require the jdk.compiler module or the java.compiler you declared here:

  https://github.com/Evemose/linq/blob/master/src/main/java/module-info.java#L2

I successfully compiled your project with that declaration removed.

The API in java.base is copied into an *internal* in the JDK compiler. This is because parts of the compiler cannot depend on new APIs in java.base, since the compiler compiles itself. We are working around that limitation by copying code. Perhaps it is possible to overcome it, but we have not investigated.
  

> Moving to API itself, there are a few points I would like to address. I would like to emphasize that I am speaking as a person that builds API to reach out from one high-level language to another, so my feedback is obviously biased. That said, I found an API containing too many low level details.I didn't even get to know what is dominatedBy and other methods related to this "domination".

Yes, that is understandable. Better documentation will I hope help, and similarly to your points on method naming below. There are features for code analysis and transformation that compilers/transformers will leverage, but not all these features are relevant to all use cases.


> The difference between body and block is also not clear, I didn't find a case during work on a project where the body just had one block. 
> 

Did or did not? The source compiler will produce a code model where each body has just one (entry) block, which is intentional. Lowering that model (a transformation) will produce a new model with one body and many blocks, interconnected to form a control flow graph. In your case, mapping to SQL I would expect you could keep at the higher-level, and likely are only dealing with Java expressions where control flow is commonly more limited to conditional expressions (although you can now include switch expressions too!).

Conceptually you can think of a code model body encapsulating some structural unit of code. The code model produced by the compiler approximately mirrors the structure in source in the arrangement of operations and their bodies. But, if you are expecting a more traditional AST representation you may be disappointed and frustrated :-) The whole area of how we model Java code is not yet documented.


> Naming could also use some improvement. Specifically, the uses() method, due to word meaning both that it uses something and that it is used by something is unclear to me.

Good point.


> capturedValues() name also was really misleading to me, since it seems like it should return a map of values of expressions inside the OP, while it, as I understand, just includes some part underlying ops. It also is really similar to capturedValues() of LambdaOp which in fact contains captured values.

Yes, it?s fundamentally the same concept in a code model but I can see how ?capture" can be misleading from a Java language perspective. A captured value in this sense is a value that is declared before an operation, O say, (it dominates the operation) but used by operations within *descendent bodies* (if any) of O. Perhaps we can find a better name to describe this.


> AAnd just generally, having VarAccessOp to contain its captured value would be really helpful since it would spare from passing down Map of captured values through a long chain of methods.
> 

A VarAccessOp does not capture any value. It *uses* a value as an operand, and the value?s type is a variable type, and commonly the result of a Var operation. Given such a (variable) value you can query it's uses to find all the loads and stores to that variable.


> I also did not find a particular use for the transform method. I initially thought it could be used to translate a tree into another language tree, but it instead transforms op into another op. I'm not sure if it replaces one node with another (which would make the tree mutable), or if it just produces a new one and then I don't really know what's the use of it.

This transformation API is code model in and code model out. It?s a functional flat-map transformation that composes traversing the input model and building the output model, that works with immutable code models. It does not make sense to use it when transforming a code model to some other in-memory representation. In that case you can traverse the model explicitly.

 
> 
> Lastly, what was particularly strange is the fact that composite condition ops do not contain their operands and are not in their operands() method, but instead in bodies() method. Not sure if its intended, but for me it was extremely counterintuitive.

Yes, it is intended. Such high-level operations have nested bodies, each corresponding to structured units of code that may or may not be executed based on the control flow rules of the language construct the operation models. Lowering such operations will collapse the bodies into an interconnected set of basic blocks forming a control flow graph (see slides 30 to 35 here https://cr.openjdk.org/~psandoz/conferences/2023-JVMLS/Code-Reflection-JVMLS-23-08-07.pdf).

Hopefully you might be able to guess how many bodies the for operation modeling a for statement might have :-)


> 
> 
> Now let's talk about positive sides. Generally, I really liked that API is (if all low-level methods are ignored), pretty simple yet powerful. I managed to get everything that I required using just a few simple methods like operands(), resolveTOHandle(), result() and other once situatively. By the way, talking about result(), I didn't find a case where it returns something other than Op.Result, and I guess for many op types result() return type could be narrowed.

I don?t understand your last sentence. Can you explain more? (The method Op::result returns a type of Op.Result). Perhaps you are referring to Op:operands returning List<Value>?


> 
> I also found it really pleasant that Quotable is implemented by default, so I don't have to do any additional steps to start working with Quotable-extending interfaces. Though, it would be really helpful if java.util.function interfaces can become Quotable (unless there is a conversion between equivalent functional interfaces), so LINQ and other querying apis could become interchangeable with streams.
> 

Yeah, that?s a challenge we also have with Serializable. We will not retrofit the existing functional interfaces to be Quotable. Reflecting over code requires permission to do so. Note in general I think we will likely make Quotable a marker interface and one will appeal to some reflection API to obtain the quoted instance.


> 
> And lastly, a few thoughts about the general direction of Babylon development. I am obviously biased, but I found the API too low level. I would also argue that most of the use cases for java developers will interact with code reflection api would involve reaching out to other high-level languages, so it would make sense to make api a little more abstracted. Generally speaking, the jdk approach to "shoot in the middle" seems wrong to me. Generally, some particular use case takes up like 95% of demand for features. This is not particularly the case here, but accumulatively high-level languages would be, I guess, the most common target. Currently, on the other hand, API aims at middle-level languages (if those even exist), and lowering tree is used for low-level interactions. I would argue that non-lowered API should aim for high level languages, while lowered for low level. Middle-level models could be produced as a high level tree + some details from a lowered one.
> 

Note that we have successfully managed to transform high-level models to C code (OpenCL C and CUDA C), or to high-level ASTs for graph query expressions in the spoofax framework. (We want to explore an ONNX script use case when we get the time). The code model at a high-level contains enough structural information to do this, but there could be some additional help (e.g., like indicating the precedence of Java operators or extracting expressions, see https://openjdk.org/projects/babylon/articles/code-models).

There are potentially many use cases at various levels of representation. The challenge we set ourselves is to see if we can devise a single representation that is applicable to many cases.


> That's all for now. I hope in future I could spare some more time and contribute something more than currently, maybe providing feedback also on API evolution. 
> 
> PS: github repo if you are interested: https://github.com/Evemose/linq


I hope so! I shall take a closer look at your code.


From rotanolexandr842 at gmail.com  Sat Sep 14 09:04:02 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Sat, 14 Sep 2024 12:04:02 +0300
Subject: Feedback on Code Reflection API
In-Reply-To: <3522A073-3365-4F00-A663-DEA7A86D7DBA@oracle.com>
References: <CAL5bRt_5swCKNdudrbK1nkMdpuU-Mt=u+bF3KEmAMMhrBMY5Wg@mail.gmail.com>
 <3522A073-3365-4F00-A663-DEA7A86D7DBA@oracle.com>
Message-ID: <CAL5bRt9DVdo_tVwVRJ-17QuOYjq16--9VN=RPHGkGDK7wudZWg@mail.gmail.com>

Hi! I really failed to articulate some points well enough yesterday. So,
let me make some of the statements more clear, along with some thoughts on
your response.


That?s odd. At runtime you should not need to require the jdk.compiler
> module or the java.compiler you declared here

https://github.com/Evemose/linq/blob/master/src/main/java/module-info.java#L2
>

I successfully compiled your project with that declaration removed.


I also found it really strange, but it at least worked. If it helps in any
way, I built jdk from this commit:
https://github.com/openjdk/babylon/commit/bf2ee69c0e14d78b207c51cf96aaaf95a7d7aa83


> The difference between body and block is also not clear, I didn't find a
> case during work on a project where the body just had one block.
> >
> Did or did not? The source compiler will produce a code model where each
> body has just one (entry) block, which is intentional. Lowering that model
> (a transformation) will produce a new model with one body and many blocks,
> interconnected to form a control flow graph. In your case, mapping to SQL I
> would expect you could keep at the higher-level, and likely are only
> dealing with Java expressions where control flow is commonly more limited
> to conditional expressions (although you can now include switch expressions
> too!).


That's what I was missing. Every time I reached into bodies (which most of
the time was when parsing composite condition ops ), I just did
bodies().blocks().getFirst() and was wondering if there is any use case
where there are more than one block.

Yes, it?s fundamentally the same concept in a code model but I can see how
> ?capture" can be misleading from a Java language perspective. A captured
> value in this sense is a value that is declared before an operation, O say,
> (it dominates the operation) but used by operations within *descendent
> bodies* (if any) of O. Perhaps we can find a better name to describe this.


That's what I was wondering. There is nothing inherently wrong with this
naming, it just feels like it clashes definitions of "capture" from two
relatively distant subject areas. I am speaking as a person whose most
robust interaction with bytecode instructions was bubble sort in asm, so I
understand how some of my statements could be barbaric to people who are
much more experienced than me in this area. I am just speaking on behalf of
less immersed into bytecode users, who just want API to sound the way they
used to.

 Lastly, what was particularly strange is the fact that composite condition
> ops do not contain their operands and are not in their operands() method,
> but instead in bodies() method. Not sure if its intended, but for me it was
> extremely counterintuitive.

Yes, it is intended. Such high-level operations have nested bodies, each
> corresponding to structured units of code that may or may not be executed
> based on the control flow rules of the language construct the operation
> models.


Once again, I just fell for my own ignorance. Although, I guess there will
be plenty of people like me wondering where the operands went :), so I
guess it would be worth of @apiNote in docs when they are here.

A VarAccessOp does not capture any value. It *uses* a value as an operand,
> and the value?s type is a variable type, and commonly the result of a Var
> operation.


I guess I have yet to learn captures and uses in cod models. Nevertheless,
while I am not saying that it makes any sense from a bytecode perspective,
it would be nice quality-of-life improvement to be able to just have
something like Object currentValue() or something like this, even if
internally it just receives its value from the parent that captured it.

I don?t understand your last sentence. Can you explain more? (The method
> Op::result returns a type of Op.Result). Perhaps you are referring to
> Op:operands returning List<Value>?


My bad. Haven't opened IDe with this project for roughly a week, some
details already have been gone from my mind. Yes, I am indeed talking about
the operands() method, which returns a list of Value. If you look into my
codebase, you will notice that every time I encounter Value, I just cast it
to Op.Result. Maybe I just haven't found the correct case yet, but
currently there has not been a single time when Value wasn't Op.Result.
Maybe I just didn't work with Ops that have such operands, or
Block.Parameter only present in a lowered model, but for now cast to
Op.Result never failed me.

Yeah, that?s a challenge we also have with Serializable. We will not
> retrofit the existing functional interfaces to be Quotable. Reflecting over
> code requires permission to do so.


Well, that's a shame. To my case specifically some times, when operation in
unmappable to sql, I plan to load chunks of data into memory using some
kind of prefetching persistent spliterator, which effectively makes API
work the same as streams the moment data is loaded in memory, and it would
be really nice to have them be interchangeable. I guess this problem might
eventually be solved by itself in Valhalla when there will finally be a
discussion on making IntStream and Stream<int> interchangeable, which will
require some sort of implicit conversion of functional interfaces. There
are of course a million problems to it, especially for stateful interfaces,
but that's another rant.

Note that we have successfully managed to transform high-level models to C
> code (OpenCL C and CUDA C), or to high-level ASTs for graph query
> expressions in the spoofax framework.


It was my intention to make feedback subjective here. I completely
understand that, most likely, a person who reaches out to, lets say, OpenCL
API most likely would consider me insane with all this "i didn't use this,
I didn't need that". That's why I think that it's important to not try
to be objective, but provide a subjective opinion and let people who get
tons of those opinions every day deduct objective one. That said, I would
argue that there are plenty of subjective opinions that would benefit from
some high-level representation, but it may be just my bubble.

And a few points that I forgot to put in a last mail:

!. That is not particularly required for my use case, but it may be good to
have some visitors (or their more modern alternatives like Jsoup API), for
tasks that aim to analyze code, not translate it. For example, the
assertion library that one of the mail list members presented a while ago,
I think, would benefit very much from something like this.
2. Limited bytecode auditing. I, honestly, not sure that it falls under
scope of this project, but it would be really nice to have some simple
auditing mechanisms that allow, for example, knowing the position from
which method is invoked (similar features are present in .Net as far as I
remember, in Java there is bytebuddy but it is always a few weeks late to
release because they have to adapt to bytecode updates in the new java
version). The use case for this example is particular in translating one
model to another. I noticed (which is pretty intuitive) that one chain of
method calls always produces the same template of request, only changes are
observed in variable values, so it would be nice to cache templates by
invocation point after the first request and then just fill in values in
these templates.

I hope now some of my points have become clearer to you. Hope some of my
feedback will be helpful for determining direction of project

Best regards

On Sat, Sep 14, 2024 at 2:38?AM Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Olexandr,
>
> Thank you for the feedback. Some comments in line below.
>
> Paul.
>
>
> > On Sep 13, 2024, at 2:44 PM, Olexandr Rotan <rotanolexandr842 at gmail.com>
> wrote:
> >
> > Hello to everyone on the mailing list. I would love to share some
> feedback with you regarding the Code Reflection API used to implement LINQ
> in java.
> >
> > Unfortunately, I found myself in the situation where I don't have much
> time to work on a project and probably will not have it in the foreseeable
> future, so I will have to speak based on limited experience using the API.
>
> Ok, appreciate the time you have spent.
>
>
> > Firstly, I will talk about the problems I encountered, then mark some
> positive features and finish with general thoughts on the direction of the
> project and jdk in general.
> >
> > The problems started earlier than expected, particularly on extending
> the Quotable interface. When I just built jdk from Babylon and created a
> new project, the quoted() method, to my surprise, has been throwing
> UnsupportedOperationException. I spent multiple hours trying to figure out
> whats wrong, unit finally I stumbled onto following rows in babylon repo:
> >
> > A subset of code in java.base is copied with package renaming into the
> jdk.compiler module.
> >
> > This gave me a hint to add "requires jdk.compiler" to module-info, and
> it finally worked! I am not sure if this is how it intended to work, but if
> so, this topic could use more clarification.
> >
>
> That?s odd. At runtime you should not need to require the jdk.compiler
> module or the java.compiler you declared here:
>
>
> https://github.com/Evemose/linq/blob/master/src/main/java/module-info.java#L2
>
> I successfully compiled your project with that declaration removed.
>
> The API in java.base is copied into an *internal* in the JDK compiler.
> This is because parts of the compiler cannot depend on new APIs in
> java.base, since the compiler compiles itself. We are working around that
> limitation by copying code. Perhaps it is possible to overcome it, but we
> have not investigated.
>
>
> > Moving to API itself, there are a few points I would like to address. I
> would like to emphasize that I am speaking as a person that builds API to
> reach out from one high-level language to another, so my feedback is
> obviously biased. That said, I found an API containing too many low level
> details.I didn't even get to know what is dominatedBy and other methods
> related to this "domination".
>
> Yes, that is understandable. Better documentation will I hope help, and
> similarly to your points on method naming below. There are features for
> code analysis and transformation that compilers/transformers will leverage,
> but not all these features are relevant to all use cases.
>
>
> > The difference between body and block is also not clear, I didn't find a
> case during work on a project where the body just had one block.
> >
>
> Did or did not? The source compiler will produce a code model where each
> body has just one (entry) block, which is intentional. Lowering that model
> (a transformation) will produce a new model with one body and many blocks,
> interconnected to form a control flow graph. In your case, mapping to SQL I
> would expect you could keep at the higher-level, and likely are only
> dealing with Java expressions where control flow is commonly more limited
> to conditional expressions (although you can now include switch expressions
> too!).
>
> Conceptually you can think of a code model body encapsulating some
> structural unit of code. The code model produced by the compiler
> approximately mirrors the structure in source in the arrangement of
> operations and their bodies. But, if you are expecting a more traditional
> AST representation you may be disappointed and frustrated :-) The whole
> area of how we model Java code is not yet documented.
>
>
> > Naming could also use some improvement. Specifically, the uses() method,
> due to word meaning both that it uses something and that it is used by
> something is unclear to me.
>
> Good point.
>
>
> > capturedValues() name also was really misleading to me, since it seems
> like it should return a map of values of expressions inside the OP, while
> it, as I understand, just includes some part underlying ops. It also is
> really similar to capturedValues() of LambdaOp which in fact contains
> captured values.
>
> Yes, it?s fundamentally the same concept in a code model but I can see how
> ?capture" can be misleading from a Java language perspective. A captured
> value in this sense is a value that is declared before an operation, O say,
> (it dominates the operation) but used by operations within *descendent
> bodies* (if any) of O. Perhaps we can find a better name to describe this.
>
>
> > AAnd just generally, having VarAccessOp to contain its captured value
> would be really helpful since it would spare from passing down Map of
> captured values through a long chain of methods.
> >
>
> A VarAccessOp does not capture any value. It *uses* a value as an operand,
> and the value?s type is a variable type, and commonly the result of a Var
> operation. Given such a (variable) value you can query it's uses to find
> all the loads and stores to that variable.
>
>
> > I also did not find a particular use for the transform method. I
> initially thought it could be used to translate a tree into another
> language tree, but it instead transforms op into another op. I'm not sure
> if it replaces one node with another (which would make the tree mutable),
> or if it just produces a new one and then I don't really know what's the
> use of it.
>
> This transformation API is code model in and code model out. It?s a
> functional flat-map transformation that composes traversing the input model
> and building the output model, that works with immutable code models. It
> does not make sense to use it when transforming a code model to some other
> in-memory representation. In that case you can traverse the model
> explicitly.
>
>
> >
> > Lastly, what was particularly strange is the fact that composite
> condition ops do not contain their operands and are not in their operands()
> method, but instead in bodies() method. Not sure if its intended, but for
> me it was extremely counterintuitive.
>
> Yes, it is intended. Such high-level operations have nested bodies, each
> corresponding to structured units of code that may or may not be executed
> based on the control flow rules of the language construct the operation
> models. Lowering such operations will collapse the bodies into an
> interconnected set of basic blocks forming a control flow graph (see slides
> 30 to 35 here
> https://cr.openjdk.org/~psandoz/conferences/2023-JVMLS/Code-Reflection-JVMLS-23-08-07.pdf
> ).
>
> Hopefully you might be able to guess how many bodies the for operation
> modeling a for statement might have :-)
>
>
> >
> >
> > Now let's talk about positive sides. Generally, I really liked that API
> is (if all low-level methods are ignored), pretty simple yet powerful. I
> managed to get everything that I required using just a few simple methods
> like operands(), resolveTOHandle(), result() and other once situatively. By
> the way, talking about result(), I didn't find a case where it returns
> something other than Op.Result, and I guess for many op types result()
> return type could be narrowed.
>
> I don?t understand your last sentence. Can you explain more? (The method
> Op::result returns a type of Op.Result). Perhaps you are referring to
> Op:operands returning List<Value>?
>
>
> >
> > I also found it really pleasant that Quotable is implemented by default,
> so I don't have to do any additional steps to start working with
> Quotable-extending interfaces. Though, it would be really helpful if
> java.util.function interfaces can become Quotable (unless there is a
> conversion between equivalent functional interfaces), so LINQ and other
> querying apis could become interchangeable with streams.
> >
>
> Yeah, that?s a challenge we also have with Serializable. We will not
> retrofit the existing functional interfaces to be Quotable. Reflecting over
> code requires permission to do so. Note in general I think we will likely
> make Quotable a marker interface and one will appeal to some reflection API
> to obtain the quoted instance.
>
>
> >
> > And lastly, a few thoughts about the general direction of Babylon
> development. I am obviously biased, but I found the API too low level. I
> would also argue that most of the use cases for java developers will
> interact with code reflection api would involve reaching out to other
> high-level languages, so it would make sense to make api a little more
> abstracted. Generally speaking, the jdk approach to "shoot in the middle"
> seems wrong to me. Generally, some particular use case takes up like 95% of
> demand for features. This is not particularly the case here, but
> accumulatively high-level languages would be, I guess, the most common
> target. Currently, on the other hand, API aims at middle-level languages
> (if those even exist), and lowering tree is used for low-level
> interactions. I would argue that non-lowered API should aim for high level
> languages, while lowered for low level. Middle-level models could be
> produced as a high level tree + some details from a lowered one.
> >
>
> Note that we have successfully managed to transform high-level models to C
> code (OpenCL C and CUDA C), or to high-level ASTs for graph query
> expressions in the spoofax framework. (We want to explore an ONNX script
> use case when we get the time). The code model at a high-level contains
> enough structural information to do this, but there could be some
> additional help (e.g., like indicating the precedence of Java operators or
> extracting expressions, see
> https://openjdk.org/projects/babylon/articles/code-models).
>
> There are potentially many use cases at various levels of representation.
> The challenge we set ourselves is to see if we can devise a single
> representation that is applicable to many cases.
>
>
> > That's all for now. I hope in future I could spare some more time and
> contribute something more than currently, maybe providing feedback also on
> API evolution.
> >
> > PS: github repo if you are interested: https://github.com/Evemose/linq
>
>
> I hope so! I shall take a closer look at your code.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20240914/0147c988/attachment-0001.htm>

From mabbay at openjdk.org  Sun Sep 15 04:25:17 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Sun, 15 Sep 2024 04:25:17 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v6]
In-Reply-To: <6jZZLfmcCac9S52g1VaXQWvZi1LWpqxzc4GbT7CMfTE=.600c610f-654c-41f1-9132-b4a224bda44c@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <KubSeuzT8ox1574rJ8hj1x-gKaf7r88p7KugHJLoZOs=.60ab6c70-7144-4cec-ab44-4d8ba0302f0d@github.com>
 <6jZZLfmcCac9S52g1VaXQWvZi1LWpqxzc4GbT7CMfTE=.600c610f-654c-41f1-9132-b4a224bda44c@github.com>
Message-ID: <No1avxFD90Us0zl64KAQlVagylJ-ydt_dxVkkSA3hgk=.39b95a69-3a4e-4773-9ae1-096a503e3c77@github.com>

On Thu, 12 Sep 2024 16:18:00 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update the result type of TypePatternOp
>
> src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 2171:
> 
>> 2169:             super(NAME, List.of(init));
>> 2170: 
>> 2171:             this.varName = varName == null || varName.isEmpty() ? null : varName;
> 
> Was there is a reason why you check for an empty string?

The compiler code may pass an empty string for the name of the Var, e.g. unnamed pattern variable.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1759961222

From mabbay at openjdk.org  Mon Sep 16 07:48:04 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 16 Sep 2024 07:48:04 GMT
Subject: [code-reflection] RFR: Support match all pattern [v2]
In-Reply-To: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
References: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
Message-ID: <cxJtRDTaLGrUtecyuHGGWWRIfGnNooxnOyg5lgngNMY=.b9e25ed4-0094-4c8f-a478-c45102af6c88@github.com>

> Support match all pattern.
> This PR is based on [227](https://github.com/openjdk/babylon/pull/227).

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

 - Simplify test of match all pattern
 - Update modeling of match all pattern

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/230/files
  - new: https://git.openjdk.org/babylon/pull/230/files/f4247001..cbe28059

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

  Stats: 78 lines in 4 files changed: 56 ins; 8 del; 14 mod
  Patch: https://git.openjdk.org/babylon/pull/230.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/230/head:pull/230

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

From mabbay at openjdk.org  Mon Sep 16 07:48:04 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 16 Sep 2024 07:48:04 GMT
Subject: [code-reflection] RFR: Support match all pattern
In-Reply-To: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
References: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
Message-ID: <cosYsnHQSvvLIUTwaQ-Bln7c4oei6sVKckj2FN1Wr1I=.8963e0ee-6981-4d4f-a801-184ad206d0bc@github.com>

On Thu, 12 Sep 2024 07:52:28 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Support match all pattern.
> This PR is based on [227](https://github.com/openjdk/babylon/pull/227).

MatchAllPatternOp doesn't have any attribute because I don't see the reason why we need to encapsulate component upper bound.

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

PR Comment: https://git.openjdk.org/babylon/pull/230#issuecomment-2352219225

From mabbay at openjdk.org  Mon Sep 16 07:50:17 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Mon, 16 Sep 2024 07:50:17 GMT
Subject: [code-reflection] RFR: Support match all pattern
In-Reply-To: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
References: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
Message-ID: <3ywSt7RO9z9uXBq-PP7MUssXJlSseefpaPyY_9EVOkI=.6db3de1f-90f5-4843-bef2-c69ee8437834@github.com>

On Thu, 12 Sep 2024 07:52:28 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Support match all pattern.
> This PR is based on [227](https://github.com/openjdk/babylon/pull/227).

To lower MatchAllPatternOp, we don't need to do anything, we just skip it, there are no bindings.

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

PR Comment: https://git.openjdk.org/babylon/pull/230#issuecomment-2352223175

From asotona at openjdk.org  Mon Sep 16 13:44:35 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 16 Sep 2024 13:44:35 GMT
Subject: [code-reflection] RFR: Bytecode cleanup, renames and javadoc [v5]
In-Reply-To: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
References: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
Message-ID: <rl0HFwbREsJFH39bFQpgkZ3nCUm4EulShlOBJgHMMEM=.a2e5163c-d7f3-469b-808f-fa3a9557f629@github.com>

> This PR introduces only minimal functional changes, it is mainly focused on the bytecode package cleanup and documentation.
> 
> Any comments and suggestions are welcome.
> 
> Thanks,
> Adam

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

  fixed lifting of INVOKESPECIAL + TestSmallCorpus skipping when UnsupportedOperationException

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/228/files
  - new: https://git.openjdk.org/babylon/pull/228/files/052ae605..c5291987

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

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

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

From psandoz at openjdk.org  Mon Sep 16 17:13:20 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 16 Sep 2024 17:13:20 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v6]
In-Reply-To: <No1avxFD90Us0zl64KAQlVagylJ-ydt_dxVkkSA3hgk=.39b95a69-3a4e-4773-9ae1-096a503e3c77@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <KubSeuzT8ox1574rJ8hj1x-gKaf7r88p7KugHJLoZOs=.60ab6c70-7144-4cec-ab44-4d8ba0302f0d@github.com>
 <6jZZLfmcCac9S52g1VaXQWvZi1LWpqxzc4GbT7CMfTE=.600c610f-654c-41f1-9132-b4a224bda44c@github.com>
 <No1avxFD90Us0zl64KAQlVagylJ-ydt_dxVkkSA3hgk=.39b95a69-3a4e-4773-9ae1-096a503e3c77@github.com>
Message-ID: <WAY3lKew3WIUSPn8eW7hFOxwgkYuZL2DL18_mSc14d4=.c5d9f502-47fc-46b7-8efa-b3954a91cae0@github.com>

On Sun, 15 Sep 2024 04:22:58 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java line 2171:
>> 
>>> 2169:             super(NAME, List.of(init));
>>> 2170: 
>>> 2171:             this.varName = varName == null || varName.isEmpty() ? null : varName;
>> 
>> Was there is a reason why you check for an empty string?
>
> The compiler code may pass an empty string for the name of the Var, e.g. unnamed pattern variable.

I think we should address that. Up to you if you wanna fix that in this PR or do it in a follow on PR.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1761537750

From psandoz at openjdk.org  Mon Sep 16 19:48:18 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 16 Sep 2024 19:48:18 GMT
Subject: [code-reflection] RFR: Support match all pattern [v2]
In-Reply-To: <cxJtRDTaLGrUtecyuHGGWWRIfGnNooxnOyg5lgngNMY=.b9e25ed4-0094-4c8f-a478-c45102af6c88@github.com>
References: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
 <cxJtRDTaLGrUtecyuHGGWWRIfGnNooxnOyg5lgngNMY=.b9e25ed4-0094-4c8f-a478-c45102af6c88@github.com>
Message-ID: <QbBVK_sQ-ukBgCRCvqGWSjJPBivNmxRLL5ZSlrD3su4=.2d11c7c0-617f-4694-8b34-4f7177ad120f@github.com>

On Mon, 16 Sep 2024 07:48:04 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Support match all pattern.
>> This PR is based on [227](https://github.com/openjdk/babylon/pull/227).
>
> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Simplify test of match all pattern
>  - Update modeling of match all pattern

src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 2922:

> 2920:         }
> 2921: 
> 2922:         static JavaType MatchAllType() {

Suggestion:

        static JavaType matchAllType() {

src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 3114:

> 3112:             public static MatchAllPatternOp create(ExternalizedOp def) {
> 3113:                 return new MatchAllPatternOp(def);
> 3114:             }

You don't need this method, the op factory can use `ExternalizedOp` constructor, just make it pubic.

I think we may be able to merge the `create` methods and the constructor when we can use flexible constructor bodies ([JEP 482](https://openjdk.org/jeps/482)).

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

PR Review Comment: https://git.openjdk.org/babylon/pull/230#discussion_r1761769704
PR Review Comment: https://git.openjdk.org/babylon/pull/230#discussion_r1761776149

From psandoz at openjdk.org  Mon Sep 16 20:03:19 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 16 Sep 2024 20:03:19 GMT
Subject: [code-reflection] RFR: Support match all pattern
In-Reply-To: <3ywSt7RO9z9uXBq-PP7MUssXJlSseefpaPyY_9EVOkI=.6db3de1f-90f5-4843-bef2-c69ee8437834@github.com>
References: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
 <3ywSt7RO9z9uXBq-PP7MUssXJlSseefpaPyY_9EVOkI=.6db3de1f-90f5-4843-bef2-c69ee8437834@github.com>
Message-ID: <_aQTvp_vVgdUfffgzenKxABYy0DDsIPE6eXDvg8uru8=.65698b31-ad77-471f-997d-ac2e0431ac27@github.com>

On Mon, 16 Sep 2024 07:47:21 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> To lower MatchAllPatternOp, we don't need to do anything, we just skip it, there are no bindings.

It's not that simple :-)

The JLS states [here](https://docs.oracle.com/javase/specs/jls/se22/html/jls-14.html#jls-14.30.1):

Let R be the type of the record pattern r, and let T be the type of the corresponding component field in R 
([?8.10.3](https://docs.oracle.com/javase/specs/jls/se22/html/jls-8.html#jls-8.10.3)). The type of the match-all 
pattern is the upward projection of T with respect to all synthetic type variables mentioned by T.


A record's component still needs to be accessed - its result is not bound to a named variable. e.g., consider:

    record R(Number s) {
        public Number s() {
            if (s instanceof Integer) {
                throw new IllegalArgumentException();
            }
            return s;
        }
    }

    R r = new R(1);
    if (r instanceof R(_)) {
        System.out.println("");
    }


The JLS states [here](https://docs.oracle.com/javase/specs/jls/se22/html/jls-14.html#jls-14.30.2):

A value v that is not the null reference matches a record pattern with type R and component pattern list L if (i) v can be 
converted by testing conversion ([?5.7](https://docs.oracle.com/javase/specs/jls/se22/html/jls-5.html#jls-5.7)) to the target 
type R without raising a ClassCastException; and (ii) each record component of v matches the corresponding component 
pattern in L; and does not match otherwise.

Each record component of v is determined by invoking the accessor method of v corresponding to that component. If 
execution of the invocation of the accessor method completes abruptly for reason S, then pattern matching completes 
abruptly by throwing a MatchException with cause S.

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

PR Comment: https://git.openjdk.org/babylon/pull/230#issuecomment-2353804076

From mabbay at openjdk.org  Tue Sep 17 02:19:16 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 17 Sep 2024 02:19:16 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v6]
In-Reply-To: <WAY3lKew3WIUSPn8eW7hFOxwgkYuZL2DL18_mSc14d4=.c5d9f502-47fc-46b7-8efa-b3954a91cae0@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <KubSeuzT8ox1574rJ8hj1x-gKaf7r88p7KugHJLoZOs=.60ab6c70-7144-4cec-ab44-4d8ba0302f0d@github.com>
 <6jZZLfmcCac9S52g1VaXQWvZi1LWpqxzc4GbT7CMfTE=.600c610f-654c-41f1-9132-b4a224bda44c@github.com>
 <No1avxFD90Us0zl64KAQlVagylJ-ydt_dxVkkSA3hgk=.39b95a69-3a4e-4773-9ae1-096a503e3c77@github.com>
 <WAY3lKew3WIUSPn8eW7hFOxwgkYuZL2DL18_mSc14d4=.c5d9f502-47fc-46b7-8efa-b3954a91cae0@github.com>
Message-ID: <Irp8iX-EcsiutZKTaS5-6hZYmAM09g9g1ZmKvOLAb78=.3440936e-49be-45c2-b3b0-ff08bd5ff65e@github.com>

On Mon, 16 Sep 2024 17:10:51 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> The compiler code may pass an empty string for the name of the Var, e.g. unnamed pattern variable.
>
> I think we should address that. Up to you if you wanna fix that in this PR or do it in a follow on PR.

I think it's better to address it in a follow PR.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1762183471

From mabbay at openjdk.org  Tue Sep 17 02:50:53 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 17 Sep 2024 02:50:53 GMT
Subject: [code-reflection] RFR: Support match all pattern [v3]
In-Reply-To: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
References: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
Message-ID: <QD3znrrhElTyYe0T4wvwNqG0axEzD3LzJjgAjO3a1po=.279e4da4-05d2-412f-a85d-58663b4b9524@github.com>

> Support match all pattern.
> This PR is based on [227](https://github.com/openjdk/babylon/pull/227).

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

  Apply suggestions

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/230/files
  - new: https://git.openjdk.org/babylon/pull/230/files/cbe28059..8313eb59

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

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

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

From asotona at openjdk.org  Tue Sep 17 07:30:51 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 17 Sep 2024 07:30:51 GMT
Subject: [code-reflection] RFR: Include boolean in primitive type conversions.
Message-ID: <BizffAPYQ-qvtj8By-YvcH83mMj9x1wp7qULXMPqeqw=.3e37ec87-6009-48a1-ac20-8bd8d37ee62e@github.com>

There is a big difference in `boolean` role in JLS and JVMS. While in JLS it is not allowed to cast between `boolean` and other primitive numeric types (obviously because it is not  a numeric type). On the other side in the bytecode it is very hard to differentiate between `byte`, `boolean`, `short`, `char` and `int`. `BytecodeLift` actually inserts an explicit `ConvOp` in the situations where the sub-int type detection failed and it needs to by adjusted on the fly. Explicit `ConvOp` works for conversions between primitive numeric types according to JLS, however `Interpreter` fails on `ConvOp` from and to booleans. `BytecodeGenerator` accepts such conversions (as Class-File API also directly supports conversions between all primitive types, see `CodeBuilder::conversion`).

I'm proposing to add `boolean` into the matrix of supported types for `ConvOp`.

Please review.

Thanks,
Adam

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

Commit messages:
 - Include boolean in primitive type conversions.

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

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

From gfrost at openjdk.org  Tue Sep 17 10:27:32 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 17 Sep 2024 10:27:32 GMT
Subject: git: openjdk/babylon: code-reflection: Updated babylon and hat build
 docs
Message-ID: <ac7559d2-5e88-42f7-8ad7-13857ab970fb@openjdk.org>

Changeset: cf3e9c9a
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-09-17 10:26:45 +0000
URL:       https://git.openjdk.org/babylon/commit/cf3e9c9a79ffe4f39bc3ca9d23d912cecad1f803

Updated babylon and hat build docs

! hat/README.md
! hat/docs/hat-00.md
! hat/docs/hat-01-01-project-layout.md
! hat/docs/hat-01-02-building-babylon.md
+ hat/docs/hat-01-03-building-hat.md
- hat/docs/hat-01-03-maven-cmake.md
! hat/docs/hat-01-04-intellij.md
! hat/docs/hat-03-programming-model.md
! hat/docs/hat-04-01-interface-mapping.md
! hat/docs/hat-04-02-cascade-interface-mapping.md
! hat/docs/hat-05-accelerator-compute.md
! hat/docs/hat-06-kernel-analysis.md
! hat/docs/hat-notes-and-links.md
! hat/intellij/.idea/vcs.xml


From gfrost at openjdk.org  Tue Sep 17 10:30:08 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 17 Sep 2024 10:30:08 GMT
Subject: [code-reflection] Integrated: Updated babylon and hat build docs
Message-ID: <M-7gH0-ULlZ5Y2zHtMRK33WuOiACZveIczRDfxs96FM=.ec7e5ffe-50be-4a38-9e8f-7dd65392b11a@github.com>

Updated markdown docs for building babylon and hat

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

Commit messages:
 - Updated babylon and hat build docs

Changes: https://git.openjdk.org/babylon/pull/233/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=233&range=00
  Stats: 361 lines in 14 files changed: 195 ins; 138 del; 28 mod
  Patch: https://git.openjdk.org/babylon/pull/233.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/233/head:pull/233

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

From gfrost at openjdk.org  Tue Sep 17 10:30:08 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Tue, 17 Sep 2024 10:30:08 GMT
Subject: [code-reflection] Integrated: Updated babylon and hat build docs
In-Reply-To: <M-7gH0-ULlZ5Y2zHtMRK33WuOiACZveIczRDfxs96FM=.ec7e5ffe-50be-4a38-9e8f-7dd65392b11a@github.com>
References: <M-7gH0-ULlZ5Y2zHtMRK33WuOiACZveIczRDfxs96FM=.ec7e5ffe-50be-4a38-9e8f-7dd65392b11a@github.com>
Message-ID: <xKdAQdDSN2eEnsFaC4JsqducYFkUvICH9jIhk1zqFIM=.e18b8c38-3b0c-4067-9855-2d008407b761@github.com>

On Tue, 17 Sep 2024 10:24:40 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Updated markdown docs for building babylon and hat

This pull request has now been integrated.

Changeset: cf3e9c9a
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/cf3e9c9a79ffe4f39bc3ca9d23d912cecad1f803
Stats:     361 lines in 14 files changed: 195 ins; 138 del; 28 mod

Updated babylon and hat build docs

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

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

From psandoz at openjdk.org  Tue Sep 17 17:10:19 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 17 Sep 2024 17:10:19 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v6]
In-Reply-To: <KubSeuzT8ox1574rJ8hj1x-gKaf7r88p7KugHJLoZOs=.60ab6c70-7144-4cec-ab44-4d8ba0302f0d@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <KubSeuzT8ox1574rJ8hj1x-gKaf7r88p7KugHJLoZOs=.60ab6c70-7144-4cec-ab44-4d8ba0302f0d@github.com>
Message-ID: <c4qLCGgw_F-dzVcu9B9neZWxVqus3p2Q2DisuqhRWzQ=.d0d5b3aa-50e3-42ae-9389-5d8d9bd294b2@github.com>

On Thu, 12 Sep 2024 07:00:47 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Update the generated code model of pattern matching when pattern variable identifier is "_"
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the result type of TypePatternOp

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/227#pullrequestreview-2310343147

From psandoz at openjdk.org  Tue Sep 17 17:10:19 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 17 Sep 2024 17:10:19 GMT
Subject: [code-reflection] RFR: Update the model of pattern matching when
 pattern variable identifier is underscore [v6]
In-Reply-To: <Irp8iX-EcsiutZKTaS5-6hZYmAM09g9g1ZmKvOLAb78=.3440936e-49be-45c2-b3b0-ff08bd5ff65e@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
 <KubSeuzT8ox1574rJ8hj1x-gKaf7r88p7KugHJLoZOs=.60ab6c70-7144-4cec-ab44-4d8ba0302f0d@github.com>
 <6jZZLfmcCac9S52g1VaXQWvZi1LWpqxzc4GbT7CMfTE=.600c610f-654c-41f1-9132-b4a224bda44c@github.com>
 <No1avxFD90Us0zl64KAQlVagylJ-ydt_dxVkkSA3hgk=.39b95a69-3a4e-4773-9ae1-096a503e3c77@github.com>
 <WAY3lKew3WIUSPn8eW7hFOxwgkYuZL2DL18_mSc14d4=.c5d9f502-47fc-46b7-8efa-b3954a91cae0@github.com>
 <Irp8iX-EcsiutZKTaS5-6hZYmAM09g9g1ZmKvOLAb78=.3440936e-49be-45c2-b3b0-ff08bd5ff65e@github.com>
Message-ID: <9z9ZU00KzV_wR94h3KBMnt6yGv2KplJvKXvfrtqUCVM=.5e7d79a9-db40-40ef-9ea5-fc8ff63ee2d5@github.com>

On Tue, 17 Sep 2024 02:16:23 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> I think we should address that. Up to you if you wanna fix that in this PR or do it in a follow on PR.
>
> I think it's better to address it in a follow PR.

Ok!

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1763592938

From psandoz at openjdk.org  Tue Sep 17 18:14:18 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 17 Sep 2024 18:14:18 GMT
Subject: [code-reflection] RFR: Support match all pattern [v3]
In-Reply-To: <QD3znrrhElTyYe0T4wvwNqG0axEzD3LzJjgAjO3a1po=.279e4da4-05d2-412f-a85d-58663b4b9524@github.com>
References: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
 <QD3znrrhElTyYe0T4wvwNqG0axEzD3LzJjgAjO3a1po=.279e4da4-05d2-412f-a85d-58663b4b9524@github.com>
Message-ID: <D52cad9xnefM5wpX30t0H38f2NrgnvfWi3Ti3S0mVJc=.b77379d8-a1a3-4479-893c-8f0661cf6e85@github.com>

On Tue, 17 Sep 2024 02:50:53 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Support match all pattern.
>> This PR is based on [227](https://github.com/openjdk/babylon/pull/227).
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions

That looks better.

We still might need to express the type for the match all (as described in the JLS section previously referenced) so that we can generate the lowered model that preserves Java program meaning.

Consider this:


record R<T extends Number>(T s) {
}

R<Double> r = new R<>(1.0);
if (r instanceof R<Double>(_)) {
    System.out.println("");
}


The generated bytecode associated with `_` is:

INVOKEVIRTUAL A$R.s ()Ljava/lang/Number;
CHECKCAST java/lang/Double
ASTORE 3


I suggest we make a comment on `MatchAllPatternOp` and investigate further, with in a subsequent PR if needed.

src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 3228:

> 3226:                 } else if (pattern instanceof TypePatternOp bp) {
> 3227:                     return lowerBindingPattern(endNoMatchBlock, currentBlock, bindings, bp, target);
> 3228:                 } else if (pattern instanceof MatchAllPatternOp) {

Feel free to promote to switch expression, the IDE will probably do most of it for you.

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

Marked as reviewed by psandoz (Lead).

PR Review: https://git.openjdk.org/babylon/pull/230#pullrequestreview-2310369166
PR Review Comment: https://git.openjdk.org/babylon/pull/230#discussion_r1763610152

From psandoz at openjdk.org  Tue Sep 17 18:46:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 17 Sep 2024 18:46:17 GMT
Subject: [code-reflection] RFR: Bytecode cleanup, renames and javadoc [v5]
In-Reply-To: <rl0HFwbREsJFH39bFQpgkZ3nCUm4EulShlOBJgHMMEM=.a2e5163c-d7f3-469b-808f-fa3a9557f629@github.com>
References: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
 <rl0HFwbREsJFH39bFQpgkZ3nCUm4EulShlOBJgHMMEM=.a2e5163c-d7f3-469b-808f-fa3a9557f629@github.com>
Message-ID: <Fslcy1tJLbx7duQxr2wOd2fZWp7We_ZGTyjnT0suDq0=.79ffd139-1fb0-4003-ad63-facd02a9b98b@github.com>

On Mon, 16 Sep 2024 13:44:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This PR introduces only minimal functional changes, it is mainly focused on the bytecode package cleanup and documentation.
>> 
>> Any comments and suggestions are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed lifting of INVOKESPECIAL + TestSmallCorpus skipping when UnsupportedOperationException

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/228#pullrequestreview-2310575338

From psandoz at openjdk.org  Tue Sep 17 18:50:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 17 Sep 2024 18:50:17 GMT
Subject: [code-reflection] RFR: Bytecode cleanup, renames and javadoc [v5]
In-Reply-To: <rl0HFwbREsJFH39bFQpgkZ3nCUm4EulShlOBJgHMMEM=.a2e5163c-d7f3-469b-808f-fa3a9557f629@github.com>
References: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
 <rl0HFwbREsJFH39bFQpgkZ3nCUm4EulShlOBJgHMMEM=.a2e5163c-d7f3-469b-808f-fa3a9557f629@github.com>
Message-ID: <QJehLTx9k74v81C6ywLR3hqPm4ZlriEYdFMyj-vb5qM=.4c3551c7-d3bb-4694-9f89-875dbacd877a@github.com>

On Mon, 16 Sep 2024 13:44:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This PR introduces only minimal functional changes, it is mainly focused on the bytecode package cleanup and documentation.
>> 
>> Any comments and suggestions are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed lifting of INVOKESPECIAL + TestSmallCorpus skipping when UnsupportedOperationException

test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java line 150:

> 148:                 }
> 149:             } catch (UnsupportedOperationException uoe) {
> 150:                 // InvokeSuperOp

Is this related to bytecode instructions for construction not conforming to an expected shape?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/228#discussion_r1763733639

From psandoz at openjdk.org  Tue Sep 17 18:53:20 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 17 Sep 2024 18:53:20 GMT
Subject: [code-reflection] RFR: Include boolean in primitive type
 conversions.
In-Reply-To: <BizffAPYQ-qvtj8By-YvcH83mMj9x1wp7qULXMPqeqw=.3e37ec87-6009-48a1-ac20-8bd8d37ee62e@github.com>
References: <BizffAPYQ-qvtj8By-YvcH83mMj9x1wp7qULXMPqeqw=.3e37ec87-6009-48a1-ac20-8bd8d37ee62e@github.com>
Message-ID: <H-QnzB-Nw3O7udxr1p07RbUEAqrtYMmBUjeYB4n-xbE=.2657151f-e8ce-49df-889d-b64073e43718@github.com>

On Tue, 17 Sep 2024 07:25:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> There is a big difference in `boolean` role in JLS and JVMS. While in JLS it is not allowed to cast between `boolean` and other primitive numeric types (obviously because it is not  a numeric type). On the other side in the bytecode it is very hard to differentiate between `byte`, `boolean`, `short`, `char` and `int`. `BytecodeLift` actually inserts an explicit `ConvOp` in the situations where the sub-int type detection failed and it needs to by adjusted on the fly. Explicit `ConvOp` works for conversions between primitive numeric types according to JLS, however `Interpreter` fails on `ConvOp` from and to booleans. `BytecodeGenerator` accepts such conversions (as Class-File API also directly supports conversions between all primitive types, see `CodeBuilder::conversion`).
> 
> I'm proposing to add `boolean` into the matrix of supported types for `ConvOp`.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/232#pullrequestreview-2310586900

From psandoz at openjdk.org  Tue Sep 17 23:00:59 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 17 Sep 2024 23:00:59 GMT
Subject: [code-reflection] RFR: Invocation to vararg methods [v4]
In-Reply-To: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
References: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
Message-ID: <gK5HIEH71fxQ2QexAngpMntQblqAr8y2m7SA1xuuiMA=.24ccb92a-e412-461c-9f2f-3257b9848ad3@github.com>

> Re-consolidate to one invocation operation that explicitly declares its invoke kind and whether it is an invocation to a varargs method.
> 
> Resolution of a method reference accepts an invoke kind. The ambiguity when resolving a method reference without an invoke kind has been cleared up, in these cases we can only resolve to a direct method, one in which the referencing class is the class that declares the method.
> 
> I managed to avoid numerous changes to update the text models in language tests. Creating an invoke operation from external form is permissive in the attributes that are present. It makes the same assumptions as the invoke factory method in determining the invocation kind from the argument count and invoke descriptor count, and assumes the method is not a varargs method (the common case).

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

 - Merge remote-tracking branch 'upstream/code-reflection' into varargs
 - Merge remote-tracking branch 'upstream/code-reflection' into varargs
 - Comments.
 - Undo edits.
 - Avoid generating attributes
 - Invocation to vararg methods.

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/225/files
  - new: https://git.openjdk.org/babylon/pull/225/files/7ff659b4..39c86466

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

  Stats: 655 lines in 20 files changed: 222 ins; 386 del; 47 mod
  Patch: https://git.openjdk.org/babylon/pull/225.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/225/head:pull/225

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

From asotona at openjdk.org  Wed Sep 18 07:13:17 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 18 Sep 2024 07:13:17 GMT
Subject: [code-reflection] RFR: Bytecode cleanup, renames and javadoc [v5]
In-Reply-To: <QJehLTx9k74v81C6ywLR3hqPm4ZlriEYdFMyj-vb5qM=.4c3551c7-d3bb-4694-9f89-875dbacd877a@github.com>
References: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
 <rl0HFwbREsJFH39bFQpgkZ3nCUm4EulShlOBJgHMMEM=.a2e5163c-d7f3-469b-808f-fa3a9557f629@github.com>
 <QJehLTx9k74v81C6ywLR3hqPm4ZlriEYdFMyj-vb5qM=.4c3551c7-d3bb-4694-9f89-875dbacd877a@github.com>
Message-ID: <NXkYJKQDz69HoMct5g7Ug3jEFeja9qjx0bfISmCHH4I=.cec832d8-ef02-4f16-94ae-2156a7dac0da@github.com>

On Tue, 17 Sep 2024 18:47:23 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed lifting of INVOKESPECIAL + TestSmallCorpus skipping when UnsupportedOperationException
>
> test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java line 150:
> 
>> 148:                 }
>> 149:             } catch (UnsupportedOperationException uoe) {
>> 150:                 // InvokeSuperOp
> 
> Is this related to bytecode instructions for construction not conforming to an expected shape?

I understand relation between `invokespecial` and `InvokeSuperOp` introduced in #221 following way:
- We cannot simply generate `invokespecial` from `InvokeSuperOp` for reasons mentioned in the `BytecodeGenerator` and so we throw `UnsupportedOperationException` for now.
- We generate `invokespecial` from `NewOp` of a non-array type.
- When `invokespecial` of `<init>` method name follows `new` of the type equals the `invokespecial` owner, it is lifted as `NewOp` of the given non-array type.
- However all other `invokespecial` instructions suppose to be lifted as `InvokeSuperOp`? 

I made this assumption and changed `BytecodeLift` of `invokespecial` to lift into`InvokeSuperOp`, which caused certain amount of `TestSmallCorpus` to throw `UnsupportedOperationException`. 
Please confirm the assumption is correct.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/228#discussion_r1764517839

From asotona at openjdk.org  Wed Sep 18 07:27:56 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 18 Sep 2024 07:27:56 GMT
Subject: [code-reflection] RFR: Bytecode cleanup, renames and javadoc [v6]
In-Reply-To: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
References: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
Message-ID: <iRyUzjtcFdmqdBnPDGjAhgh__ZT2OqbwyeIyhkHZUy8=.aade4448-b4c3-4172-bb8b-f79dc867965b@github.com>

> This PR introduces only minimal functional changes, it is mainly focused on the bytecode package cleanup and documentation.
> 
> Any comments and suggestions are welcome.
> 
> Thanks,
> Adam

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

  fixed typo

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/228/files
  - new: https://git.openjdk.org/babylon/pull/228/files/c5291987..8efb11a8

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

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

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

From asotona at openjdk.org  Wed Sep 18 09:15:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 18 Sep 2024 09:15:09 GMT
Subject: git: openjdk/babylon: code-reflection: Include boolean in primitive
 type conversions.
Message-ID: <5ea95375-d6bc-46b3-846b-45d3d224dd7c@openjdk.org>

Changeset: 5b015c89
Branch: code-reflection
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-09-18 09:12:48 +0000
URL:       https://git.openjdk.org/babylon/commit/5b015c89c8995bd349bf0af9c13a165782884dbd

Include boolean in primitive type conversions.

Reviewed-by: psandoz

! src/java.base/share/classes/java/lang/reflect/code/interpreter/InvokableLeafOps.java


From asotona at openjdk.org  Wed Sep 18 09:16:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 18 Sep 2024 09:16:18 GMT
Subject: [code-reflection] RFR: Include boolean in primitive type
 conversions.
In-Reply-To: <BizffAPYQ-qvtj8By-YvcH83mMj9x1wp7qULXMPqeqw=.3e37ec87-6009-48a1-ac20-8bd8d37ee62e@github.com>
References: <BizffAPYQ-qvtj8By-YvcH83mMj9x1wp7qULXMPqeqw=.3e37ec87-6009-48a1-ac20-8bd8d37ee62e@github.com>
Message-ID: <dsZTlAtWzTf5z9j5Rn1H_0orhKlo-eRGSa0xJtrx1pA=.65670999-c225-4ee8-b56a-1317ec45e860@github.com>

On Tue, 17 Sep 2024 07:25:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> There is a big difference in `boolean` role in JLS and JVMS. While in JLS it is not allowed to cast between `boolean` and other primitive numeric types (obviously because it is not  a numeric type). On the other side in the bytecode it is very hard to differentiate between `byte`, `boolean`, `short`, `char` and `int`. `BytecodeLift` actually inserts an explicit `ConvOp` in the situations where the sub-int type detection failed and it needs to by adjusted on the fly. Explicit `ConvOp` works for conversions between primitive numeric types according to JLS, however `Interpreter` fails on `ConvOp` from and to booleans. `BytecodeGenerator` accepts such conversions (as Class-File API also directly supports conversions between all primitive types, see `CodeBuilder::conversion`).
> 
> I'm proposing to add `boolean` into the matrix of supported types for `ConvOp`.
> 
> Please review.
> 
> Thanks,
> Adam

Thank you!

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

PR Comment: https://git.openjdk.org/babylon/pull/232#issuecomment-2357922964

From asotona at openjdk.org  Wed Sep 18 09:16:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 18 Sep 2024 09:16:18 GMT
Subject: [code-reflection] Integrated: Include boolean in primitive type
 conversions.
In-Reply-To: <BizffAPYQ-qvtj8By-YvcH83mMj9x1wp7qULXMPqeqw=.3e37ec87-6009-48a1-ac20-8bd8d37ee62e@github.com>
References: <BizffAPYQ-qvtj8By-YvcH83mMj9x1wp7qULXMPqeqw=.3e37ec87-6009-48a1-ac20-8bd8d37ee62e@github.com>
Message-ID: <iLlsn46nAFhjwPhyUk63A0JQOkox4epYsZA2oliI574=.54b7beda-c793-4bb6-b489-aff85643274e@github.com>

On Tue, 17 Sep 2024 07:25:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> There is a big difference in `boolean` role in JLS and JVMS. While in JLS it is not allowed to cast between `boolean` and other primitive numeric types (obviously because it is not  a numeric type). On the other side in the bytecode it is very hard to differentiate between `byte`, `boolean`, `short`, `char` and `int`. `BytecodeLift` actually inserts an explicit `ConvOp` in the situations where the sub-int type detection failed and it needs to by adjusted on the fly. Explicit `ConvOp` works for conversions between primitive numeric types according to JLS, however `Interpreter` fails on `ConvOp` from and to booleans. `BytecodeGenerator` accepts such conversions (as Class-File API also directly supports conversions between all primitive types, see `CodeBuilder::conversion`).
> 
> I'm proposing to add `boolean` into the matrix of supported types for `ConvOp`.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 5b015c89
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/5b015c89c8995bd349bf0af9c13a165782884dbd
Stats:     47 lines in 1 file changed: 47 ins; 0 del; 0 mod

Include boolean in primitive type conversions.

Reviewed-by: psandoz

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

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

From asotona at openjdk.org  Wed Sep 18 09:21:32 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 18 Sep 2024 09:21:32 GMT
Subject: git: openjdk/babylon: code-reflection: Bytecode cleanup,
 renames and javadoc
Message-ID: <91287586-5eba-4183-bd89-59f7a5e4fd6c@openjdk.org>

Changeset: c6c071ad
Branch: code-reflection
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-09-18 09:19:33 +0000
URL:       https://git.openjdk.org/babylon/commit/c6c071adf2053f5b346938d9364cf17caf309bfd

Bytecode cleanup, renames and javadoc

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/LocalsCompactor.java
+ src/java.base/share/classes/java/lang/reflect/code/bytecode/LocalsToVarMapper.java
- src/java.base/share/classes/java/lang/reflect/code/bytecode/LocalsTypeMapper.java
! test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java


From asotona at openjdk.org  Wed Sep 18 09:22:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 18 Sep 2024 09:22:18 GMT
Subject: [code-reflection] Integrated: Bytecode cleanup, renames and javadoc
In-Reply-To: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
References: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
Message-ID: <5TmRjtRDyKti-sYPcrWUQnZ8eRRRiBpfjk4FBh9PfxA=.3b7f6a28-66d3-4a0c-a085-5d5aaa2137b6@github.com>

On Wed, 11 Sep 2024 15:30:44 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This PR introduces only minimal functional changes, it is mainly focused on the bytecode package cleanup and documentation.
> 
> Any comments and suggestions are welcome.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: c6c071ad
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/c6c071adf2053f5b346938d9364cf17caf309bfd
Stats:     1779 lines in 6 files changed: 1046 ins; 688 del; 45 mod

Bytecode cleanup, renames and javadoc

Reviewed-by: psandoz

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

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

From mabbay at openjdk.org  Wed Sep 18 12:35:06 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 18 Sep 2024 12:35:06 GMT
Subject: git: openjdk/babylon: code-reflection: Update the model of pattern
 matching when pattern variable identifier is underscore
Message-ID: <e1962ffe-1028-4d6c-b3ea-8b8a7f960910@openjdk.org>

Changeset: a23e320c
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2024-09-18 12:33:35 +0000
URL:       https://git.openjdk.org/babylon/commit/a23e320c96052552a201f65dd3e788e00a23db0a

Update the model of pattern matching when pattern variable identifier is underscore

Reviewed-by: psandoz

! src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java
! src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java
! test/langtools/tools/javac/reflect/PatternsTest.java
! test/langtools/tools/javac/reflect/SwitchExpressionTest.java
! test/langtools/tools/javac/reflect/SwitchExpressionTest2.java
! test/langtools/tools/javac/reflect/SwitchStatementTest.java


From mabbay at openjdk.org  Wed Sep 18 12:36:31 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 18 Sep 2024 12:36:31 GMT
Subject: [code-reflection] Integrated: Update the model of pattern matching
 when pattern variable identifier is underscore
In-Reply-To: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
References: <PNVN4hdtRJ_T988gUlaOvZhymDbuwLNZ46i1OmJo5Zc=.d264283c-14e5-4af1-95ea-df375786166b@github.com>
Message-ID: <byU6c78zYbhBFvux4ipwbgXQ9XiJxWQSOk3HdY0xXlQ=.e8b03599-c39f-471a-b732-6e9082bfa048@github.com>

On Tue, 10 Sep 2024 07:08:40 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Update the generated code model of pattern matching when pattern variable identifier is "_"

This pull request has now been integrated.

Changeset: a23e320c
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/a23e320c96052552a201f65dd3e788e00a23db0a
Stats:     253 lines in 7 files changed: 26 ins; 0 del; 227 mod

Update the model of pattern matching when pattern variable identifier is underscore

Reviewed-by: psandoz

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

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

From mabbay at openjdk.org  Wed Sep 18 13:53:48 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 18 Sep 2024 13:53:48 GMT
Subject: [code-reflection] RFR: Support match all pattern [v4]
In-Reply-To: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
References: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
Message-ID: <OMEFraLVyaXaLiddMkAe246kwo0M7hwuIGpMpL7c81c=.61845c7c-6b21-42d5-9672-1f98e9829769@github.com>

> Support match all pattern.
> This PR is based on [227](https://github.com/openjdk/babylon/pull/227).

Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'code-reflection' into match-all-pattern
   
   # Conflicts:
   #	test/langtools/tools/javac/reflect/PatternsTest.java
 - Apply suggestions
 - Simplify test of match all pattern
 - Update modeling of match all pattern
 - Support match all pattern for non-generic records
 - Update the result type of TypePatternOp
 - Keep Var that correspond to unnamed pattern variable
 - Rename BindingPatternOp to TypePatternOp
 - Pass null as binding-name when type pattern variable unnamed
 - Update effected tests
 - ... and 1 more: https://git.openjdk.org/babylon/compare/a23e320c...2f521c0a

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

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

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

From mabbay at openjdk.org  Wed Sep 18 13:59:38 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 18 Sep 2024 13:59:38 GMT
Subject: [code-reflection] RFR: Support match all pattern [v5]
In-Reply-To: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
References: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
Message-ID: <JJe2D9Kk5URRIlc-eidqdido0mCs7vaUoHYCgRZ7-gs=.49ddddb3-b664-4df1-a516-626a7f04fe58@github.com>

> Support match all pattern.
> This PR is based on [227](https://github.com/openjdk/babylon/pull/227).

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

 - Align variable names with its types
 - Refactor

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/230/files
  - new: https://git.openjdk.org/babylon/pull/230/files/2f521c0a..fe403436

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

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

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

From mabbay at openjdk.org  Wed Sep 18 14:33:20 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 18 Sep 2024 14:33:20 GMT
Subject: [code-reflection] RFR: Support match all pattern [v6]
In-Reply-To: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
References: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
Message-ID: <nc1tPfhGBowd9ZdziVpuiu6PWwf8XxecoCK6j2c0BXY=.00d852e7-6446-4e7c-9d55-b9cd24aa32f4@github.com>

> Support match all pattern.
> This PR is based on [227](https://github.com/openjdk/babylon/pull/227).

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

  Add comment about future work

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/230/files
  - new: https://git.openjdk.org/babylon/pull/230/files/fe403436..d62c42ad

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

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

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

From mabbay at openjdk.org  Wed Sep 18 14:35:07 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 18 Sep 2024 14:35:07 GMT
Subject: git: openjdk/babylon: code-reflection: Support match all pattern
Message-ID: <e5a3d584-2ff9-41aa-a67b-1dca17bd9aed@openjdk.org>

Changeset: 733ebe96
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2024-09-18 14:32:30 +0000
URL:       https://git.openjdk.org/babylon/commit/733ebe964db3506caf18d052a5abfaa38dd83304

Support match all pattern

Reviewed-by: psandoz

! src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java
! test/jdk/java/lang/reflect/code/TestPatterns.java
! test/langtools/tools/javac/reflect/PatternsTest.java


From mabbay at openjdk.org  Wed Sep 18 14:36:39 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 18 Sep 2024 14:36:39 GMT
Subject: [code-reflection] Integrated: Support match all pattern
In-Reply-To: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
References: <uZLu_beHKYyLMUmnBkff3I16aqhVyVczTIh0EuXbX6E=.487f8260-0496-4dd8-9634-8e64896cd299@github.com>
Message-ID: <_9f99Z8VoMN2rX4Q8LH__x5of4LCDG3m0wROzN6cbEo=.d0ea4f9d-8cab-4fd0-ba04-5b775aae2630@github.com>

On Thu, 12 Sep 2024 07:52:28 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Support match all pattern.
> This PR is based on [227](https://github.com/openjdk/babylon/pull/227).

This pull request has now been integrated.

Changeset: 733ebe96
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/733ebe964db3506caf18d052a5abfaa38dd83304
Stats:     113 lines in 4 files changed: 103 ins; 1 del; 9 mod

Support match all pattern

Reviewed-by: psandoz

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

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

From psandoz at openjdk.org  Wed Sep 18 17:18:23 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 18 Sep 2024 17:18:23 GMT
Subject: [code-reflection] RFR: Bytecode cleanup, renames and javadoc [v5]
In-Reply-To: <NXkYJKQDz69HoMct5g7Ug3jEFeja9qjx0bfISmCHH4I=.cec832d8-ef02-4f16-94ae-2156a7dac0da@github.com>
References: <c1SRkb7cxuho12RJaM6gq4j7oJztJM9FDQ2NsYfUf0Y=.4d88d692-9158-4aa9-a886-c0a797179437@github.com>
 <rl0HFwbREsJFH39bFQpgkZ3nCUm4EulShlOBJgHMMEM=.a2e5163c-d7f3-469b-808f-fa3a9557f629@github.com>
 <QJehLTx9k74v81C6ywLR3hqPm4ZlriEYdFMyj-vb5qM=.4c3551c7-d3bb-4694-9f89-875dbacd877a@github.com>
 <NXkYJKQDz69HoMct5g7Ug3jEFeja9qjx0bfISmCHH4I=.cec832d8-ef02-4f16-94ae-2156a7dac0da@github.com>
Message-ID: <_bZI5erApS28u6NcAvqgsmdx4AC7mEoJJvcvC35HBhc=.682b6fba-623b-4316-a913-640f2e543437@github.com>

On Wed, 18 Sep 2024 07:10:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java line 150:
>> 
>>> 148:                 }
>>> 149:             } catch (UnsupportedOperationException uoe) {
>>> 150:                 // InvokeSuperOp
>> 
>> Is this related to bytecode instructions for construction not conforming to an expected shape?
>
> I understand relation between `invokespecial` and `InvokeSuperOp` introduced in #221 following way:
> - We cannot simply generate `invokespecial` from `InvokeSuperOp` for reasons mentioned in the `BytecodeGenerator` and so we throw `UnsupportedOperationException` for now.
> - We generate `invokespecial` from `NewOp` of a non-array type.
> - When `invokespecial` of `<init>` method name follows `new` of the type equals the `invokespecial` owner, it is lifted as `NewOp` of the given non-array type.
> - However all other `invokespecial` instructions suppose to be lifted as `InvokeSuperOp`? 
> 
> I made this assumption and changed `BytecodeLift` of `invokespecial` to lift into`InvokeSuperOp`, which caused certain amount of `TestSmallCorpus` to throw `UnsupportedOperationException`. 
> Please confirm the assumption is correct.

Ok, i see now. Your assumptions are correct.
(Note #225 lumps `InvokeSuperOp` into `InvokeOp` but it does not change the assumptions.)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/228#discussion_r1765432426

From gfrost at openjdk.org  Wed Sep 18 17:46:30 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 18 Sep 2024 17:46:30 GMT
Subject: [code-reflection] RFR: Implementation of a HAT Spirv backend
In-Reply-To: <FfGTMsL7dvSDFSIzwPxrxVf4EhW5UrmjHUuOZO6wjvA=.5c002e46-64b9-4e34-aa84-d5624bcb58f1@github.com>
References: <FfGTMsL7dvSDFSIzwPxrxVf4EhW5UrmjHUuOZO6wjvA=.5c002e46-64b9-4e34-aa84-d5624bcb58f1@github.com>
Message-ID: <cCx6jyL2MzJjn_P5eD7eG8oZmMJC0LMssZzC5LaYqgI=.9e373c86-b3ec-463d-808d-dbf8775cb2d0@github.com>

On Wed, 11 Sep 2024 22:27:46 GMT, Steve Dohrmann <sdohrmann at openjdk.org> wrote:

> ## A HAT SPIR-V backend 
> 
> Implements an initial version of a HAT SPIR-V backend. It extends JavaBackend and includes no native code. It is complete enough to run the HAT Mandel example and some other simple examples.  It lacks generalized data structure support and so will not yet run, e.g., the BlackScholes or ViolaJones examples.
> 
> The backend currently only supports Linux and requires an Intel GPU to run.  Examples of compatible Intel GPU hardware are:
> 
>   * Integrated Intel GPU such as:
>     * Iris Xe or UHD graphics in 11th generation or later CPUs (Rocket Lake, Alder Lake, Raptor Lake, ...) 
>     * Arc graphics available with the latest CPUs, e.g., Meteor Lake
>   * Discrete Intel GPU such as Arc 580, 750, 770
>     * these are available on Amazon, search, e.g., "Intel Arc 580" or "Intel Arc 770"
> 
> Linux drivers for the above hardware have been included in some major Linux distros (e.g. Ubuntu) in time corresponding to the release of the hardware.  Drivers for the discrete Arc cards are included in, e.g., Ubuntu 23.10.  Ubuntu drivers for Arc discrete GPUs can also be downloaded separately.  See https://www.intel.com/content/www/us/en/download/747008/intel-arc-graphics-driver-ubuntu.html 
> 
> ## Dependencies
> Software-wise, the backend has several dependencies outside of the Babylon repo:
> 
> 	1. The Intel Level Zero library, a low level native library used to access the GPU
> 	2. A Java binding to the Level Zero library, generated using the OpenJDK jextract tool
> 	3. The Beehive Labs Java SPIR-V toolkit, used to construct a SPIR-V binary module
> 
> Currently these dependencies are not automatically built.  Below is information on how to build and install the three items above.
> 
> 
> ### Intel Level Zero library 
> 
> A build-levelzero.sh script is included in the hat/backends/spirv/scripts directory.  Superuser privileges may be required when running this script.  Execute the script with the scripts directory as the current directory:
> 
> cd backends/spirv/scripts
> sh build-level-zero.sh
> 
> This will build and install the Level Zero ze_loader.so to /usr/local/lib.  This path must be include in java.library.path or LD_LIBRARY_PATH when running using the spirv backend.
> 
> ### OpenJDK jextract tool and generated binding to Level Zero
> 
> An early-access binary of the jextract tool can be found at: 
> 
> 	https://jdk.java.net/jextract/
> 
> - expand the archive 
> - set a JEXTRACT_DIR environment variable to point at the jextract directory.
> 
> A generate-level-zero-binding.sh script is included in the hat...

Marked as reviewed by gfrost (Reviewer).

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

PR Review: https://git.openjdk.org/babylon/pull/229#pullrequestreview-2313366738

From gfrost at openjdk.org  Wed Sep 18 18:29:05 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Wed, 18 Sep 2024 18:29:05 GMT
Subject: git: openjdk/babylon: code-reflection: Implementation of a HAT Spirv
 backend
Message-ID: <e1aa1748-e790-40db-8f3c-dc9319ba99cb@openjdk.org>

Changeset: 85f14e14
Branch: code-reflection
Author:    Steve Dohrmann <sdohrmann at openjdk.org>
Committer: Gary Frost <gfrost at openjdk.org>
Date:      2024-09-18 18:27:35 +0000
URL:       https://git.openjdk.org/babylon/commit/85f14e140ef3111f072c8051d9b26734c94c2496

Implementation of a HAT Spirv backend

Reviewed-by: gfrost

! hat/backends/spirv/pom.xml
+ hat/backends/spirv/scripts/build-beehive-spirv-toolkit.sh
+ hat/backends/spirv/scripts/build-level-zero.sh
+ hat/backends/spirv/scripts/generate-level-zero-binding.sh
! hat/backends/spirv/src/main/java/hat/backend/SpirvBackend.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/StorageType.java
+ hat/backends/spirv/src/main/java/intel/code/spirv/TranslateToSpirvModel.java
+ hat/backends/spirv/src/main/java/intel/code/spirv/UsmArena.java
! hat/hatrun.bash


From duke at openjdk.org  Wed Sep 18 18:27:21 2024
From: duke at openjdk.org (duke)
Date: Wed, 18 Sep 2024 18:27:21 GMT
Subject: [code-reflection] RFR: Implementation of a HAT Spirv backend
In-Reply-To: <FfGTMsL7dvSDFSIzwPxrxVf4EhW5UrmjHUuOZO6wjvA=.5c002e46-64b9-4e34-aa84-d5624bcb58f1@github.com>
References: <FfGTMsL7dvSDFSIzwPxrxVf4EhW5UrmjHUuOZO6wjvA=.5c002e46-64b9-4e34-aa84-d5624bcb58f1@github.com>
Message-ID: <jmI2vZk3qvKtnNnhwe7qDnDwItMrR4gV8HhqwAlymMI=.f00ea8b2-2576-43fd-b7fb-2d68d0ee938c@github.com>

On Wed, 11 Sep 2024 22:27:46 GMT, Steve Dohrmann <sdohrmann at openjdk.org> wrote:

> ## A HAT SPIR-V backend 
> 
> Implements an initial version of a HAT SPIR-V backend. It extends JavaBackend and includes no native code. It is complete enough to run the HAT Mandel example and some other simple examples.  It lacks generalized data structure support and so will not yet run, e.g., the BlackScholes or ViolaJones examples.
> 
> The backend currently only supports Linux and requires an Intel GPU to run.  Examples of compatible Intel GPU hardware are:
> 
>   * Integrated Intel GPU such as:
>     * Iris Xe or UHD graphics in 11th generation or later CPUs (Rocket Lake, Alder Lake, Raptor Lake, ...) 
>     * Arc graphics available with the latest CPUs, e.g., Meteor Lake
>   * Discrete Intel GPU such as Arc 580, 750, 770
>     * these are available on Amazon, search, e.g., "Intel Arc 580" or "Intel Arc 770"
> 
> Linux drivers for the above hardware have been included in some major Linux distros (e.g. Ubuntu) in time corresponding to the release of the hardware.  Drivers for the discrete Arc cards are included in, e.g., Ubuntu 23.10.  Ubuntu drivers for Arc discrete GPUs can also be downloaded separately.  See https://www.intel.com/content/www/us/en/download/747008/intel-arc-graphics-driver-ubuntu.html 
> 
> ## Dependencies
> Software-wise, the backend has several dependencies outside of the Babylon repo:
> 
> 	1. The Intel Level Zero library, a low level native library used to access the GPU
> 	2. A Java binding to the Level Zero library, generated using the OpenJDK jextract tool
> 	3. The Beehive Labs Java SPIR-V toolkit, used to construct a SPIR-V binary module
> 
> Currently these dependencies are not automatically built.  Below is information on how to build and install the three items above.
> 
> 
> ### Intel Level Zero library 
> 
> A build-levelzero.sh script is included in the hat/backends/spirv/scripts directory.  Superuser privileges may be required when running this script.  Execute the script with the scripts directory as the current directory:
> 
> cd backends/spirv/scripts
> sh build-level-zero.sh
> 
> This will build and install the Level Zero ze_loader.so to /usr/local/lib.  This path must be include in java.library.path or LD_LIBRARY_PATH when running using the spirv backend.
> 
> ### OpenJDK jextract tool and generated binding to Level Zero
> 
> An early-access binary of the jextract tool can be found at: 
> 
> 	https://jdk.java.net/jextract/
> 
> - expand the archive 
> - set a JEXTRACT_DIR environment variable to point at the jextract directory.
> 
> A generate-level-zero-binding.sh script is included in the hat...

@steveatgh 
Your change (at version 77b68fe5c630b0cc9890df27270810e48fc5214f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/babylon/pull/229#issuecomment-2359136844

From sdohrmann at openjdk.org  Wed Sep 18 18:30:29 2024
From: sdohrmann at openjdk.org (Steve Dohrmann)
Date: Wed, 18 Sep 2024 18:30:29 GMT
Subject: [code-reflection] Integrated: Implementation of a HAT Spirv backend
In-Reply-To: <FfGTMsL7dvSDFSIzwPxrxVf4EhW5UrmjHUuOZO6wjvA=.5c002e46-64b9-4e34-aa84-d5624bcb58f1@github.com>
References: <FfGTMsL7dvSDFSIzwPxrxVf4EhW5UrmjHUuOZO6wjvA=.5c002e46-64b9-4e34-aa84-d5624bcb58f1@github.com>
Message-ID: <1_fkUJsb7FpY2koVIjSWPiULNcoeBH9SA0eLHOBq-jc=.fb3855ac-d4d4-48fe-98e1-6e8c90e190cc@github.com>

On Wed, 11 Sep 2024 22:27:46 GMT, Steve Dohrmann <sdohrmann at openjdk.org> wrote:

> ## A HAT SPIR-V backend 
> 
> Implements an initial version of a HAT SPIR-V backend. It extends JavaBackend and includes no native code. It is complete enough to run the HAT Mandel example and some other simple examples.  It lacks generalized data structure support and so will not yet run, e.g., the BlackScholes or ViolaJones examples.
> 
> The backend currently only supports Linux and requires an Intel GPU to run.  Examples of compatible Intel GPU hardware are:
> 
>   * Integrated Intel GPU such as:
>     * Iris Xe or UHD graphics in 11th generation or later CPUs (Rocket Lake, Alder Lake, Raptor Lake, ...) 
>     * Arc graphics available with the latest CPUs, e.g., Meteor Lake
>   * Discrete Intel GPU such as Arc 580, 750, 770
>     * these are available on Amazon, search, e.g., "Intel Arc 580" or "Intel Arc 770"
> 
> Linux drivers for the above hardware have been included in some major Linux distros (e.g. Ubuntu) in time corresponding to the release of the hardware.  Drivers for the discrete Arc cards are included in, e.g., Ubuntu 23.10.  Ubuntu drivers for Arc discrete GPUs can also be downloaded separately.  See https://www.intel.com/content/www/us/en/download/747008/intel-arc-graphics-driver-ubuntu.html 
> 
> ## Dependencies
> Software-wise, the backend has several dependencies outside of the Babylon repo:
> 
> 	1. The Intel Level Zero library, a low level native library used to access the GPU
> 	2. A Java binding to the Level Zero library, generated using the OpenJDK jextract tool
> 	3. The Beehive Labs Java SPIR-V toolkit, used to construct a SPIR-V binary module
> 
> Currently these dependencies are not automatically built.  Below is information on how to build and install the three items above.
> 
> 
> ### Intel Level Zero library 
> 
> A build-levelzero.sh script is included in the hat/backends/spirv/scripts directory.  Superuser privileges may be required when running this script.  Execute the script with the scripts directory as the current directory:
> 
> cd backends/spirv/scripts
> sh build-level-zero.sh
> 
> This will build and install the Level Zero ze_loader.so to /usr/local/lib.  This path must be include in java.library.path or LD_LIBRARY_PATH when running using the spirv backend.
> 
> ### OpenJDK jextract tool and generated binding to Level Zero
> 
> An early-access binary of the jextract tool can be found at: 
> 
> 	https://jdk.java.net/jextract/
> 
> - expand the archive 
> - set a JEXTRACT_DIR environment variable to point at the jextract directory.
> 
> A generate-level-zero-binding.sh script is included in the hat...

This pull request has now been integrated.

Changeset: 85f14e14
Author:    Steve Dohrmann <sdohrmann at openjdk.org>
Committer: Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/85f14e140ef3111f072c8051d9b26734c94c2496
Stats:     3095 lines in 15 files changed: 3052 ins; 26 del; 17 mod

Implementation of a HAT Spirv backend

Reviewed-by: gfrost

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

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

From psandoz at openjdk.org  Wed Sep 18 23:01:05 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 18 Sep 2024 23:01:05 GMT
Subject: [code-reflection] RFR: Invocation to vararg methods [v5]
In-Reply-To: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
References: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
Message-ID: <A1u0lSTyLZKZQ3Qq04VQg1Y0XkW6no_TpZ88nHbWBcE=.7ca64469-a04c-47dd-a2a3-7ef37a95d2ff@github.com>

> Re-consolidate to one invocation operation that explicitly declares its invoke kind and whether it is an invocation to a varargs method.
> 
> Resolution of a method reference accepts an invoke kind. The ambiguity when resolving a method reference without an invoke kind has been cleared up, in these cases we can only resolve to a direct method, one in which the referencing class is the class that declares the method.
> 
> I managed to avoid numerous changes to update the text models in language tests. Creating an invoke operation from external form is permissive in the attributes that are present. It makes the same assumptions as the invoke factory method in determining the invocation kind from the argument count and invoke descriptor count, and assumes the method is not a varargs method (the common case).

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

 - Update invoke ops in bytecode lifting
 - Merge remote-tracking branch 'upstream/code-reflection' into varargs
 - Merge remote-tracking branch 'upstream/code-reflection' into varargs
 - Merge remote-tracking branch 'upstream/code-reflection' into varargs
 - Comments.
 - Undo edits.
 - Avoid generating attributes
 - Invocation to vararg methods.

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/225/files
  - new: https://git.openjdk.org/babylon/pull/225/files/39c86466..36e86324

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

  Stats: 5290 lines in 30 files changed: 4277 ins; 715 del; 298 mod
  Patch: https://git.openjdk.org/babylon/pull/225.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/225/head:pull/225

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

From psandoz at openjdk.org  Wed Sep 18 23:04:08 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 18 Sep 2024 23:04:08 GMT
Subject: git: openjdk/babylon: code-reflection: Invocation to vararg methods
Message-ID: <cf6142c5-72b8-4617-a867-000aa2094a7b@openjdk.org>

Changeset: bb48552f
Branch: code-reflection
Author:    Paul Sandoz <psandoz at openjdk.org>
Date:      2024-09-18 23:03:36 +0000
URL:       https://git.openjdk.org/babylon/commit/bb48552fc3166ff941fdeaa2c4f26a52b2ea81f3

Invocation to vararg methods

! 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/interpreter/Interpreter.java
! src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java
! src/java.base/share/classes/java/lang/reflect/code/type/MethodRef.java
! src/java.base/share/classes/java/lang/reflect/code/type/TypeVarRef.java
! src/java.base/share/classes/java/lang/reflect/code/type/impl/MethodRefImpl.java
! src/java.base/share/classes/java/lang/reflect/code/writer/OpBuilder.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java
! test/jdk/java/lang/reflect/code/TestTransitiveInvokeModule.java
+ test/jdk/java/lang/reflect/code/TestVarArgsInvoke.java
! test/jdk/java/lang/reflect/code/bytecode/TestSmallCorpus.java
! test/langtools/tools/javac/reflect/BoxingConversionTest.java
! test/langtools/tools/javac/reflect/ImplicitConversionTest.java
! test/langtools/tools/javac/reflect/NullTest.java
! test/langtools/tools/javac/reflect/SuperTest.java
! test/langtools/tools/javac/reflect/SwitchStatementTest.java


From psandoz at openjdk.org  Wed Sep 18 23:06:58 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 18 Sep 2024 23:06:58 GMT
Subject: [code-reflection] Integrated: Invocation to vararg methods
In-Reply-To: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
References: <ZNk9HyqWeKmMgPoDG0D4Aog1ZU8Tw3GDABZzGpdoDFE=.4453a1d4-cbb3-42f0-bf42-804d9aaea141@github.com>
Message-ID: <7iWrBUyfaeIi0dxUVinTX-pJzpvOopptfs1hfDXDch8=.f85f9f5c-76b1-4571-9a61-3d22c7fe71c4@github.com>

On Tue, 10 Sep 2024 01:06:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Re-consolidate to one invocation operation that explicitly declares its invoke kind and whether it is an invocation to a varargs method.
> 
> Resolution of a method reference accepts an invoke kind. The ambiguity when resolving a method reference without an invoke kind has been cleared up, in these cases we can only resolve to a direct method, one in which the referencing class is the class that declares the method.
> 
> I managed to avoid numerous changes to update the text models in language tests. Creating an invoke operation from external form is permissive in the attributes that are present. It makes the same assumptions as the invoke factory method in determining the invocation kind from the argument count and invoke descriptor count, and assumes the method is not a varargs method (the common case).

This pull request has now been integrated.

Changeset: bb48552f
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/bb48552fc3166ff941fdeaa2c4f26a52b2ea81f3
Stats:     649 lines in 17 files changed: 430 ins; 118 del; 101 mod

Invocation to vararg methods

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

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

From mabbay at openjdk.org  Thu Sep 19 08:00:03 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 19 Sep 2024 08:00:03 GMT
Subject: [code-reflection] RFR: Fix failing cases in SwitchStatementTest
Message-ID: <_KtfUGB7w737glfc38TItJSTclExcieVf27kzBglvEo=.dc6aec41-703f-4629-9eb6-00b3fb2feb62@github.com>

In a previous PR, we merged an update to avoid boxing when concatenating a string with a primitive, this update affected some cases in `SwitchStatementTest`. In this PR we update the expected IR for these cases.

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

Commit messages:
 - Update expected IR

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

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

From mabbay at openjdk.org  Thu Sep 19 08:24:58 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 19 Sep 2024 08:24:58 GMT
Subject: [code-reflection] RFR: Address var name
Message-ID: <CD7qeMpsLw0A5Kj4pdMSa1acas_sM0F6Bh33g8olQjA=.9664d00c-1aa4-4f03-8684-02ccd94bf80f@github.com>

Address var name

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

Commit messages:
 - Add method CoreOp.VarOp.isUnnamedVariable
 - Update javadoc of CoreOp.var factory methods

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

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

From mcimadamore at openjdk.org  Thu Sep 19 12:20:53 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Sep 2024 12:20:53 GMT
Subject: [code-reflection] RFR: Fix failing cases in SwitchStatementTest
In-Reply-To: <_KtfUGB7w737glfc38TItJSTclExcieVf27kzBglvEo=.dc6aec41-703f-4629-9eb6-00b3fb2feb62@github.com>
References: <_KtfUGB7w737glfc38TItJSTclExcieVf27kzBglvEo=.dc6aec41-703f-4629-9eb6-00b3fb2feb62@github.com>
Message-ID: <UFlM0ufwbBTYTrpEw_nC6TQujMeRwmZZEVVhXpx2Cm8=.2a9b37f9-dfc5-4c38-b24b-98af02ff4159@github.com>

On Thu, 19 Sep 2024 07:54:45 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> In a previous PR, we merged an update to avoid boxing when concatenating a string with a primitive, this update affected some cases in `SwitchStatementTest`. In this PR we update the expected IR for these cases.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/babylon/pull/234#pullrequestreview-2315365052

From gfrost at openjdk.org  Thu Sep 19 12:48:34 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 19 Sep 2024 12:48:34 GMT
Subject: git: openjdk/babylon: code-reflection: Initial prep for swapping
 callgraphs for Op.Module
Message-ID: <4a65a55c-bd03-4b58-bb99-e366911fff7e@openjdk.org>

Changeset: fd4e1729
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-09-19 12:46:46 +0000
URL:       https://git.openjdk.org/babylon/commit/fd4e17293e37b9624379e2cb2347ddb19722aa2b

Initial prep for swapping callgraphs for Op.Module

! hat/backends/ptx/src/main/java/hat/backend/PTXCodeBuilder.java
! hat/hat/src/main/java/hat/Accelerator.java
! hat/hat/src/main/java/hat/ComputeContext.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/optools/InvokeOpWrapper.java
! hat/hat/src/main/java/hat/optools/LambdaOpWrapper.java
+ hat/hat/src/main/java/hat/optools/ModuleOpWrapper.java
! hat/hat/src/main/java/hat/optools/OpWrapper.java


From gfrost at openjdk.org  Thu Sep 19 12:49:13 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 19 Sep 2024 12:49:13 GMT
Subject: [code-reflection] Integrated: Initial prep for swapping callgraphs for
 Op.Module
Message-ID: <8xPcmv51FqwFcHOSTQBps2kFKkpTuXJw-_onmC9ZBSw=.8e983abb-08b5-4c5d-b837-5355f987d139@github.com>

These are initial steps towards swapping existing callgraph implementation with CoreOp.ModuleOp

Basically adding ModuleOpWrapper

I also took the opportunity of cleanup up some code for converting MethodRef -> Method.

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

Commit messages:
 - Initial prep for swapping callgraphs for Op.Module

Changes: https://git.openjdk.org/babylon/pull/236/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=236&range=00
  Stats: 202 lines in 9 files changed: 154 ins; 7 del; 41 mod
  Patch: https://git.openjdk.org/babylon/pull/236.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/236/head:pull/236

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

From gfrost at openjdk.org  Thu Sep 19 12:49:14 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Thu, 19 Sep 2024 12:49:14 GMT
Subject: [code-reflection] Integrated: Initial prep for swapping callgraphs for
 Op.Module
In-Reply-To: <8xPcmv51FqwFcHOSTQBps2kFKkpTuXJw-_onmC9ZBSw=.8e983abb-08b5-4c5d-b837-5355f987d139@github.com>
References: <8xPcmv51FqwFcHOSTQBps2kFKkpTuXJw-_onmC9ZBSw=.8e983abb-08b5-4c5d-b837-5355f987d139@github.com>
Message-ID: <brZrsMlWdRMwSpBUk2iINEpFdQhf7aFW2WDkOicnng0=.b0c98519-d27b-4c5a-801e-02d0156a9911@github.com>

On Thu, 19 Sep 2024 12:44:40 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> These are initial steps towards swapping existing callgraph implementation with CoreOp.ModuleOp
> 
> Basically adding ModuleOpWrapper
> 
> I also took the opportunity of cleanup up some code for converting MethodRef -> Method.

This pull request has now been integrated.

Changeset: fd4e1729
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/fd4e17293e37b9624379e2cb2347ddb19722aa2b
Stats:     202 lines in 9 files changed: 154 ins; 7 del; 41 mod

Initial prep for swapping callgraphs for Op.Module

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

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

From psandoz at openjdk.org  Thu Sep 19 16:14:49 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 19 Sep 2024 16:14:49 GMT
Subject: [code-reflection] RFR: Fix failing cases in SwitchStatementTest
In-Reply-To: <_KtfUGB7w737glfc38TItJSTclExcieVf27kzBglvEo=.dc6aec41-703f-4629-9eb6-00b3fb2feb62@github.com>
References: <_KtfUGB7w737glfc38TItJSTclExcieVf27kzBglvEo=.dc6aec41-703f-4629-9eb6-00b3fb2feb62@github.com>
Message-ID: <1KGi4a2UWzSlo1kAOv5z5r60I-E2bxjSBGCAUqL1ERI=.bcc6558a-5798-4cce-b645-64a12f295823@github.com>

On Thu, 19 Sep 2024 07:54:45 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> In a previous PR, we merged an update to avoid boxing when concatenating a string with a primitive, this update affected some cases in `SwitchStatementTest`. In this PR we update the expected IR for these cases.

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/234#pullrequestreview-2316016032

From mabbay at openjdk.org  Thu Sep 19 16:21:06 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 19 Sep 2024 16:21:06 GMT
Subject: git: openjdk/babylon: code-reflection: Fix failing cases in
 SwitchStatementTest
Message-ID: <a8e78a9f-59c9-4f13-a135-22a168d26e65@openjdk.org>

Changeset: 7746e41b
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2024-09-19 16:20:08 +0000
URL:       https://git.openjdk.org/babylon/commit/7746e41b9fc35a3765ec2e662e8d87cf68edd5a1

Fix failing cases in SwitchStatementTest

Reviewed-by: mcimadamore, psandoz

! test/langtools/tools/javac/reflect/SwitchStatementTest.java


From mabbay at openjdk.org  Thu Sep 19 16:23:49 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Thu, 19 Sep 2024 16:23:49 GMT
Subject: [code-reflection] Integrated: Fix failing cases in SwitchStatementTest
In-Reply-To: <_KtfUGB7w737glfc38TItJSTclExcieVf27kzBglvEo=.dc6aec41-703f-4629-9eb6-00b3fb2feb62@github.com>
References: <_KtfUGB7w737glfc38TItJSTclExcieVf27kzBglvEo=.dc6aec41-703f-4629-9eb6-00b3fb2feb62@github.com>
Message-ID: <J2zFd2KjphpcAXnAKSqwkDMbGVLYnXhEmiqD8Vz7Qg4=.8cbda450-db42-40da-92a7-f70e135f3bc9@github.com>

On Thu, 19 Sep 2024 07:54:45 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> In a previous PR, we merged an update to avoid boxing when concatenating a string with a primitive, this update affected some cases in `SwitchStatementTest`. In this PR we update the expected IR for these cases.

This pull request has now been integrated.

Changeset: 7746e41b
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/7746e41b9fc35a3765ec2e662e8d87cf68edd5a1
Stats:     338 lines in 1 file changed: 0 ins; 17 del; 321 mod

Fix failing cases in SwitchStatementTest

Reviewed-by: mcimadamore, psandoz

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

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

From psandoz at openjdk.org  Thu Sep 19 16:37:51 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 19 Sep 2024 16:37:51 GMT
Subject: [code-reflection] RFR: Address var name
In-Reply-To: <CD7qeMpsLw0A5Kj4pdMSa1acas_sM0F6Bh33g8olQjA=.9664d00c-1aa4-4f03-8684-02ccd94bf80f@github.com>
References: <CD7qeMpsLw0A5Kj4pdMSa1acas_sM0F6Bh33g8olQjA=.9664d00c-1aa4-4f03-8684-02ccd94bf80f@github.com>
Message-ID: <xLNRLNkrfszPgauhJ8-MYJfrkG-h9XVIox98GCp-E3U=.9df8383d-f02b-4865-9950-b8a40d7c94ac@github.com>

On Thu, 19 Sep 2024 08:19:42 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Address var name

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

> 3946:      * Creates a var operation.
> 3947:      * <p>
> 3948:      * Null or empty string means unnamed variable

I recommend updating all three methods to state:

    Creates a var operation modeling a variable, either a local variable or a parameter.

Then we can add to the second two methods:

    If the given name is {@code null} or an empty string then the variable is an unnamed variable.

We can then update the first method (that accepts no name) to:

    Creates a var operation modeling an unnamed variable, either an unnamed local variable or an unnamed parameter.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/235#discussion_r1767159659

From igraves at openjdk.org  Mon Sep 23 15:59:19 2024
From: igraves at openjdk.org (Ian Graves)
Date: Mon, 23 Sep 2024 15:59:19 GMT
Subject: [code-reflection] RFR: Draft: ANF Experimental Code Model
Message-ID: <txE8d8OA4SW-Nm2B4eDPQWm4eWUSiv2jpJ8y66YO9es=.31c84fec-4c25-4d38-80b2-1d52a7319d86@github.com>

Experiments with Administrative Normal Form (A-Normal Form; ANF) transformations in the code model. See https://github.com/igraves/babylon-anf for additional code using these changes.

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

Commit messages:
 - Additional updates

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

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

From psandoz at openjdk.org  Mon Sep 23 21:21:35 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 23 Sep 2024 21:21:35 GMT
Subject: [code-reflection] RFR: Normalize blocks transformer
Message-ID: <6AxScIe6WgrDgTcJDOCC5on44x-Er_mt4SzJsYw-ow0=.3cfb8652-1ea5-4c1c-9175-c8224b284170@github.com>

A model transformer that normalizes blocks. Merges redundant blocks with their predecessors, those which are unconditionally branched to and have only one predecessor. Removes unused block parameters.

This is useful to normalize models that have been lowered or lifted and contain redundant blocks.

--

Observation: transformers can be stateless or stateful. Currently for the latter we cannot expose an `OpTransformer` instance since it can really only be used once it it accumulates state that may be incorrect on subsequent transformations. What may be required is the concept of a transformer that provides two or more methods that return functional interfaces for separate aspects (like `Collector` or `Gatherer`), such as a function to produce a state object, and a function to transform given that state object. The state object might be produced by traversing the model before it is transformed. Something to consider later in a refactoring of this API.

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

Commit messages:
 - Remove trailing WS.
 - Normalize blocks
 - Use HashSet
 - Merge blocks transformer.

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

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

From psandoz at openjdk.org  Mon Sep 23 21:26:10 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 23 Sep 2024 21:26:10 GMT
Subject: [code-reflection] RFR: Normalize blocks transformer [v2]
In-Reply-To: <6AxScIe6WgrDgTcJDOCC5on44x-Er_mt4SzJsYw-ow0=.3cfb8652-1ea5-4c1c-9175-c8224b284170@github.com>
References: <6AxScIe6WgrDgTcJDOCC5on44x-Er_mt4SzJsYw-ow0=.3cfb8652-1ea5-4c1c-9175-c8224b284170@github.com>
Message-ID: <qnETlN4jYCk-jN1JyHkKcaYpO2AJO-mGPOHd4lvHJw4=.85946d07-f1ec-4188-a6ab-47b7de98e144@github.com>

> A model transformer that normalizes blocks. Merges redundant blocks with their predecessors, those which are unconditionally branched to and have only one predecessor. Removes unused block parameters.
> 
> This is useful to normalize models that have been lowered or lifted and contain redundant blocks.
> 
> --
> 
> Observation: transformers can be stateless or stateful. Currently for the latter we cannot expose an `OpTransformer` instance since it can really only be used once it it accumulates state that may be incorrect on subsequent transformations. What may be required is the concept of a transformer that provides two or more methods that return functional interfaces for separate aspects (like `Collector` or `Gatherer`), such as a function to produce a state object, and a function to transform given that state object. The state object might be produced by traversing the model before it is transformed. Something to consider later in a refactoring of this API.

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

  Use different values

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/238/files
  - new: https://git.openjdk.org/babylon/pull/238/files/686e94f7..44395537

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

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

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

From mabbay at openjdk.org  Tue Sep 24 13:39:52 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 24 Sep 2024 13:39:52 GMT
Subject: [code-reflection] RFR: Address var name [v2]
In-Reply-To: <CD7qeMpsLw0A5Kj4pdMSa1acas_sM0F6Bh33g8olQjA=.9664d00c-1aa4-4f03-8684-02ccd94bf80f@github.com>
References: <CD7qeMpsLw0A5Kj4pdMSa1acas_sM0F6Bh33g8olQjA=.9664d00c-1aa4-4f03-8684-02ccd94bf80f@github.com>
Message-ID: <iGMhkSxHYx1MAkldgHmkoWQLiqH2uZcqEzWUTbcomJM=.08f7b8e9-f7d6-49f4-b718-6b1fd3ed2040@github.com>

> Address var name

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

 - Merge branch 'code-reflection' into var-name
 - Update TestVarOp following change in var.name for unnamed variables
 - Consider empty string as the value varName for unnamed variable
 - Apply suggestions
 - Add method CoreOp.VarOp.isUnnamedVariable
 - Update javadoc of CoreOp.var factory methods

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/235/files
  - new: https://git.openjdk.org/babylon/pull/235/files/f8b95b70..fa15770d

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

  Stats: 4294 lines in 42 files changed: 3636 ins; 168 del; 490 mod
  Patch: https://git.openjdk.org/babylon/pull/235.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/235/head:pull/235

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

From psandoz at openjdk.org  Tue Sep 24 17:33:06 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 24 Sep 2024 17:33:06 GMT
Subject: [code-reflection] RFR: Address var name [v2]
In-Reply-To: <iGMhkSxHYx1MAkldgHmkoWQLiqH2uZcqEzWUTbcomJM=.08f7b8e9-f7d6-49f4-b718-6b1fd3ed2040@github.com>
References: <CD7qeMpsLw0A5Kj4pdMSa1acas_sM0F6Bh33g8olQjA=.9664d00c-1aa4-4f03-8684-02ccd94bf80f@github.com>
 <iGMhkSxHYx1MAkldgHmkoWQLiqH2uZcqEzWUTbcomJM=.08f7b8e9-f7d6-49f4-b718-6b1fd3ed2040@github.com>
Message-ID: <cncN-2ySW6-nUFOpeoJ3fKafa0INW-Z9OShIVwxpiVg=.a9e8da2e-52ce-4dd7-b4ce-41c02367f80e@github.com>

On Tue, 24 Sep 2024 13:39:52 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Address var name
>
> Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'code-reflection' into var-name
>  - Update TestVarOp following change in var.name for unnamed variables
>  - Consider empty string as the value varName for unnamed variable
>  - Apply suggestions
>  - Add method CoreOp.VarOp.isUnnamedVariable
>  - Update javadoc of CoreOp.var factory methods

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/235#pullrequestreview-2325932881

From mabbay at openjdk.org  Tue Sep 24 17:53:00 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Tue, 24 Sep 2024 17:53:00 GMT
Subject: [code-reflection] RFR: Support record pattern for generic records
Message-ID: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>

Support record pattern for generic records

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

Commit messages:
 - Use externalize method in toString of RecordTypeRefImpl, MethodRefImpl and FieldRefImpl
 - Modify TypeVarRef.toString to print more info about type variable

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

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

From psandoz at openjdk.org  Tue Sep 24 18:16:07 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 24 Sep 2024 18:16:07 GMT
Subject: [code-reflection] RFR: Support record pattern for generic records
In-Reply-To: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>
References: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>
Message-ID: <H77gx8dzKm3lFHMaOpe4YrhMSEmmYb6Ut8vEUUldVl8=.78e6021c-c3f9-4a0e-a13a-8abf1703bd60@github.com>

On Tue, 24 Sep 2024 14:07:12 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Support record pattern for generic records

Can you add a simple language test for a generic record?

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

PR Review: https://git.openjdk.org/babylon/pull/240#pullrequestreview-2326028039

From igraves at openjdk.org  Tue Sep 24 20:51:40 2024
From: igraves at openjdk.org (Ian Graves)
Date: Tue, 24 Sep 2024 20:51:40 GMT
Subject: [code-reflection] RFR: Draft: ANF Experimental Code Model [v2]
In-Reply-To: <txE8d8OA4SW-Nm2B4eDPQWm4eWUSiv2jpJ8y66YO9es=.31c84fec-4c25-4d38-80b2-1d52a7319d86@github.com>
References: <txE8d8OA4SW-Nm2B4eDPQWm4eWUSiv2jpJ8y66YO9es=.31c84fec-4c25-4d38-80b2-1d52a7319d86@github.com>
Message-ID: <MFH1FnMf-fKPF_i_rhS7gYOcsd6OKbCjbRAJN6v9cUI=.aaf828dd-f3af-496a-8214-38814c710974@github.com>

> Experiments with Administrative Normal Form (A-Normal Form; ANF) transformations in the code model. See https://github.com/igraves/babylon-anf for additional code using these changes.

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

  Moving new ops into AnfDialect

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/239/files
  - new: https://git.openjdk.org/babylon/pull/239/files/4ff6487b..b9077dad

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

  Stats: 655 lines in 3 files changed: 437 ins; 216 del; 2 mod
  Patch: https://git.openjdk.org/babylon/pull/239.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/239/head:pull/239

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

From mcimadamore at openjdk.org  Wed Sep 25 10:13:52 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Sep 2024 10:13:52 GMT
Subject: [code-reflection] RFR: Support record pattern for generic records
In-Reply-To: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>
References: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>
Message-ID: <GVJR_LLRUhsc16Lcdr2II5WVvCTS4elWwIsxzMjl55o=.3d796325-f808-4fd3-b4a2-9d349f537017@github.com>

On Tue, 24 Sep 2024 14:07:12 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Support record pattern for generic records

No tests?

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

PR Review: https://git.openjdk.org/babylon/pull/240#pullrequestreview-2327808912

From mabbay at openjdk.org  Wed Sep 25 11:22:47 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 25 Sep 2024 11:22:47 GMT
Subject: [code-reflection] RFR: Support record pattern for generic records
In-Reply-To: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>
References: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>
Message-ID: <xUiaDzR1w8KPQkOILysL5AHPZNC4bJ2pwk_ZHPlL1lE=.72f824f9-2152-495a-8242-e3ecf88da1c2@github.com>

On Tue, 24 Sep 2024 14:07:12 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Support record pattern for generic records

Forget to stage test file.

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

PR Comment: https://git.openjdk.org/babylon/pull/240#issuecomment-2373800594

From mabbay at openjdk.org  Wed Sep 25 11:58:57 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 25 Sep 2024 11:58:57 GMT
Subject: git: openjdk/babylon: code-reflection: Address var name
Message-ID: <fbe6d975-23e5-431a-be79-d2e91dba08d7@openjdk.org>

Changeset: 971b90fa
Branch: code-reflection
Author:    Mourad Abbay <mabbay at openjdk.org>
Date:      2024-09-25 11:58:09 +0000
URL:       https://git.openjdk.org/babylon/commit/971b90fa70eaa31810d3658f2f689c2b1ea4c4be

Address var name

Reviewed-by: psandoz

! src/java.base/share/classes/java/lang/reflect/code/op/CoreOp.java
! test/jdk/java/lang/reflect/code/TestVarOp.java


From mabbay at openjdk.org  Wed Sep 25 12:00:51 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 25 Sep 2024 12:00:51 GMT
Subject: [code-reflection] Integrated: Address var name
In-Reply-To: <CD7qeMpsLw0A5Kj4pdMSa1acas_sM0F6Bh33g8olQjA=.9664d00c-1aa4-4f03-8684-02ccd94bf80f@github.com>
References: <CD7qeMpsLw0A5Kj4pdMSa1acas_sM0F6Bh33g8olQjA=.9664d00c-1aa4-4f03-8684-02ccd94bf80f@github.com>
Message-ID: <h6AMlz8vK16gnGKux1OdJ3V1EeCoiT8NkMV0JRac_8w=.42e7a1e9-6c8f-4ad1-b7df-a6c8a0d5fec9@github.com>

On Thu, 19 Sep 2024 08:19:42 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

> Address var name

This pull request has now been integrated.

Changeset: 971b90fa
Author:    Mourad Abbay <mabbay at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/971b90fa70eaa31810d3658f2f689c2b1ea4c4be
Stats:     15 lines in 2 files changed: 8 ins; 0 del; 7 mod

Address var name

Reviewed-by: psandoz

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

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

From mabbay at openjdk.org  Wed Sep 25 12:24:16 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 25 Sep 2024 12:24:16 GMT
Subject: [code-reflection] RFR: Support record pattern for generic records
 [v2]
In-Reply-To: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>
References: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>
Message-ID: <jDd012M0LFZKPZZz_PFBu6NPW1kFZpVMShpiu5MWkh8=.8e3ff7e2-72d0-430f-ae78-9d27a2556d11@github.com>

> Support record pattern for generic records

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

  Add tests

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/240/files
  - new: https://git.openjdk.org/babylon/pull/240/files/cb093d86..538a7d8c

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

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

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

From mabbay at openjdk.org  Wed Sep 25 15:07:31 2024
From: mabbay at openjdk.org (Mourad Abbay)
Date: Wed, 25 Sep 2024 15:07:31 GMT
Subject: [code-reflection] RFR: Support record pattern for generic records
 [v3]
In-Reply-To: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>
References: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>
Message-ID: <phaCzhJFBn6S5-d1oVNAJf4R__KwZBEAVqfPGoMFa90=.07d1ba57-e63e-4cf7-b5fe-18fbf7f619d6@github.com>

> Support record pattern for generic records

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

 - Merge branch 'code-reflection' into record-pattern
 - Add tests
 - Use externalize method in toString of RecordTypeRefImpl, MethodRefImpl and FieldRefImpl
 - Modify TypeVarRef.toString to print more info about type variable

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/240/files
  - new: https://git.openjdk.org/babylon/pull/240/files/538a7d8c..8dca783f

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

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

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

From psandoz at openjdk.org  Wed Sep 25 22:28:48 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 25 Sep 2024 22:28:48 GMT
Subject: [code-reflection] RFR: Support record pattern for generic records
 [v3]
In-Reply-To: <phaCzhJFBn6S5-d1oVNAJf4R__KwZBEAVqfPGoMFa90=.07d1ba57-e63e-4cf7-b5fe-18fbf7f619d6@github.com>
References: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>
 <phaCzhJFBn6S5-d1oVNAJf4R__KwZBEAVqfPGoMFa90=.07d1ba57-e63e-4cf7-b5fe-18fbf7f619d6@github.com>
Message-ID: <mHrXsmVv4aeccCO-dvUkxfExN9h8DFw7Q8Rv-pjRpZw=.c51c1d5c-8f6a-48f7-a660-f0a1a9dcb332@github.com>

On Wed, 25 Sep 2024 15:07:31 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Support record pattern for generic records
>
> Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'code-reflection' into record-pattern
>  - Add tests
>  - Use externalize method in toString of RecordTypeRefImpl, MethodRefImpl and FieldRefImpl
>  - Modify TypeVarRef.toString to print more info about type variable

Tests looks good.

Can you also add a few more test cases to [`TestReferences`](https://github.com/openjdk/babylon/blob/code-reflection/test/jdk/java/lang/reflect/code/type/TestReferences.java) ?

(I forgot we had this test.)

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

PR Review: https://git.openjdk.org/babylon/pull/240#pullrequestreview-2329639080

From psandoz at openjdk.org  Wed Sep 25 23:26:32 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 25 Sep 2024 23:26:32 GMT
Subject: git: openjdk/babylon: code-reflection: Normalize blocks transformer
Message-ID: <1233efe6-782c-4629-87b7-742ea0370936@openjdk.org>

Changeset: e7b1d158
Branch: code-reflection
Author:    Paul Sandoz <psandoz at openjdk.org>
Date:      2024-09-25 23:25:48 +0000
URL:       https://git.openjdk.org/babylon/commit/e7b1d158fc2b6279cddf27f88707d556c72bb764

Normalize blocks transformer

! src/java.base/share/classes/java/lang/reflect/code/CodeItem.java
+ src/java.base/share/classes/java/lang/reflect/code/analysis/NormalizeBlocksTransformer.java
! src/java.base/share/classes/java/lang/reflect/code/analysis/StringConcatTransformer.java
+ test/jdk/java/lang/reflect/code/TestNormalizeBlocksTransformer.java


From psandoz at openjdk.org  Wed Sep 25 23:28:54 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 25 Sep 2024 23:28:54 GMT
Subject: [code-reflection] Integrated: Normalize blocks transformer
In-Reply-To: <6AxScIe6WgrDgTcJDOCC5on44x-Er_mt4SzJsYw-ow0=.3cfb8652-1ea5-4c1c-9175-c8224b284170@github.com>
References: <6AxScIe6WgrDgTcJDOCC5on44x-Er_mt4SzJsYw-ow0=.3cfb8652-1ea5-4c1c-9175-c8224b284170@github.com>
Message-ID: <nHlO1PnMA414SiKsM69F-Qx_dQziFNHIORIl5eHVdPA=.f0d51452-caf2-4e9b-8abf-44bc2fcffbe6@github.com>

On Fri, 20 Sep 2024 23:26:11 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> A model transformer that normalizes blocks. Merges redundant blocks with their predecessors, those which are unconditionally branched to and have only one predecessor. Removes unused block parameters.
> 
> This is useful to normalize models that have been lowered or lifted and contain redundant blocks.
> 
> --
> 
> Observation: transformers can be stateless or stateful. Currently for the latter we cannot expose an `OpTransformer` instance since it can really only be used once it it accumulates state that may be incorrect on subsequent transformations. What may be required is the concept of a transformer that provides two or more methods that return functional interfaces for separate aspects (like `Collector` or `Gatherer`), such as a function to produce a state object, and a function to transform given that state object. The state object might be produced by traversing the model before it is transformed. Something to consider later in a refactoring of this API.

This pull request has now been integrated.

Changeset: e7b1d158
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/e7b1d158fc2b6279cddf27f88707d556c72bb764
Stats:     416 lines in 4 files changed: 415 ins; 0 del; 1 mod

Normalize blocks transformer

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

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

From mcimadamore at openjdk.org  Thu Sep 26 09:16:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 26 Sep 2024 09:16:10 GMT
Subject: [code-reflection] RFR: Support record pattern for generic records
 [v3]
In-Reply-To: <phaCzhJFBn6S5-d1oVNAJf4R__KwZBEAVqfPGoMFa90=.07d1ba57-e63e-4cf7-b5fe-18fbf7f619d6@github.com>
References: <OOm6sxU8xojqt0xSkp_zxftVZ5rg6EWXgJP7GOA2bX8=.22abaf7c-23c9-4e94-b8d5-a8986a3c9ead@github.com>
 <phaCzhJFBn6S5-d1oVNAJf4R__KwZBEAVqfPGoMFa90=.07d1ba57-e63e-4cf7-b5fe-18fbf7f619d6@github.com>
Message-ID: <bJ5FHZHvXaivHAnMbgXi4zHIJqVnMxRgWHV-vV4O1Vc=.2159a830-d62c-4c6a-9f88-deda62f54c1a@github.com>

On Wed, 25 Sep 2024 15:07:31 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> Support record pattern for generic records
>
> Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'code-reflection' into record-pattern
>  - Add tests
>  - Use externalize method in toString of RecordTypeRefImpl, MethodRefImpl and FieldRefImpl
>  - Modify TypeVarRef.toString to print more info about type variable

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/babylon/pull/240#pullrequestreview-2330616906

From asotona at openjdk.org  Fri Sep 27 07:35:59 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 27 Sep 2024 07:35:59 GMT
Subject: [code-reflection] RFR: BytecodeLift with NormalizerBlockTransformer +
 fix + ExceptionTableCompactor
Message-ID: <kcL3yxHkHFOySaNwJYsF1BERHUoZMHHCwwsuh0AGyqs=.35624e5f-4f02-4a10-b5c9-48ff668140be@github.com>

Minor fix of `NormalizerBlockTransformer` to skip exception handlers.
`NormalizerBlockTransformer` plugged into `BytecodeLift`.
Implementation of `ExceptionTableCompactor` plugged into `BytecodeGenerator`.

Please review.

Thanks,
Adam

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

Commit messages:
 - implementation of ExceptionTableCompactor for BytecodeGenerator
 - BytecodeLift uses NormalizeBlocksTransformer
 - NormalizerBlockTransformer fix to exclude exception handlers

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

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

From psandoz at openjdk.org  Fri Sep 27 16:41:49 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 27 Sep 2024 16:41:49 GMT
Subject: [code-reflection] RFR: BytecodeLift with
 NormalizerBlockTransformer + fix + ExceptionTableCompactor
In-Reply-To: <kcL3yxHkHFOySaNwJYsF1BERHUoZMHHCwwsuh0AGyqs=.35624e5f-4f02-4a10-b5c9-48ff668140be@github.com>
References: <kcL3yxHkHFOySaNwJYsF1BERHUoZMHHCwwsuh0AGyqs=.35624e5f-4f02-4a10-b5c9-48ff668140be@github.com>
Message-ID: <8OteWZiuJyzchkHs-1ixZAo9xvWJnKXg6NR75yWEZm0=.bfc3d5bb-6c41-404c-8b15-76855e12ff06@github.com>

On Fri, 27 Sep 2024 07:30:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Minor fix of `NormalizerBlockTransformer` to skip exception handlers.
> `NormalizerBlockTransformer` plugged into `BytecodeLift`.
> Implementation of `ExceptionTableCompactor` plugged into `BytecodeGenerator`.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by psandoz (Lead).

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

PR Review: https://git.openjdk.org/babylon/pull/242#pullrequestreview-2334190204

From psandoz at openjdk.org  Fri Sep 27 17:18:57 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 27 Sep 2024 17:18:57 GMT
Subject: [code-reflection] RFR: BytecodeLift with
 NormalizerBlockTransformer + fix + ExceptionTableCompactor
In-Reply-To: <kcL3yxHkHFOySaNwJYsF1BERHUoZMHHCwwsuh0AGyqs=.35624e5f-4f02-4a10-b5c9-48ff668140be@github.com>
References: <kcL3yxHkHFOySaNwJYsF1BERHUoZMHHCwwsuh0AGyqs=.35624e5f-4f02-4a10-b5c9-48ff668140be@github.com>
Message-ID: <xkCuyapF2y0ENBqQVw_kwoK-eHerMpxuMhai3XX6npo=.98345e04-e38e-41cb-b47f-6ec8530c014b@github.com>

On Fri, 27 Sep 2024 07:30:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Minor fix of `NormalizerBlockTransformer` to skip exception handlers.
> `NormalizerBlockTransformer` plugged into `BytecodeLift`.
> Implementation of `ExceptionTableCompactor` plugged into `BytecodeGenerator`.
> 
> Please review.
> 
> Thanks,
> Adam

I know i already approved, but could you also add another test to `TestNormalizeBlocksTransformer` where the exception block parameter is not used? There is already a test using exception regions, but block parameter is used.

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

PR Comment: https://git.openjdk.org/babylon/pull/242#issuecomment-2379731127

From psandoz at openjdk.org  Fri Sep 27 21:12:50 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 27 Sep 2024 21:12:50 GMT
Subject: git: openjdk/babylon: code-reflection: Fix method resolution on invoke
 op wrapper
Message-ID: <cf2186bb-fb56-425e-8cae-d916e6d6cb2d@openjdk.org>

Changeset: fb4592aa
Branch: code-reflection
Author:    Paul Sandoz <psandoz at openjdk.org>
Date:      2024-09-27 21:11:34 +0000
URL:       https://git.openjdk.org/babylon/commit/fb4592aa8a69d77ef5eadf44ad33083447ccd665

Fix method resolution on invoke op wrapper

! hat/hat/src/main/java/hat/optools/InvokeOpWrapper.java


From psandoz at openjdk.org  Fri Sep 27 21:15:16 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 27 Sep 2024 21:15:16 GMT
Subject: [code-reflection] Integrated: Fix method resolution on invoke op
 wrapper
Message-ID: <A7c8N9MwkY4VAOpPlvNZB_EOnuHKqj_o_JxeuohiHjU=.c42f7c11-e3f1-4c47-9ffb-861a6827ef75@github.com>

Changes in the modeling of invoke expressions broke HAT. This PR fixes that.

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

Commit messages:
 - Fix method resultion on invoke op wrapper

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

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

From psandoz at openjdk.org  Fri Sep 27 21:15:16 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 27 Sep 2024 21:15:16 GMT
Subject: [code-reflection] Integrated: Fix method resolution on invoke op
 wrapper
In-Reply-To: <A7c8N9MwkY4VAOpPlvNZB_EOnuHKqj_o_JxeuohiHjU=.c42f7c11-e3f1-4c47-9ffb-861a6827ef75@github.com>
References: <A7c8N9MwkY4VAOpPlvNZB_EOnuHKqj_o_JxeuohiHjU=.c42f7c11-e3f1-4c47-9ffb-861a6827ef75@github.com>
Message-ID: <VVVP13eSBbAuiJ2vXETLcgg16FfemvLaQnutx1y33SY=.5a692768-ba61-4d2c-b280-211fe335aa1d@github.com>

On Fri, 27 Sep 2024 21:08:32 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Changes in the modeling of invoke expressions broke HAT. This PR fixes that.

This pull request has now been integrated.

Changeset: fb4592aa
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/fb4592aa8a69d77ef5eadf44ad33083447ccd665
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

Fix method resolution on invoke op wrapper

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

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

From gfrost at openjdk.org  Sat Sep 28 10:35:20 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Sat, 28 Sep 2024 10:35:20 GMT
Subject: git: openjdk/babylon: code-reflection: Working on spirv integration, 
 need to exclude from intellij imls =?UTF-8?B?dGVtcOKApg==?=
Message-ID: <f067324b-f0bf-49f8-aa16-f1f61118c6a2@openjdk.org>

Changeset: 2bb9f2ad
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-09-28 10:33:31 +0000
URL:       https://git.openjdk.org/babylon/commit/2bb9f2adb438c9d159fb3034c31fec408498ae00

Working on spirv integration, need to exclude from intellij imls temp?

! hat/hat/src/main/java/hat/optools/InvokeOpWrapper.java
! hat/intellij/backend_spirv.iml


From gfrost at openjdk.org  Sat Sep 28 10:36:04 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Sat, 28 Sep 2024 10:36:04 GMT
Subject: [code-reflection] Integrated: Working on spirv integration,
 need to exclude from intellij imls =?UTF-8?B?dGVtcOKApg==?=
Message-ID: <BOwWhx5JwDQDJ_Bt_VZXoVHw5su5K8SaKboKgSIE-OE=.e245df0a-3860-4314-9213-2d1afea57e45@github.com>

Working on spirv integration into build.  Need to exclude spirv backend from intellij build until I complete command line build.

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

Commit messages:
 - Working on spirv integration, need to exclude from intellij imls temporarily

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

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

From gfrost at openjdk.org  Sat Sep 28 10:36:04 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Sat, 28 Sep 2024 10:36:04 GMT
Subject: [code-reflection] Integrated: Working on spirv integration,
 need to exclude from intellij imls =?UTF-8?B?dGVtcOKApg==?=
In-Reply-To: <BOwWhx5JwDQDJ_Bt_VZXoVHw5su5K8SaKboKgSIE-OE=.e245df0a-3860-4314-9213-2d1afea57e45@github.com>
References: <BOwWhx5JwDQDJ_Bt_VZXoVHw5su5K8SaKboKgSIE-OE=.e245df0a-3860-4314-9213-2d1afea57e45@github.com>
Message-ID: <IDERCJ5aKv16IpnwBUIYVhd-sBi8WYqqrMSsgItIEgk=.36f9b3ad-ff9a-416e-b989-fd02f7bc0502@github.com>

On Sat, 28 Sep 2024 10:30:36 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Working on spirv integration into build.  Need to exclude spirv backend from intellij build until I complete command line build.

This pull request has now been integrated.

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

Working on spirv integration, need to exclude from intellij imls temp?

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

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

From gfrost at openjdk.org  Sat Sep 28 15:09:01 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Sat, 28 Sep 2024 15:09:01 GMT
Subject: [code-reflection] RFR: add a pure java (no maven) build option
Message-ID: <EfM2zH5Oh6EO7Y2cfGDeNZpwU0E6_XbRdn3wxbpyV8E=.d3433b77-c689-4cc8-8aac-2284217cb126@github.com>

Added  pure java builder (replacing `mvn clean compile jar:jar install`)

So after adding ~babylon/build/xxx-yyy-server-release/jdk/bin to your path (and setting JAVA_HOME accordingly) with env.bash 

You should be able to build hat + backends + examples with just 

./bld

  
Relies on hashbang via `#!/usr/bin/env java --enable-preview --source 24`  to launch the file using babylon jdk

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

Commit messages:
 - add a pure java (no maven) build option
 - add a pure java (no maven) build option

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

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

From gfrost at openjdk.org  Sat Sep 28 15:12:32 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Sat, 28 Sep 2024 15:12:32 GMT
Subject: git: openjdk/babylon: code-reflection: add a pure java (no maven)
 build option
Message-ID: <aafb02be-234c-4481-b038-00fe3264e72c@openjdk.org>

Changeset: e02b5d42
Branch: code-reflection
Author:    Gary Frost <gfrost at openjdk.org>
Date:      2024-09-28 15:10:37 +0000
URL:       https://git.openjdk.org/babylon/commit/e02b5d423da7596625600dd39d3ab200e26d407d

add a pure java (no maven) build option

! hat/backends/.gitignore
+ hat/bld
! hat/hatrun.bash


From gfrost at openjdk.org  Sat Sep 28 15:13:58 2024
From: gfrost at openjdk.org (Gary Frost)
Date: Sat, 28 Sep 2024 15:13:58 GMT
Subject: [code-reflection] Integrated: add a pure java (no maven) build option
In-Reply-To: <EfM2zH5Oh6EO7Y2cfGDeNZpwU0E6_XbRdn3wxbpyV8E=.d3433b77-c689-4cc8-8aac-2284217cb126@github.com>
References: <EfM2zH5Oh6EO7Y2cfGDeNZpwU0E6_XbRdn3wxbpyV8E=.d3433b77-c689-4cc8-8aac-2284217cb126@github.com>
Message-ID: <-wZg3XM2xW_GcoBwXHrtx8rUrUWqRgmmTxJ85KQuENc=.38cc22ff-c441-4b50-ae4b-70697e73677e@github.com>

On Sat, 28 Sep 2024 14:59:11 GMT, Gary Frost <gfrost at openjdk.org> wrote:

> Added  pure java builder (replacing `mvn clean compile jar:jar install`)
> 
> So after adding ~babylon/build/xxx-yyy-server-release/jdk/bin to your path (and setting JAVA_HOME accordingly) with env.bash 
> 
> You should be able to build hat + backends + examples with just 
> 
> ./bld
> 
>   
> Relies on hashbang via `#!/usr/bin/env java --enable-preview --source 24`  to launch the file using babylon jdk

This pull request has now been integrated.

Changeset: e02b5d42
Author:    Gary Frost <gfrost at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/e02b5d423da7596625600dd39d3ab200e26d407d
Stats:     265 lines in 3 files changed: 261 ins; 0 del; 4 mod

add a pure java (no maven) build option

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

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

From asotona at openjdk.org  Mon Sep 30 08:59:12 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 30 Sep 2024 08:59:12 GMT
Subject: [code-reflection] RFR: BytecodeLift with
 NormalizerBlockTransformer + fix + ExceptionTableCompactor [v2]
In-Reply-To: <kcL3yxHkHFOySaNwJYsF1BERHUoZMHHCwwsuh0AGyqs=.35624e5f-4f02-4a10-b5c9-48ff668140be@github.com>
References: <kcL3yxHkHFOySaNwJYsF1BERHUoZMHHCwwsuh0AGyqs=.35624e5f-4f02-4a10-b5c9-48ff668140be@github.com>
Message-ID: <f_AZgoVzZTaDs5-ZQ2R7Mw4pdHedcGXH3Ey5ZNXM-u4=.e0b41f05-9232-4528-92bd-e88cfac59e09@github.com>

> Minor fix of `NormalizerBlockTransformer` to skip exception handlers.
> `NormalizerBlockTransformer` plugged into `BytecodeLift`.
> Implementation of `ExceptionTableCompactor` plugged into `BytecodeGenerator`.
> 
> Please review.
> 
> Thanks,
> Adam

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

  added TestNormalizeBlocksTransformer test to keep unused exception handler block parameter

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/242/files
  - new: https://git.openjdk.org/babylon/pull/242/files/5ce104a7..73984ca6

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

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

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

From asotona at openjdk.org  Mon Sep 30 09:03:08 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 30 Sep 2024 09:03:08 GMT
Subject: git: openjdk/babylon: code-reflection: BytecodeLift with
 NormalizerBlockTransformer + fix + ExceptionTableCompactor
Message-ID: <9de82fff-08c6-425d-bc70-c7e3002be4e5@openjdk.org>

Changeset: 9ec0798c
Branch: code-reflection
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-09-30 09:02:11 +0000
URL:       https://git.openjdk.org/babylon/commit/9ec0798c43fb8132e815c4fe34069efdce7f8fd9

BytecodeLift with NormalizerBlockTransformer + fix + ExceptionTableCompactor

Reviewed-by: psandoz

! src/java.base/share/classes/java/lang/reflect/code/analysis/NormalizeBlocksTransformer.java
! src/java.base/share/classes/java/lang/reflect/code/bytecode/BytecodeLift.java
! src/java.base/share/classes/java/lang/reflect/code/bytecode/LocalsCompactor.java
! test/jdk/java/lang/reflect/code/TestNormalizeBlocksTransformer.java


From asotona at openjdk.org  Mon Sep 30 09:04:48 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 30 Sep 2024 09:04:48 GMT
Subject: [code-reflection] RFR: BytecodeLift with
 NormalizerBlockTransformer + fix + ExceptionTableCompactor [v2]
In-Reply-To: <f_AZgoVzZTaDs5-ZQ2R7Mw4pdHedcGXH3Ey5ZNXM-u4=.e0b41f05-9232-4528-92bd-e88cfac59e09@github.com>
References: <kcL3yxHkHFOySaNwJYsF1BERHUoZMHHCwwsuh0AGyqs=.35624e5f-4f02-4a10-b5c9-48ff668140be@github.com>
 <f_AZgoVzZTaDs5-ZQ2R7Mw4pdHedcGXH3Ey5ZNXM-u4=.e0b41f05-9232-4528-92bd-e88cfac59e09@github.com>
Message-ID: <j4cr4FQ7A2xnHg4_xN6yaU4i2DDYAjHMvZEnzH74_sE=.c7f285f3-9bf4-4ffd-be61-8f4ab5a1d136@github.com>

On Mon, 30 Sep 2024 08:59:12 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Minor fix of `NormalizerBlockTransformer` to skip exception handlers.
>> `NormalizerBlockTransformer` plugged into `BytecodeLift`.
>> Implementation of `ExceptionTableCompactor` plugged into `BytecodeGenerator`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added TestNormalizeBlocksTransformer test to keep unused exception handler block parameter

Thank you for the review.

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

PR Comment: https://git.openjdk.org/babylon/pull/242#issuecomment-2382540519

From asotona at openjdk.org  Mon Sep 30 09:04:49 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 30 Sep 2024 09:04:49 GMT
Subject: [code-reflection] Integrated: BytecodeLift with
 NormalizerBlockTransformer + fix + ExceptionTableCompactor
In-Reply-To: <kcL3yxHkHFOySaNwJYsF1BERHUoZMHHCwwsuh0AGyqs=.35624e5f-4f02-4a10-b5c9-48ff668140be@github.com>
References: <kcL3yxHkHFOySaNwJYsF1BERHUoZMHHCwwsuh0AGyqs=.35624e5f-4f02-4a10-b5c9-48ff668140be@github.com>
Message-ID: <67w1EuevUdPjGraIFK2JMMXc1gSNyHmHncYFxJj42Ys=.c5a878c6-da92-46be-9988-7b9f250a1aae@github.com>

On Fri, 27 Sep 2024 07:30:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Minor fix of `NormalizerBlockTransformer` to skip exception handlers.
> `NormalizerBlockTransformer` plugged into `BytecodeLift`.
> Implementation of `ExceptionTableCompactor` plugged into `BytecodeGenerator`.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 9ec0798c
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/babylon/commit/9ec0798c43fb8132e815c4fe34069efdce7f8fd9
Stats:     111 lines in 4 files changed: 96 ins; 6 del; 9 mod

BytecodeLift with NormalizerBlockTransformer + fix + ExceptionTableCompactor

Reviewed-by: psandoz

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

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

From psandoz at openjdk.org  Mon Sep 30 16:12:54 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 30 Sep 2024 16:12:54 GMT
Subject: [code-reflection] RFR: BytecodeLift with
 NormalizerBlockTransformer + fix + ExceptionTableCompactor [v2]
In-Reply-To: <f_AZgoVzZTaDs5-ZQ2R7Mw4pdHedcGXH3Ey5ZNXM-u4=.e0b41f05-9232-4528-92bd-e88cfac59e09@github.com>
References: <kcL3yxHkHFOySaNwJYsF1BERHUoZMHHCwwsuh0AGyqs=.35624e5f-4f02-4a10-b5c9-48ff668140be@github.com>
 <f_AZgoVzZTaDs5-ZQ2R7Mw4pdHedcGXH3Ey5ZNXM-u4=.e0b41f05-9232-4528-92bd-e88cfac59e09@github.com>
Message-ID: <JuCtaMO8aM8A_3ZjWbee5nDGxYdviz76gqNZ4BD4U4E=.9848b60a-0a68-486d-9eb2-44f326a155d6@github.com>

On Mon, 30 Sep 2024 08:59:12 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Minor fix of `NormalizerBlockTransformer` to skip exception handlers.
>> `NormalizerBlockTransformer` plugged into `BytecodeLift`.
>> Implementation of `ExceptionTableCompactor` plugged into `BytecodeGenerator`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added TestNormalizeBlocksTransformer test to keep unused exception handler block parameter

It just occurred to me that we could also change the "specification" of `exception.region.enter` such that a catch block without a block parameter means that the exception is ignored. That seems less fragile. Is that easy to support in the bytecode generator? WDYT?

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

PR Comment: https://git.openjdk.org/babylon/pull/242#issuecomment-2383618527