From dsimms at openjdk.org Fri Nov 1 06:44:50 2024 From: dsimms at openjdk.org (David Simms) Date: Fri, 1 Nov 2024 06:44:50 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: <9Zyujd00-jkRdjtJDc75Tkby66DhwiMG6B2qsopP7sk=.f09d8467-3afc-4d0d-a723-17911e783c3f@github.com> On Thu, 31 Oct 2024 13:49:57 GMT, David Simms wrote: > Merge jdk-24+17 and jdk-24+18 This pull request has now been integrated. Changeset: 90c9079e Author: David Simms URL: https://git.openjdk.org/valhalla/commit/90c9079ea4ee2f0216e019f3aa4f3682e776e756 Stats: 43388 lines in 803 files changed: 34332 ins; 5162 del; 3894 mod Merge jdk Merge jdk-24+17 and jdk-24+18 ------------- PR: https://git.openjdk.org/valhalla/pull/1290 From tobias.hartmann at oracle.com Fri Nov 1 07:32:24 2024 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 1 Nov 2024 08:32:24 +0100 Subject: New Valhalla Committer: Bhavana Kilambi In-Reply-To: References: Message-ID: Vote: yes Best regards, Tobias On 10/30/24 17:28, Bhateja, Jatin wrote: > I hereby nominate Bhavana Kilambi(OpenJDK name: *bkilambi*)[1]to Valhalla Committer. > > Bhavana is an author in JDK Project. She authored 17 bug fixes and enhancements to C2 Compiler encompassing AARCH64 Float16 backend support, mid-end transformations, and optimized inline expansions [2]. > > In the context of the?Valhalla Project, Bhawana has contributed 4 patches on lworld+fp16 branch optimizing various Float16 operations notably [3][4][5][6]. > > Going forward she will be helping us in productizing the?VectorAPI-Valhalla prototype on the?lworld+vector branch. > > Votes are due by 2024-11-13 at?17:00 PST. > > Only current Valhalla Committers [7] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [8]. > > Best regards, > > Jatin Bhateja > > [1] https://openjdk.org/census#bkilambi > > [2] https://github.com/openjdk/jdk/commits/master?author=bkilambi at openjdk.org > > [3] _https://github.com/openjdk/valhalla/commit/9005a9a309e615780e87e49673ca9f9ea4831137 _ > > [4] _https://github.com/openjdk/valhalla/commit/ce32e8c9bb2e99b20d088b88819feac9da6125f5 _ > > [5] _https://github.com/openjdk/valhalla/commit/2e21e366969e1f02db46a684046812d00fa3eb52 _ > > [6] _https://github.com/openjdk/valhalla/commit/3f42a1c9b9fc806e79e56ff794a745749feb823e _ > > _[7] _https://openjdk.org/census#valhalla > > [8] https://openjdk.org/projects/#committer-vote > From dsimms at openjdk.org Fri Nov 1 10:05:22 2024 From: dsimms at openjdk.org (David Simms) Date: Fri, 1 Nov 2024 10:05:22 GMT Subject: [lworld] RFR: [lworld] Adjust testing after merging jdk-24+18 Message-ID: JDK-8334060 causes IR mismatches ------------- Commit messages: - [lworld] Adjust testing after merging jdk-24+18 Changes: https://git.openjdk.org/valhalla/pull/1293/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1293&range=00 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/valhalla/pull/1293.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1293/head:pull/1293 PR: https://git.openjdk.org/valhalla/pull/1293 From dsimms at openjdk.org Fri Nov 1 11:48:47 2024 From: dsimms at openjdk.org (David Simms) Date: Fri, 1 Nov 2024 11:48:47 GMT Subject: [lworld] Integrated: [lworld] Adjust testing after merging jdk-24+18 In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 09:59:37 GMT, David Simms wrote: > JDK-8334060 causes IR mismatches This pull request has now been integrated. Changeset: 115d3dea Author: David Simms URL: https://git.openjdk.org/valhalla/commit/115d3dea17c1c8cc2f06f0b83ca9617a56099744 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod [lworld] Adjust testing after merging jdk-24+18 ------------- PR: https://git.openjdk.org/valhalla/pull/1293 From rriggs at openjdk.org Fri Nov 1 15:48:00 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 1 Nov 2024 15:48:00 GMT Subject: [lworld] RFR: 8343444: ProblemList 3 network tests failing with java.net.SocketException: Exec format error Message-ID: Problem listing using the mainline bug # bug java/nio/channels/DatagramChannel/BasicMulticastTests.java 8144003 macosx-all java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java 8144003 macosx-all java/nio/channels/DatagramChannel/Promiscuous.java 8144003 macosx-all ------------- Commit messages: - ProblemList 3 network tests failing with java.net.SocketException: Exec format error Changes: https://git.openjdk.org/valhalla/pull/1294/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1294&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343444 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1294.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1294/head:pull/1294 PR: https://git.openjdk.org/valhalla/pull/1294 From rriggs at openjdk.org Fri Nov 1 20:31:28 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 1 Nov 2024 20:31:28 GMT Subject: [lworld] RFR: 8343444: ProblemList 3 network tests failing with java.net.SocketException: Exec format error In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 15:43:27 GMT, Roger Riggs wrote: > Problem listing using the mainline bug # bug > > java/nio/channels/DatagramChannel/BasicMulticastTests.java 8144003 macosx-all > java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java 8144003 macosx-all > java/nio/channels/DatagramChannel/Promiscuous.java 8144003 macosx-all Problem list already updated. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1294#issuecomment-2452544015 From rriggs at openjdk.org Fri Nov 1 20:31:29 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 1 Nov 2024 20:31:29 GMT Subject: [lworld] Withdrawn: 8343444: ProblemList 3 network tests failing with java.net.SocketException: Exec format error In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 15:43:27 GMT, Roger Riggs wrote: > Problem listing using the mainline bug # bug > > java/nio/channels/DatagramChannel/BasicMulticastTests.java 8144003 macosx-all > java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java 8144003 macosx-all > java/nio/channels/DatagramChannel/Promiscuous.java 8144003 macosx-all This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/valhalla/pull/1294 From vromero at openjdk.org Fri Nov 1 22:01:41 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 1 Nov 2024 22:01:41 GMT Subject: RFR: Merge lworld Message-ID: Merge branch 'lworld' into lw5_merge_lworld # Conflicts: # src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java # src/java.compiler/share/classes/javax/lang/model/element/Modifier.java # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java # src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java # src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java # test/langtools/tools/javac/diags/examples.not-yet.txt ------------- Commit messages: - Merge branch 'lworld' into lw5_merge_lworld - [lworld] Adjust testing after merging jdk-24+18 - Merge jdk - 8341148: Open source several Choice related tests - 8334060: Implementation of Late Barrier Expansion for G1 - 8341091: CDS: Segmented roots array misses roots - 8341239: Open source closed frame tests # 3 - 8341191: Open source few more AWT FileDialog tests - 8341177: Opensource few List and a Window test - 8309841: Jarsigner should print a warning if an entry is removed - ... and 1529 more: https://git.openjdk.org/valhalla/compare/ff277645...4a7d52c6 The webrevs contain the adjustments done while merging with regards to each parent branch: - lw5: https://webrevs.openjdk.org/?repo=valhalla&pr=1295&range=00.0 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1295&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1295/files Stats: 385195 lines in 5106 files changed: 295615 ins; 60531 del; 29049 mod Patch: https://git.openjdk.org/valhalla/pull/1295.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1295/head:pull/1295 PR: https://git.openjdk.org/valhalla/pull/1295 From vromero at openjdk.org Fri Nov 1 22:11:05 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 1 Nov 2024 22:11:05 GMT Subject: RFR: Merge lworld [v2] In-Reply-To: References: Message-ID: <4JlRKO9Rz2azwt25nEtYr3hD-fza98dCO2gtBuP2G7E=.d26a1464-8eb0-412b-b299-87c40fd16804@github.com> > Merge branch 'lworld' into lw5_merge_lworld > # Conflicts: > # src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > # src/java.compiler/share/classes/javax/lang/model/element/Modifier.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > # test/langtools/tools/javac/diags/examples.not-yet.txt Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: - Merge branch 'lworld' into lw5_merge_lworld # Conflicts: # src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java # src/java.compiler/share/classes/javax/lang/model/element/Modifier.java # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java # src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java # src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java # test/langtools/tools/javac/diags/examples.not-yet.txt - 8340125: [lw5] null checks are not being generated for method invocations and array writes - Merge lworld - 8340027: [lw5] the ACC_STRICT flag is not being set for non-nullable static fields - Merge lworld - 8339357: [lw5] make non-nullable instance fields strict - 8339339: [lw5] javac should issue an error if a null-restricted field is left uninitialized, fix override related warnings - 8338910: [lw5] enhance the Signature attribute to represent nullability - Improve support for nullable types and arrays - 8339087: [lw5] remove parametric types related warnings - ... and 50 more: https://git.openjdk.org/valhalla/compare/115d3dea...4a7d52c6 ------------- Changes: https://git.openjdk.org/valhalla/pull/1295/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1295&range=01 Stats: 6859 lines in 106 files changed: 6738 ins; 5 del; 116 mod Patch: https://git.openjdk.org/valhalla/pull/1295.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1295/head:pull/1295 PR: https://git.openjdk.org/valhalla/pull/1295 From vromero at openjdk.org Fri Nov 1 22:11:09 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 1 Nov 2024 22:11:09 GMT Subject: Integrated: Merge lworld In-Reply-To: References: Message-ID: <3D8p5DdTUuzHjzKspgkCSK0alim4sFrQLdfnY24GUS4=.43f3031a-a590-4630-a6e0-58a217464ab2@github.com> On Fri, 1 Nov 2024 21:44:03 GMT, Vicente Romero wrote: > Merge branch 'lworld' into lw5_merge_lworld > # Conflicts: > # src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > # src/java.compiler/share/classes/javax/lang/model/element/Modifier.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java > # src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > # test/langtools/tools/javac/diags/examples.not-yet.txt This pull request has now been integrated. Changeset: 62dc50e5 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/62dc50e573a318afd99f537841d8cc4ed2f53f70 Stats: 385195 lines in 5106 files changed: 295615 ins; 60531 del; 29049 mod Merge lworld ------------- PR: https://git.openjdk.org/valhalla/pull/1295 From frederic.parain at oracle.com Mon Nov 4 21:49:46 2024 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 4 Nov 2024 16:49:46 -0500 Subject: New Valhalla Committer: Bhavana Kilambi In-Reply-To: References: Message-ID: <5cfe4cc0-abd4-4000-b680-51cd08789b18@oracle.com> Vote: yes Best regards, Fred On 10/30/24 12:28, Bhateja, Jatin wrote: > I hereby nominate Bhavana Kilambi(OpenJDK name: *bkilambi*)[1]to > Valhalla Committer. > Bhavana is an author in JDK Project. She authored 17 bug fixes and > enhancements to C2 Compiler encompassing AARCH64 Float16 backend > support, mid-end transformations, and optimized inline expansions [2]. > In the context of the?Valhalla Project, Bhawana has contributed 4 > patches on lworld+fp16 branch optimizing various Float16 operations > notably [3][4][5][6]. > Going forward she will be helping us in productizing > the?VectorAPI-Valhalla prototype on the?lworld+vector branch. > Votes are due by 2024-11-13 at?17:00 PST. > Only current Valhalla Committers [7] are eligible to vote on this > nomination.? Votes must be cast in the open by replying to this > mailing list. > For Lazy Consensus voting instructions, see [8]. > Best regards, > Jatin Bhateja > [1] https://openjdk.org/census#bkilambi > [2] > https://github.com/openjdk/jdk/commits/master?author=bkilambi at openjdk.org > [3] > _https://github.com/openjdk/valhalla/commit/9005a9a309e615780e87e49673ca9f9ea4831137_ > [4] > _https://github.com/openjdk/valhalla/commit/ce32e8c9bb2e99b20d088b88819feac9da6125f5_ > [5] > _https://github.com/openjdk/valhalla/commit/2e21e366969e1f02db46a684046812d00fa3eb52_ > [6] > _https://github.com/openjdk/valhalla/commit/3f42a1c9b9fc806e79e56ff794a745749feb823e > _ > _[7] _https://openjdk.org/census#valhalla > > [8] https://openjdk.org/projects/#committer-vote > From roger.riggs at oracle.com Tue Nov 5 14:57:15 2024 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 5 Nov 2024 09:57:15 -0500 Subject: New Valhalla Committer: Bhavana Kilambi In-Reply-To: References: Message-ID: Vote: yes On 10/30/24 12:28 PM, Bhateja, Jatin wrote: > I hereby nominate Bhavana Kilambi(OpenJDK name: *bkilambi*)[1]to > Valhalla Committer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbhateja at openjdk.org Wed Nov 6 14:11:53 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 6 Nov 2024 14:11:53 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines In-Reply-To: References:

Message-ID: On Thu, 31 Oct 2024 13:50:34 GMT, Bhavana Kilambi wrote: >> This patch adds intrinsic support for FP16 conversion routines to int/long/double and also the aarch64 backend support. This patch implements both scalar and vector versions for these conversions. >> >> Performance numbers on aarch64 machine with SVE support : >> >> >> Benchmark (vectorDim) Gain >> Float16OpsBenchmark.fp16ToDouble 1024 18.23 >> Float16OpsBenchmark.fp16ToInt 1024 1.93 >> Float16OpsBenchmark.fp16ToLong 1024 3.95 >> >> >> The Gain column is the ratio between thrpt of this patch and the thrpt with the intrinsics disabled (which generates FP32 arithmetic). > > Hi @jatin-bhateja , I have uploaded a patch addressing your comments. Please review. Hi @Bhavana-Kilambi , should also consider float16 to integral conversion, i.e. to int/short/long. ISA supports direct instruction corresponding to these APIs. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1283#issuecomment-2459853719 From bkilambi at openjdk.org Wed Nov 6 14:16:45 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Wed, 6 Nov 2024 14:16:45 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v2] In-Reply-To: References:

Message-ID: <_f4vQRZLx26zx6TZOv9HsryAWjeN4wxcZ1sByLRLWYM=.4abbad34-d773-4200-ae0e-7096c10297ad@github.com> On Thu, 31 Oct 2024 13:50:40 GMT, Bhavana Kilambi wrote: >> This patch adds intrinsic support for FP16 conversion routines to int/long/double and also the aarch64 backend support. This patch implements both scalar and vector versions for these conversions. >> >> Performance numbers on aarch64 machine with SVE support : >> >> >> Benchmark (vectorDim) Gain >> Float16OpsBenchmark.fp16ToDouble 1024 18.23 >> Float16OpsBenchmark.fp16ToInt 1024 1.93 >> Float16OpsBenchmark.fp16ToLong 1024 3.95 >> >> >> The Gain column is the ratio between thrpt of this patch and the thrpt with the intrinsics disabled (which generates FP32 arithmetic). > > Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: > > Remove intrinsification of conversion methods in Float16 Hi Jatin, I have added support for float16 to int and long. Apologies for missing the conversion to `short`. Will add that. This patch adds support for fp16 -> double as well. fp16->float is already taken care of. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1283#issuecomment-2459867101 From jbhateja at openjdk.org Thu Nov 7 07:27:56 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 7 Nov 2024 07:27:56 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v2] In-Reply-To: References:

Message-ID: On Thu, 31 Oct 2024 13:50:40 GMT, Bhavana Kilambi wrote: >> This patch adds intrinsic support for FP16 conversion routines to int/long/double and also the aarch64 backend support. This patch implements both scalar and vector versions for these conversions. >> >> Performance numbers on aarch64 machine with SVE support : >> >> >> Benchmark (vectorDim) Gain >> Float16OpsBenchmark.fp16ToDouble 1024 18.23 >> Float16OpsBenchmark.fp16ToInt 1024 1.93 >> Float16OpsBenchmark.fp16ToLong 1024 3.95 >> >> >> The Gain column is the ratio between thrpt of this patch and the thrpt with the intrinsics disabled (which generates FP32 arithmetic). > > Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: > > Remove intrinsification of conversion methods in Float16 My bad, I meant the other way round i.e. integral to float16 conversion case, which takes a slow path route currently. Consider the following micro kernel:- public class float16_allocation { public static float micro(int value) { Float16 val = Float16.valueOf(value); // [a] return val.floatValue(); // [b] } public static void main(String [] args) { float res = 0.0f; for (int i = 0; i < 100000; i++) { res += micro(i); } System.out.println("[res]" + res); } } Here, the integer parameter is first converted to float16 value [a], valueOf routine first type cast integer value to double type and then passes it to Float16.valueOf(double) routine resulting in a bulky JIT sequence. We can outline the following code [c] into a new leaf routine returning a short value, and directly pass it to the Float16 constructor similar to https://github.com/openjdk/valhalla/blob/lworld%2Bfp16/src/java.base/share/classes/java/lang/Float16.java#L411 New routine can then be intrinsified to yield ConvI2HF IR, which then gets boxed as a value object. Since Float16 is a value type, it will scalarize its field accesses, thus directly forwarding HF ('short') value to subsequent ConvHF2F [b]. On mainline where Float16 is a value-based class we can bank on escape analysis to eliminate redundant boxing allocations. public static Float16 valueOf(int value) { // int -> double conversion is exact return valueOf((double)value); // [c] } We can spill this over to another patch if you suggest it, kindly let me know your views. Best Regards, Jatin ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1283#issuecomment-2461500053 From chagedorn at openjdk.org Thu Nov 7 07:50:06 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 7 Nov 2024 07:50:06 GMT Subject: [lworld] RFR: 8343423: [lworld] compiler/valhalla/inlinetypes/TestArrays.java IR mismatches after after merging JDK-8334060 in jdk-24+18 Message-ID: There are several events that need to be taken into consideration to understand why `TestArray::test97-100()` are now failing after the merge of JDK-24+18: ### Background #### Original Intent of `test95-101()`: Orignally, the tests were added with [JDK-8251442](https://bugs.openjdk.org/browse/JDK-8251442) to check that sub type checks are properly folded with a new regex `CHECKCAST_ARRAY`. Back there, we did not have the possibility to match on compilation phases. We could only match on the output of `PrintIdeal` or `PrintOptoAssembly`. `PrintIdeal` is after the macro node expansion and thus `SubTypeCheck` nodes cannot be found anymore. As an alternative, a matching on `PrintOptoAssembly` was chosen by matching multiple lines. Note that only `test101()` is a positive test for a sub type check (it requires that one is found) while `test95-100()` are negative tests that checks the absense of a sub type check. #### Matching on Multiple Lines in Opto Assembly Is Fragile As seen in the past, matching multiples lines on Opto Assembly is fragile when some unrelated instructions are inserted in between (for example spills). The regexes can become quite complicated and also slow to process. #### `CHECKCAST_ARRAY` Stopped Working Correctly at some Point Due to Scheduling Bool and If Apart At some point, code emission started to schedule the nodes for the bool/comparison earlier, then scheduled an unrelated If and only then the actual jump for the sub type check. Example: ![image](https://github.com/user-attachments/assets/bc9fb4b9-3493-48a1-8c0a-f3cb5a22808f) The nodes for `74 compP_reg` are first emitted. Then we emit `101 testL_reg` together with `100 jmpCon_short` and only then `73 jmpConU`: --- 74 compP_rReg nodes --- 0c4 B7: # out( B9 B8 ) <- in( B32 B21 B19 B6 ) Freq: 0.87277 0c4 # checkcastPP of RBP 0c4 movl R11, [RBP + #8 (8-bit)] # compressed klass ptr 0c8 encode_heap_oop_not_null R8,RBX 10d movl [R13], R8 # compressed ptr 111 movq R10, R13 # ptr -> long 114 movq R8, RBX # ptr -> long 117 xorq R8, R10 # long 11a shrq R8, #22 11e movq RBX, precise [precise compiler/valhalla/inlinetypes/MyValue1: 0x00006ffd384d65a8 (compiler/valhalla/inlinetypes/MyInterface):Constant:exact * (java/lang/Cloneable,java/io/Serializable): :Constant:exact * # ptr 128 decode_and_move_klass_not_null R9,R11 12b movq RBP, [R9 + #80 (8-bit)] # class --- 100 jmpCon_short nodes --- 12f testq R8, R8 132 je,s B9 P=0.001000 C=-1.000000 --- True Path of 100 jmpCon_short --- 134 B8: # out( B22 B9 ) <- in( B7 ) Freq: 0.871897 134 shrq R10, #9 138 movq RDI, 0x00006ffd51000000 # ptr 142 addq RDI, R10 # ptr 145 cmpb [RDI], #2 148 jne B22 P=0.001000 C=-1.000000 --- False Path of 100 jmpCon_short --- 14e B9: # out( B18 B10 ) <- in( B24 B25 B22 B8 B7 ) Freq: 0.87277 --- 73 jmpConU --- 14e cmpq RBP, RBX # ptr #### `test101()` still Working Unfortunately, this only seemed to have affected the negative tests and not the positive `test101()`. I have not investigated further there why but it's not important for this bug fix. #### Starting to Track `ArrayStoreExceptions` in Interpreter With [JDK-8275908](https://bugs.openjdk.org/browse/JDK-8275908), we started to profile `ArrayStoreExceptions` in the interpreter already and propagate that information over the MDO to the C2 compiler: https://github.com/openjdk/valhalla/blob/115d3dea17c1c8cc2f06f0b83ca9617a56099744/src/hotspot/share/interpreter/interpreterRuntime.cpp#L566-L567 #### Cannot Propagate Improved Type Information with `CheckCastPP` Due to Non-Zero Trap Count With the additional profiling in the interpreter with JDK-8275908, we are no longer able to propagate the additional type information with the `CheckCastPP` because we require that the array store check trap was never taken at runtime: https://github.com/openjdk/valhalla/blob/115d3dea17c1c8cc2f06f0b83ca9617a56099744/src/hotspot/share/opto/parseHelper.cpp#L196 https://github.com/openjdk/valhalla/blob/115d3dea17c1c8cc2f06f0b83ca9617a56099744/src/hotspot/share/opto/compile.cpp#L4617 As a result, we miss to propagate the exactness here: https://github.com/openjdk/valhalla/blob/115d3dea17c1c8cc2f06f0b83ca9617a56099744/src/hotspot/share/opto/parseHelper.cpp#L215 And thus cannot remove the sub type checks in `test97-100()`. #### Not Noticed with Broken `CHECKCAST_ARRAY` but only after the Late Barrier Expansion for G1 JEP We should actually have found this after JDK-8275908 but as described above, `CHECKCAST_ARRAY` was broken. We only started to notice it when merging in the Late Barrier Expansion for G1 JEP which must have changed the scheduling decisions. ### Proposed Fix To simulate the pre-JDK-8275908 behavior, we can simply set a warm-up of 0 which ensures that no trap is ever recorded to have been taken. We additionally require that the IR rules are only evaluated if `MonomorphicArrayCheck` is set which is a requirement to propagate the type: https://github.com/openjdk/valhalla/blob/115d3dea17c1c8cc2f06f0b83ca9617a56099744/src/hotspot/share/opto/parseHelper.cpp#L171 #### Additional Tweaks To get this working, I've also changed the following: - Using `IRNode.SUBTYPE_CHECK` instead of `CHECKCAST_ARRAY` is easier and less fragile which does the matching on `CompilePhase.BEFORE_MACRO_EXPANSION`. - Allowed us to remove `CHECKCAST_ARRAY`. - Noticed that `IRNode.SUBTYPE_CHECK` had the wrong default `CompilePhase` set (`CompilePhase.PRINT_IDEAL`). I've changed that by introducing a new `IRNode.macroNodes()` method which sets it to `CompilePhase.BEFORE_MACRO_EXPANSION` (this means if you omit `phase = ...` it will fall back to `CompilePhase.BEFORE_MACRO_EXPANSION` when using `IRNode.SUBTYPE_CHECK`). - This could also be upstreamed to mainline. - As a result, I've noticed that `InlineTypeIRNode` is not initialized when we trying to fetch the default compile phases in the flag VM. Added `InlineTypeIRNode.forceStaticInitialization()` to `IRNode` and removed the other call. This should now ensure that we always have properly initialized the Valhalla specific IR nodes. Thanks, Christian ------------- Commit messages: - Only run test97-100 with MonomorphicArrayCheck enabled - 8343423: [lworld] compiler/valhalla/inlinetypes/TestArrays.java IR mismatches after after merging JDK-8334060 in jdk-24+18 Changes: https://git.openjdk.org/valhalla/pull/1296/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1296&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343423 Stats: 52 lines in 5 files changed: 31 ins; 7 del; 14 mod Patch: https://git.openjdk.org/valhalla/pull/1296.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1296/head:pull/1296 PR: https://git.openjdk.org/valhalla/pull/1296 From chagedorn at openjdk.org Thu Nov 7 09:35:30 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 7 Nov 2024 09:35:30 GMT Subject: [lworld] RFR: 8343423: [lworld] compiler/valhalla/inlinetypes/TestArrays.java IR mismatches after after merging JDK-8334060 in jdk-24+18 [v2] In-Reply-To: References: Message-ID: > There are several events that need to be taken into consideration to understand why `TestArray::test97-100()` are now failing after the merge of JDK-24+18: > > ### Background > #### Original Intent of `test95-101()`: > Orignally, the tests were added with [JDK-8251442](https://bugs.openjdk.org/browse/JDK-8251442) to check that sub type checks are properly folded with a new regex `CHECKCAST_ARRAY`. Back there, we did not have the possibility to match on compilation phases. We could only match on the output of `PrintIdeal` or `PrintOptoAssembly`. `PrintIdeal` is after the macro node expansion and thus `SubTypeCheck` nodes cannot be found anymore. As an alternative, a matching on `PrintOptoAssembly` was chosen by matching multiple lines. > > Note that only `test101()` is a positive test for a sub type check (it requires that one is found) while `test95-100()` are negative tests that checks the absense of a sub type check. > > #### Matching on Multiple Lines in Opto Assembly Is Fragile > As seen in the past, matching multiples lines on Opto Assembly is fragile when some unrelated instructions are inserted in between (for example spills). The regexes can become quite complicated and also slow to process. > > #### `CHECKCAST_ARRAY` Stopped Working Correctly at some Point Due to Scheduling Bool and If Apart > At some point, code emission started to schedule the nodes for the bool/comparison earlier, then scheduled an unrelated If and only then the actual jump for the sub type check. Example: > > ![image](https://github.com/user-attachments/assets/bc9fb4b9-3493-48a1-8c0a-f3cb5a22808f) > > The nodes for `74 compP_reg` are first emitted. Then we emit `101 testL_reg` together with `100 jmpCon_short` and only then `73 jmpConU`: > > --- 74 compP_rReg nodes --- > 0c4 B7: # out( B9 B8 ) <- in( B32 B21 B19 B6 ) Freq: 0.87277 > 0c4 # checkcastPP of RBP > 0c4 movl R11, [RBP + #8 (8-bit)] # compressed klass ptr > 0c8 encode_heap_oop_not_null R8,RBX > 10d movl [R13], R8 # compressed ptr > 111 movq R10, R13 # ptr -> long > 114 movq R8, RBX # ptr -> long > 117 xorq R8, R10 # long > 11a shrq R8, #22 > 11e movq RBX, precise [precise compiler/valhalla/inlinetypes/MyValue1: 0x00006ffd384d65a8 (compiler/valhalla/inlinetypes/MyInterface):Constant:exact * (java/lang/Cloneable,java/io/Serializable): :Constant:exact * # ptr > 128 decode_and_move_klass_not_null R9,R11 > 12b movq RBP, [R9 + #80 (8-bit)] # class > > --- 100 jmpCon_short nodes --- > 12f testq R8, R8 > 132... Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Update comments and use RunInfo instead of zero warm-up ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1296/files - new: https://git.openjdk.org/valhalla/pull/1296/files/352a931e..250ac01c Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1296&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1296&range=00-01 Stats: 64 lines in 1 file changed: 27 ins; 11 del; 26 mod Patch: https://git.openjdk.org/valhalla/pull/1296.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1296/head:pull/1296 PR: https://git.openjdk.org/valhalla/pull/1296 From chagedorn at openjdk.org Thu Nov 7 10:20:41 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 7 Nov 2024 10:20:41 GMT Subject: [lworld] RFR: 8343423: [lworld] compiler/valhalla/inlinetypes/TestArrays.java IR mismatches after after merging JDK-8334060 in jdk-24+18 [v3] In-Reply-To: References: Message-ID: > There are several events that need to be taken into consideration to understand why `TestArray::test97-100()` are now failing after the merge of JDK-24+18: > > ### Background > #### Original Intent of `test95-101()`: > Orignally, the tests were added with [JDK-8251442](https://bugs.openjdk.org/browse/JDK-8251442) to check that sub type checks are properly folded with a new regex `CHECKCAST_ARRAY`. Back there, we did not have the possibility to match on compilation phases. We could only match on the output of `PrintIdeal` or `PrintOptoAssembly`. `PrintIdeal` is after the macro node expansion and thus `SubTypeCheck` nodes cannot be found anymore. As an alternative, a matching on `PrintOptoAssembly` was chosen by matching multiple lines. > > Note that only `test101()` is a positive test for a sub type check (it requires that one is found) while `test95-100()` are negative tests that checks the absense of a sub type check. > > #### Matching on Multiple Lines in Opto Assembly Is Fragile > As seen in the past, matching multiples lines on Opto Assembly is fragile when some unrelated instructions are inserted in between (for example spills). The regexes can become quite complicated and also slow to process. > > #### `CHECKCAST_ARRAY` Stopped Working Correctly at some Point Due to Scheduling Bool and If Apart > At some point, code emission started to schedule the nodes for the bool/comparison earlier, then scheduled an unrelated If and only then the actual jump for the sub type check. Example: > > ![image](https://github.com/user-attachments/assets/bc9fb4b9-3493-48a1-8c0a-f3cb5a22808f) > > The nodes for `74 compP_reg` are first emitted. Then we emit `101 testL_reg` together with `100 jmpCon_short` and only then `73 jmpConU`: > > --- 74 compP_rReg nodes --- > 0c4 B7: # out( B9 B8 ) <- in( B32 B21 B19 B6 ) Freq: 0.87277 > 0c4 # checkcastPP of RBP > 0c4 movl R11, [RBP + #8 (8-bit)] # compressed klass ptr > 0c8 encode_heap_oop_not_null R8,RBX > 10d movl [R13], R8 # compressed ptr > 111 movq R10, R13 # ptr -> long > 114 movq R8, RBX # ptr -> long > 117 xorq R8, R10 # long > 11a shrq R8, #22 > 11e movq RBX, precise [precise compiler/valhalla/inlinetypes/MyValue1: 0x00006ffd384d65a8 (compiler/valhalla/inlinetypes/MyInterface):Constant:exact * (java/lang/Cloneable,java/io/Serializable): :Constant:exact * # ptr > 128 decode_and_move_klass_not_null R9,R11 > 12b movq RBP, [R9 + #80 (8-bit)] # class > > --- 100 jmpCon_short nodes --- > 12f testq R8, R8 > 132... Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Update comment again ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1296/files - new: https://git.openjdk.org/valhalla/pull/1296/files/250ac01c..c0fbd0c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1296&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1296&range=01-02 Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.org/valhalla/pull/1296.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1296/head:pull/1296 PR: https://git.openjdk.org/valhalla/pull/1296 From chagedorn at openjdk.org Thu Nov 7 10:34:04 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 7 Nov 2024 10:34:04 GMT Subject: [lworld] RFR: 8343423: [lworld] compiler/valhalla/inlinetypes/TestArrays.java IR mismatches after after merging JDK-8334060 in jdk-24+18 [v4] In-Reply-To: References: Message-ID: > There are several events that need to be taken into consideration to understand why `TestArray::test97-100()` are now failing after the merge of JDK-24+18: > > ### Background > #### Original Intent of `test95-101()`: > Orignally, the tests were added with [JDK-8251442](https://bugs.openjdk.org/browse/JDK-8251442) to check that sub type checks are properly folded with a new regex `CHECKCAST_ARRAY`. Back there, we did not have the possibility to match on compilation phases. We could only match on the output of `PrintIdeal` or `PrintOptoAssembly`. `PrintIdeal` is after the macro node expansion and thus `SubTypeCheck` nodes cannot be found anymore. As an alternative, a matching on `PrintOptoAssembly` was chosen by matching multiple lines. > > Note that only `test101()` is a positive test for a sub type check (it requires that one is found) while `test95-100()` are negative tests that checks the absense of a sub type check. > > #### Matching on Multiple Lines in Opto Assembly Is Fragile > As seen in the past, matching multiples lines on Opto Assembly is fragile when some unrelated instructions are inserted in between (for example spills). The regexes can become quite complicated and also slow to process. > > #### `CHECKCAST_ARRAY` Stopped Working Correctly at some Point Due to Scheduling Bool and If Apart > At some point, code emission started to schedule the nodes for the bool/comparison earlier, then scheduled an unrelated If and only then the actual jump for the sub type check. Example: > > ![image](https://github.com/user-attachments/assets/bc9fb4b9-3493-48a1-8c0a-f3cb5a22808f) > > The nodes for `74 compP_reg` are first emitted. Then we emit `101 testL_reg` together with `100 jmpCon_short` and only then `73 jmpConU`: > > --- 74 compP_rReg nodes --- > 0c4 B7: # out( B9 B8 ) <- in( B32 B21 B19 B6 ) Freq: 0.87277 > 0c4 # checkcastPP of RBP > 0c4 movl R11, [RBP + #8 (8-bit)] # compressed klass ptr > 0c8 encode_heap_oop_not_null R8,RBX > 10d movl [R13], R8 # compressed ptr > 111 movq R10, R13 # ptr -> long > 114 movq R8, RBX # ptr -> long > 117 xorq R8, R10 # long > 11a shrq R8, #22 > 11e movq RBX, precise [precise compiler/valhalla/inlinetypes/MyValue1: 0x00006ffd384d65a8 (compiler/valhalla/inlinetypes/MyInterface):Constant:exact * (java/lang/Cloneable,java/io/Serializable): :Constant:exact * # ptr > 128 decode_and_move_klass_not_null R9,R11 > 12b movq RBP, [R9 + #80 (8-bit)] # class > > --- 100 jmpCon_short nodes --- > 12f testq R8, R8 > 132... Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Tobias Hartmann ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1296/files - new: https://git.openjdk.org/valhalla/pull/1296/files/c0fbd0c2..b17ee7c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1296&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1296&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1296.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1296/head:pull/1296 PR: https://git.openjdk.org/valhalla/pull/1296 From thartmann at openjdk.org Thu Nov 7 10:34:04 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 7 Nov 2024 10:34:04 GMT Subject: [lworld] RFR: 8343423: [lworld] compiler/valhalla/inlinetypes/TestArrays.java IR mismatches after after merging JDK-8334060 in jdk-24+18 [v3] In-Reply-To: References:

Message-ID: On Thu, 7 Nov 2024 10:20:41 GMT, Christian Hagedorn wrote: >> There are several events that need to be taken into consideration to understand why `TestArray::test97-100()` are now failing after the merge of JDK-24+18: >> >> ### Background >> #### Original Intent of `test95-101()`: >> Orignally, the tests were added with [JDK-8251442](https://bugs.openjdk.org/browse/JDK-8251442) to check that sub type checks are properly folded with a new regex `CHECKCAST_ARRAY`. Back there, we did not have the possibility to match on compilation phases. We could only match on the output of `PrintIdeal` or `PrintOptoAssembly`. `PrintIdeal` is after the macro node expansion and thus `SubTypeCheck` nodes cannot be found anymore. As an alternative, a matching on `PrintOptoAssembly` was chosen by matching multiple lines. >> >> Note that only `test101()` is a positive test for a sub type check (it requires that one is found) while `test95-100()` are negative tests that checks the absense of a sub type check. >> >> #### Matching on Multiple Lines in Opto Assembly Is Fragile >> As seen in the past, matching multiples lines on Opto Assembly is fragile when some unrelated instructions are inserted in between (for example spills). The regexes can become quite complicated and also slow to process. >> >> #### `CHECKCAST_ARRAY` Stopped Working Correctly at some Point Due to Scheduling Bool and If Apart >> At some point, code emission started to schedule the nodes for the bool/comparison earlier, then scheduled an unrelated If and only then the actual jump for the sub type check. Example: >> >> ![image](https://github.com/user-attachments/assets/bc9fb4b9-3493-48a1-8c0a-f3cb5a22808f) >> >> The nodes for `74 compP_reg` are first emitted. Then we emit `101 testL_reg` together with `100 jmpCon_short` and only then `73 jmpConU`: >> >> --- 74 compP_rReg nodes --- >> 0c4 B7: # out( B9 B8 ) <- in( B32 B21 B19 B6 ) Freq: 0.87277 >> 0c4 # checkcastPP of RBP >> 0c4 movl R11, [RBP + #8 (8-bit)] # compressed klass ptr >> 0c8 encode_heap_oop_not_null R8,RBX >> 10d movl [R13], R8 # compressed ptr >> 111 movq R10, R13 # ptr -> long >> 114 movq R8, RBX # ptr -> long >> 117 xorq R8, R10 # long >> 11a shrq R8, #22 >> 11e movq RBX, precise [precise compiler/valhalla/inlinetypes/MyValue1: 0x00006ffd384d65a8 (compiler/valhalla/inlinetypes/MyInterface):Constant:exact * (java/lang/Cloneable,java/io/Serializable): :Constant:exact * # ptr >> 128 decode_and_move_klass_not_null R9,R11 >> 12b movq RBP, [R9 + #80 (8-bit)] # cl... > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Update comment again Nice analysis Christian! Thanks for the detailed description, this will be useful for future reference. test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java line 2423: > 2421: // At runtime, we will hit the ArrayStoreException in the first execution when array is a MyValue1[]. > 2422: // With the default IR framework warm-up, we will profile the ArrayStoreException in the interpreter and > 2423: // pass it in the MDO to the C2 compiler which treat these exceptions as traps being hit (see Suggestion: // pass it in the MDO to the C2 compiler which treats these exceptions as traps being hit (see test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java line 2427: > 2425: // type Object[] to an exact type before the first sub type check because we've seen too many traps being taken > 2426: // at that bci due to the ArrayStoreException that was hit at the very same bci (see Compile::too_many_traps() > 2427: // which checks that zero traps have been taken so far). Thus, neither the first sub type check for the array Suggestion: // which checks that zero traps have been taken so far). Thus, neither the first sub type check for the array test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java line 2430: > 2428: // check cast nor the second sub type check for the instanceof can be removed. > 2429: // By not executing test97() with MyValue1[] during warm-up, which would trigger the ArrayStoreException, > 2430: // we will not observe an ArrayStoreException before C2 compilation. Note that C2 also require Suggestion: // we will not observe an ArrayStoreException before C2 compilation. Note that C2 also requires ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1296#pullrequestreview-2420553021 PR Review Comment: https://git.openjdk.org/valhalla/pull/1296#discussion_r1832433007 PR Review Comment: https://git.openjdk.org/valhalla/pull/1296#discussion_r1832433451 PR Review Comment: https://git.openjdk.org/valhalla/pull/1296#discussion_r1832433907 From chagedorn at openjdk.org Thu Nov 7 10:34:04 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 7 Nov 2024 10:34:04 GMT Subject: [lworld] RFR: 8343423: [lworld] compiler/valhalla/inlinetypes/TestArrays.java IR mismatches after after merging JDK-8334060 in jdk-24+18 [v3] In-Reply-To: References:

Message-ID: <7OxKVRP3q-0LWn86ih78dTD76Yt3ObErNI8BFgLGDTc=.7322c859-9676-4c29-81ca-39ac4e9dd771@github.com> On Thu, 7 Nov 2024 10:20:41 GMT, Christian Hagedorn wrote: >> There are several events that need to be taken into consideration to understand why `TestArray::test97-100()` are now failing after the merge of JDK-24+18: >> >> ### Background >> #### Original Intent of `test95-101()`: >> Orignally, the tests were added with [JDK-8251442](https://bugs.openjdk.org/browse/JDK-8251442) to check that sub type checks are properly folded with a new regex `CHECKCAST_ARRAY`. Back there, we did not have the possibility to match on compilation phases. We could only match on the output of `PrintIdeal` or `PrintOptoAssembly`. `PrintIdeal` is after the macro node expansion and thus `SubTypeCheck` nodes cannot be found anymore. As an alternative, a matching on `PrintOptoAssembly` was chosen by matching multiple lines. >> >> Note that only `test101()` is a positive test for a sub type check (it requires that one is found) while `test95-100()` are negative tests that checks the absense of a sub type check. >> >> #### Matching on Multiple Lines in Opto Assembly Is Fragile >> As seen in the past, matching multiples lines on Opto Assembly is fragile when some unrelated instructions are inserted in between (for example spills). The regexes can become quite complicated and also slow to process. >> >> #### `CHECKCAST_ARRAY` Stopped Working Correctly at some Point Due to Scheduling Bool and If Apart >> At some point, code emission started to schedule the nodes for the bool/comparison earlier, then scheduled an unrelated If and only then the actual jump for the sub type check. Example: >> >> ![image](https://github.com/user-attachments/assets/bc9fb4b9-3493-48a1-8c0a-f3cb5a22808f) >> >> The nodes for `74 compP_reg` are first emitted. Then we emit `101 testL_reg` together with `100 jmpCon_short` and only then `73 jmpConU`: >> >> --- 74 compP_rReg nodes --- >> 0c4 B7: # out( B9 B8 ) <- in( B32 B21 B19 B6 ) Freq: 0.87277 >> 0c4 # checkcastPP of RBP >> 0c4 movl R11, [RBP + #8 (8-bit)] # compressed klass ptr >> 0c8 encode_heap_oop_not_null R8,RBX >> 10d movl [R13], R8 # compressed ptr >> 111 movq R10, R13 # ptr -> long >> 114 movq R8, RBX # ptr -> long >> 117 xorq R8, R10 # long >> 11a shrq R8, #22 >> 11e movq RBX, precise [precise compiler/valhalla/inlinetypes/MyValue1: 0x00006ffd384d65a8 (compiler/valhalla/inlinetypes/MyInterface):Constant:exact * (java/lang/Cloneable,java/io/Serializable): :Constant:exact * # ptr >> 128 decode_and_move_klass_not_null R9,R11 >> 12b movq RBP, [R9 + #80 (8-bit)] # cl... > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Update comment again Thanks Tobias for your review and the offline discussion! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1296#issuecomment-2461869803 From chagedorn at openjdk.org Thu Nov 7 10:34:04 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 7 Nov 2024 10:34:04 GMT Subject: [lworld] Integrated: 8343423: [lworld] compiler/valhalla/inlinetypes/TestArrays.java IR mismatches after after merging JDK-8334060 in jdk-24+18 In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 15:28:46 GMT, Christian Hagedorn wrote: > There are several events that need to be taken into consideration to understand why `TestArray::test97-100()` are now failing after the merge of JDK-24+18: > > ### Background > #### Original Intent of `test95-101()`: > Orignally, the tests were added with [JDK-8251442](https://bugs.openjdk.org/browse/JDK-8251442) to check that sub type checks are properly folded with a new regex `CHECKCAST_ARRAY`. Back there, we did not have the possibility to match on compilation phases. We could only match on the output of `PrintIdeal` or `PrintOptoAssembly`. `PrintIdeal` is after the macro node expansion and thus `SubTypeCheck` nodes cannot be found anymore. As an alternative, a matching on `PrintOptoAssembly` was chosen by matching multiple lines. > > Note that only `test101()` is a positive test for a sub type check (it requires that one is found) while `test95-100()` are negative tests that checks the absense of a sub type check. > > #### Matching on Multiple Lines in Opto Assembly Is Fragile > As seen in the past, matching multiples lines on Opto Assembly is fragile when some unrelated instructions are inserted in between (for example spills). The regexes can become quite complicated and also slow to process. > > #### `CHECKCAST_ARRAY` Stopped Working Correctly at some Point Due to Scheduling Bool and If Apart > At some point, code emission started to schedule the nodes for the bool/comparison earlier, then scheduled an unrelated If and only then the actual jump for the sub type check. Example: > > ![image](https://github.com/user-attachments/assets/bc9fb4b9-3493-48a1-8c0a-f3cb5a22808f) > > The nodes for `74 compP_reg` are first emitted. Then we emit `101 testL_reg` together with `100 jmpCon_short` and only then `73 jmpConU`: > > --- 74 compP_rReg nodes --- > 0c4 B7: # out( B9 B8 ) <- in( B32 B21 B19 B6 ) Freq: 0.87277 > 0c4 # checkcastPP of RBP > 0c4 movl R11, [RBP + #8 (8-bit)] # compressed klass ptr > 0c8 encode_heap_oop_not_null R8,RBX > 10d movl [R13], R8 # compressed ptr > 111 movq R10, R13 # ptr -> long > 114 movq R8, RBX # ptr -> long > 117 xorq R8, R10 # long > 11a shrq R8, #22 > 11e movq RBX, precise [precise compiler/valhalla/inlinetypes/MyValue1: 0x00006ffd384d65a8 (compiler/valhalla/inlinetypes/MyInterface):Constant:exact * (java/lang/Cloneable,java/io/Serializable): :Constant:exact * # ptr > 128 decode_and_move_klass_not_null R9,R11 > 12b movq RBP, [R9 + #80 (8-bit)] # class > > --- 100 jmpCon_short nodes --- > 12f testq R8, R8 > 132... This pull request has now been integrated. Changeset: ba508a3b Author: Christian Hagedorn URL: https://git.openjdk.org/valhalla/commit/ba508a3b02d5009a3696b17bc1522e82e5eaa6a9 Stats: 95 lines in 5 files changed: 48 ins; 7 del; 40 mod 8343423: [lworld] compiler/valhalla/inlinetypes/TestArrays.java IR mismatches after after merging JDK-8334060 in jdk-24+18 Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1296 From bkilambi at openjdk.org Thu Nov 7 15:40:58 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 7 Nov 2024 15:40:58 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v2] In-Reply-To: References:

Message-ID: On Thu, 7 Nov 2024 07:24:42 GMT, Jatin Bhateja wrote: >> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove intrinsification of conversion methods in Float16 > > My bad, I meant the other way round i.e. integral to float16 conversion case, which takes a slow path route currently. Consider the following micro kernel:- > > > public class float16_allocation { > public static float micro(int value) { > Float16 val = Float16.valueOf(value); // [a] > return val.floatValue(); // [b] > } > > public static void main(String [] args) { > float res = 0.0f; > for (int i = 0; i < 100000; i++) { > res += micro(i); > } > System.out.println("[res]" + res); > } > } > > > Here, the integer parameter is first converted to float16 value [a], valueOf routine first typecast integer value to double type and then passes it to Float16.valueOf(double) routine resulting in a bulky JIT sequence. > > We can outline the following code [c] into a new leaf routine returning a short value, and directly pass it to the Float16 constructor similar to https://github.com/openjdk/valhalla/blob/lworld%2Bfp16/src/java.base/share/classes/java/lang/Float16.java#L411 > > New routine can then be intrinsified to yield ConvI2HF IR, which then gets boxed as a value object. Since Float16 is a value type, it will scalarize its field accesses, thus directly forwarding HF ('short') value to subsequent ConvHF2F [b]. On mainline where Float16 is a value-based class we can bank on escape analysis to eliminate redundant boxing allocations. > > > > public static Float16 valueOf(int value) { > // int -> double conversion is exact > return valueOf((double)value); // [c] > } > > > > We can spill this over to another patch if you suggest it, kindly let me know your views. > > Best Regards, > Jatin Hi @jatin-bhateja , Thanks for the reminder. I remember asking you in a previous email about the reverse conversions and I forgot about that myself. I am thinking if we have to intrinsify, can we not directly intrinsify Float16 valueOf() routines in Float16 itself instead of defining a new routine in Integer.java and then calling it in the Float16.valueOf() method and intrinsifying the one in Integer.java? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1283#issuecomment-2462547565 From bkilambi at openjdk.org Thu Nov 7 15:40:58 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 7 Nov 2024 15:40:58 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v2] In-Reply-To: References:

Message-ID: On Thu, 7 Nov 2024 07:24:42 GMT, Jatin Bhateja wrote: >> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove intrinsification of conversion methods in Float16 > > My bad, I meant the other way round i.e. integral to float16 conversion case, which takes a slow path route currently. Consider the following micro kernel:- > > > public class float16_allocation { > public static float micro(int value) { > Float16 val = Float16.valueOf(value); // [a] > return val.floatValue(); // [b] > } > > public static void main(String [] args) { > float res = 0.0f; > for (int i = 0; i < 100000; i++) { > res += micro(i); > } > System.out.println("[res]" + res); > } > } > > > Here, the integer parameter is first converted to float16 value [a], valueOf routine first typecast integer value to double type and then passes it to Float16.valueOf(double) routine resulting in a bulky JIT sequence. > > We can outline the following code [c] into a new leaf routine returning a short value, and directly pass it to the Float16 constructor similar to https://github.com/openjdk/valhalla/blob/lworld%2Bfp16/src/java.base/share/classes/java/lang/Float16.java#L411 > > New routine can then be intrinsified to yield ConvI2HF IR, which then gets boxed as a value object. Since Float16 is a value type, it will scalarize its field accesses, thus directly forwarding HF ('short') value to subsequent ConvHF2F [b]. On mainline where Float16 is a value-based class we can bank on escape analysis to eliminate redundant boxing allocations. > > > > public static Float16 valueOf(int value) { > // int -> double conversion is exact > return valueOf((double)value); // [c] > } > > > > We can spill this over to another patch if you suggest it, kindly let me know your views. > > Best Regards, > Jatin > Hi @jatin-bhateja , Thanks for the reminder. I remember asking you in a previous email about the reverse conversions and I forgot about that myself. I am thinking if we have to intrinsify, can we not directly intrinsify Float16 valueOf() routines in Float16 Idea here is to avoid complexifying scalar intrinsic by delegating boxing to expander, otherwise we will also have to pass additional box type argument. Instead, we can rely explicit boxing happening in Java side and bank on escape analysis for its elimination thus directly exposing ConvI2HF to its user. > new routine in Integer.java and then calling it in the Float16.valueOf() method and intrinsifying the one in Integer.java? No, I am not suggesting to add .float16Value() API in existing primitive classes for time being, let Joe decide that. If you intrinsify leaf level wrapper routine, then we just need to plug that into Integer.float16Value(), we will lose this flexibility if we intrinsify Float16.valueOf(int). ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1283#issuecomment-2463986341 From jbhateja at openjdk.org Fri Nov 8 07:59:26 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 8 Nov 2024 07:59:26 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v2] In-Reply-To: References:

Message-ID: On Thu, 7 Nov 2024 15:38:36 GMT, Bhavana Kilambi wrote: > I would prefer if I can do this in a separate patch please? I feel this patch is big enough. I will add some Ideal/Identity transformations as required for the new IR (for ex. ConvHF2I <-> ConvI2HF return the half float etc) in the new patch. Sounds good! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1283#issuecomment-2463986642 From bkilambi at openjdk.org Fri Nov 8 10:26:36 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Fri, 8 Nov 2024 10:26:36 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v2] In-Reply-To: References:

Message-ID: On Fri, 8 Nov 2024 07:54:47 GMT, Jatin Bhateja wrote: > No, I am not suggesting to add .float16Value() API in existing primitive classes for time being, let Joe decide that. If you intrinsify leaf level wrapper routine, then we just need to plug that into Integer.float16Value(), we will lose this flexibility if we intrinsify Float16.valueOf(int). Thanks for the explanation. So from what I understand - we currently have four valueOf() routines in Float16.java, float16 to int/long/float/double. The valueOf(long) calls valueOf(float) inside it which contains an intrinsified routine already so we have ConvL2F -> ConvF2HF being generated for that. I can add an Ideal optimization to generate ConvL2HF for this sequence. For `valueOf(int)` which calls `valueOf(double)` -> I will add a new leaf routine something like `short d2hf(double d)` in Float16.java which I will intrinsify to generate ConvD2HF and this routine will be called in valueOf(int i) - public static Float16 valueOf(int value) { return Float16(d2hf((double) value); } This would probably generate a ConvI2D -> ConvD2HF which can be optimized to ConvI2HF. The same routine can be called in `Float16 valueOf(double value)` as well which should generate ConvD2HF. Is this ok? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1283#issuecomment-2464329525 From bkilambi at openjdk.org Fri Nov 8 10:26:37 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Fri, 8 Nov 2024 10:26:37 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v2] In-Reply-To: References:

Message-ID: On Thu, 14 Nov 2024 09:41:14 GMT, Jatin Bhateja wrote: >> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove intrinsification of conversion methods in Float16 > > src/hotspot/share/opto/cfgnode.cpp line 1907: > >> 1905: } else if (convert_op == Op_ConvHF2F || convert_op == Op_ConvF2HF || convert_op == Op_ConvHF2D || convert_op == Op_ConvHF2L) { >> 1906: return T_SHORT; >> 1907: } > > This transformation is moving conversion across the Phi node thereby saving expensive conversion instructions. > > `Phi (ConvHF2F src1) (ConvHF2F src2) => ConvHF2F (Phi src1 src2) > ` > > For the Op_ConvF2HF case, type parameter will be of float type and thus we will never enter control flow between L1905 - L1907. > > I think it will be harmless if we remove convert_op == Op_ConvF2HF check... We can also update existing test for new conversion test/hotspot/jtreg/compiler/c2/irTests/TestPhiDuplicatedConversion.java ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1283#discussion_r1841879971 From bkilambi at openjdk.org Thu Nov 14 11:17:45 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 14 Nov 2024 11:17:45 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v2] In-Reply-To: References:

Message-ID: On Thu, 14 Nov 2024 09:43:49 GMT, Jatin Bhateja wrote: >> src/hotspot/share/opto/cfgnode.cpp line 1907: >> >>> 1905: } else if (convert_op == Op_ConvHF2F || convert_op == Op_ConvF2HF || convert_op == Op_ConvHF2D || convert_op == Op_ConvHF2L) { >>> 1906: return T_SHORT; >>> 1907: } >> >> This transformation is moving conversion across the Phi node thereby saving expensive conversion instructions. >> >> `Phi (ConvHF2F src1) (ConvHF2F src2) => ConvHF2F (Phi src1 src2) >> ` >> >> For the Op_ConvF2HF case, type parameter will be of float type and thus we will never enter control flow between L1905 - L1907. >> >> I think it will be harmless if we remove convert_op == Op_ConvF2HF check... > > We can also update existing test for new conversion > > test/hotspot/jtreg/compiler/c2/irTests/TestPhiDuplicatedConversion.java > This transformation is moving conversion across the Phi node thereby saving expensive conversion instructions. > > `Phi (ConvHF2F src1) (ConvHF2F src2) => ConvHF2F (Phi src1 src2) ` > > For the Op_ConvF2HF case, type parameter will be of float type and thus we will never enter control flow between L1905 - L1907. > > I think it will be harmless if we remove convert_op == Op_ConvF2HF check... Hi @jatin-bhateja , I think that check should be there. The lines 1905-1907 will be reachable when get_convert_type() is called again with the dest_type (`short`) when it is supposed to return `short`. If this check is not there, it will return `T_INT`. For the following example - `rng.nextBoolean() ? Float.floatToFloat16(a) : Float.floatToFloat16(b) ` it will generate `ConvF2I` instead of `ConvF2HF`. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1283#discussion_r1843605982 From caleb.cushing at gmail.com Fri Nov 15 16:16:00 2024 From: caleb.cushing at gmail.com (Caleb Cushing) Date: Fri, 15 Nov 2024 11:16:00 -0500 Subject: Fwd: Null-Restricted and Nullable Types concern In-Reply-To: References: Message-ID: > It is not a goal to automatically re-interpret existing code?use of these features should be optional and explicitly opted in to (future work will explore mechanisms to request a bulk opt-in without needing to change individual types) Before anything makes it into the JDK I'd like to see the plan for this, especially since I do not believe such a feature should be released unless it has been applied to the entirety of the JDK. Without this the adoption will be almost as slow as JPMS (an aside on that I'd like progressive enforcement there so it could be possible to get there). Not to speak for anyone other than myself, the community seems to be leaning towards the conversion where non null is the default, and using marker annotations on packages,classes,modules. This or something like this to speed conversion would be appreciated. maybe the following (Evil tangent: let this only exist on module, I'd like to get modules actually moving, in a different email it'd be nice if jars without at least an automatic module would start failing to load) module org.example! {} // or ? package org.example.something!; // or ? could be used for speedy defaults on otherwise unmarked code. Some have taken to separating API and Fields though. How do these behave? given the following interface, static implementations (meaning they aren't doing real loads from an external database), that Stream::map arguments are marked "?" as nullable and use interface MyRepository { Stream! findFoos(); } class Foo {} given class MyRepositoryValueNeedsNullCheck implements MyRepository { Stream! findFoos() { return Stream.of(new Foo(), null); } } class MyRepositoryValueDoesNotNeedNullCheck implements MyRepository { Stream! findFoos() { return Stream.of(new Foo()); } } when MyRepositoryValueNeedsNullCheck findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) when MyRepositoryValueDoesNotNeedNullCheck findFoos().map( foo -> foo.toString()) will the above be considered "ok" since neither of them would actually create a runtime error? they should be considered ok in my opinion. class MyRepositoryValueNeedsNullCheck implements MyRepository { Stream! findFoos() { return /// do something with a database or something that cannot be known until runtime } } when MyRepositoryValueNeedsNullCheck findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) findFoos().map( foo -> foo.toString()) does the return on findFoos() do an implicit runtime check for the Stream throwing some good NPE error? will the map without the filter result in a compile time NPE? class MyRepositoryValueNeedsNullCheck implements MyRepository { Stream? findFoos() { return null; } } is this valid? I have a valid use case for what's more or less the inverse (where the interface is nullable, but the implementation is not) Will we be getting a way to assert variables with inferred types? `var! foo = null` (tangent: can we reopen mutability on var here? meaning val! foo or const! foo, that thing I foolishly voted against... and was wrong, it should exist (I hadn't used a language that had it yet, maybe I wasn't the only one), I don't like const because I see that as a static final) given Foo! foo; foo = new Foo(); valid so long as it's assigned before use? is partial markup really valid at compile time? interface MyRepository { Stream findFoos(); } I find the examples using this, but then Stream is nullable? it feels like if you define any nullability on a given type then the whole type should be fully marked up. In all of these stream examples, the concept in checker framework is @PolyNull, will there be a way of writing functional interfaces that defines that the implementers can use them in a PolyNull fashion? meaning the null check necessity can't be known until usage is defined? Will the compiler strip if null checks out of the bytecode if it determines they are no longer necessary? probably not necessary to define in the jep. -- Caleb Cushing Appointments https://calendly.com/caleb-cushing https://xenoterracide.com From brian.goetz at oracle.com Fri Nov 15 16:55:04 2024 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 15 Nov 2024 11:55:04 -0500 Subject: Fwd: Null-Restricted and Nullable Types concern In-Reply-To: References:

Message-ID: > Before anything makes it into the JDK I'd like to see the plan for > this This is a valid opinion, but let's be clear what you're saying: it means you think that having a solid, committed flippening story is so important that you're willing to say that "no one can have the benefits of valhalla for another 5-10 years, or maybe ever." That's a pretty big deal.? (And, yes, sometimes we are willing to make such tradeoffs, but it's still a pretty big deal.) But, maybe that's not what you meant.? Maybe what you meant is "I want to impress on you how important I think it is to get to where the nullity default is flipped."? If that's what you mean, yes, we understand how strongly some people feel about this.? Our antipathy to attacking this problem *right now* is not because we don't think it is a real pain point, but one of practicality: it's not possible to solve all the problems simultaneously and still deliver something in a mortal lifetime. Or maybe what you meant is "there seem to be simple solutions to this problem, why wouldn't we jump on them?"? Unfortunately just because a solution is obvious (like "let's just put a bang on the module directive"), doesn't mean they are simple. (To be clear, you are asking for what would be, by far, the biggest change to Java ever -- reinterpreting existing code to mean something else based on a directive _in another file_.)? Rest assured that we've seen these "solutions" proposed before, and our lack of enthusiasm for them is that they may well create more problems than they solve. So, we get that adding null restriction to Java will significantly worsen the fact that "nullable" is yet another bad default; this is pretty clear.? But if we really thought that we can't do Valhalla until we reinterpret all the world's Java code with a new default, the rational response might well be to cancel the project.? Sometimes things have to be separated out into smaller, dependent chunks; sometimes we even have to accept that we might not even get to all the later chunks. I get that you would be more comfortable if we had a committed, bulletproof plan for this.? But I think I can say with confidence that we won't; we need to focus our attention on the many nearly-impossible problems we already have in front of us before adding more to our plate. On 11/15/2024 11:16 AM, Caleb Cushing wrote: >> It is not a goal to automatically re-interpret existing code?use of these features should be optional and explicitly opted in to (future work will explore mechanisms to request a bulk opt-in without needing to change individual types) > Before anything makes it into the JDK I'd like to see the plan for > this, especially since I do not believe such a feature should be > released unless it has been applied to the entirety of the JDK. > Without this the adoption will be almost as slow as JPMS (an aside on > that I'd like progressive enforcement there so it could be possible to > get there). > > Not to speak for anyone other than myself, the community seems to be > leaning towards the conversion where non null is the default, and > using marker annotations on packages,classes,modules. This or > something like this to speed conversion would be appreciated. maybe > the following (Evil tangent: let this only exist on module, I'd like > to get modules actually moving, in a different email it'd be nice if > jars without at least an automatic module would start failing to load) > > module org.example! {} // or ? > package org.example.something!; // or ? > > could be used for speedy defaults on otherwise unmarked code. Some > have taken to separating API and Fields though. > > How do these behave? given the following interface, static > implementations (meaning they aren't doing real loads from an external > database), that Stream::map arguments are marked "?" as nullable and > use > > interface MyRepository { > Stream! findFoos(); > } > > class Foo {} > > given > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream! findFoos() { > return Stream.of(new Foo(), null); > } > } > > class MyRepositoryValueDoesNotNeedNullCheck implements MyRepository { > Stream! findFoos() { > return Stream.of(new Foo()); > } > } > > when MyRepositoryValueNeedsNullCheck > findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) > > when MyRepositoryValueDoesNotNeedNullCheck > findFoos().map( foo -> foo.toString()) > > will the above be considered "ok" since neither of them would actually > create a runtime error? they should be considered ok in my opinion. > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream! findFoos() { > return /// do something with a database or something that > cannot be known until runtime > } > } > when MyRepositoryValueNeedsNullCheck > findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) > findFoos().map( foo -> foo.toString()) > > does the return on findFoos() do an implicit runtime check for the > Stream throwing some good NPE error? will the map without the filter > result in a compile time NPE? > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream? findFoos() { > return null; > } > } > > is this valid? I have a valid use case for what's more or less the > inverse (where the interface is nullable, but the implementation is > not) > > Will we be getting a way to assert variables with inferred types? > > `var! foo = null` (tangent: can we reopen mutability on var here? > meaning val! foo or const! foo, that thing I foolishly voted > against... and was wrong, it should exist (I hadn't used a language > that had it yet, maybe I wasn't the only one), I don't like const > because I see that as a static final) > > given > > Foo! foo; > foo = new Foo(); > > valid so long as it's assigned before use? > > is partial markup really valid at compile time? > > interface MyRepository { > Stream findFoos(); > } > > I find the examples using this, but then Stream is nullable? it feels > like if you define any nullability on a given type then the whole type > should be fully marked up. > > In all of these stream examples, the concept in checker framework is > @PolyNull, will there be a way of writing functional interfaces that > defines that the implementers can use them in a PolyNull fashion? > meaning the null check necessity can't be known until usage is > defined? > > Will the compiler strip if null checks out of the bytecode if it > determines they are no longer necessary? probably not necessary to > define in the jep. -------------- next part -------------- An HTML attachment was scrubbed... URL: From caleb.cushing at gmail.com Fri Nov 15 17:13:49 2024 From: caleb.cushing at gmail.com (Caleb Cushing) Date: Fri, 15 Nov 2024 12:13:49 -0500 Subject: Fwd: Null-Restricted and Nullable Types concern In-Reply-To: References:

Message-ID: > This is a valid opinion, but let's be clear what you're saying: it means you think that having a solid, committed flippening story is so important that you're willing to say that "no one can have the benefits of valhalla for another 5-10 years, or maybe ever." That's a pretty big deal. (And, yes, sometimes we are willing to make such tradeoffs, but it's still a pretty big deal.) I just want to say that I get that, but also things that go into the JDK tend to get stuck that way. I would like this feature 10 years ago, but I don't want to get stuck in a bad situation that we can't back out of because it might break someone's code. There are weird (unrelated) situations where I do not understand why the behavior has been preserved when it doesn't make sense, only because someone, somewhere, might be relying on the implicit (NPE) failure which was likely a mistake in coding. So even some semblance of an idea for a plan, even if it's not committed to, like this is a "preliminary idea which could change"; would be good. I'm just concerned about delivering a "stable" feature that can't change because it might break someone's code. Please also be aware that I wouldn't be commenting at all if I didn't care, or wasn't excited about this impossible work. In any sense, the JEP didn't seem to discuss the exact examples mentioned, so hopefully we can move on to those ;) although perhaps they are "future work" On Fri, Nov 15, 2024 at 11:55?AM Brian Goetz wrote: > > Before anything makes it into the JDK I'd like to see the plan for > this > > > This is a valid opinion, but let's be clear what you're saying: it means you think that having a solid, committed flippening story is so important that you're willing to say that "no one can have the benefits of valhalla for another 5-10 years, or maybe ever." That's a pretty big deal. (And, yes, sometimes we are willing to make such tradeoffs, but it's still a pretty big deal.) > > But, maybe that's not what you meant. Maybe what you meant is "I want to impress on you how important I think it is to get to where the nullity default is flipped." If that's what you mean, yes, we understand how strongly some people feel about this. Our antipathy to attacking this problem *right now* is not because we don't think it is a real pain point, but one of practicality: it's not possible to solve all the problems simultaneously and still deliver something in a mortal lifetime. > > Or maybe what you meant is "there seem to be simple solutions to this problem, why wouldn't we jump on them?" Unfortunately just because a solution is obvious (like "let's just put a bang on the module directive"), doesn't mean they are simple. (To be clear, you are asking for what would be, by far, the biggest change to Java ever -- reinterpreting existing code to mean something else based on a directive _in another file_.) Rest assured that we've seen these "solutions" proposed before, and our lack of enthusiasm for them is that they may well create more problems than they solve. > > So, we get that adding null restriction to Java will significantly worsen the fact that "nullable" is yet another bad default; this is pretty clear. But if we really thought that we can't do Valhalla until we reinterpret all the world's Java code with a new default, the rational response might well be to cancel the project. Sometimes things have to be separated out into smaller, dependent chunks; sometimes we even have to accept that we might not even get to all the later chunks. > > I get that you would be more comfortable if we had a committed, bulletproof plan for this. But I think I can say with confidence that we won't; we need to focus our attention on the many nearly-impossible problems we already have in front of us before adding more to our plate. > > > > > On 11/15/2024 11:16 AM, Caleb Cushing wrote: > > It is not a goal to automatically re-interpret existing code?use of these features should be optional and explicitly opted in to (future work will explore mechanisms to request a bulk opt-in without needing to change individual types) > > Before anything makes it into the JDK I'd like to see the plan for > this, especially since I do not believe such a feature should be > released unless it has been applied to the entirety of the JDK. > Without this the adoption will be almost as slow as JPMS (an aside on > that I'd like progressive enforcement there so it could be possible to > get there). > > Not to speak for anyone other than myself, the community seems to be > leaning towards the conversion where non null is the default, and > using marker annotations on packages,classes,modules. This or > something like this to speed conversion would be appreciated. maybe > the following (Evil tangent: let this only exist on module, I'd like > to get modules actually moving, in a different email it'd be nice if > jars without at least an automatic module would start failing to load) > > module org.example! {} // or ? > package org.example.something!; // or ? > > could be used for speedy defaults on otherwise unmarked code. Some > have taken to separating API and Fields though. > > How do these behave? given the following interface, static > implementations (meaning they aren't doing real loads from an external > database), that Stream::map arguments are marked "?" as nullable and > use > > interface MyRepository { > Stream! findFoos(); > } > > class Foo {} > > given > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream! findFoos() { > return Stream.of(new Foo(), null); > } > } > > class MyRepositoryValueDoesNotNeedNullCheck implements MyRepository { > Stream! findFoos() { > return Stream.of(new Foo()); > } > } > > when MyRepositoryValueNeedsNullCheck > findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) > > when MyRepositoryValueDoesNotNeedNullCheck > findFoos().map( foo -> foo.toString()) > > will the above be considered "ok" since neither of them would actually > create a runtime error? they should be considered ok in my opinion. > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream! findFoos() { > return /// do something with a database or something that > cannot be known until runtime > } > } > when MyRepositoryValueNeedsNullCheck > findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) > findFoos().map( foo -> foo.toString()) > > does the return on findFoos() do an implicit runtime check for the > Stream throwing some good NPE error? will the map without the filter > result in a compile time NPE? > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream? findFoos() { > return null; > } > } > > is this valid? I have a valid use case for what's more or less the > inverse (where the interface is nullable, but the implementation is > not) > > Will we be getting a way to assert variables with inferred types? > > `var! foo = null` (tangent: can we reopen mutability on var here? > meaning val! foo or const! foo, that thing I foolishly voted > against... and was wrong, it should exist (I hadn't used a language > that had it yet, maybe I wasn't the only one), I don't like const > because I see that as a static final) > > given > > Foo! foo; > foo = new Foo(); > > valid so long as it's assigned before use? > > is partial markup really valid at compile time? > > interface MyRepository { > Stream findFoos(); > } > > I find the examples using this, but then Stream is nullable? it feels > like if you define any nullability on a given type then the whole type > should be fully marked up. > > In all of these stream examples, the concept in checker framework is > @PolyNull, will there be a way of writing functional interfaces that > defines that the implementers can use them in a PolyNull fashion? > meaning the null check necessity can't be known until usage is > defined? > > Will the compiler strip if null checks out of the bytecode if it > determines they are no longer necessary? probably not necessary to > define in the jep. > > -- Caleb Cushing Appointments https://calendly.com/caleb-cushing https://xenoterracide.com From jbossons at gmail.com Fri Nov 15 23:05:42 2024 From: jbossons at gmail.com (John Bossons) Date: Fri, 15 Nov 2024 18:05:42 -0500 Subject: Fwd: Null-Restricted and Nullable Types concern In-Reply-To: References:

Message-ID: Can we please agree on whatever route gets Valhalla implemented fastest? Developers can work with whatever version emerges. The current JEP proposals are clear and hopefully can be implemented. Whether they are ideal is less important than the fact that they represent progress. JEP 401 alone would be a huge step forward. On Fri, Nov 15, 2024 at 12:44?PM Brian Goetz wrote: > Before anything makes it into the JDK I'd like to see the plan for > this > > > This is a valid opinion, but let's be clear what you're saying: it means > you think that having a solid, committed flippening story is so important > that you're willing to say that "no one can have the benefits of valhalla > for another 5-10 years, or maybe ever." That's a pretty big deal. (And, > yes, sometimes we are willing to make such tradeoffs, but it's still a > pretty big deal.) > > But, maybe that's not what you meant. Maybe what you meant is "I want to > impress on you how important I think it is to get to where the nullity > default is flipped." If that's what you mean, yes, we understand how > strongly some people feel about this. Our antipathy to attacking this > problem *right now* is not because we don't think it is a real pain point, > but one of practicality: it's not possible to solve all the problems > simultaneously and still deliver something in a mortal lifetime. > > Or maybe what you meant is "there seem to be simple solutions to this > problem, why wouldn't we jump on them?" Unfortunately just because a > solution is obvious (like "let's just put a bang on the module directive"), > doesn't mean they are simple. (To be clear, you are asking for what > would be, by far, the biggest change to Java ever -- reinterpreting > existing code to mean something else based on a directive _in another > file_.) Rest assured that we've seen these "solutions" proposed before, > and our lack of enthusiasm for them is that they may well create more > problems than they solve. > > So, we get that adding null restriction to Java will significantly worsen > the fact that "nullable" is yet another bad default; this is pretty clear. > But if we really thought that we can't do Valhalla until we reinterpret all > the world's Java code with a new default, the rational response might well > be to cancel the project. Sometimes things have to be separated out into > smaller, dependent chunks; sometimes we even have to accept that we might > not even get to all the later chunks. > > I get that you would be more comfortable if we had a committed, > bulletproof plan for this. But I think I can say with confidence that we > won't; we need to focus our attention on the many nearly-impossible > problems we already have in front of us before adding more to our plate. > > > > > On 11/15/2024 11:16 AM, Caleb Cushing wrote: > > It is not a goal to automatically re-interpret existing code?use of these features should be optional and explicitly opted in to (future work will explore mechanisms to request a bulk opt-in without needing to change individual types) > > Before anything makes it into the JDK I'd like to see the plan for > this, especially since I do not believe such a feature should be > released unless it has been applied to the entirety of the JDK. > Without this the adoption will be almost as slow as JPMS (an aside on > that I'd like progressive enforcement there so it could be possible to > get there). > > Not to speak for anyone other than myself, the community seems to be > leaning towards the conversion where non null is the default, and > using marker annotations on packages,classes,modules. This or > something like this to speed conversion would be appreciated. maybe > the following (Evil tangent: let this only exist on module, I'd like > to get modules actually moving, in a different email it'd be nice if > jars without at least an automatic module would start failing to load) > > module org.example! {} // or ? > package org.example.something!; // or ? > > could be used for speedy defaults on otherwise unmarked code. Some > have taken to separating API and Fields though. > > How do these behave? given the following interface, static > implementations (meaning they aren't doing real loads from an external > database), that Stream::map arguments are marked "?" as nullable and > use > > interface MyRepository { > Stream! findFoos(); > } > > class Foo {} > > given > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream! findFoos() { > return Stream.of(new Foo(), null); > } > } > > class MyRepositoryValueDoesNotNeedNullCheck implements MyRepository { > Stream! findFoos() { > return Stream.of(new Foo()); > } > } > > when MyRepositoryValueNeedsNullCheck > findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) > > when MyRepositoryValueDoesNotNeedNullCheck > findFoos().map( foo -> foo.toString()) > > will the above be considered "ok" since neither of them would actually > create a runtime error? they should be considered ok in my opinion. > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream! findFoos() { > return /// do something with a database or something that > cannot be known until runtime > } > } > when MyRepositoryValueNeedsNullCheck > findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) > findFoos().map( foo -> foo.toString()) > > does the return on findFoos() do an implicit runtime check for the > Stream throwing some good NPE error? will the map without the filter > result in a compile time NPE? > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream? findFoos() { > return null; > } > } > > is this valid? I have a valid use case for what's more or less the > inverse (where the interface is nullable, but the implementation is > not) > > Will we be getting a way to assert variables with inferred types? > > `var! foo = null` (tangent: can we reopen mutability on var here? > meaning val! foo or const! foo, that thing I foolishly voted > against... and was wrong, it should exist (I hadn't used a language > that had it yet, maybe I wasn't the only one), I don't like const > because I see that as a static final) > > given > > Foo! foo; > foo = new Foo(); > > valid so long as it's assigned before use? > > is partial markup really valid at compile time? > > interface MyRepository { > Stream findFoos(); > } > > I find the examples using this, but then Stream is nullable? it feels > like if you define any nullability on a given type then the whole type > should be fully marked up. > > In all of these stream examples, the concept in checker framework is > @PolyNull, will there be a way of writing functional interfaces that > defines that the implementers can use them in a PolyNull fashion? > meaning the null check necessity can't be known until usage is > defined? > > Will the compiler strip if null checks out of the bytecode if it > determines they are no longer necessary? probably not necessary to > define in the jep. > > > -- Phone: (416) 450-3584 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Sat Nov 16 00:42:20 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Sat, 16 Nov 2024 00:42:20 +0000 Subject: Fwd: Null-Restricted and Nullable Types concern In-Reply-To: References:

Message-ID: Hi Caleb, The point you've raised, that some antique language features should be retired, has been raised many times by others too, even within Oracle. I will share my two cents about that. These antique features are indeed frustrating: they are confusing at best, like the C-style array notations (Have you seen `int process(int array[])[]`?) or worse, error-prone, like the fall-through switches. One proposal is to let users add some sort of declaration, like a header comment "this is java xxx" and the old feature usages all become errors. Another proposal is to introduce a progressive deprecation policy, like that for the core library features of finalization and security manager. That way we get a few releases to prepare. However, for either proposal, I think they will take time to mature; and I do not think they are blockers for the null-restricted types. Two efforts can run parallel to each other. As notorious as Valhalla is for "not delivering features", I will actually give you an example from Valhalla, where the Java language and programming model first introduces enhancements before the JVM follows up: nested classes. Nested/inner classes have always been an artificial construct because they are just equal classes in the same package in the VM's eye; therefore, access to private members of these classes required generation of accessor methods. However, in JDK 11, Valhalla introduced nestmates - this means now private members are accessible within a "nest", and the Java compiler conveniently treats a top-level class as the host of a nest, eliminating the synthetic accessors. I believe the same story will happen to null-restricted types and generic reification: currently, generics are erased and casted at use sites. Thus, in conclusion, I think you don't need to worry too much about the tiny details of the current prototype. They are still open to changes. Back to your example: for findFoos, I believe javac will generate some sort of unchecked cast warning upon both instances of toString calls; there is no way the compiler knows that the result of a filter(Objects:nonNull) changes the type of the resulting stream. I believe a mapMulti call is required to aid the compiler. And for the return null for stream, that one indeed is not valid because the nullable type is less specific than the non-null type. Current plan is to generate null checks at method returns for bang-returning methods. I hope that answers your questions and relieves your concerns. Regards, Chen Liang ________________________________ From: valhalla-dev on behalf of Caleb Cushing Sent: Friday, November 15, 2024 11:13 AM To: Brian Goetz Cc: valhalla-dev at openjdk.org Subject: Re: Fwd: Null-Restricted and Nullable Types concern > This is a valid opinion, but let's be clear what you're saying: it means you think that having a solid, committed flippening story is so important that you're willing to say that "no one can have the benefits of valhalla for another 5-10 years, or maybe ever." That's a pretty big deal. (And, yes, sometimes we are willing to make such tradeoffs, but it's still a pretty big deal.) I just want to say that I get that, but also things that go into the JDK tend to get stuck that way. I would like this feature 10 years ago, but I don't want to get stuck in a bad situation that we can't back out of because it might break someone's code. There are weird (unrelated) situations where I do not understand why the behavior has been preserved when it doesn't make sense, only because someone, somewhere, might be relying on the implicit (NPE) failure which was likely a mistake in coding. So even some semblance of an idea for a plan, even if it's not committed to, like this is a "preliminary idea which could change"; would be good. I'm just concerned about delivering a "stable" feature that can't change because it might break someone's code. Please also be aware that I wouldn't be commenting at all if I didn't care, or wasn't excited about this impossible work. In any sense, the JEP didn't seem to discuss the exact examples mentioned, so hopefully we can move on to those ;) although perhaps they are "future work" On Fri, Nov 15, 2024 at 11:55?AM Brian Goetz wrote: > > Before anything makes it into the JDK I'd like to see the plan for > this > > > This is a valid opinion, but let's be clear what you're saying: it means you think that having a solid, committed flippening story is so important that you're willing to say that "no one can have the benefits of valhalla for another 5-10 years, or maybe ever." That's a pretty big deal. (And, yes, sometimes we are willing to make such tradeoffs, but it's still a pretty big deal.) > > But, maybe that's not what you meant. Maybe what you meant is "I want to impress on you how important I think it is to get to where the nullity default is flipped." If that's what you mean, yes, we understand how strongly some people feel about this. Our antipathy to attacking this problem *right now* is not because we don't think it is a real pain point, but one of practicality: it's not possible to solve all the problems simultaneously and still deliver something in a mortal lifetime. > > Or maybe what you meant is "there seem to be simple solutions to this problem, why wouldn't we jump on them?" Unfortunately just because a solution is obvious (like "let's just put a bang on the module directive"), doesn't mean they are simple. (To be clear, you are asking for what would be, by far, the biggest change to Java ever -- reinterpreting existing code to mean something else based on a directive _in another file_.) Rest assured that we've seen these "solutions" proposed before, and our lack of enthusiasm for them is that they may well create more problems than they solve. > > So, we get that adding null restriction to Java will significantly worsen the fact that "nullable" is yet another bad default; this is pretty clear. But if we really thought that we can't do Valhalla until we reinterpret all the world's Java code with a new default, the rational response might well be to cancel the project. Sometimes things have to be separated out into smaller, dependent chunks; sometimes we even have to accept that we might not even get to all the later chunks. > > I get that you would be more comfortable if we had a committed, bulletproof plan for this. But I think I can say with confidence that we won't; we need to focus our attention on the many nearly-impossible problems we already have in front of us before adding more to our plate. > > > > > On 11/15/2024 11:16 AM, Caleb Cushing wrote: > > It is not a goal to automatically re-interpret existing code?use of these features should be optional and explicitly opted in to (future work will explore mechanisms to request a bulk opt-in without needing to change individual types) > > Before anything makes it into the JDK I'd like to see the plan for > this, especially since I do not believe such a feature should be > released unless it has been applied to the entirety of the JDK. > Without this the adoption will be almost as slow as JPMS (an aside on > that I'd like progressive enforcement there so it could be possible to > get there). > > Not to speak for anyone other than myself, the community seems to be > leaning towards the conversion where non null is the default, and > using marker annotations on packages,classes,modules. This or > something like this to speed conversion would be appreciated. maybe > the following (Evil tangent: let this only exist on module, I'd like > to get modules actually moving, in a different email it'd be nice if > jars without at least an automatic module would start failing to load) > > module org.example! {} // or ? > package org.example.something!; // or ? > > could be used for speedy defaults on otherwise unmarked code. Some > have taken to separating API and Fields though. > > How do these behave? given the following interface, static > implementations (meaning they aren't doing real loads from an external > database), that Stream::map arguments are marked "?" as nullable and > use > > interface MyRepository { > Stream! findFoos(); > } > > class Foo {} > > given > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream! findFoos() { > return Stream.of(new Foo(), null); > } > } > > class MyRepositoryValueDoesNotNeedNullCheck implements MyRepository { > Stream! findFoos() { > return Stream.of(new Foo()); > } > } > > when MyRepositoryValueNeedsNullCheck > findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) > > when MyRepositoryValueDoesNotNeedNullCheck > findFoos().map( foo -> foo.toString()) > > will the above be considered "ok" since neither of them would actually > create a runtime error? they should be considered ok in my opinion. > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream! findFoos() { > return /// do something with a database or something that > cannot be known until runtime > } > } > when MyRepositoryValueNeedsNullCheck > findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) > findFoos().map( foo -> foo.toString()) > > does the return on findFoos() do an implicit runtime check for the > Stream throwing some good NPE error? will the map without the filter > result in a compile time NPE? > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream? findFoos() { > return null; > } > } > > is this valid? I have a valid use case for what's more or less the > inverse (where the interface is nullable, but the implementation is > not) > > Will we be getting a way to assert variables with inferred types? > > `var! foo = null` (tangent: can we reopen mutability on var here? > meaning val! foo or const! foo, that thing I foolishly voted > against... and was wrong, it should exist (I hadn't used a language > that had it yet, maybe I wasn't the only one), I don't like const > because I see that as a static final) > > given > > Foo! foo; > foo = new Foo(); > > valid so long as it's assigned before use? > > is partial markup really valid at compile time? > > interface MyRepository { > Stream findFoos(); > } > > I find the examples using this, but then Stream is nullable? it feels > like if you define any nullability on a given type then the whole type > should be fully marked up. > > In all of these stream examples, the concept in checker framework is > @PolyNull, will there be a way of writing functional interfaces that > defines that the implementers can use them in a PolyNull fashion? > meaning the null check necessity can't be known until usage is > defined? > > Will the compiler strip if null checks out of the bytecode if it > determines they are no longer necessary? probably not necessary to > define in the jep. > > -- Caleb Cushing Appointments https://calendly.com/caleb-cushing https://xenoterracide.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkilambi at openjdk.org Mon Nov 18 16:48:45 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 18 Nov 2024 16:48:45 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v3] In-Reply-To: References: Message-ID: > This patch adds intrinsic support for FP16 conversion routines to int/long/double and also the aarch64 backend support. This patch implements both scalar and vector versions for these conversions. > > Performance numbers on aarch64 machine with SVE support : > > > Benchmark (vectorDim) Gain > Float16OpsBenchmark.fp16ToDouble 1024 18.23 > Float16OpsBenchmark.fp16ToInt 1024 1.93 > Float16OpsBenchmark.fp16ToLong 1024 3.95 > > > The Gain column is the ratio between thrpt of this patch and the thrpt with the intrinsics disabled (which generates FP32 arithmetic). Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1283/files - new: https://git.openjdk.org/valhalla/pull/1283/files/0809cedc..05b9347f Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1283&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1283&range=01-02 Stats: 31 lines in 3 files changed: 26 ins; 1 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1283.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/valhalla/pull/1283 From bkilambi at openjdk.org Mon Nov 18 16:48:45 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 18 Nov 2024 16:48:45 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v2] In-Reply-To: References:

Message-ID: On Thu, 14 Nov 2024 08:49:11 GMT, Jatin Bhateja wrote: >> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove intrinsification of conversion methods in Float16 > > src/hotspot/share/opto/cfgnode.cpp line 1899: > >> 1897: >> 1898: // Returns the BasicType of a given convert node and a type, with special handling to ensure that conversions to >> 1899: // and from half float will return the SHORT basic type, as that wouldn't be returned typically from TypeInt. > > Comment needs re-formatting, "Returns the BasicType of a given convert node based on its opcode or type", not related to this patch though. Done > test/jdk/java/lang/Float16/FP16ScalarOperations.java line 177: > >> 175: System.out.println("Incorrest result for FP16 to double conversion. Expected value:" + expected + " Actual value: " + actual); >> 176: } >> 177: } > > Adding some constant folding cases covering the following Float16 values to test newly introduced value transforms will be helpful:- > - Float16.NaN > - Float16.MAX_VALUE (0x1.ffcP+15) > - Float16.MIN_VALUE (0x1.0P-24) > - Float16.MIN_NORMAL_VALUE (0x.1P-14) > - Float16.POSITIVE_INFINITE > - Float16.NEGATIVE_INFINITE > - And few cases in the normal value range. Some of these values are already being tested through the `special_values` array. I have modified to include a few more FP16 special values. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1283#discussion_r1846924624 PR Review Comment: https://git.openjdk.org/valhalla/pull/1283#discussion_r1846925861 From bkilambi at openjdk.org Mon Nov 18 16:48:47 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 18 Nov 2024 16:48:47 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v2] In-Reply-To: References:

Message-ID: <-2xrV79bezqNp7Nyy9Kxy8Z2moBYgHdoVOLPn7og2Cs=.608af2da-c6ea-4c02-a3d6-d4f1ec88787c@github.com> On Fri, 15 Nov 2024 11:09:53 GMT, Bhavana Kilambi wrote: >> We can also update existing test for new conversion >> >> test/hotspot/jtreg/compiler/c2/irTests/TestPhiDuplicatedConversion.java > >> This transformation is moving conversion across the Phi node thereby saving expensive conversion instructions. >> >> `Phi (ConvHF2F src1) (ConvHF2F src2) => ConvHF2F (Phi src1 src2) ` >> >> For the Op_ConvF2HF case, type parameter will be of float type and thus we will never enter control flow between L1905 - L1907. >> >> I think it will be harmless if we remove convert_op == Op_ConvF2HF check... > > Hi @jatin-bhateja , I think that check should be there. The lines 1905-1907 will be reachable when get_convert_type() is called again with the dest_type (`short`) when it is supposed to return `short`. If this check is not there, it will return `T_INT`. For the following example - > `rng.nextBoolean() ? Float.floatToFloat16(a) : Float.floatToFloat16(b) > ` > it will generate `ConvF2I` instead of `ConvF2HF`. I have added tests in `TestPhiDuplicatedConversion.java` ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1283#discussion_r1846924260 From caleb.cushing at gmail.com Mon Nov 18 17:54:18 2024 From: caleb.cushing at gmail.com (Caleb Cushing) Date: Mon, 18 Nov 2024 12:54:18 -0500 Subject: Fwd: Null-Restricted and Nullable Types concern In-Reply-To: References:

Message-ID: > > Back to your example: for findFoos, I believe javac will generate some > sort of unchecked cast warning upon both instances of toString calls; there > is no way the compiler knows that the result of a filter(Objects:nonNull) > changes the type of the resulting stream. > I would think that the jdk would be the only thing that would be able to make this inference. even if this was only planned as future work, it feels like a thing that needs to be planned as future work. ... So to me it sounds like the only benefit over existing implementations is syntactic sugar? I'm all for syntactic sugar in this case. Although then I don't see the need for the changes to the constructor; that's not something I'm worried about though. even if it was released in the next jdk it won't super effective for another decade at least (this doesn't mean don't try). I'm basing this on the amount of time it will take libraries and Enterprise to adopt. Spring has only recently adopted Java 17. Most things are still on Java 11 or even 8 as far as compatibility support. Without any support to enforce a policy at the package or module level I don't really see people adopting this anymore than they have adopted jpms which is to mean pulling teeth to get them to even add an automatic module. The libraries that have null support now seem to have only done so because of their ability to provide sensible defaults. I really do believe this is a feature that Java needs, and I'm glad it's being worked on, I just think it needs to go a little farther before it would be adopted. Anyways, I just felt like I needed to give feedback as best I could based on the JEP that I read. As this is a feature that I truly care about. I can take off now, I have said what I needed to say. I hope that answers your questions and relieves your concerns. > > Regards, > Chen Liang > ------------------------------ > *From:* valhalla-dev on behalf of Caleb > Cushing > *Sent:* Friday, November 15, 2024 11:13 AM > *To:* Brian Goetz > *Cc:* valhalla-dev at openjdk.org > *Subject:* Re: Fwd: Null-Restricted and Nullable Types concern > > > This is a valid opinion, but let's be clear what you're saying: it means > you think that having a solid, committed flippening story is so important > that you're willing to say that "no one can have the benefits of valhalla > for another 5-10 years, or maybe ever." That's a pretty big deal. (And, > yes, sometimes we are willing to make such tradeoffs, but it's still a > pretty big deal.) > > I just want to say that I get that, but also things that go into the > JDK tend to get stuck that way. I would like this feature 10 years > ago, but I don't want to get stuck in a bad situation that we can't > back out of because it might break someone's code. There are weird > (unrelated) situations where I do not understand why the behavior has > been preserved when it doesn't make sense, only because someone, > somewhere, might be relying on the implicit (NPE) failure which was > likely a mistake in coding. So even some semblance of an idea for a > plan, even if it's not committed to, like this is a "preliminary idea > which could change"; would be good. I'm just concerned about > delivering a "stable" feature that can't change because it might break > someone's code. Please also be aware that I wouldn't be commenting at > all if I didn't care, or wasn't excited about this impossible work. > > In any sense, the JEP didn't seem to discuss the exact examples > mentioned, so hopefully we can move on to those ;) although perhaps > they are "future work" > > On Fri, Nov 15, 2024 at 11:55?AM Brian Goetz > wrote: > > > > Before anything makes it into the JDK I'd like to see the plan for > > this > > > > > > This is a valid opinion, but let's be clear what you're saying: it means > you think that having a solid, committed flippening story is so important > that you're willing to say that "no one can have the benefits of valhalla > for another 5-10 years, or maybe ever." That's a pretty big deal. (And, > yes, sometimes we are willing to make such tradeoffs, but it's still a > pretty big deal.) > > > > But, maybe that's not what you meant. Maybe what you meant is "I want > to impress on you how important I think it is to get to where the nullity > default is flipped." If that's what you mean, yes, we understand how > strongly some people feel about this. Our antipathy to attacking this > problem *right now* is not because we don't think it is a real pain point, > but one of practicality: it's not possible to solve all the problems > simultaneously and still deliver something in a mortal lifetime. > > > > Or maybe what you meant is "there seem to be simple solutions to this > problem, why wouldn't we jump on them?" Unfortunately just because a > solution is obvious (like "let's just put a bang on the module directive"), > doesn't mean they are simple. (To be clear, you are asking for what would > be, by far, the biggest change to Java ever -- reinterpreting existing code > to mean something else based on a directive _in another file_.) Rest > assured that we've seen these "solutions" proposed before, and our lack of > enthusiasm for them is that they may well create more problems than they > solve. > > > > So, we get that adding null restriction to Java will significantly > worsen the fact that "nullable" is yet another bad default; this is pretty > clear. But if we really thought that we can't do Valhalla until we > reinterpret all the world's Java code with a new default, the rational > response might well be to cancel the project. Sometimes things have to be > separated out into smaller, dependent chunks; sometimes we even have to > accept that we might not even get to all the later chunks. > > > > I get that you would be more comfortable if we had a committed, > bulletproof plan for this. But I think I can say with confidence that we > won't; we need to focus our attention on the many nearly-impossible > problems we already have in front of us before adding more to our plate. > > > > > > > > > > On 11/15/2024 11:16 AM, Caleb Cushing wrote: > > > > It is not a goal to automatically re-interpret existing code?use of > these features should be optional and explicitly opted in to (future work > will explore mechanisms to request a bulk opt-in without needing to change > individual types) > > > > Before anything makes it into the JDK I'd like to see the plan for > > this, especially since I do not believe such a feature should be > > released unless it has been applied to the entirety of the JDK. > > Without this the adoption will be almost as slow as JPMS (an aside on > > that I'd like progressive enforcement there so it could be possible to > > get there). > > > > Not to speak for anyone other than myself, the community seems to be > > leaning towards the conversion where non null is the default, and > > using marker annotations on packages,classes,modules. This or > > something like this to speed conversion would be appreciated. maybe > > the following (Evil tangent: let this only exist on module, I'd like > > to get modules actually moving, in a different email it'd be nice if > > jars without at least an automatic module would start failing to load) > > > > module org.example! {} // or ? > > package org.example.something!; // or ? > > > > could be used for speedy defaults on otherwise unmarked code. Some > > have taken to separating API and Fields though. > > > > How do these behave? given the following interface, static > > implementations (meaning they aren't doing real loads from an external > > database), that Stream::map arguments are marked "?" as nullable and > > use > > > > interface MyRepository { > > Stream! findFoos(); > > } > > > > class Foo {} > > > > given > > > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > > Stream! findFoos() { > > return Stream.of(new Foo(), null); > > } > > } > > > > class MyRepositoryValueDoesNotNeedNullCheck implements MyRepository { > > Stream! findFoos() { > > return Stream.of(new Foo()); > > } > > } > > > > when MyRepositoryValueNeedsNullCheck > > findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) > > > > when MyRepositoryValueDoesNotNeedNullCheck > > findFoos().map( foo -> foo.toString()) > > > > will the above be considered "ok" since neither of them would actually > > create a runtime error? they should be considered ok in my opinion. > > > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > > Stream! findFoos() { > > return /// do something with a database or something that > > cannot be known until runtime > > } > > } > > when MyRepositoryValueNeedsNullCheck > > findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) > > findFoos().map( foo -> foo.toString()) > > > > does the return on findFoos() do an implicit runtime check for the > > Stream throwing some good NPE error? will the map without the filter > > result in a compile time NPE? > > > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > > Stream? findFoos() { > > return null; > > } > > } > > > > is this valid? I have a valid use case for what's more or less the > > inverse (where the interface is nullable, but the implementation is > > not) > > > > Will we be getting a way to assert variables with inferred types? > > > > `var! foo = null` (tangent: can we reopen mutability on var here? > > meaning val! foo or const! foo, that thing I foolishly voted > > against... and was wrong, it should exist (I hadn't used a language > > that had it yet, maybe I wasn't the only one), I don't like const > > because I see that as a static final) > > > > given > > > > Foo! foo; > > foo = new Foo(); > > > > valid so long as it's assigned before use? > > > > is partial markup really valid at compile time? > > > > interface MyRepository { > > Stream findFoos(); > > } > > > > I find the examples using this, but then Stream is nullable? it feels > > like if you define any nullability on a given type then the whole type > > should be fully marked up. > > > > In all of these stream examples, the concept in checker framework is > > @PolyNull, will there be a way of writing functional interfaces that > > defines that the implementers can use them in a PolyNull fashion? > > meaning the null check necessity can't be known until usage is > > defined? > > > > Will the compiler strip if null checks out of the bytecode if it > > determines they are no longer necessary? probably not necessary to > > define in the jep. > > > > > > > -- > Caleb Cushing > > Appointments https://calendly.com/caleb-cushing > https://xenoterracide.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fparain at openjdk.org Mon Nov 18 20:48:03 2024 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 18 Nov 2024 20:48:03 GMT Subject: [lworld] Integrated: 8344454: [lworld] Nullable flat fields fixes Message-ID: Various fixes in nullable flat fields: - null marker test in the interpreter runtime is incorrect - during field layout computation, if the payload is shifted to satisfy alignment requirement, null marker offsets are not updated accordingly ------------- Commit messages: - Various fixes for nullable flat fields Changes: https://git.openjdk.org/valhalla/pull/1302/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1302&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344454 Stats: 10 lines in 3 files changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1302.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1302/head:pull/1302 PR: https://git.openjdk.org/valhalla/pull/1302 From fparain at openjdk.org Mon Nov 18 20:48:04 2024 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 18 Nov 2024 20:48:04 GMT Subject: [lworld] Integrated: 8344454: [lworld] Nullable flat fields fixes In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 20:40:53 GMT, Frederic Parain wrote: > Various fixes in nullable flat fields: > - null marker test in the interpreter runtime is incorrect > - during field layout computation, if the payload is shifted to satisfy alignment requirement, null marker offsets are not updated accordingly This pull request has now been integrated. Changeset: c7433814 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/c7433814b29a45e9fdfee59ab570f1f44a2b2385 Stats: 10 lines in 3 files changed: 6 ins; 0 del; 4 mod 8344454: [lworld] Nullable flat fields fixes ------------- PR: https://git.openjdk.org/valhalla/pull/1302 From andvasp at gmail.com Tue Nov 19 11:22:04 2024 From: andvasp at gmail.com (Anderson Vasconcelos Pires) Date: Tue, 19 Nov 2024 08:22:04 -0300 Subject: Fwd: Null-Restricted and Nullable Types concern In-Reply-To: References:

Message-ID: Hi Guys! So, we get that adding null restriction to Java will significantly worsen the fact that "nullable" is yet another bad default; this is pretty clear. About "nullable" being a bad default. Have you thought for value classes the default to be not nullable? Like the == comparison that is being "fixed" where value objects compare if they are of the same class and have the same field values. If we think in the long future to "fix" the default to be not nullable, this would be a step. Thinking about reading code, maybe it is not a good choice to have this difference between value and identity objects because we would have to check the variable type to understand the logic. Obviously not for the first versions! Thanks! Anderson. On Fri, Nov 15, 2024 at 1:55?PM Brian Goetz wrote: > Before anything makes it into the JDK I'd like to see the plan for > this > > > This is a valid opinion, but let's be clear what you're saying: it means > you think that having a solid, committed flippening story is so important > that you're willing to say that "no one can have the benefits of valhalla > for another 5-10 years, or maybe ever." That's a pretty big deal. (And, > yes, sometimes we are willing to make such tradeoffs, but it's still a > pretty big deal.) > > But, maybe that's not what you meant. Maybe what you meant is "I want to > impress on you how important I think it is to get to where the nullity > default is flipped." If that's what you mean, yes, we understand how > strongly some people feel about this. Our antipathy to attacking this > problem *right now* is not because we don't think it is a real pain point, > but one of practicality: it's not possible to solve all the problems > simultaneously and still deliver something in a mortal lifetime. > > Or maybe what you meant is "there seem to be simple solutions to this > problem, why wouldn't we jump on them?" Unfortunately just because a > solution is obvious (like "let's just put a bang on the module directive"), > doesn't mean they are simple. (To be clear, you are asking for what > would be, by far, the biggest change to Java ever -- reinterpreting > existing code to mean something else based on a directive _in another > file_.) Rest assured that we've seen these "solutions" proposed before, > and our lack of enthusiasm for them is that they may well create more > problems than they solve. > > So, we get that adding null restriction to Java will significantly worsen > the fact that "nullable" is yet another bad default; this is pretty clear. > But if we really thought that we can't do Valhalla until we reinterpret all > the world's Java code with a new default, the rational response might well > be to cancel the project. Sometimes things have to be separated out into > smaller, dependent chunks; sometimes we even have to accept that we might > not even get to all the later chunks. > > I get that you would be more comfortable if we had a committed, > bulletproof plan for this. But I think I can say with confidence that we > won't; we need to focus our attention on the many nearly-impossible > problems we already have in front of us before adding more to our plate. > > > > > On 11/15/2024 11:16 AM, Caleb Cushing wrote: > > It is not a goal to automatically re-interpret existing code?use of these features should be optional and explicitly opted in to (future work will explore mechanisms to request a bulk opt-in without needing to change individual types) > > Before anything makes it into the JDK I'd like to see the plan for > this, especially since I do not believe such a feature should be > released unless it has been applied to the entirety of the JDK. > Without this the adoption will be almost as slow as JPMS (an aside on > that I'd like progressive enforcement there so it could be possible to > get there). > > Not to speak for anyone other than myself, the community seems to be > leaning towards the conversion where non null is the default, and > using marker annotations on packages,classes,modules. This or > something like this to speed conversion would be appreciated. maybe > the following (Evil tangent: let this only exist on module, I'd like > to get modules actually moving, in a different email it'd be nice if > jars without at least an automatic module would start failing to load) > > module org.example! {} // or ? > package org.example.something!; // or ? > > could be used for speedy defaults on otherwise unmarked code. Some > have taken to separating API and Fields though. > > How do these behave? given the following interface, static > implementations (meaning they aren't doing real loads from an external > database), that Stream::map arguments are marked "?" as nullable and > use > > interface MyRepository { > Stream! findFoos(); > } > > class Foo {} > > given > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream! findFoos() { > return Stream.of(new Foo(), null); > } > } > > class MyRepositoryValueDoesNotNeedNullCheck implements MyRepository { > Stream! findFoos() { > return Stream.of(new Foo()); > } > } > > when MyRepositoryValueNeedsNullCheck > findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) > > when MyRepositoryValueDoesNotNeedNullCheck > findFoos().map( foo -> foo.toString()) > > will the above be considered "ok" since neither of them would actually > create a runtime error? they should be considered ok in my opinion. > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream! findFoos() { > return /// do something with a database or something that > cannot be known until runtime > } > } > when MyRepositoryValueNeedsNullCheck > findFoos().filter(Objects::nonNull).map( foo -> foo.toString()) > findFoos().map( foo -> foo.toString()) > > does the return on findFoos() do an implicit runtime check for the > Stream throwing some good NPE error? will the map without the filter > result in a compile time NPE? > > class MyRepositoryValueNeedsNullCheck implements MyRepository { > Stream? findFoos() { > return null; > } > } > > is this valid? I have a valid use case for what's more or less the > inverse (where the interface is nullable, but the implementation is > not) > > Will we be getting a way to assert variables with inferred types? > > `var! foo = null` (tangent: can we reopen mutability on var here? > meaning val! foo or const! foo, that thing I foolishly voted > against... and was wrong, it should exist (I hadn't used a language > that had it yet, maybe I wasn't the only one), I don't like const > because I see that as a static final) > > given > > Foo! foo; > foo = new Foo(); > > valid so long as it's assigned before use? > > is partial markup really valid at compile time? > > interface MyRepository { > Stream findFoos(); > } > > I find the examples using this, but then Stream is nullable? it feels > like if you define any nullability on a given type then the whole type > should be fully marked up. > > In all of these stream examples, the concept in checker framework is > @PolyNull, will there be a way of writing functional interfaces that > defines that the implementers can use them in a PolyNull fashion? > meaning the null check necessity can't be known until usage is > defined? > > Will the compiler strip if null checks out of the bytecode if it > determines they are no longer necessary? probably not necessary to > define in the jep. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsimms at openjdk.org Tue Nov 19 11:30:50 2024 From: dsimms at openjdk.org (David Simms) Date: Tue, 19 Nov 2024 11:30:50 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge jdk-24+20 ------------- Commit messages: - Logical merge fixes, adjust testing - Merge tag 'jdk-24+20' into lworld_merge_jdk_24_20 - 8338851: Hoist os::Posix::realpath() to os::realpath() and implement on Windows - 8342338: Remove redundant IIOPURLTest.java - 8341715: PPC64: ObjectMonitor::_owner should be reset unconditionally in nmethod unlocking - 8342042: PPC64: compiler_fast_unlock_object flags failure instead of success - 8340279: Open source several AWT Dialog tests - Batch 2 - 8341072: Open source several AWT Canvas and Rectangle related tests - 8341328: Refactor initial Assertion Predicate creation into separate classes - 8340313: Crash due to invalid oop in nmethod after C1 patching - ... and 88 more: https://git.openjdk.org/valhalla/compare/c7433814...f58412b2 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1303&range=00.0 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1303&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1303/files Stats: 24451 lines in 535 files changed: 20212 ins; 1668 del; 2571 mod Patch: https://git.openjdk.org/valhalla/pull/1303.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1303/head:pull/1303 PR: https://git.openjdk.org/valhalla/pull/1303 From dsimms at openjdk.org Tue Nov 19 11:56:30 2024 From: dsimms at openjdk.org (David Simms) Date: Tue, 19 Nov 2024 11:56:30 GMT Subject: [lworld] RFR: Merge jdk [v2] In-Reply-To: References: Message-ID: > Merge jdk-24+20 David Simms has updated the pull request incrementally with one additional commit since the last revision: Adjust testing ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1303/files - new: https://git.openjdk.org/valhalla/pull/1303/files/f58412b2..b95994e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1303&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1303&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1303.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1303/head:pull/1303 PR: https://git.openjdk.org/valhalla/pull/1303 From brian.goetz at oracle.com Tue Nov 19 13:14:12 2024 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 19 Nov 2024 13:14:12 +0000 Subject: Null-Restricted and Nullable Types concern In-Reply-To: References:

Message-ID: <6811577C-E738-4953-84F5-4BCE4A4E3653@oracle.com> On Nov 19, 2024, at 6:22 AM, Anderson Vasconcelos Pires > wrote: Hi Guys! So, we get that adding null restriction to Java will significantly worsen the fact that "nullable" is yet another bad default; this is pretty clear. About "nullable" being a bad default. Have you thought for value classes the default to be not nullable? Indeed we have. In fact, this was our initial position for a number of years, until we realized (thanks Kevin!) that this was a bad idea. Asymmetries like this (value classes are non-nullable, identity classes are nullable) adds significant cognitive load to _reading_ code; users have to carry around a mental dictionary of what classes are nullable and what are not in order to be able to reason about nullity. And further, asymmetries like this make it far more difficult to make migrating an identity class (like Optional) to be a value class. In fact, much of the complexity of our intermediate designs revolved around undoing the effects of this ?split default? choice. If we think in the long future to "fix" the default to be not nullable, this would be a step. Half steps often look like steps, but looks can be deceiving. Getting halfway there by having a remote, (seemingly, to some users) random criteria determine whether a variable is nullable or not would not feel like a step to many. Thinking about reading code, maybe it is not a good choice to have this difference between value and identity objects because we would have to check the variable type to understand the logic. Exactly. (Among other reasons.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsimms at openjdk.org Wed Nov 20 06:58:39 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 20 Nov 2024 06:58:39 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: <2R2kCJel4j7-LOBMLfZdQdKQfCnQTzGYUB0ovaUXpCY=.f33ccf0b-ffa7-4da5-b319-4bb768ce2b6a@github.com> On Tue, 19 Nov 2024 11:24:47 GMT, David Simms wrote: > Merge jdk-24+20 This pull request has now been integrated. Changeset: 0d54f19c Author: David Simms URL: https://git.openjdk.org/valhalla/commit/0d54f19c6efb4ca7a71b47242b5f564af192526d Stats: 24452 lines in 535 files changed: 20213 ins; 1668 del; 2571 mod Merge jdk Merge jdk-24+20 ------------- PR: https://git.openjdk.org/valhalla/pull/1303 From dsimms at openjdk.org Wed Nov 20 08:03:23 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 20 Nov 2024 08:03:23 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge jdk-24+21 ------------- Commit messages: - Merge jdk - 8342681: TestLoadBypassesNullCheck.java fails improperly specified VM option - 8342609: jpackage test helper function incorrectly removes a directory instead of its contents only - 8342715: x86 unused orw instruction encoding could be removed - 8342011: Conditionally compile ReservedHeapSpace compressed heap support - 8338570: sun/font/HBShaper - mismatch in return type of FFM upcall function description and native invocation - 8340477: Remove JDK1.1 compatible behavior for "EST", "MST", and "HST" time zones - 8342698: Fix order of @param tags in module java.base - 8335271: Specify the MessageFormat ArgumentIndex Implementation Limit - 8339507: Test generation tool and gtest for testing APX encoding of extended gpr instructions - ... and 53 more: https://git.openjdk.org/valhalla/compare/0d54f19c...187e9467 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1304&range=00.0 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1304&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1304/files Stats: 94695 lines in 422 files changed: 92101 ins; 1980 del; 614 mod Patch: https://git.openjdk.org/valhalla/pull/1304.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1304/head:pull/1304 PR: https://git.openjdk.org/valhalla/pull/1304 From vromero at openjdk.org Wed Nov 20 16:52:54 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 20 Nov 2024 16:52:54 GMT Subject: [lworld] RFR: 8344590: [lworld] non-abstract value classes can not be sealed or non-sealed Message-ID: <35jSPXMaGEgQSRRHwVX22QOmXbuqx6RVPNh7JiQEj_k=.77acd753-fd26-4041-951a-1669ad6e666e@github.com> Non abstract value classes can't be sealed or non-sealed ------------- Commit messages: - 8344590: [lworld] non-abstract value classes can not be sealed or non-sealed Changes: https://git.openjdk.org/valhalla/pull/1305/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1305&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344590 Stats: 70 lines in 4 files changed: 64 ins; 3 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1305.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1305/head:pull/1305 PR: https://git.openjdk.org/valhalla/pull/1305 From vromero at openjdk.org Wed Nov 20 17:27:40 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 20 Nov 2024 17:27:40 GMT Subject: [lworld] Integrated: 8344590: [lworld] non-abstract value classes can not be sealed or non-sealed In-Reply-To: <35jSPXMaGEgQSRRHwVX22QOmXbuqx6RVPNh7JiQEj_k=.77acd753-fd26-4041-951a-1669ad6e666e@github.com> References: <35jSPXMaGEgQSRRHwVX22QOmXbuqx6RVPNh7JiQEj_k=.77acd753-fd26-4041-951a-1669ad6e666e@github.com> Message-ID: On Wed, 20 Nov 2024 16:47:35 GMT, Vicente Romero wrote: > Non abstract value classes can't be sealed or non-sealed This pull request has now been integrated. Changeset: 5a2a2749 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/5a2a2749595dc5082371aecb49cd70afa343e4dd Stats: 70 lines in 4 files changed: 64 ins; 3 del; 3 mod 8344590: [lworld] non-abstract value classes can not be sealed or non-sealed ------------- PR: https://git.openjdk.org/valhalla/pull/1305 From vromero at openjdk.org Wed Nov 20 23:12:02 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 20 Nov 2024 23:12:02 GMT Subject: [lworld] RFR: 8344571: [lworld] javac is rejecting valid value classes due to DA/DU bug Message-ID: updated DA/DU as of last version of JEP 401 ------------- Commit messages: - test plus minor adjustments - Merge branch 'lworld' into JDK-8344571 - 8344571: [lworld] javac is rejecting valid value classes due to DA/DU bug Changes: https://git.openjdk.org/valhalla/pull/1306/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1306&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344571 Stats: 41 lines in 3 files changed: 37 ins; 0 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1306.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1306/head:pull/1306 PR: https://git.openjdk.org/valhalla/pull/1306 From vromero at openjdk.org Thu Nov 21 14:57:50 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 21 Nov 2024 14:57:50 GMT Subject: [lworld] RFR: 8344571: [lworld] sync DA/DU analysis with last version of JEP 401 [v2] In-Reply-To: References: Message-ID: > updated DA/DU as of last version of JEP 401 Vicente Romero has updated the pull request incrementally with two additional commits since the last revision: - minor comment fix - adding comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1306/files - new: https://git.openjdk.org/valhalla/pull/1306/files/cf21da84..3bef3908 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1306&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1306&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1306.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1306/head:pull/1306 PR: https://git.openjdk.org/valhalla/pull/1306 From vromero at openjdk.org Thu Nov 21 14:57:50 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 21 Nov 2024 14:57:50 GMT Subject: [lworld] Integrated: 8344571: [lworld] sync DA/DU analysis with last version of JEP 401 In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 23:06:09 GMT, Vicente Romero wrote: > updated DA/DU as of last version of JEP 401 This pull request has now been integrated. Changeset: c77b62f0 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/c77b62f09a6e9a67e9759b7f87262d64e3f5e1c9 Stats: 46 lines in 3 files changed: 41 ins; 0 del; 5 mod 8344571: [lworld] sync DA/DU analysis with last version of JEP 401 ------------- PR: https://git.openjdk.org/valhalla/pull/1306 From vromero at openjdk.org Thu Nov 21 17:45:50 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 21 Nov 2024 17:45:50 GMT Subject: [lworld] Integrated: 8344764: [lworld] add more binary compatibility tests after refinements to JEP 401 Message-ID: adding a regression test to reflect latest changes to `Chapter 13: Binary Compatibility`, see: https://cr.openjdk.org/~dlsmith/jep401/jep401-20241108/specs/value-objects-jls.html#jls-13.4.1 ------------- Commit messages: - 8344764: [lworld] add more binary compatibility tests after refinements to JEP 401 Changes: https://git.openjdk.org/valhalla/pull/1307/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1307&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344764 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1307.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1307/head:pull/1307 PR: https://git.openjdk.org/valhalla/pull/1307 From vromero at openjdk.org Thu Nov 21 17:45:50 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 21 Nov 2024 17:45:50 GMT Subject: [lworld] Integrated: 8344764: [lworld] add more binary compatibility tests after refinements to JEP 401 In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 17:41:20 GMT, Vicente Romero wrote: > adding a regression test to reflect latest changes to `Chapter 13: Binary Compatibility`, see: > > https://cr.openjdk.org/~dlsmith/jep401/jep401-20241108/specs/value-objects-jls.html#jls-13.4.1 This pull request has now been integrated. Changeset: df874c7d Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/df874c7d750c5918be9d6cc4aa9fb4edc214021a Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod 8344764: [lworld] add more binary compatibility tests after refinements to JEP 401 ------------- PR: https://git.openjdk.org/valhalla/pull/1307 From vromero at openjdk.org Fri Nov 22 20:30:37 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 22 Nov 2024 20:30:37 GMT Subject: Integrated: Merge lworld Message-ID: Merge branch 'lworld' into lw5_merge_lworld # Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ------------- Commit messages: - Merge branch 'lworld' into lw5_merge_lworld - Merge lworld - Merge lworld - 8340125: [lw5] null checks are not being generated for method invocations and array writes - Merge lworld - 8340027: [lw5] the ACC_STRICT flag is not being set for non-nullable static fields - Merge lworld - 8339357: [lw5] make non-nullable instance fields strict - 8339339: [lw5] javac should issue an error if a null-restricted field is left uninitialized, fix override related warnings - 8338910: [lw5] enhance the Signature attribute to represent nullability - ... and 52 more: https://git.openjdk.org/valhalla/compare/df874c7d...eecb6700 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/valhalla/pull/1308/files Stats: 6861 lines in 106 files changed: 6739 ins; 5 del; 117 mod Patch: https://git.openjdk.org/valhalla/pull/1308.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1308/head:pull/1308 PR: https://git.openjdk.org/valhalla/pull/1308 From vromero at openjdk.org Fri Nov 22 20:30:38 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 22 Nov 2024 20:30:38 GMT Subject: Integrated: Merge lworld In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 20:25:21 GMT, Vicente Romero wrote: > Merge branch 'lworld' into lw5_merge_lworld > # Conflicts: > # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java This pull request has now been integrated. Changeset: 8ccf815d Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/8ccf815d20d95ccfcd638d6aeed1e286f283f0b6 Stats: 24602 lines in 545 files changed: 20349 ins; 1671 del; 2582 mod Merge lworld ------------- PR: https://git.openjdk.org/valhalla/pull/1308 From bkilambi at openjdk.org Mon Nov 25 09:41:43 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 25 Nov 2024 09:41:43 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v2] In-Reply-To: References:

Message-ID: <1BO81memyZOeBCuSqhLERTLl2BotV-98GLSWjdt83Is=.d8235c3d-871d-4dce-ab66-b5f6af16bc27@github.com> On Fri, 8 Nov 2024 07:54:59 GMT, Jatin Bhateja wrote: >> I would prefer if I can do this in a separate patch please? I feel this patch is big enough. I will add some Ideal/Identity transformations as required for the new IR (for ex. ConvHF2I <-> ConvI2HF return the half float etc) in the new patch. > >> I would prefer if I can do this in a separate patch please? I feel this patch is big enough. I will add some Ideal/Identity transformations as required for the new IR (for ex. ConvHF2I <-> ConvI2HF return the half float etc) in the new patch. > > Sounds good! Hi @jatin-bhateja , can I integrate these changes if you feel these are good to go? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1283#issuecomment-2497426525 From dsimms at openjdk.org Tue Nov 26 08:35:18 2024 From: dsimms at openjdk.org (David Simms) Date: Tue, 26 Nov 2024 08:35:18 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: <4ve4MqW9GsziTsattNhiOMUoOCN_Z_Thv2uzQKcq_wk=.21565dac-fb0e-4173-a342-e3689d4418b7@github.com> On Wed, 20 Nov 2024 07:56:36 GMT, David Simms wrote: > Merge jdk-24+21 This pull request has now been integrated. Changeset: 6e67ac6e Author: David Simms URL: https://git.openjdk.org/valhalla/commit/6e67ac6e9fe481527b11ada370b5fea5963efa98 Stats: 94695 lines in 422 files changed: 92101 ins; 1980 del; 614 mod Merge jdk Merge jdk-24+21 ------------- PR: https://git.openjdk.org/valhalla/pull/1304 From jbhateja at openjdk.org Tue Nov 26 09:56:11 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 26 Nov 2024 09:56:11 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v2] In-Reply-To: References:

Message-ID: On Fri, 8 Nov 2024 07:54:59 GMT, Jatin Bhateja wrote: >> I would prefer if I can do this in a separate patch please? I feel this patch is big enough. I will add some Ideal/Identity transformations as required for the new IR (for ex. ConvHF2I <-> ConvI2HF return the half float etc) in the new patch. > >> I would prefer if I can do this in a separate patch please? I feel this patch is big enough. I will add some Ideal/Identity transformations as required for the new IR (for ex. ConvHF2I <-> ConvI2HF return the half float etc) in the new patch. > > Sounds good! > Hi @jatin-bhateja , can I integrate these changes if you feel these are good to go? Hi @Bhavana-Kilambi , Kindly integrate this, you now have committer's rights :-) Best Regards, Jatin FTR, upcasting from float16 to float conversions using existing runtime helpers is precision preserving, and constant folding for newly introduced scalar IR can be performed by subsequent integral casting thereby avoiding the need for newly introduced helpers. This can be addressed in a follow-up patch, we can take this liberty on a project branch. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1283#issuecomment-2500154658 From bkilambi at openjdk.org Tue Nov 26 11:20:10 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 26 Nov 2024 11:20:10 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v3] In-Reply-To: References:

Message-ID: On Mon, 18 Nov 2024 16:48:45 GMT, Bhavana Kilambi wrote: >> This patch adds intrinsic support for FP16 conversion routines to int/long/double and also the aarch64 backend support. This patch implements both scalar and vector versions for these conversions. >> >> Performance numbers on aarch64 machine with SVE support : >> >> >> Benchmark (vectorDim) Gain >> Float16OpsBenchmark.fp16ToDouble 1024 18.23 >> Float16OpsBenchmark.fp16ToInt 1024 1.93 >> Float16OpsBenchmark.fp16ToLong 1024 3.95 >> >> >> The Gain column is the ratio between thrpt of this patch and the thrpt with the intrinsics disabled (which generates FP32 arithmetic). > > Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Yes :) I just wanted to make sure you are ok with the changes before I integrate. So for constant folding we would do something like - convert half float value to float and then to integral/double right? But that would mean extra instructions in the backend when we have direct instructions to cast from half float to integral/double? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1283#issuecomment-2500353017 From bkilambi at openjdk.org Tue Nov 26 11:20:11 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 26 Nov 2024 11:20:11 GMT Subject: [lworld+fp16] Integrated: 8341414: Add support for FP16 conversion routines In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 14:07:52 GMT, Bhavana Kilambi wrote: > This patch adds intrinsic support for FP16 conversion routines to int/long/double and also the aarch64 backend support. This patch implements both scalar and vector versions for these conversions. > > Performance numbers on aarch64 machine with SVE support : > > > Benchmark (vectorDim) Gain > Float16OpsBenchmark.fp16ToDouble 1024 18.23 > Float16OpsBenchmark.fp16ToInt 1024 1.93 > Float16OpsBenchmark.fp16ToLong 1024 3.95 > > > The Gain column is the ratio between thrpt of this patch and the thrpt with the intrinsics disabled (which generates FP32 arithmetic). This pull request has now been integrated. Changeset: 6bcf899e Author: Bhavana Kilambi URL: https://git.openjdk.org/valhalla/commit/6bcf899e70f2615216166da009f28c2a3d5778f8 Stats: 1580 lines in 31 files changed: 771 ins; 74 del; 735 mod 8341414: Add support for FP16 conversion routines Reviewed-by: jbhateja ------------- PR: https://git.openjdk.org/valhalla/pull/1283 From jbhateja at openjdk.org Tue Nov 26 15:43:28 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 26 Nov 2024 15:43:28 GMT Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines [v3] In-Reply-To: References:

Message-ID: On Tue, 26 Nov 2024 11:17:28 GMT, Bhavana Kilambi wrote: > Yes :) I just wanted to make sure you are ok with the changes before I integrate. > > So for constant folding we would do something like - convert half float value to float and then to integral/double right? But that would mean extra instructions in the backend when we have direct instructions to cast from half float to integral/double? Since constants are folded at compile time, adding runtime helpers just for constant folding looks like an overkill. Post folding compile will directly operate over constant IR. Best Regards, Jatin ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1283#issuecomment-2501195393 From rriggs at openjdk.org Tue Nov 26 19:24:08 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 26 Nov 2024 19:24:08 GMT Subject: [lworld] RFR: 8345070: [lworld] Correct ProblemList.txt for SinceChecker Message-ID: Correct entry for SinceChecker to remove "jdk/" prefix. ------------- Commit messages: - 8345070: [lworld] Correct ProblemList.txt for SinceChecker Changes: https://git.openjdk.org/valhalla/pull/1309/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1309&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345070 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1309.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1309/head:pull/1309 PR: https://git.openjdk.org/valhalla/pull/1309 From rriggs at openjdk.org Tue Nov 26 19:38:57 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 26 Nov 2024 19:38:57 GMT Subject: [lworld] Integrated: 8345070: [lworld] Correct ProblemList.txt for SinceChecker In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 19:19:26 GMT, Roger Riggs wrote: > Correct entry for SinceChecker to remove "jdk/" prefix. This pull request has now been integrated. Changeset: 892a7a6e Author: Roger Riggs URL: https://git.openjdk.org/valhalla/commit/892a7a6ed31703faaca67a81a1714ea4e7233cb6 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8345070: [lworld] Correct ProblemList.txt for SinceChecker ------------- PR: https://git.openjdk.org/valhalla/pull/1309 From vromero at openjdk.org Wed Nov 27 00:03:22 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 27 Nov 2024 00:03:22 GMT Subject: [lworld] Integrated: 8342036: [lworld] tools/javap/UndefinedAccessFlagTest.java fails after merge of jdk-24+4 Message-ID: <_SWsUyQ1_EmDQAa1Z1wCdBIA05BpZY0vRhS5nPwE7Us=.9fa5bcf4-ed39-4f49-823c-9540f2f7e024@github.com> fixing `com.sun.tools.javap.ClassWriter::getClassModifiers` to use method `flagsReportUnknown` which capture exceptions thrown by `AccessFlag.maskToAccessFlags` ------------- Commit messages: - 8342036: [lworld] tools/javap/UndefinedAccessFlagTest.java fails after merge of jdk-24+4 Changes: https://git.openjdk.org/valhalla/pull/1310/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1310&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342036 Stats: 8 lines in 3 files changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.org/valhalla/pull/1310.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1310/head:pull/1310 PR: https://git.openjdk.org/valhalla/pull/1310 From vromero at openjdk.org Wed Nov 27 00:03:22 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 27 Nov 2024 00:03:22 GMT Subject: [lworld] Integrated: 8342036: [lworld] tools/javap/UndefinedAccessFlagTest.java fails after merge of jdk-24+4 In-Reply-To: <_SWsUyQ1_EmDQAa1Z1wCdBIA05BpZY0vRhS5nPwE7Us=.9fa5bcf4-ed39-4f49-823c-9540f2f7e024@github.com> References: <_SWsUyQ1_EmDQAa1Z1wCdBIA05BpZY0vRhS5nPwE7Us=.9fa5bcf4-ed39-4f49-823c-9540f2f7e024@github.com> Message-ID: On Tue, 26 Nov 2024 23:53:45 GMT, Vicente Romero wrote: > fixing `com.sun.tools.javap.ClassWriter::getClassModifiers` to use method `flagsReportUnknown` which capture exceptions thrown by `AccessFlag.maskToAccessFlags` This pull request has now been integrated. Changeset: 10700a6f Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/10700a6f1fbb1ebc5260de739bda17af184f0262 Stats: 8 lines in 3 files changed: 0 ins; 1 del; 7 mod 8342036: [lworld] tools/javap/UndefinedAccessFlagTest.java fails after merge of jdk-24+4 ------------- PR: https://git.openjdk.org/valhalla/pull/1310 From vromero at openjdk.org Wed Nov 27 04:11:56 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 27 Nov 2024 04:11:56 GMT Subject: Integrated: Merge lworld Message-ID: Merge branch 'lworld' into lw5_merge_lworld ------------- Commit messages: - Merge branch 'lworld' into lw5_merge_lworld - Merge lworld - Merge lworld - Merge lworld - 8340125: [lw5] null checks are not being generated for method invocations and array writes - Merge lworld - 8340027: [lw5] the ACC_STRICT flag is not being set for non-nullable static fields - Merge lworld - 8339357: [lw5] make non-nullable instance fields strict - 8339339: [lw5] javac should issue an error if a null-restricted field is left uninitialized, fix override related warnings - ... and 53 more: https://git.openjdk.org/valhalla/compare/10700a6f...9e97433f The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/valhalla/pull/1311/files Stats: 6861 lines in 106 files changed: 6739 ins; 5 del; 117 mod Patch: https://git.openjdk.org/valhalla/pull/1311.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1311/head:pull/1311 PR: https://git.openjdk.org/valhalla/pull/1311 From vromero at openjdk.org Wed Nov 27 04:11:57 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 27 Nov 2024 04:11:57 GMT Subject: Integrated: Merge lworld In-Reply-To: References: Message-ID: