From bchristi at openjdk.org  Sat Feb  1 00:16:04 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Sat, 1 Feb 2025 00:16:04 GMT
Subject: RFR: 8349107: Remove RMI finalizers
Message-ID: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>

3 finalizers in RMI code can be removed, as they do not perform meaningful cleanup.

**`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**

`RegistryContext.finalize()` just calls `close()`. The `close()` method does not perform any cleanup per se, but rather "helps the garbage collector" by setting `environment` and `registry` to `null`.


**`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.BindingEnumeration`**

`BindingEnumeration.finalize()` simply calls `close()` on the `ctx` field, itself a `RegistryContext` (and `close()` just "helps the GC.")


**`src/java.rmi/share/classes/sun/rmi/log/LogInputStream`**

`LogInputStream` tracks its length with an int field, `length`. If `length` ever becomes == 0, `LogInputStream`'s methods will return without doing anything.

The finalizer calls `close()`, which just sets length = 0.

By the time a `LogInputStream` becomes unreachable and is finalized, it's a moot point whether length == 0, as no more methods can be called.
If anything, this finalizer could cause a bug. If a `LogInputStream` were to became unreachable while a method were still running, the finalizer could set the length to 0 while method code is still running and expecting a length != 0.
It's possible that there is a very long standing bug that `close()` should be calling `in.close()`, in which case this evaluation will need to be revisited.

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

Commit messages:
 - Remove finalizer from RMI LogInputStream
 - Remove finalizer from RMI RegistryContext.BindingEnumeration
 - Remove finalizer from RMI RegistryContext

Changes: https://git.openjdk.org/jdk/pull/23406/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23406&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349107
  Stats: 20 lines in 2 files changed: 0 ins; 19 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23406/head:pull/23406

PR: https://git.openjdk.org/jdk/pull/23406

From swen at openjdk.org  Sat Feb  1 00:41:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 1 Feb 2025 00:41:52 GMT
Subject: RFR: 8337279: Optimize format instant [v7]
In-Reply-To: <HkP-NaJux3FUlRBC5SBu6rSwtFwkxMv0dXInEzRAKc4=.9b397c8e-ad0d-450a-b77d-ad77ada4cc85@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <WR4VFQQBMNtkhd0I01eEVRTcY5fJOpNw3XDNsvNS2dc=.e2d72550-6ad5-4a85-8185-7880357b47c3@github.com>
 <ZyLsa7o--VDmIlJS2vlhaTR2AQNg2Mo9Kyxh8DevTOg=.40c84a94-e863-4ba3-89b4-54617769e79f@github.com>
 <HkP-NaJux3FUlRBC5SBu6rSwtFwkxMv0dXInEzRAKc4=.9b397c8e-ad0d-450a-b77d-ad77ada4cc85@github.com>
Message-ID: <DXoUSX22Omyn2Z9S6c9frY8eucCUJWpOR7aCypm8x2g=.359222f3-38fd-4382-9bea-35ef5cb7663d@github.com>

On Mon, 23 Sep 2024 05:33:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> I don't think using SharedSecret just for performance improvement and code size reduction is the right way, as the class is the last resort as the header says:
> 
> ```
>  * <p><strong>
>  * Usage of these APIs often means bad encapsulation designs,
>  * increased complexity and lack of sustainability.
>  * Use this only as a last resort!
>  * </strong>
> ```

@naotoj 
 I have removed SharedSecrets, can you review it again?

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

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2628624789

From swen at openjdk.org  Sat Feb  1 00:51:59 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 1 Feb 2025 00:51:59 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 Unsafe.allocateUninitializedArray
Message-ID: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>

The byte[] allocated in Integer/Long.toString is fully filled, so we can use Unsafe.allocateUninitializedArray to create byte[] to improve performance.

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

Commit messages:
 - simplify
 - use Unsafe.allocateUninitializedArray
 - revert StringConcatHelper newArray change
 - copyright
 - remove duplicate check
 - allocateUninitializedArray

Changes: https://git.openjdk.org/jdk/pull/23353/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23353&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349176
  Stats: 12 lines in 2 files changed: 6 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23353.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23353/head:pull/23353

PR: https://git.openjdk.org/jdk/pull/23353

From swen at openjdk.org  Sat Feb  1 00:51:59 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 1 Feb 2025 00:51:59 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 Unsafe.allocateUninitializedArray
In-Reply-To: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
References: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
Message-ID: <Ml2GAfGhSyjQoVIMdrpIlyJGgAGMK6gj0Cjv7Q5pBKk=.fdaf9e89-edc1-43eb-8e34-28dc4cf4bb89@github.com>

On Wed, 29 Jan 2025 16:36:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The byte[] allocated in Integer/Long.toString is fully filled, so we can use Unsafe.allocateUninitializedArray to create byte[] to improve performance.

This change demonstrates 2?23% speed improvements across multiple aarch64/x64 scenarios, but introduces ~18% regression in the Integers.toStringTiny benchmark on AMD EPYC? Genoa processors. The regression is non-deterministic and not consistently reproducible.


## 1. Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

#baseline
git checkout f98d9a330128302207fb66dfa2555885ad93135f
make test TEST="micro:java.lang.Longs.toString"
make test TEST="micro:java.lang.Integers.toString"

# current
git checkout 2a06d12fcb7822395960c813d91a34eda0d661ce
make test TEST="micro:java.lang.Longs.toString"
make test TEST="micro:java.lang.Integers.toString"


## 2. MacBook M1 Pro (aarch64)

-# baseline
-Benchmark               (size)  Mode  Cnt  Score   Error  Units (f98d9a33012)
-Longs.toStringBig          500  avgt   15  7.265 ? 0.063  us/op
-Longs.toStringSmall        500  avgt   15  3.043 ? 0.051  us/op
-Integers.toStringBig       500  avgt   15  4.837 ? 0.076  us/op
-Integers.toStringSmall     500  avgt   15  2.922 ? 0.020  us/op
-Integers.toStringTiny      500  avgt   15  2.136 ? 0.010  us/op


+# current
+Benchmark               (size)  Mode  Cnt  Score   Error  Units (2a06d12fcb7)
+Longs.toStringBig          500  avgt   15  7.025 ? 0.024  us/op
+Longs.toStringSmall        500  avgt   15  2.735 ? 0.008  us/op
+Integers.toStringBig       500  avgt   15  4.592 ? 0.015  us/op
+Integers.toStringSmall     500  avgt   15  2.632 ? 0.026  us/op
+Integers.toStringTiny      500  avgt   15  1.734 ? 0.006  us/op


|   | pattern | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Longs.toStringBig | 500 | 7.265 | 7.025 | 3.42% |
| Longs.toStringSmall | 500 | 3.043 | 2.735 | 11.26% |
| Integers.toStringBig | 500 | 4.837 | 4.592 | 5.34% |
| Integers.toStringSmall | 500 | 2.922 | 2.632 | 11.02% |
| Integers.toStringTiny | 500 | 2.136 | 1.734 | 23.18% |


## 3. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa)

+# baseline
+Benchmark               (size)  Mode  Cnt  Score   Error  Units (f98d9a33012)
+Longs.toStringBig          500  avgt   15  8.126 ? 0.027  us/op
+Longs.toStringSmall        500  avgt   15  3.296 ? 0.029  us/op
+Integers.toStringBig       500  avgt   15  4.957 ? 0.008  us/op
+Integers.toStringSmall     500  avgt   15  3.467 ? 0.020  us/op
+Integers.toStringTiny      500  avgt   15  2.534 ? 0.040  us/op

-# current
-Benchmark               (size)  Mode  Cnt  Score   Error  Units (2a06d12fcb7)
-Longs.toStringBig          500  avgt   15  7.540 ? 0.019  us/op
-Longs.toStringSmall        500  avgt   15  3.055 ? 0.006  us/op
-Integers.toStringBig       500  avgt   15  4.646 ? 0.024  us/op
-Integers.toStringSmall     500  avgt   15  3.173 ? 0.008  us/op
-Integers.toStringTiny      500  avgt   15  3.118 ? 0.029  us/op


|   | pattern | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Longs.toStringBig | 500 | 8.126 | 7.540 | 7.77% |
| Longs.toStringSmall | 500 | 3.296 | 3.055 | 7.89% |
| Integers.toStringBig | 500 | 4.957 | 4.646 | 6.69% |
| Integers.toStringSmall | 500 | 3.467 | 3.173 | 9.27% |
| Integers.toStringTiny | 500 | 2.534 | 3.118 | -18.73% |


It is observed here that performance degradation begins at Warmup Iteration 3.


# Warmup Iteration   1: 2.333 us/op
# Warmup Iteration   2: 2.248 us/op
# Warmup Iteration   3: 3.118 us/op
# Warmup Iteration   4: 3.121 us/op
# Warmup Iteration   5: 3.129 us/op
# Warmup Iteration   6: 3.122 us/op
# Warmup Iteration   7: 3.118 us/op
# Warmup Iteration   8: 3.154 us/op
# Warmup Iteration   9: 3.097 us/op
# Warmup Iteration  10: 3.090 us/op
Iteration   1: 3.090 us/op
Iteration   2: 3.091 us/op
Iteration   3: 3.092 us/op
Iteration   4: 3.093 us/op
Iteration   5: 3.098 us/op


## 4. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids)

+# baseline
+Benchmark               (size)  Mode  Cnt  Score   Error  Units (f98d9a33012)
+Longs.toStringBig          500  avgt   15  7.992 ? 0.039  us/op
+Longs.toStringSmall        500  avgt   15  3.578 ? 0.022  us/op
+Integers.toStringBig       500  avgt   15  5.536 ? 0.017  us/op
+Integers.toStringSmall     500  avgt   15  3.657 ? 0.152  us/op
+Integers.toStringTiny      500  avgt   15  2.638 ? 0.047  us/op

-# current
-Benchmark               (size)  Mode  Cnt  Score   Error  Units (2a06d12fcb7)
-Longs.toStringBig          500  avgt   15  7.731 ? 0.011  us/op
-Longs.toStringSmall        500  avgt   15  3.413 ? 0.020  us/op
-Integers.toStringBig       500  avgt   15  4.738 ? 0.021  us/op
-Integers.toStringSmall     500  avgt   15  3.184 ? 0.140  us/op
-Integers.toStringTiny      500  avgt   15  2.621 ? 0.126  us/op


|   | pattern | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Longs.toStringBig | 500 | 7.992 | 7.731 | 3.38% |
| Longs.toStringSmall | 500 | 3.578 | 3.413 | 4.83% |
| Integers.toStringBig | 500 | 5.536 | 4.738 | 16.84% |
| Integers.toStringSmall | 500 | 3.657 | 3.184 | 14.86% |
| Integers.toStringTiny | 500 | 2.638 | 2.621 | 0.65% |


## 5. aliyun_ecs_c8y_aarch64 (CPU Aliyun Yitian 710)

+# baseline
+Benchmark               (size)  Mode  Cnt  Score   Error  Units (f98d9a33012)
+Longs.toStringBig          500  avgt   15  11.017 ? 0.084  us/op
+Longs.toStringSmall        500  avgt   15   4.400 ? 0.078  us/op
+Integers.toStringBig       500  avgt   15   7.377 ? 0.103  us/op
+Integers.toStringSmall     500  avgt   15   4.504 ? 0.083  us/op
+Integers.toStringTiny      500  avgt   15   3.693 ? 0.107  us/op

-# current
-Benchmark               (size)  Mode  Cnt  Score   Error  Units (2a06d12fcb7)
-Longs.toStringBig          500  avgt   15  10.696 ? 0.055  us/op
-Longs.toStringSmall        500  avgt   15   4.111 ? 0.113  us/op
-Integers.toStringBig       500  avgt   15   6.815 ? 0.097  us/op
-Integers.toStringSmall     500  avgt   15   4.136 ? 0.103  us/op
-Integers.toStringTiny      500  avgt   15   3.588 ? 0.102  us/op


|   | pattern | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Longs.toStringBig | 500 | 11.017 | 10.696 | 3.00% |
| Longs.toStringSmall | 500 | 4.400 | 4.111 | 7.03% |
| Integers.toStringBig | 500 | 7.377 | 6.815 | 8.25% |
| Integers.toStringSmall | 500 | 4.504 | 4.136 | 8.90% |
| Integers.toStringTiny | 500 | 3.693 | 3.588 | 2.93% |


## 6. orange_pi5_aarch64 (CPU RK3588S)

+# baseline
+Benchmark               (size)  Mode  Cnt   Score   Error  Units (f98d9a33012)
+Longs.toStringBig          500  avgt   15  23.235 ? 1.973  us/op
+Longs.toStringSmall        500  avgt   15   8.262 ? 0.555  us/op
+Integers.toStringBig       500  avgt   15  14.435 ? 0.819  us/op
+Integers.toStringSmall     500  avgt   15   8.384 ? 0.669  us/op
+Integers.toStringTiny      500  avgt   15   5.661 ? 0.404  us/op

-# current
-Benchmark               (size)  Mode  Cnt   Score   Error  Units (2a06d12fcb7)
-Longs.toStringBig          500  avgt   15  21.727 ? 1.396  us/op
-Longs.toStringSmall        500  avgt   15   7.591 ? 0.581  us/op
-Integers.toStringBig       500  avgt   15  13.682 ? 0.930  us/op
-Integers.toStringSmall     500  avgt   15   7.691 ? 0.575  us/op
-Integers.toStringTiny      500  avgt   15   4.943 ? 0.473  us/op


|   | pattern | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| Longs.toStringBig | 500 | 23.235 | 21.727 | 6.94% |
| Longs.toStringSmall | 500 | 8.262 | 7.591 | 8.84% |
| Integers.toStringBig | 500 | 14.435 | 13.682 | 5.50% |
| Integers.toStringSmall | 500 | 8.384 | 7.691 | 9.01% |
| Integers.toStringTiny | 500 | 5.661 | 4.943 | 14.53% |

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

PR Comment: https://git.openjdk.org/jdk/pull/23353#issuecomment-2623354805

From liach at openjdk.org  Sat Feb  1 00:51:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 1 Feb 2025 00:51:59 GMT
Subject: RFR: 8349176: Speed up Integer/Long.toString via
 Unsafe.allocateUninitializedArray
In-Reply-To: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
References: <u9INrX9ZnlI8Hs0gC1hnE-oYiHLrnL93Q5hF1yzmJgM=.8b5bb878-27f0-4c21-a1bb-82ce65634b81@github.com>
Message-ID: <Rhd8EFcMrVzX0t0Qr38vjtgT1pGaszIQPKeCsZML7-o=.9f906396-d62f-46f8-be60-a8abb82212eb@github.com>

On Wed, 29 Jan 2025 16:36:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The byte[] allocated in Integer/Long.toString is fully filled, so we can use Unsafe.allocateUninitializedArray to create byte[] to improve performance.

src/java.base/share/classes/java/lang/StringConcatHelper.java line 559:

> 557:     static byte[] newArray(int length) {
> 558:         return (byte[]) UNSAFE.allocateUninitializedArray(byte.class, length);
> 559:     }

I think we should keep this check, as string concatenation seems to use this to throw OOME.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23353#discussion_r1934548644

From duke at openjdk.org  Sat Feb  1 01:45:57 2025
From: duke at openjdk.org (duke)
Date: Sat, 1 Feb 2025 01:45:57 GMT
Subject: Withdrawn: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <F-suAvyFSl3gsI5fXLDr8WNXklPj2bsbqbgSfwkUIsY=.0e1cee1d-19cb-45f1-af4e-48d3876718b9@github.com>

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this change that adds a new dynamic proxies implementation as hidden classes.
> 
> Summary:
> 1. Adds new implementation which can be `-Djdk.reflect.useHiddenProxy=true` for early adoption.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/19356

From alanb at openjdk.org  Sat Feb  1 08:01:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 1 Feb 2025 08:01:45 GMT
Subject: RFR: 8342775: [Graal]
 java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME  thrown from the
 UncaughtExceptionHandler [v2]
In-Reply-To: <Jprvvkq84POahF2BKozy86qqsuhGSoZfonTrc3Cz8XA=.675935c2-bb38-4e80-9d3f-cbe44205b02f@github.com>
References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com>
 <lrh03fitAdQaPV_6JUwD4aLqRLtjLw-rdqJN9G-HMSI=.a185a575-2057-407c-bf2a-9ce16b3463e4@github.com>
 <Jprvvkq84POahF2BKozy86qqsuhGSoZfonTrc3Cz8XA=.675935c2-bb38-4e80-9d3f-cbe44205b02f@github.com>
Message-ID: <CSpslHI9dOAE8Eq89n3mbRWzWhw074sOE009DhaVQt4=.12565b23-3945-4460-9c5a-bcccfca75435@github.com>

On Fri, 31 Jan 2025 22:15:20 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> I've disabled the test for Graal with Xcomp. Is that an acceptable solution? 

Yes, this should be okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/21745#issuecomment-2628839816

From swen at openjdk.org  Sat Feb  1 08:42:32 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 1 Feb 2025 08:42:32 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v4]
In-Reply-To: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
Message-ID: <JENdZLiCWbHnkdjyhqKGyjZxHcq2byLXXj1YRwi_X18=.a94901e5-cc33-4aa8-8f89-16a4fdb9c361@github.com>

> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
 - remove getChars(long, int, char[])
 - copyright
 - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
 - simplify and comments
 - simplify
 - simplify
 - code style
 - revert change
 - bug fix
 - ... and 19 more: https://git.openjdk.org/jdk/compare/651ac3cc...f9af0b02

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

Changes: https://git.openjdk.org/jdk/pull/23310/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23310&range=03
  Stats: 452 lines in 3 files changed: 239 ins; 119 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/23310.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23310/head:pull/23310

PR: https://git.openjdk.org/jdk/pull/23310

From swen at openjdk.org  Sat Feb  1 10:07:25 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 1 Feb 2025 10:07:25 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v13]
In-Reply-To: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
Message-ID: <e9mfG7ub-X9TkBSwUSiq1DoE5bUXSCvKSxS0UnrOauU=.1f4ec4c7-0ba5-4759-b56b-a819e30aad4e@github.com>

> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
 - multiply 10
 - copyright
 - error message
 - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
 - use &
 - from @rgiulietti
 - remove unused
 - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - vector digit2
 - ... and 19 more: https://git.openjdk.org/jdk/compare/651ac3cc...1fb40bb9

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

Changes: https://git.openjdk.org/jdk/pull/22919/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=12
  Stats: 196 lines in 5 files changed: 116 ins; 26 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/22919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919

PR: https://git.openjdk.org/jdk/pull/22919

From duke at openjdk.org  Sat Feb  1 11:20:59 2025
From: duke at openjdk.org (Matthias Ernst)
Date: Sat, 1 Feb 2025 11:20:59 GMT
Subject: RFR: 8287788: Implement a better allocator for downcalls [v18]
In-Reply-To: <IZlZEhyy67aCP5VIumH2t9aF-yUWNlxT3-QyG39A3AU=.176bf64d-bee3-4e56-b0ab-9619db86ff24@github.com>
References: <lGAHUKO5rriFO4hwvI2udJxslv2RB_YVDb3qdPmm0PU=.056a498a-8fc5-450c-ab51-6ddf1abe8fa2@github.com>
 <IZlZEhyy67aCP5VIumH2t9aF-yUWNlxT3-QyG39A3AU=.176bf64d-bee3-4e56-b0ab-9619db86ff24@github.com>
Message-ID: <Ycfo32fkfmcX332ag1BKYatxVVdLtiyHQSzmW82GuiY=.dc58a535-ba78-4ce6-a059-76af5df8e5c8@github.com>

On Thu, 23 Jan 2025 17:36:11 GMT, Matthias Ernst <duke at openjdk.org> wrote:

>> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead.
>> 
>> Sample stack trace:
>> 
>>    java.lang.Thread.State: RUNNABLE
>> 	at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method)
>> ...
>> 	at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386)
>> 	at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source)
>> ...
>> 	at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder)
>> 
>> 
>> To alleviate this, this PR implements a per carrier-thread stacked allocator.
>> 
>> Performance (MBA M3):
>> 
>> 
>> Before:
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> CallOverheadByValue.byPtr    avgt   10   3.333 ? 0.152  ns/op
>> CallOverheadByValue.byValue  avgt   10  33.892 ? 0.034  ns/op
>> 
>> After:
>> Benchmark                    Mode  Cnt  Score   Error  Units
>> CallOverheadByValue.byPtr    avgt   30  3.311 ? 0.034  ns/op
>> CallOverheadByValue.byValue  avgt   30  6.143 ? 0.053  ns/op
>> 
>> 
>> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before.
>
> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test under VThread factory

Tried a few hours to repro with various approaches, to no avail.

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

PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2628910700

From alanb at openjdk.org  Sat Feb  1 12:05:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 1 Feb 2025 12:05:52 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native
In-Reply-To: <fNDc9c4ZXdKqu4pI1y1NFpeoCknVW3oLvQQZsO4hkLM=.3b5e9cc3-eae8-4bc4-9511-4f782e40e51f@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <g2Cl2ACu9JAP6fLusOy-2EroQg-w3ARVt5vo1RVSUEU=.3a302417-0def-468c-baff-a08a70788a65@github.com>
 <8t8V6-A3nLdnBCS_yjfVqurgQDNCrYkACZPN3V3lYvs=.3c35a2e0-917f-4801-ad1d-d1eb428adaff@github.com>
 <CwM8SNDCb2lAp3epYLGb2mAUGHdBqO_esyT6Nqfr_0k=.c195988f-9bdc-465d-8b31-5611f85c1fd8@github.com>
 <fNDc9c4ZXdKqu4pI1y1NFpeoCknVW3oLvQQZsO4hkLM=.3b5e9cc3-eae8-4bc4-9511-4f782e40e51f@github.com>
Message-ID: <2SFAoEqpXa6eH5YyN07oH_tcppE3yMUDpoN3xMxheWU=.1ba07c63-f68d-434d-822f-67a3b15d0293@github.com>

On Fri, 31 Jan 2025 17:22:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am thinking if anything new happens if we can reflect the field, `setAccessible(true)` it, and overwrite it. I guess the normal protection rules disallow the `setAccessible` part, but it does not hurt to think and confirm this is still enough and good.

The field won't be accessible by default so I think you are pondering the case where someone opens java.lang for deep reflection and hack on this field. At some point the ongoing work on integrity will get to "final means final" so code can't modify a final instance field (this restriction already exists for records and hidden classes). In the mean-time, no objection to extending the current reflection filter to hide this field although that filtering mechanism is a ah hoc and needs to go away in the long term.

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

PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2628925203

From duke at openjdk.org  Sat Feb  1 12:41:02 2025
From: duke at openjdk.org (altrisi)
Date: Sat, 1 Feb 2025 12:41:02 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v20]
In-Reply-To: <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
Message-ID: <T_xvNvOmPe8Fx4FvDHc-x8Bu6ZUAubFZgxKD-zLeV8A=.39a227fc-9e32-45e2-aacf-0c3a1288b7c9@github.com>

On Fri, 18 Oct 2024 21:56:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/optim_str_builder_append_202406' into optim_str_builder_append_202406
>  - fix build error
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'origin/optim_str_builder_append_202406' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - revert test
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/26d36e92...457735c9

I have concerns with the changes here, because of what it can cause when an (incorrect) program is sharing a StringBuilder between multiple threads.

Even without any reordering, a thread could start an `append(boolean|null)`, pass the `ensureCapacityInternal` call, then another thread up the count by enough to no longer have enough capacity. Then the first thread could proceed to read the new (no longer enough!) count, and write without any bounds checks outside of the array. Easy to reproduce with a debugger and some breakpoints.

The previous code would have thrown an exception at an explicit or implicit bounds check, but with the changes here that'd no longer happen.

<details>
<summary>For example</summary>

|(initial state)|
|-----------------|
| value.length = 16 |
| count = 11 |

| Thread 1                  | Thread 2           |
|---------------------------|--------------------|
| append(true)              |                    |
| -ensureCap(11+4)          |                    |
| --nothing to do            |                    |
|                           | append("str")      |
|                           | - ensureCap(11+3)  |
|                           | -- nothing to do      |
|                           | - ...              |
|                           | - this.count <- 14 |
| - cnt <- this.count (14!) |                    |
| - val <- this.value       |                    |
| - val[cnt] <-u 't'         |                    |
| - val[cnt+1] <-u 'r'        |                    |
| - val[cnt+2 (16!)] <-u 'u'        |                    |
| - ...                          |                    |
</details>

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

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2628937397

From swen at openjdk.org  Sat Feb  1 13:45:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 1 Feb 2025 13:45:06 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v20]
In-Reply-To: <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
Message-ID: <eEQSmQDZu3sqsQyjCCw-41HpY94kTwfHg-PjfGE-I5c=.2ade38b6-738d-4592-b6b8-7e2ce989a2c2@github.com>

On Fri, 18 Oct 2024 21:56:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/optim_str_builder_append_202406' into optim_str_builder_append_202406
>  - fix build error
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'origin/optim_str_builder_append_202406' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - revert test
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/95d177e1...457735c9

AbstractStringBuilder's value/coder/count are not volatile. If you use StringBuilder, you may not get the correct result. If you want thread safety, you should use StringBuffer.

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

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2628958534

From syan at openjdk.org  Sat Feb  1 14:42:23 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 1 Feb 2025 14:42:23 GMT
Subject: RFR: 8349184: [JMH]
 jdk.incubator.vector.ColumnFilterBenchmark.filterDoubleColumn fails on
 linux-aarch64
Message-ID: <I4Wts1dKzO8OZvP8mmrLIQPahmrmCjeXVNyVlO_9ghc=.43a4c88d-4ddb-4fae-9167-5c5e9fce40b3@github.com>

Hi all,
Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on linux-aarch64. The VM option '-XX:UseAVX=2' only support on x86_64 platform. This PR add option '-XX:+IgnoreUnrecognizedVMOptions' to make test run normally on non x86_64 platform.
Change has been verified locally, test-fix only, no risk.

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

Commit messages:
 - 8349184: [JMH] jdk.incubator.vector.ColumnFilterBenchmark.filterDoubleColumn fails on linux-aarch64

Changes: https://git.openjdk.org/jdk/pull/23409/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23409&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349184
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23409.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23409/head:pull/23409

PR: https://git.openjdk.org/jdk/pull/23409

From duke at openjdk.org  Sat Feb  1 15:20:07 2025
From: duke at openjdk.org (altrisi)
Date: Sat, 1 Feb 2025 15:20:07 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v20]
In-Reply-To: <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
Message-ID: <ew-FWLrsDKQAf3lvYob7bQ0FGsI1YHWINkuQgS5LvBk=.c6ca9f3b-49e9-49dc-87b4-c5f8aa963713@github.com>

On Fri, 18 Oct 2024 21:56:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/optim_str_builder_append_202406' into optim_str_builder_append_202406
>  - fix build error
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'origin/optim_str_builder_append_202406' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - revert test
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/54dfd56d...457735c9

Sure, I already mentioned such program would be incorrect, but one thing is an incorrect result in the StringBuilder and another one is writing outside the bounds of the array into other parts (possibly objects) of the heap, or even outside, causing a VM crash.

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

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2628991914

From duke at openjdk.org  Sat Feb  1 21:06:52 2025
From: duke at openjdk.org (Johannes Graham)
Date: Sat, 1 Feb 2025 21:06:52 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v4]
In-Reply-To: <JENdZLiCWbHnkdjyhqKGyjZxHcq2byLXXj1YRwi_X18=.a94901e5-cc33-4aa8-8f89-16a4fdb9c361@github.com>
References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
 <JENdZLiCWbHnkdjyhqKGyjZxHcq2byLXXj1YRwi_X18=.a94901e5-cc33-4aa8-8f89-16a4fdb9c361@github.com>
Message-ID: <9LbRapcfDX6kWDYczs-aC4YNRO4fI_QSVSlLJ1PZnUg=.4a5d83db-8b4c-479b-8647-cf74ba64914b@github.com>

On Sat, 1 Feb 2025 08:42:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>  - remove getChars(long, int, char[])
>  - copyright
>  - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>  - simplify and comments
>  - simplify
>  - simplify
>  - code style
>  - revert change
>  - bug fix
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/651ac3cc...f9af0b02

src/java.base/share/classes/java/math/BigDecimal.java line 4329:

> 4327: 
> 4328:     private static String scale2(int intCompact) {
> 4329:         int highInt = intCompact / 100;

Something to experiment with here:

        int highInt = intCompact / 100;
        int lowInt = intCompact - highInt * 100;
        short packed=DecimalDigits.pair(lowInt);

        return new StringBuilder()
                .append(highInt)
                .append('.')
                .append((char) (packed & 0xFF))
                .append((char) (packed >> 8))
                .toString();


C2 seems to be able to optimize out the SB here, so it might do as well as `newStringNoRepl`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r1938345667

From rriggs at openjdk.org  Sat Feb  1 21:08:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 1 Feb 2025 21:08:46 GMT
Subject: RFR: 8349107: Remove RMI finalizers
In-Reply-To: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
References: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
Message-ID: <VxHzq1t-Tuow_kmdnVqIgjLfc2ESP-qtM-84uZi8Lio=.36b4ae72-394c-4460-9b06-80d06231560e@github.com>

On Sat, 1 Feb 2025 00:11:31 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> 3 finalizers in RMI code can be removed, as they do not perform meaningful cleanup.
> 
> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**
> 
> `RegistryContext.finalize()` just calls `close()`. The `close()` method does not perform any cleanup per se, but rather "helps the garbage collector" by setting `environment` and `registry` to `null`.
> 
> 
> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.BindingEnumeration`**
> 
> `BindingEnumeration.finalize()` simply calls `close()` on the `ctx` field, itself a `RegistryContext` (and `close()` just "helps the GC.")
> 
> 
> **`src/java.rmi/share/classes/sun/rmi/log/LogInputStream`**
> 
> `LogInputStream` tracks its length with an int field, `length`. If `length` ever becomes == 0, `LogInputStream`'s methods will return without doing anything.
> 
> The finalizer calls `close()`, which just sets length = 0.
> 
> By the time a `LogInputStream` becomes unreachable and is finalized, it's a moot point whether length == 0, as no more methods can be called.
> If anything, this finalizer could cause a bug. If a `LogInputStream` were to became unreachable while a method were still running, the finalizer could set the length to 0 while method code is still running and expecting a length != 0.
> It's possible that there is a very long standing bug that `close()` should be calling `in.close()`, in which case this evaluation will need to be revisited.

Nice cleanup.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23406#pullrequestreview-2588405195

From mukulg at apache.org  Sun Feb  2 05:35:33 2025
From: mukulg at apache.org (Mukul Gandhi)
Date: Sun, 2 Feb 2025 11:05:33 +0530
Subject: adding Xalan's XSL 3 implementation within jdk
Message-ID: <CABuuzNP66-_d7J=UKz2UBY17V2eVk=xvB5w4bRj4A5aEaDQXcw@mail.gmail.com>

Hi all,
     Apache Xalan team wrote much of XSL 3 spec's implementation (I
wrote lot of Java code for this enhancing upon lot of Xalan code
that's within jdk's XML api implementations). Here's url of codebase
repos branch for this,
https://github.com/apache/xalan-java/tree/xalan-j_xslt3.0_mvn.

Is it kindly possible for someone on this list, to look at this code
repos branch and study feasibility of including these Xalan
implementation changes to future jdk release. It may also be helpful
to have these code changes to be part of a possible jdk 1.8 compliant
service pack. It is requested please someone to have git clone of this
code repos branch since there are chances for having code on this
repos branch to change.

I wrote this request mail, initially to Sharat Chander who works with
Oracle (Senior Director, Product Management & Developer Engagement).
He advised me to post this request to, this mail list to try having
this request fulfilled.

Hoping that this list shall oblige with this request over the next few
weeks, or months.

Many thanks.


-- 
Regards,
Mukul Gandhi

From swen at openjdk.org  Sun Feb  2 06:05:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 2 Feb 2025 06:05:48 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v4]
In-Reply-To: <9LbRapcfDX6kWDYczs-aC4YNRO4fI_QSVSlLJ1PZnUg=.4a5d83db-8b4c-479b-8647-cf74ba64914b@github.com>
References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
 <JENdZLiCWbHnkdjyhqKGyjZxHcq2byLXXj1YRwi_X18=.a94901e5-cc33-4aa8-8f89-16a4fdb9c361@github.com>
 <9LbRapcfDX6kWDYczs-aC4YNRO4fI_QSVSlLJ1PZnUg=.4a5d83db-8b4c-479b-8647-cf74ba64914b@github.com>
Message-ID: <jo0xCee8wqLOD5QS6QN91G5btQgLDQYClCUMxJcvlzU=.f17e3f8a-a6b9-48cd-8f43-95fafd047531@github.com>

On Sat, 1 Feb 2025 21:04:29 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>>  - remove getChars(long, int, char[])
>>  - copyright
>>  - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>>  - simplify and comments
>>  - simplify
>>  - simplify
>>  - code style
>>  - revert change
>>  - bug fix
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/651ac3cc...f9af0b02
>
> src/java.base/share/classes/java/math/BigDecimal.java line 4329:
> 
>> 4327: 
>> 4328:     private static String scale2(int intCompact) {
>> 4329:         int highInt = intCompact / 100;
> 
> Something to experiment with here:
> 
>         int highInt = intCompact / 100;
>         int lowInt = intCompact - highInt * 100;
>         short packed=DecimalDigits.pair(lowInt);
> 
>         return new StringBuilder()
>                 .append(highInt)
>                 .append('.')
>                 .append((char) (packed & 0xFF))
>                 .append((char) (packed >> 8))
>                 .toString();
> 
> 
> C2 seems to be able to optimize out the SB here, so it might do as well as `newStringNoRepl`.

Good suggestion, but DecimalDigits no longer provides a pair method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r1938409275

From alanb at openjdk.org  Sun Feb  2 08:47:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 2 Feb 2025 08:47:00 GMT
Subject: RFR: 8258246: sun.net.www.ParseUtil.decode throws
 java.lang.IllegalArgumentException: Error decoding percent encoded characters
 [v2]
In-Reply-To: <CnLPVVzUEGZ9R0R3gGM4uCB67doJjiahAiig8B-nE9k=.3d9a136a-0ff8-47b2-bd6b-5f07b2fdb5bf@github.com>
References: <uesJl3CEVXdcJWQQCIMZ83s3jYG4TTN1Up7npYs5TEs=.c10689e6-50ef-4da8-b82b-6ccff1daac03@github.com>
 <CnLPVVzUEGZ9R0R3gGM4uCB67doJjiahAiig8B-nE9k=.3d9a136a-0ff8-47b2-bd6b-5f07b2fdb5bf@github.com>
Message-ID: <TWpWJEqLSqaLiryQl2jl4z5mWxxcBcp_v4BERb0SFZw=.4346d6b1-d254-4455-898a-117eab91e10d@github.com>

On Fri, 31 Jan 2025 12:53:32 GMT, Fabian Meumertzheim <fmeum at openjdk.org> wrote:

>> `URLClassPath` called into `ParseUtil.fileToEncodedURL`, which misencoded characters with a four byte UTF-8 representation. Replacing that function with `toPath().toUri().toURL()` (and removing it, since its only used once) results in correct encoding for all Unicode characters.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug reference

The reason this issue has been open in JBS for sometime is because it's a not a small project that is fraught with danger. It's bigger and broader than the bug report suggests. Doing anything will require going over decisions make in JDK 1.2, and later in JDK 7 and working through all the compatibility issues that any changes in this area will have.

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

PR Comment: https://git.openjdk.org/jdk/pull/23383#issuecomment-2629301464

From jpai at openjdk.org  Sun Feb  2 12:52:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 2 Feb 2025 12:52:57 GMT
Subject: RFR: 8342775: [Graal]
 java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME  thrown from the
 UncaughtExceptionHandler [v3]
In-Reply-To: <VMIZUY6IHPwpq6mdYzK68tVWo1vZtcrfOEEBnQIfd5Q=.6d097417-42cd-4012-aaa1-53ad1938245c@github.com>
References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com>
 <VMIZUY6IHPwpq6mdYzK68tVWo1vZtcrfOEEBnQIfd5Q=.6d097417-42cd-4012-aaa1-53ad1938245c@github.com>
Message-ID: <QRPN5JCIewbNp875AiEt1ef7_2ta0QeANOnvwX9e4Uk=.a4458907-06b0-4f17-856b-0200bb228e13@github.com>

On Fri, 31 Jan 2025 22:18:32 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309.  In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure.  Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt.
>
> Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Disable test for Graal with Xcomp
>  - Merge branch 'master' into tkr-oomeinaqs-ea
>  - adjust OOMEInStampedLock.java too
>  - Merge branch 'master' into tkr-oomeinaqs-ea
>  - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler

Hello Tom, the change to  the `OOMEInAQS.java` test to skip it when running the combination of Graal and `-Xcomp` looks fine to me. I see that the `OOMEInStampedLock.java` has been updated too to do the same. The original bug report doesn't mention this test. Is the change to `OOMEInStampedLock.java` done as precaution against the same issue?

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

PR Comment: https://git.openjdk.org/jdk/pull/21745#issuecomment-2629383775

From jpai at openjdk.org  Sun Feb  2 13:22:44 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 2 Feb 2025 13:22:44 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
In-Reply-To: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
Message-ID: <qZQgtqmPZb4k4WWoIWhASkD2meVOey-KlCXtIm-jqP4=.30544a26-0b72-4082-b1bc-30424f49fb3f@github.com>

On Fri, 31 Jan 2025 19:42:55 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
> 
> 
> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
> 
> 
> **Other highlights:**
> 
> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
> - `test.lib.Asserts::assertFileContentsEqual` is added

test/lib/jdk/test/lib/Asserts.java line 623:

> 621:      * @throws IOException on I/O failures
> 622:      */
> 623:     public static void assertFileContentsEqual(Path f1, Path f2) throws IOException {

Hello Volkan, is this new method needed? Can its call sites instead be replaced with `java.nio.file.Files.mismatch(...)` call?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1938490806

From mukulg at apache.org  Sun Feb  2 14:27:48 2025
From: mukulg at apache.org (Mukul Gandhi)
Date: Sun, 2 Feb 2025 19:57:48 +0530
Subject: adding Xalan's XSL 3 implementation within jdk
In-Reply-To: <CABuuzNP66-_d7J=UKz2UBY17V2eVk=xvB5w4bRj4A5aEaDQXcw@mail.gmail.com>
References: <CABuuzNP66-_d7J=UKz2UBY17V2eVk=xvB5w4bRj4A5aEaDQXcw@mail.gmail.com>
Message-ID: <CABuuzNPKrdhGyqD-FEP-SU7MS4T_7h1smMBg31G9V2LHcPoq=g@mail.gmail.com>

Hi all,
    Due to an unknowing issue with the previous mail that I've sent as
mentioned within mail trail, the URL of codebase repos branch got
specified as https://github.com/apache/xalan-java/tree/xalan-j_xslt3.0_mvn.
(with an erroneous period suffix character). The correct URL is
https://github.com/apache/xalan-java/tree/xalan-j_xslt3.0_mvn (this
code repos branch also has a test suite with corresponding README
document. The test suite can be run to verify integrity of the
implementation wrt W3C XSL 3.0 specifications).

If I need to provide any clarification about this work, please let me
know and I shall try my best to answer questions wrt this.

I'm also copying this mail to Joseph Kesselman (Xalan PMC member) &
Gary Gregory (Xalan PMC chair), who have also been working on this
implementation.

With best wishes.

On Sun, Feb 2, 2025 at 11:05?AM Mukul Gandhi <mukulg at apache.org> wrote:

>  Apache Xalan team wrote much of XSL 3 spec's implementation (I
> wrote lot of Java code for this enhancing upon lot of Xalan code
> that's within jdk's XML api implementations). Here's url of codebase
> repos branch for this,
> https://github.com/apache/xalan-java/tree/xalan-j_xslt3.0_mvn.
>
> Is it kindly possible for someone on this list, to look at this code
> repos branch and study feasibility of including these Xalan
> implementation changes to future jdk release. It may also be helpful
> to have these code changes to be part of a possible jdk 1.8 compliant
> service pack. It is requested please someone to have git clone of this
> code repos branch since there are chances for having code on this
> repos branch to change.
>
> I wrote this request mail, initially to Sharat Chander who works with
> Oracle (Senior Director, Product Management & Developer Engagement).
> He advised me to post this request to, this mail list to try having
> this request fulfilled.
>
> Hoping that this list shall oblige with this request over the next few
> weeks, or months.
>
> Many thanks.



-- 
Regards,
Mukul Gandhi

From alan.bateman at oracle.com  Sun Feb  2 16:08:01 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sun, 2 Feb 2025 16:08:01 +0000
Subject: adding Xalan's XSL 3 implementation within jdk
In-Reply-To: <CABuuzNPKrdhGyqD-FEP-SU7MS4T_7h1smMBg31G9V2LHcPoq=g@mail.gmail.com>
References: <CABuuzNP66-_d7J=UKz2UBY17V2eVk=xvB5w4bRj4A5aEaDQXcw@mail.gmail.com>
 <CABuuzNPKrdhGyqD-FEP-SU7MS4T_7h1smMBg31G9V2LHcPoq=g@mail.gmail.com>
Message-ID: <e6c986db-9816-4172-9589-e6ce08674dae@oracle.com>

On 02/02/2025 14:27, Mukul Gandhi wrote:
> Hi all,
>      Due to an unknowing issue with the previous mail that I've sent as
> mentioned within mail trail, the URL of codebase repos branch got
> specified ashttps://github.com/apache/xalan-java/tree/xalan-j_xslt3.0_mvn.
> (with an erroneous period suffix character). The correct URL is
> https://github.com/apache/xalan-java/tree/xalan-j_xslt3.0_mvn  (this
> code repos branch also has a test suite with corresponding README
> document. The test suite can be run to verify integrity of the
> implementation wrt W3C XSL 3.0 specifications).
>
> If I need to provide any clarification about this work, please let me
> know and I shall try my best to answer questions wrt this.
>
> I'm also copying this mail to Joseph Kesselman (Xalan PMC member) &
> Gary Gregory (Xalan PMC chair), who have also been working on this
> implementation.

The stats for that branch suggest 5,845 changed files with 234,372 
additions and 84,058 deletions. I can't easily tell how much of this 
would need to come into the jdk repo but this looks like a major update. 
If only 10% of this is applicable to the JDK then it still needs seems 
like a major update that would require a huge investment to audit and 
integrate this code. How much XML is in new applications developed in 
2025? Only asking because it's an area that is surely much lower 
priority compared to all the other major investments right now. Maybe 
there are useful security or performance changes that would be useful to 
cherry pick instead? Finally, does this Xalan update work with the SPIs 
so that someone really looking for XSL 3 can just deploy it on the class 
path and module path?

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250202/c2b7381e/attachment-0001.htm>

From swen at openjdk.org  Sun Feb  2 17:37:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 2 Feb 2025 17:37:43 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
Message-ID: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>

By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.

Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:

1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.

2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.

These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

Commit messages:
 - code style
 - simplify & code style
 - fix comment
 - fix comment
 - support OffsetTime
 - fix comments
 - optimize parseOffsetDateTime
 - optimize nano3
 - Generate PrinterParser using bytecode
 - add benchmark

Changes: https://git.openjdk.org/jdk/pull/23384/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23384&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349189
  Stats: 1687 lines in 9 files changed: 1543 ins; 88 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

PR: https://git.openjdk.org/jdk/pull/23384

From swen at openjdk.org  Sun Feb  2 17:37:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 2 Feb 2025 17:37:43 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <TiRhj8Dq3ABd736LbX0VR5_QxgpLeng3x-4g059wEik=.652ee830-d57c-4159-90d0-a77150e8d8ac@github.com>

On Fri, 31 Jan 2025 10:29:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

Below are the performance numbers on the MacBook M1, which show very significant performance improvements in both parse and format scenarios. Many scenarios have an improvement of more than 100%, and in parse, some scenarios have a performance improvement of more than 10 times.

# 1. Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

#baseline
git checkout 75caf4f7c6acf04d4acbe6434ecdc9ce9a6b35d7
make test TEST="micro:java.time.format.DateTimeFormatterParse"
make test TEST="micro:java.time.format.DateTimeFormatterBench"

# current
git checkout 55ac19d6dfc401d66bb141ada501945b8145c62e
make test TEST="micro:java.time.format.DateTimeFormatterParse"
make test TEST="micro:java.time.format.DateTimeFormatterBench"



# 2. the performance benchmarks on MacBook M1 Pro



-# baseline
-Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units (c49dd5b8efd)
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  16.326 ? 0.440  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  10.870 ? 0.080  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   9.187 ? 0.374  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.086 ? 0.235  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  23.344 ? 0.297  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  16.015 ? 0.198  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  13.561 ? 0.527  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  10.241 ? 0.055  ops/ms

+# current
+Benchmark                                                   (pattern)   Mode  Cnt    Score   Error   Units (55ac19d6dfc)
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15   44.066 ? 0.526  ops/ms
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15   31.789 ? 0.124  ops/ms
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   29.527 ? 0.090  ops/ms
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   23.733 ? 0.083  ops/ms
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  116.871 ? 1.173  ops/ms
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15   75.032 ? 0.321  ops/ms
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15   64.843 ? 0.633  ops/ms
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   49.958 ? 0.511  ops/ms


|   | pattern | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| DateTimeFormatterBench.formatInstants | HH:mm:ss | 16.326 | 44.066 | 169.91% |
| DateTimeFormatterBench.formatInstants | HH:mm:ss.SSS | 10.870 | 31.789 | 192.45% |
| DateTimeFormatterBench.formatInstants | yyyy-MM-dd'T'HH:mm:ss | 9.187 | 29.527 | 221.40% |
| DateTimeFormatterBench.formatInstants | yyyy-MM-dd'T'HH:mm:ss.SSS | 7.086 | 23.733 | 234.93% |
| DateTimeFormatterBench.formatZonedDateTime | HH:mm:ss | 23.344 | 116.871 | 400.65% |
| DateTimeFormatterBench.formatZonedDateTime | HH:mm:ss.SSS | 16.015 | 75.032 | 368.51% |
| DateTimeFormatterBench.formatZonedDateTime | yyyy-MM-dd'T'HH:mm:ss | 13.561 | 64.843 | 378.16% |
| DateTimeFormatterBench.formatZonedDateTime | yyyy-MM-dd'T'HH:mm:ss.SSS | 10.241 | 49.958 | 387.82% |



-# baseline
-Benchmark                                           Mode  Cnt     Score      Error   Units (c49dd5b8efd)
-DateTimeFormatterParse.parseInstant                thrpt   15  2271.484 ?  114.069  ops/ms
-DateTimeFormatterParse.parseLocalDate              thrpt   15  6729.739 ? 1800.372  ops/ms
-DateTimeFormatterParse.parseLocalDateTime          thrpt   15  4224.068 ?  153.198  ops/ms
-DateTimeFormatterParse.parseLocalDateTimeWithNano  thrpt   15  4180.456 ?   82.478  ops/ms
-DateTimeFormatterParse.parseLocalTime              thrpt   15  4908.282 ?  208.797  ops/ms
-DateTimeFormatterParse.parseLocalTimeWithNano      thrpt   15  5412.657 ?  133.999  ops/ms
-DateTimeFormatterParse.parseOffsetDateTime         thrpt   15  2788.254 ?   85.754  ops/ms
-DateTimeFormatterParse.parseZonedDateTime          thrpt   15  2032.773 ?   78.660  ops/ms

+# current
+Benchmark                                           Mode  Cnt       Score       Error   Units (55ac19d6dfc)
+DateTimeFormatterParse.parseInstant                thrpt   15    3645.826 ?    53.758  ops/ms
+DateTimeFormatterParse.parseLocalDate              thrpt   15   57592.249 ?  3711.524  ops/ms
+DateTimeFormatterParse.parseLocalDateTime          thrpt   15   24713.840 ?  1462.137  ops/ms
+DateTimeFormatterParse.parseLocalDateTimeWithNano  thrpt   15   15246.892 ?   960.591  ops/ms
+DateTimeFormatterParse.parseLocalTime              thrpt   15  115757.021 ? 15040.874  ops/ms
+DateTimeFormatterParse.parseLocalTimeWithNano      thrpt   15   64888.840 ?   297.881  ops/ms
+DateTimeFormatterParse.parseOffsetDateTime         thrpt   15   15789.014 ?   188.675  ops/ms
+DateTimeFormatterParse.parseZonedDateTime          thrpt   15    2313.851 ?    61.707  ops/ms


|   | baseline  | current | delta |
| --- | --- | --- | --- |
| DateTimeFormatterParse.parseInstant | 2271.484 | 3645.826 | 60.50% |
| DateTimeFormatterParse.parseLocalDate | 6729.739 | 57592.249 | 755.79% |
| DateTimeFormatterParse.parseLocalDateTime | 4224.068 | 24713.840 | 485.07% |
| DateTimeFormatterParse.parseLocalDateTimeWithNano | 4180.456 | 15246.892 | 264.72% |
| DateTimeFormatterParse.parseLocalTime | 4908.282 | 115757.021 | 2258.40% |
| DateTimeFormatterParse.parseLocalTimeWithNano | 5412.657 | 64888.840 | 1098.84% |
| DateTimeFormatterParse.parseOffsetDateTime | 2788.254 | 15789.014 | 466.27% |
| DateTimeFormatterParse.parseZonedDateTime | 2032.773 | 2313.851 | 13.83% |

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

PR Comment: https://git.openjdk.org/jdk/pull/23384#issuecomment-2629267435

From duke at openjdk.org  Sun Feb  2 18:39:52 2025
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Sun, 2 Feb 2025 18:39:52 GMT
Subject: RFR: 8349107: Remove RMI finalizers
In-Reply-To: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
References: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
Message-ID: <cdfl6Izjb6zZm6lCnmF_lol6ifMxWixUW-Cw1YaXigA=.b4c6788e-59f6-4248-8f65-cfeffe07aa4e@github.com>

On Sat, 1 Feb 2025 00:11:31 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> 3 finalizers in RMI code can be removed, as they do not perform meaningful cleanup.
> 
> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**
> 
> `RegistryContext.finalize()` just calls `close()`. The `close()` method does not perform any cleanup per se, but rather "helps the garbage collector" by setting `environment` and `registry` to `null`.
> 
> 
> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.BindingEnumeration`**
> 
> `BindingEnumeration.finalize()` simply calls `close()` on the `ctx` field, itself a `RegistryContext` (and `close()` just "helps the GC.")
> 
> 
> **`src/java.rmi/share/classes/sun/rmi/log/LogInputStream`**
> 
> `LogInputStream` tracks its length with an int field, `length`. If `length` ever becomes == 0, `LogInputStream`'s methods will return without doing anything.
> 
> The finalizer calls `close()`, which just sets length = 0.
> 
> By the time a `LogInputStream` becomes unreachable and is finalized, it's a moot point whether length == 0, as no more methods can be called.
> If anything, this finalizer could cause a bug. If a `LogInputStream` were to became unreachable while a method were still running, the finalizer could set the length to 0 while method code is still running and expecting a length != 0.
> It's possible that there is a very long standing bug that `close()` should be calling `in.close()`, in which case this evaluation will need to be revisited.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/23406#pullrequestreview-2588611248

From swen at openjdk.org  Mon Feb  3 01:23:53 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 01:23:53 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v4]
In-Reply-To: <pmewlrwxiR1-6SGqlegXjl_zTf6kFbSrfMJ50jsljzU=.da2bcbe0-dfbe-42a2-9057-c3b1273c811b@github.com>
References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
 <JENdZLiCWbHnkdjyhqKGyjZxHcq2byLXXj1YRwi_X18=.a94901e5-cc33-4aa8-8f89-16a4fdb9c361@github.com>
 <9LbRapcfDX6kWDYczs-aC4YNRO4fI_QSVSlLJ1PZnUg=.4a5d83db-8b4c-479b-8647-cf74ba64914b@github.com>
 <jo0xCee8wqLOD5QS6QN91G5btQgLDQYClCUMxJcvlzU=.f17e3f8a-a6b9-48cd-8f43-95fafd047531@github.com>
 <pmewlrwxiR1-6SGqlegXjl_zTf6kFbSrfMJ50jsljzU=.da2bcbe0-dfbe-42a2-9057-c3b1273c811b@github.com>
Message-ID: <zs454taPrQIs0fAG_TDxUqiOyyt-0CSQf7Rjb46W4q4=.fcc60df5-3c09-4552-9c80-5d1a2e68c5aa@github.com>

On Sun, 2 Feb 2025 06:58:21 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Good suggestion, but DecimalDigits no longer provides a pair method
>
> Right - you?d need to add it back to try this

I tested it on a MacBook M1 Max machine and the results were different from what you said. Using StringBuilder + digitPair would degrade performance.



git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# use JLA
git checkout f9af0b0203145b95d82a2067a10bde61b0915dd7
make test TEST="micro:java.math.BigDecimals.smallScale2"

# use digitPair
git checkout 4124121933e08ab185f3f879856197ed15caafd7
make test TEST="micro:java.math.BigDecimals.smallScale2"



Benchmark                                   Mode  Cnt  Score   Error  Units (f9af0b02031)
BigDecimals.smallScale2EngineeringToString  avgt   15  9.658 ? 0.228  ns/op
BigDecimals.smallScale2LayoutCharsToString  avgt   15  9.597 ? 0.047  ns/op
BigDecimals.smallScale2PlainToString        avgt   15  9.759 ? 0.054  ns/op


Benchmark                                   Mode  Cnt   Score   Error  Units (4124121933e)
BigDecimals.smallScale2EngineeringToString  avgt   15  18.763 ? 0.332  ns/op
BigDecimals.smallScale2LayoutCharsToString  avgt   15  18.738 ? 0.214  ns/op
BigDecimals.smallScale2PlainToString        avgt   15  18.992 ? 0.226  ns/op

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r1938650872

From haosun at openjdk.org  Mon Feb  3 01:52:56 2025
From: haosun at openjdk.org (Hao Sun)
Date: Mon, 3 Feb 2025 01:52:56 GMT
Subject: RFR: 8349184: [JMH]
 jdk.incubator.vector.ColumnFilterBenchmark.filterDoubleColumn fails on
 linux-aarch64
In-Reply-To: <I4Wts1dKzO8OZvP8mmrLIQPahmrmCjeXVNyVlO_9ghc=.43a4c88d-4ddb-4fae-9167-5c5e9fce40b3@github.com>
References: <I4Wts1dKzO8OZvP8mmrLIQPahmrmCjeXVNyVlO_9ghc=.43a4c88d-4ddb-4fae-9167-5c5e9fce40b3@github.com>
Message-ID: <09ZkIHMiBZ9A4z_9jUZr2PPLjoGQTODqGCsEMF5gkXA=.86bd56d8-43b3-4175-91c8-970a34603e38@github.com>

On Sat, 1 Feb 2025 14:37:44 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on linux-aarch64. The VM option '-XX:UseAVX=2' only support on x86_64 platform. This PR add option '-XX:+IgnoreUnrecognizedVMOptions' to make test run normally on non x86_64 platform.
> Change has been verified locally, test-fix only, no risk.

test/micro/org/openjdk/bench/jdk/incubator/vector/ColumnFilterBenchmark.java line 2:

> 1: /*
> 2:  *  Copyright (c) 2024, 2025 Oracle and/or its affiliates. All rights reserved.

Should be `2025,`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23409#discussion_r1938662921

From haosun at openjdk.org  Mon Feb  3 02:02:56 2025
From: haosun at openjdk.org (Hao Sun)
Date: Mon, 3 Feb 2025 02:02:56 GMT
Subject: [jdk24] RFR: 8347038: [JMH] jdk.incubator.vector.SpiltReplicate
 fails NoClassDefFoundError
In-Reply-To: <P02Qlvs092QKmxY6m2SAMHUIgCDx9X3czfVhf6C972o=.555415fd-bb31-45c7-9f3d-9b13e1289bf2@github.com>
References: <P02Qlvs092QKmxY6m2SAMHUIgCDx9X3czfVhf6C972o=.555415fd-bb31-45c7-9f3d-9b13e1289bf2@github.com>
Message-ID: <8stNu1IUCCv5vkxERTO47b_ccMvs4chKfTvzblkETT4=.6410168c-527f-40dd-bea7-40b20d9cee0c@github.com>

On Tue, 7 Jan 2025 15:14:18 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4d8fb807](https://github.com/openjdk/jdk/commit/4d8fb80732fd17352c36254c6dfc1be5dbfbacf1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24.
> 
> The commit being backported was authored by SendaoYan on 7 Jan 2025 and was reviewed by Paul Sandoz. Fix the JMH test bug, test-fix only, no risk.
> 
> Thanks!

Marked as reviewed by haosun (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22949#pullrequestreview-2588750728

From syan at openjdk.org  Mon Feb  3 04:16:57 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 3 Feb 2025 04:16:57 GMT
Subject: RFR: 8349184: [JMH]
 jdk.incubator.vector.ColumnFilterBenchmark.filterDoubleColumn fails on
 linux-aarch64 [v2]
In-Reply-To: <I4Wts1dKzO8OZvP8mmrLIQPahmrmCjeXVNyVlO_9ghc=.43a4c88d-4ddb-4fae-9167-5c5e9fce40b3@github.com>
References: <I4Wts1dKzO8OZvP8mmrLIQPahmrmCjeXVNyVlO_9ghc=.43a4c88d-4ddb-4fae-9167-5c5e9fce40b3@github.com>
Message-ID: <MyzpFFgh5CI1xalidzWA4PaoAmIYou0YJo8L-FOxgCI=.5fdb55b1-6d0e-48b9-af77-0fe5b1267aca@github.com>

> Hi all,
> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on linux-aarch64. The VM option '-XX:UseAVX=2' only support on x86_64 platform. This PR add option '-XX:+IgnoreUnrecognizedVMOptions' to make test run normally on non x86_64 platform.
> Change has been verified locally, test-fix only, no risk.

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

  add missing ,

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23409/files
  - new: https://git.openjdk.org/jdk/pull/23409/files/533bc644..fd8a14d3

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

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

PR: https://git.openjdk.org/jdk/pull/23409

From syan at openjdk.org  Mon Feb  3 04:16:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 3 Feb 2025 04:16:58 GMT
Subject: RFR: 8349184: [JMH]
 jdk.incubator.vector.ColumnFilterBenchmark.filterDoubleColumn fails on
 linux-aarch64 [v2]
In-Reply-To: <09ZkIHMiBZ9A4z_9jUZr2PPLjoGQTODqGCsEMF5gkXA=.86bd56d8-43b3-4175-91c8-970a34603e38@github.com>
References: <I4Wts1dKzO8OZvP8mmrLIQPahmrmCjeXVNyVlO_9ghc=.43a4c88d-4ddb-4fae-9167-5c5e9fce40b3@github.com>
 <09ZkIHMiBZ9A4z_9jUZr2PPLjoGQTODqGCsEMF5gkXA=.86bd56d8-43b3-4175-91c8-970a34603e38@github.com>
Message-ID: <52ITSH8hkmbYoXoBTnOQKjFRdqy-ZhggIJ5v7PnT1tU=.43860553-ca71-4d46-9b5c-e56478ba9be4@github.com>

On Mon, 3 Feb 2025 01:49:45 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add missing ,
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/ColumnFilterBenchmark.java line 2:
> 
>> 1: /*
>> 2:  *  Copyright (c) 2024, 2025 Oracle and/or its affiliates. All rights reserved.
> 
> Should be `2025,`

Thanks, the missing comma has been added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23409#discussion_r1938744749

From never at openjdk.org  Mon Feb  3 04:59:55 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 3 Feb 2025 04:59:55 GMT
Subject: RFR: 8342775: [Graal]
 java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME  thrown from the
 UncaughtExceptionHandler [v3]
In-Reply-To: <VMIZUY6IHPwpq6mdYzK68tVWo1vZtcrfOEEBnQIfd5Q=.6d097417-42cd-4012-aaa1-53ad1938245c@github.com>
References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com>
 <VMIZUY6IHPwpq6mdYzK68tVWo1vZtcrfOEEBnQIfd5Q=.6d097417-42cd-4012-aaa1-53ad1938245c@github.com>
Message-ID: <WFuVqHqV2VzKb_NiKDyN19qQ42Cx-rm3TLEFH-iw1VY=.4604be72-e063-48ac-a720-8a5395459848@github.com>

On Fri, 31 Jan 2025 22:18:32 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309.  In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure.  Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt.
>
> Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Disable test for Graal with Xcomp
>  - Merge branch 'master' into tkr-oomeinaqs-ea
>  - adjust OOMEInStampedLock.java too
>  - Merge branch 'master' into tkr-oomeinaqs-ea
>  - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler

At the time it was filed, OOMEInStampedLock.java didn't exist but it's a direct clone of OOMEInAQS.java and has the exact same problem in our testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/21745#issuecomment-2629956593

From jpai at openjdk.org  Mon Feb  3 06:11:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Feb 2025 06:11:50 GMT
Subject: RFR: 8342775: [Graal]
 java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME  thrown from the
 UncaughtExceptionHandler [v3]
In-Reply-To: <VMIZUY6IHPwpq6mdYzK68tVWo1vZtcrfOEEBnQIfd5Q=.6d097417-42cd-4012-aaa1-53ad1938245c@github.com>
References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com>
 <VMIZUY6IHPwpq6mdYzK68tVWo1vZtcrfOEEBnQIfd5Q=.6d097417-42cd-4012-aaa1-53ad1938245c@github.com>
Message-ID: <wW6Es5aoPwKpjJ3lPG5XUDMSd7WE44BEk0DsZkB2loU=.dde0e619-97a5-4c76-ae0e-821f9112f622@github.com>

On Fri, 31 Jan 2025 22:18:32 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309.  In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure.  Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt.
>
> Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Disable test for Graal with Xcomp
>  - Merge branch 'master' into tkr-oomeinaqs-ea
>  - adjust OOMEInStampedLock.java too
>  - Merge branch 'master' into tkr-oomeinaqs-ea
>  - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21745#pullrequestreview-2588986495

From dholmes at openjdk.org  Mon Feb  3 07:30:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Feb 2025 07:30:58 GMT
Subject: RFR: 8342775: [Graal]
 java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME  thrown from the
 UncaughtExceptionHandler [v3]
In-Reply-To: <VMIZUY6IHPwpq6mdYzK68tVWo1vZtcrfOEEBnQIfd5Q=.6d097417-42cd-4012-aaa1-53ad1938245c@github.com>
References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com>
 <VMIZUY6IHPwpq6mdYzK68tVWo1vZtcrfOEEBnQIfd5Q=.6d097417-42cd-4012-aaa1-53ad1938245c@github.com>
Message-ID: <OdZNoJHMbe2eo559ksWC8XikWwtwHY18xhrxo3Y1lhw=.01e35868-7f49-45f7-a01b-b935011c94f8@github.com>

On Fri, 31 Jan 2025 22:18:32 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309.  In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure.  Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt.
>
> Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Disable test for Graal with Xcomp
>  - Merge branch 'master' into tkr-oomeinaqs-ea
>  - adjust OOMEInStampedLock.java too
>  - Merge branch 'master' into tkr-oomeinaqs-ea
>  - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler

Thanks for the fix.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21745#pullrequestreview-2589105737

From haosun at openjdk.org  Mon Feb  3 07:42:46 2025
From: haosun at openjdk.org (Hao Sun)
Date: Mon, 3 Feb 2025 07:42:46 GMT
Subject: RFR: 8349184: [JMH]
 jdk.incubator.vector.ColumnFilterBenchmark.filterDoubleColumn fails on
 linux-aarch64 [v2]
In-Reply-To: <MyzpFFgh5CI1xalidzWA4PaoAmIYou0YJo8L-FOxgCI=.5fdb55b1-6d0e-48b9-af77-0fe5b1267aca@github.com>
References: <I4Wts1dKzO8OZvP8mmrLIQPahmrmCjeXVNyVlO_9ghc=.43a4c88d-4ddb-4fae-9167-5c5e9fce40b3@github.com>
 <MyzpFFgh5CI1xalidzWA4PaoAmIYou0YJo8L-FOxgCI=.5fdb55b1-6d0e-48b9-af77-0fe5b1267aca@github.com>
Message-ID: <pa8bStqg6pLF3FSbuX2ZxGHDzyOPXL0ncAVu37c2oA4=.4b1faae5-1260-4e05-bc0a-8b1efb9d265f@github.com>

On Mon, 3 Feb 2025 04:16:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on linux-aarch64. The VM option '-XX:UseAVX=2' only support on x86_64 platform. This PR add option '-XX:+IgnoreUnrecognizedVMOptions' to make test run normally on non x86_64 platform.
>> Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing ,

Marked as reviewed by haosun (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/23409#pullrequestreview-2589123424

From syan at openjdk.org  Mon Feb  3 08:42:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 3 Feb 2025 08:42:34 GMT
Subject: RFR: 8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark fails
Message-ID: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>

Hi all,
The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:


        TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
        System.out.println(tz.getDisplayName());
        System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
        System.out.println(tz.getDisplayName(false, TimeZone.SHORT));


- Java 22 output:


~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
Ecuador Time
ECST
ECT


- Java 23 output:


~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
Ecuador Time
GMT-04:00
GMT-05:00


This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.

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

Commit messages:
 - 8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark fails

Changes: https://git.openjdk.org/jdk/pull/23414/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23414&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349200
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23414/head:pull/23414

PR: https://git.openjdk.org/jdk/pull/23414

From scolebourne at openjdk.org  Mon Feb  3 09:05:48 2025
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Mon, 3 Feb 2025 09:05:48 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <9CyvGLWWh4ELygv9gkUMlemHuIxsge2CC1BdcOHT3WQ=.999ff8e5-8fb2-45b2-b826-ce7a4f84809d@github.com>

On Fri, 31 Jan 2025 10:29:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

My comments refer to the outer parts of the PR. I haven't reviewed the class file generation part.

With these changes, please ensure that the same field can be output twice. Not sure if any tests cover that.

Thanks for the performance boost.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2594:

> 2592:         }
> 2593: 
> 2594:         public <T> T parse(CharSequence text, DateTimeFormatter formatter, TemporalQuery<T> query) {

Would package or protected scope be sufficient?

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2635:

> 2633:         }
> 2634: 
> 2635:         static int litteral(CharSequence text, int pos, char literlal) {

`literal`

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3062:

> 3060: 
> 3061:         protected final void printValueFixWidth3NotNegative(StringBuilder buf, int value) {
> 3062:             if (value > 1000) {

Should this be `>=` ?

src/java.base/share/classes/java/time/temporal/TemporalAccessor.java line 327:

> 325:      * @return the year, from MIN_YEAR to MAX_YEAR
> 326:      */
> 327:     default int getYear() {

The whole point of `TemporalAccessor` is that it does not have methods like these - it does not assume anything about the temporal.

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

PR Review: https://git.openjdk.org/jdk/pull/23384#pullrequestreview-2589155307
PR Review Comment: https://git.openjdk.org/jdk/pull/23384#discussion_r1938938121
PR Review Comment: https://git.openjdk.org/jdk/pull/23384#discussion_r1938998806
PR Review Comment: https://git.openjdk.org/jdk/pull/23384#discussion_r1939005206
PR Review Comment: https://git.openjdk.org/jdk/pull/23384#discussion_r1938934674

From vyazici at openjdk.org  Mon Feb  3 09:25:08 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Feb 2025 09:25:08 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v2]
In-Reply-To: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
Message-ID: <DMQ0eJ-Az5OH3GVlyl9Cq2n4S7k8S8CZ5K_IJAUcQVw=.8f2210a4-4b6d-4b70-9e4a-79c922dee79e@github.com>

> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
> 
> 
> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
> 
> 
> **Other highlights:**
> 
> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
> - `test.lib.Asserts::assertFileContentsEqual` is added

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

  Remove `assertFileContentsEqual()`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23401/files
  - new: https://git.openjdk.org/jdk/pull/23401/files/29571eab..421d19d4

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

  Stats: 56 lines in 7 files changed: 6 ins; 44 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23401/head:pull/23401

PR: https://git.openjdk.org/jdk/pull/23401

From vyazici at openjdk.org  Mon Feb  3 09:28:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Feb 2025 09:28:54 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v2]
In-Reply-To: <qZQgtqmPZb4k4WWoIWhASkD2meVOey-KlCXtIm-jqP4=.30544a26-0b72-4082-b1bc-30424f49fb3f@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
 <qZQgtqmPZb4k4WWoIWhASkD2meVOey-KlCXtIm-jqP4=.30544a26-0b72-4082-b1bc-30424f49fb3f@github.com>
Message-ID: <FGGD4jb6mdaByF3Kra06Dqo4orEWEUK527yOFP4DlvU=.24d6f489-21f0-4119-b224-03833d21128c@github.com>

On Sun, 2 Feb 2025 13:20:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove `assertFileContentsEqual()`
>
> test/lib/jdk/test/lib/Asserts.java line 623:
> 
>> 621:      * @throws IOException on I/O failures
>> 622:      */
>> 623:     public static void assertFileContentsEqual(Path f1, Path f2) throws IOException {
> 
> Hello Volkan, is this new method needed? Can its call sites instead be replaced with `java.nio.file.Files.mismatch(...)` call?

I thought it reports more useful diagnostics compared to the earlier `file compare failed` message. Nevertheless, replaced it with `Files::mismatch` in 421d19d468d62bdb04aee458c72a338a5c053e73.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1939052590

From aph at openjdk.org  Mon Feb  3 11:02:47 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 3 Feb 2025 11:02:47 GMT
Subject: RFR: 8349184: [JMH]
 jdk.incubator.vector.ColumnFilterBenchmark.filterDoubleColumn fails on
 linux-aarch64 [v2]
In-Reply-To: <MyzpFFgh5CI1xalidzWA4PaoAmIYou0YJo8L-FOxgCI=.5fdb55b1-6d0e-48b9-af77-0fe5b1267aca@github.com>
References: <I4Wts1dKzO8OZvP8mmrLIQPahmrmCjeXVNyVlO_9ghc=.43a4c88d-4ddb-4fae-9167-5c5e9fce40b3@github.com>
 <MyzpFFgh5CI1xalidzWA4PaoAmIYou0YJo8L-FOxgCI=.5fdb55b1-6d0e-48b9-af77-0fe5b1267aca@github.com>
Message-ID: <nUOOgTIdsORkeTZOAVHdWNGjmWywoKs_7KC4lYvEshA=.5611642f-67ff-44c7-a59c-1d32ed05f17d@github.com>

On Mon, 3 Feb 2025 04:16:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on linux-aarch64. The VM option '-XX:UseAVX=2' only support on x86_64 platform. This PR add option '-XX:+IgnoreUnrecognizedVMOptions' to make test run normally on non x86_64 platform.
>> Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing ,

Marked as reviewed by aph (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23409#pullrequestreview-2589570399

From duke at openjdk.org  Mon Feb  3 11:57:54 2025
From: duke at openjdk.org (duke)
Date: Mon, 3 Feb 2025 11:57:54 GMT
Subject: Withdrawn: 8344246: Unnecessary Hashtable usage in
 EventSupport.notifiers
In-Reply-To: <DyA3eTtyK0cAhwf_o-GTkHWMai75huS45AP1TTdVo5w=.6ec6de4f-1ad2-498f-a64e-f0dec465a306@github.com>
References: <DyA3eTtyK0cAhwf_o-GTkHWMai75huS45AP1TTdVo5w=.6ec6de4f-1ad2-498f-a64e-f0dec465a306@github.com>
Message-ID: <idro-SkDRSDic1cCq44ljT5IOy9uoeW3g2Bq8G1xmz0=.65836f93-5537-4d10-9503-68fd7284702d@github.com>

On Tue, 5 Nov 2024 08:28:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> The field `com.sun.jndi.ldap.EventSupport#notifiers` is always accessed under `lock`. It means extra synchronization from `Hashtable` is not needed.
> Subtle difference in Hashtable vs Hashmap behavior is that Hashtable doesn't allow `null` keys and `null` values. I've checked all usages of it - only non-null keys and values are put into it. So, replacement is safe.
> 
> One thing which was suspicous for me is `null` check of value in the `com.sun.jndi.ldap.EventSupport#removeNamingListener` method:
> https://github.com/openjdk/jdk/blob/b54bd824b59b6b5dff9278ddebab4e9e2dfaf57b/src/java.naming/share/classes/com/sun/jndi/ldap/EventSupport.java#L230-L235
> The condition `notifier != null` is always `true`.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/21894

From aturbanov at openjdk.org  Mon Feb  3 12:49:51 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 3 Feb 2025 12:49:51 GMT
Subject: RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v2]
In-Reply-To: <44mZCe1gb7oIVFrfWrX0QB01AC8MPanddHyguOkwF7U=.92b8bb69-94c8-4f87-8ee8-9f12f5f9d47a@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
 <44mZCe1gb7oIVFrfWrX0QB01AC8MPanddHyguOkwF7U=.92b8bb69-94c8-4f87-8ee8-9f12f5f9d47a@github.com>
Message-ID: <WsZgDc0x-v--FYgQyThleuAUZRha5hookrYV_Rra2oE=.33748369-aa18-4b1c-84cb-5297d120d19f@github.com>

On Fri, 31 Jan 2025 19:46:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`.
>> 
>> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   generalize format comment

src/java.base/share/classes/java/util/Currency.java line 1182:

> 1180:         private static boolean isPastCutoverDate(String cutOver) {
> 1181:             return System.currentTimeMillis() >
> 1182:                     LocalDateTime.parse(cutOver.trim(), DateTimeFormatter.ISO_LOCAL_DATE_TIME)

Btw, do we really need this `trim()` call?
It looks redundant. prop.date is result part of `m.group(4)` of this regexp:
https://github.com/openjdk/jdk/blob/3f1d9b573546685215af06031656efe6f1429caf/src/java.base/share/classes/java/util/Currency.java#L255-L257
`(\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2})`

I don't see how it could contain whitespace characters on start or end.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23374#discussion_r1939322191

From swen at openjdk.org  Mon Feb  3 13:07:27 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 13:07:27 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v2]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <h38bDMF4XGArBXFrLI7YA5imWXY_CIX-tGnbH7t8xiI=.04e1af22-3ce8-4e41-a33f-c0c9aa9002e4@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:

 - typo
 - bug fix, from @jodastephen
 - bug fix, from @jodastephen
 - typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/aec84b03..b0ac02d4

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

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

PR: https://git.openjdk.org/jdk/pull/23384

From swen at openjdk.org  Mon Feb  3 13:10:47 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 13:10:47 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v2]
In-Reply-To: <9CyvGLWWh4ELygv9gkUMlemHuIxsge2CC1BdcOHT3WQ=.999ff8e5-8fb2-45b2-b826-ce7a4f84809d@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
 <9CyvGLWWh4ELygv9gkUMlemHuIxsge2CC1BdcOHT3WQ=.999ff8e5-8fb2-45b2-b826-ce7a4f84809d@github.com>
Message-ID: <uzybaBXeJAB-oLmwnYsWEQeUvCFA5vii6jIG_YkzqSY=.ccaa6d2d-a4f5-4eb0-884d-9d31b9b985f3@github.com>

On Mon, 3 Feb 2025 07:59:02 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - typo
>>  - bug fix, from @jodastephen
>>  - bug fix, from @jodastephen
>>  - typo
>
> src/java.base/share/classes/java/time/temporal/TemporalAccessor.java line 327:
> 
>> 325:      * @return the year, from MIN_YEAR to MAX_YEAR
>> 326:      */
>> 327:     default int getYear() {
> 
> The whole point of `TemporalAccessor` is that it does not have methods like these - it does not assume anything about the temporal.

If these methods are not added here, query will be called during formatting, which will incur some overhead. By providing these methods, if these Fields are not supported by the implementation of the TemporalAccessor, the error reporting behavior will remain the same as before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23384#discussion_r1939350252

From swen at openjdk.org  Mon Feb  3 13:19:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 13:19:45 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v2]
In-Reply-To: <9CyvGLWWh4ELygv9gkUMlemHuIxsge2CC1BdcOHT3WQ=.999ff8e5-8fb2-45b2-b826-ce7a4f84809d@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
 <9CyvGLWWh4ELygv9gkUMlemHuIxsge2CC1BdcOHT3WQ=.999ff8e5-8fb2-45b2-b826-ce7a4f84809d@github.com>
Message-ID: <fhxOg8uMZiZHU2MRntKVxe1xTRuFTC8wZpkv7nknMiw=.e290bf1b-d236-4f5d-8b5a-ee7f57200cc9@github.com>

On Mon, 3 Feb 2025 09:02:59 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

> My comments refer to the outer parts of the PR. I haven't reviewed the class file generation part.
> 
> With these changes, please ensure that the same field can be output twice. Not sure if any tests cover that.
> 
> Thanks for the performance boost.

Thanks @jodastephen, the optimization of this PR is to take a shorter path through ClassFile generation, without changing the original behavior. The behavior of outputting the same field multiple times should be the same as before. I will also add tests to cover the current changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/23384#issuecomment-2630982846

From scolebourne at openjdk.org  Mon Feb  3 13:30:47 2025
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Mon, 3 Feb 2025 13:30:47 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v2]
In-Reply-To: <uzybaBXeJAB-oLmwnYsWEQeUvCFA5vii6jIG_YkzqSY=.ccaa6d2d-a4f5-4eb0-884d-9d31b9b985f3@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
 <9CyvGLWWh4ELygv9gkUMlemHuIxsge2CC1BdcOHT3WQ=.999ff8e5-8fb2-45b2-b826-ce7a4f84809d@github.com>
 <uzybaBXeJAB-oLmwnYsWEQeUvCFA5vii6jIG_YkzqSY=.ccaa6d2d-a4f5-4eb0-884d-9d31b9b985f3@github.com>
Message-ID: <1W_tF6ZOntsiJh9n7QVeH3hZko7VQ22S6w64A9RCYk8=.0b7e24ec-a99d-4048-9a9c-64eaaa7ba207@github.com>

On Mon, 3 Feb 2025 13:07:54 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/temporal/TemporalAccessor.java line 327:
>> 
>>> 325:      * @return the year, from MIN_YEAR to MAX_YEAR
>>> 326:      */
>>> 327:     default int getYear() {
>> 
>> The whole point of `TemporalAccessor` is that it does not have methods like these - it does not assume anything about the temporal.
>
> If these methods are not added here, query will be called during formatting, which will incur some overhead. By providing these methods, if these Fields are not supported by the implementation of the TemporalAccessor, the error reporting behavior will remain the same as before.

To retain the design of java.time, you cannot add these methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23384#discussion_r1939378358

From jvernee at openjdk.org  Mon Feb  3 13:53:04 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Feb 2025 13:53:04 GMT
Subject: RFR: 8287788: Implement a better allocator for downcalls [v18]
In-Reply-To: <Ycfo32fkfmcX332ag1BKYatxVVdLtiyHQSzmW82GuiY=.dc58a535-ba78-4ce6-a059-76af5df8e5c8@github.com>
References: <lGAHUKO5rriFO4hwvI2udJxslv2RB_YVDb3qdPmm0PU=.056a498a-8fc5-450c-ab51-6ddf1abe8fa2@github.com>
 <IZlZEhyy67aCP5VIumH2t9aF-yUWNlxT3-QyG39A3AU=.176bf64d-bee3-4e56-b0ab-9619db86ff24@github.com>
 <Ycfo32fkfmcX332ag1BKYatxVVdLtiyHQSzmW82GuiY=.dc58a535-ba78-4ce6-a059-76af5df8e5c8@github.com>
Message-ID: <lQ-yUf4BbfswNxo82qYKEO__3zrBctEn_cSCTMpuTQ8=.c95c7f99-7d5a-4bc0-af23-557e16187748@github.com>

On Sat, 1 Feb 2025 11:18:18 GMT, Matthias Ernst <duke at openjdk.org> wrote:

>> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix test under VThread factory
>
> Tried for a few hours to repro with various approaches, to no avail.

@mernst-github 

It should be possible to reproduce on either an x64 or AArch64 mac machine using:


make test TEST=test/jdk/java/foreign/TestBufferStack.java JTREG_REPEAT_COUNT=1000


It will take a while to run/fail. The failure seems to be detected by the `malloc` implementation on mac. The process fails with exit code 134 without any output, but the core file should be usable.

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

PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2631053427

From jvernee at openjdk.org  Mon Feb  3 13:53:04 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Feb 2025 13:53:04 GMT
Subject: RFR: 8287788: Implement a better allocator for downcalls [v18]
In-Reply-To: <IZlZEhyy67aCP5VIumH2t9aF-yUWNlxT3-QyG39A3AU=.176bf64d-bee3-4e56-b0ab-9619db86ff24@github.com>
References: <lGAHUKO5rriFO4hwvI2udJxslv2RB_YVDb3qdPmm0PU=.056a498a-8fc5-450c-ab51-6ddf1abe8fa2@github.com>
 <IZlZEhyy67aCP5VIumH2t9aF-yUWNlxT3-QyG39A3AU=.176bf64d-bee3-4e56-b0ab-9619db86ff24@github.com>
Message-ID: <ZHqgIMh1C0YLY5VYTrinl8Mt9y3Hnhd8CWkWUGzLsrM=.5fd85172-f33d-4099-a26d-61a2978c6947@github.com>

On Thu, 23 Jan 2025 17:36:11 GMT, Matthias Ernst <duke at openjdk.org> wrote:

>> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead.
>> 
>> Sample stack trace:
>> 
>>    java.lang.Thread.State: RUNNABLE
>> 	at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method)
>> ...
>> 	at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386)
>> 	at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source)
>> ...
>> 	at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder)
>> 
>> 
>> To alleviate this, this PR implements a per carrier-thread stacked allocator.
>> 
>> Performance (MBA M3):
>> 
>> 
>> Before:
>> Benchmark                    Mode  Cnt   Score   Error  Units
>> CallOverheadByValue.byPtr    avgt   10   3.333 ? 0.152  ns/op
>> CallOverheadByValue.byValue  avgt   10  33.892 ? 0.034  ns/op
>> 
>> After:
>> Benchmark                    Mode  Cnt  Score   Error  Units
>> CallOverheadByValue.byPtr    avgt   30  3.311 ? 0.034  ns/op
>> CallOverheadByValue.byValue  avgt   30  6.143 ? 0.053  ns/op
>> 
>> 
>> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before.
>
> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test under VThread factory

P.S. I have not tried this yet, but some of the malloc debugging flags available on mac may help trigger this faster: https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html

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

PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2631058894

From swen at openjdk.org  Mon Feb  3 14:16:31 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 14:16:31 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v3]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <3Z8AuD9fsDc7OcJs0HIJKB7xhg24fdX4XjQ1PnpRi8U=.805655b2-278d-4ee4-b5b7-c28dd02a687b@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - revert TemporalAccessor change, from @jodastephen
 - revert TemporalAccessor change, from @jodastephen

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/b0ac02d4..5388a40e

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

  Stats: 113 lines in 3 files changed: 5 ins; 89 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

PR: https://git.openjdk.org/jdk/pull/23384

From galder at openjdk.org  Mon Feb  3 14:22:52 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 3 Feb 2025 14:22:52 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
Message-ID: <ZB3z3AeYNtcPXQt2oBLNokMziVx2WOnKoVCxMoyEO7M=.84e952ac-7415-4c3e-8f6a-06ae1b7526d4@github.com>

On Fri, 17 Jan 2025 17:53:24 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

@eastig fyi

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2631136070

From syan at openjdk.org  Mon Feb  3 14:29:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 3 Feb 2025 14:29:03 GMT
Subject: RFR: 8349184: [JMH]
 jdk.incubator.vector.ColumnFilterBenchmark.filterDoubleColumn fails on
 linux-aarch64 [v2]
In-Reply-To: <MyzpFFgh5CI1xalidzWA4PaoAmIYou0YJo8L-FOxgCI=.5fdb55b1-6d0e-48b9-af77-0fe5b1267aca@github.com>
References: <I4Wts1dKzO8OZvP8mmrLIQPahmrmCjeXVNyVlO_9ghc=.43a4c88d-4ddb-4fae-9167-5c5e9fce40b3@github.com>
 <MyzpFFgh5CI1xalidzWA4PaoAmIYou0YJo8L-FOxgCI=.5fdb55b1-6d0e-48b9-af77-0fe5b1267aca@github.com>
Message-ID: <WknplkrYdjcofNSqrR3s6-H254g5g4PSDkXOPaJ_fw4=.4fee4115-f647-4fce-9d71-88b6a187ed5f@github.com>

On Mon, 3 Feb 2025 04:16:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on linux-aarch64. The VM option '-XX:UseAVX=2' only support on x86_64 platform. This PR add option '-XX:+IgnoreUnrecognizedVMOptions' to make test run normally on non x86_64 platform.
>> Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing ,

Thanks all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23409#issuecomment-2631148133

From syan at openjdk.org  Mon Feb  3 14:29:05 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 3 Feb 2025 14:29:05 GMT
Subject: Integrated: 8349184: [JMH]
 jdk.incubator.vector.ColumnFilterBenchmark.filterDoubleColumn fails on
 linux-aarch64
In-Reply-To: <I4Wts1dKzO8OZvP8mmrLIQPahmrmCjeXVNyVlO_9ghc=.43a4c88d-4ddb-4fae-9167-5c5e9fce40b3@github.com>
References: <I4Wts1dKzO8OZvP8mmrLIQPahmrmCjeXVNyVlO_9ghc=.43a4c88d-4ddb-4fae-9167-5c5e9fce40b3@github.com>
Message-ID: <7gA-robvkBnqAb-BqdaL-J_pbT7xpdYwREp9Myh_P8o=.d14d3e57-3d4c-4e40-bfeb-ebb72a2f7281@github.com>

On Sat, 1 Feb 2025 14:37:44 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on linux-aarch64. The VM option '-XX:UseAVX=2' only support on x86_64 platform. This PR add option '-XX:+IgnoreUnrecognizedVMOptions' to make test run normally on non x86_64 platform.
> Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: a57c9b10
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a57c9b101a7fdb08ed1c8ca31ab0d4cc0040f1ba
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8349184: [JMH] jdk.incubator.vector.ColumnFilterBenchmark.filterDoubleColumn fails on linux-aarch64

Reviewed-by: haosun, aph

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

PR: https://git.openjdk.org/jdk/pull/23409

From coleenp at openjdk.org  Mon Feb  3 14:31:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 14:31:28 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v3]
In-Reply-To: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
Message-ID: <f5eXDXA1waU4JEF8Obcewzm0EzEDcpX7jPdgxc3nrro=.c6d73e92-2b13-4811-a5ef-081981b249fa@github.com>

> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.

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

 - Hide Class.protectionDomain for reflection and add a test case.
 - Merge branch 'master' into protection-domain
 - Fix two tests.
 - Fix the test.
 - 8349145: Make Class.getProtectionDomain() non-native

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23396/files
  - new: https://git.openjdk.org/jdk/pull/23396/files/d7aafbaf..954c9a76

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

  Stats: 3875 lines in 26 files changed: 176 ins; 3644 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/23396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23396/head:pull/23396

PR: https://git.openjdk.org/jdk/pull/23396

From swen at openjdk.org  Mon Feb  3 14:37:30 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 14:37:30 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v4]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <-Dzxwsi4EhGQOWXnqpbO6K7yVMbB_gmguHsfMjrIKrg=.f9002b1c-fccd-4fc0-994f-7877cf10a563@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  use get & formatInt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/5388a40e..c44d03b5

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

  Stats: 21 lines in 1 file changed: 1 ins; 11 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

PR: https://git.openjdk.org/jdk/pull/23384

From liach at openjdk.org  Mon Feb  3 14:55:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Feb 2025 14:55:49 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v3]
In-Reply-To: <f5eXDXA1waU4JEF8Obcewzm0EzEDcpX7jPdgxc3nrro=.c6d73e92-2b13-4811-a5ef-081981b249fa@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <f5eXDXA1waU4JEF8Obcewzm0EzEDcpX7jPdgxc3nrro=.c6d73e92-2b13-4811-a5ef-081981b249fa@github.com>
Message-ID: <dU_uUZJWjalhNPFw8FrOh9l2XYiJXIy9qOBXFtSfZjg=.a58e8230-bf3b-4f2c-b33c-d953977d5356@github.com>

On Mon, 3 Feb 2025 14:31:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Hide Class.protectionDomain for reflection and add a test case.
>  - Merge branch 'master' into protection-domain
>  - Fix two tests.
>  - Fix the test.
>  - 8349145: Make Class.getProtectionDomain() non-native

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 59:

> 57:             Reflection.class, ALL_MEMBERS,
> 58:             AccessibleObject.class, ALL_MEMBERS,
> 59:             Class.class, Set.of("classLoader", "classData", "protectionDomain"),

Can you run a hello world with `-Xlog:class+init` to see if Reflection is initialized after `System$2` or something that implements JavaLangAccess?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1939515576

From jpai at openjdk.org  Mon Feb  3 15:53:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Feb 2025 15:53:17 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append boolean
 & null
Message-ID: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>

Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?

The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated.

This backout was done using `git revert 5890d9438bbde88b89070052926a2eafe13d7b42`, but the the revert wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.

tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.

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

Commit messages:
 - Revert "8333893: Optimization for StringBuilder append boolean & null"

Changes: https://git.openjdk.org/jdk/pull/23420/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23420&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349183
  Stats: 133 lines in 5 files changed: 18 ins; 79 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/23420.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23420/head:pull/23420

PR: https://git.openjdk.org/jdk/pull/23420

From coleenp at openjdk.org  Mon Feb  3 16:02:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 16:02:00 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v3]
In-Reply-To: <f5eXDXA1waU4JEF8Obcewzm0EzEDcpX7jPdgxc3nrro=.c6d73e92-2b13-4811-a5ef-081981b249fa@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <f5eXDXA1waU4JEF8Obcewzm0EzEDcpX7jPdgxc3nrro=.c6d73e92-2b13-4811-a5ef-081981b249fa@github.com>
Message-ID: <v-kahgpWNMpQNed48roZ80NZXYS0FwX25ti4xzphCy8=.e6e90006-c68d-47df-a62c-9b6d820e498f@github.com>

On Mon, 3 Feb 2025 14:31:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Hide Class.protectionDomain for reflection and add a test case.
>  - Merge branch 'master' into protection-domain
>  - Fix two tests.
>  - Fix the test.
>  - 8349145: Make Class.getProtectionDomain() non-native

[0.102s][info][class,init] 55 Initializing 'java/lang/System$1'(no method) (0x0000000042057eb8) by thread "main"
...
[0.125s][info][class,init] 174 Initializing 'jdk/internal/reflect/Reflection' (0x0000000042066f50) by thread "main"

I don't have System$2 just System$1.

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

PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2631411677

From coleenp at openjdk.org  Mon Feb  3 16:11:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 16:11:06 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]
In-Reply-To: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
Message-ID: <syxVRD9ASKql288dZ8hdYJjliScymiDGldc7fSoEAiU=.d4084758-4fb0-496f-a7bb-ad0093129f11@github.com>

> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.

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

  Fix test that knows which fields are hidden from reflection in jvmci.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23396/files
  - new: https://git.openjdk.org/jdk/pull/23396/files/954c9a76..d04b808f

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

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

PR: https://git.openjdk.org/jdk/pull/23396

From liach at openjdk.org  Mon Feb  3 16:11:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Feb 2025 16:11:07 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v3]
In-Reply-To: <f5eXDXA1waU4JEF8Obcewzm0EzEDcpX7jPdgxc3nrro=.c6d73e92-2b13-4811-a5ef-081981b249fa@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <f5eXDXA1waU4JEF8Obcewzm0EzEDcpX7jPdgxc3nrro=.c6d73e92-2b13-4811-a5ef-081981b249fa@github.com>
Message-ID: <c8XFyrfS3LPGaUORPFce2vodmVuXqtKq3f5z4Z2dhOk=.fcc0debe-8973-455d-8577-0af4f977885a@github.com>

On Mon, 3 Feb 2025 14:31:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Hide Class.protectionDomain for reflection and add a test case.
>  - Merge branch 'master' into protection-domain
>  - Fix two tests.
>  - Fix the test.
>  - 8349145: Make Class.getProtectionDomain() non-native

The subsequent changes look good.

Something might have changed in the recent bootstrap sequence, but yes it's great to see that Reflection now loads after JLA and can actually use String hash codes.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23396#pullrequestreview-2590379807
PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2631425455

From jpai at openjdk.org  Mon Feb  3 16:37:09 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Feb 2025 16:37:09 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
Message-ID: <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>

> Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?
> 
> The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated. Furthermore, one part of that original change introduced a few internal methods. These internal methods were then used in few other places within the JDK through https://bugs.openjdk.org/browse/JDK-8343650. As a result, this backout PR also reverts the change that was done in JDK-8343650.
> 
> The backout was done as follows, using `git revert` against the 2 relevant commits:
> 
> 
> git revert 74ae3c688b37e693e20eb4e17c631897c5464400
> git revert 5890d9438bbde88b89070052926a2eafe13d7b42
> 
> The revert of `5890d9438bbde88b89070052926a2eafe13d7b42` wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.
> 
> tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.

Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:

 - Revert "8333893: Optimization for StringBuilder append boolean & null"
   
   This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42.
 - Revert "8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt"
   
   This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23420/files
  - new: https://git.openjdk.org/jdk/pull/23420/files/d406bc1d..23d01f0a

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

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

PR: https://git.openjdk.org/jdk/pull/23420

From vpaprotski at openjdk.org  Mon Feb  3 16:44:10 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 3 Feb 2025 16:44:10 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v4]
In-Reply-To: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
Message-ID: <9DMCff2xI947yLBGtcDldqt-r16p11nCIJoZtxJjHvo=.ffe41f5e-2613-4006-8e48-b25fef3a2c02@github.com>

> (Also see `8319429: Resetting MXCSR flags degrades ecore`) 
> 
> For performance, signaling flags (bottom 6 bits) are set by default in MXCSR. This PR fixes the Xcheck:jni comparison that is producing these copious warnings:
> 
> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
> 
> 
> **This in fact happens on both Windows _AND_ Linux.** However, _only_ on Windows there is a crash. This PR fixes the crash but I have not been able to track down the source of the crash (i.e. crash in the warn handler).

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

  fix crash in fxrstor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22673/files
  - new: https://git.openjdk.org/jdk/pull/22673/files/2b15f99a..b1a712bf

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

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

PR: https://git.openjdk.org/jdk/pull/22673

From swen at openjdk.org  Mon Feb  3 17:06:47 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 17:06:47 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
Message-ID: <kKgnTqO7Zcifnc1TqDzej5WlJKvnY54-jHQgjLZXjZU=.22a7ff73-9682-4e8a-83f3-5bbc60a2b48c@github.com>

On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>> 
>> The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated. Furthermore, one part of that original change introduced a few internal methods. These internal methods were then used in few other places within the JDK through https://bugs.openjdk.org/browse/JDK-8343650. As a result, this backout PR also reverts the change that was done in JDK-8343650.
>> 
>> The backout was done as follows, using `git revert` against the 2 relevant commits:
>> 
>> 
>> git revert 74ae3c688b37e693e20eb4e17c631897c5464400
>> git revert 5890d9438bbde88b89070052926a2eafe13d7b42
>> 
>> The revert of `5890d9438bbde88b89070052926a2eafe13d7b42` wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.
>> 
>> tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.
>
> Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Revert "8333893: Optimization for StringBuilder append boolean & null"
>    
>    This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42.
>  - Revert "8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt"
>    
>    This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400.

This concurrency problem also exists in the UTF16 scenario, so why only change to Latin1 here?

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

PR Comment: https://git.openjdk.org/jdk/pull/23420#issuecomment-2631574736

From never at openjdk.org  Mon Feb  3 17:07:53 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 3 Feb 2025 17:07:53 GMT
Subject: RFR: 8342775: [Graal]
 java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME  thrown from the
 UncaughtExceptionHandler [v3]
In-Reply-To: <VMIZUY6IHPwpq6mdYzK68tVWo1vZtcrfOEEBnQIfd5Q=.6d097417-42cd-4012-aaa1-53ad1938245c@github.com>
References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com>
 <VMIZUY6IHPwpq6mdYzK68tVWo1vZtcrfOEEBnQIfd5Q=.6d097417-42cd-4012-aaa1-53ad1938245c@github.com>
Message-ID: <Xtz10QktEb1Z4KYoAdAe0dHDowyDpthDAWDlNMMyHec=.cf0d0e02-efb3-413d-8e40-614b1dd30e70@github.com>

On Fri, 31 Jan 2025 22:18:32 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309.  In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure.  Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt.
>
> Tom Rodriguez has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Disable test for Graal with Xcomp
>  - Merge branch 'master' into tkr-oomeinaqs-ea
>  - adjust OOMEInStampedLock.java too
>  - Merge branch 'master' into tkr-oomeinaqs-ea
>  - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21745#issuecomment-2631573334

From never at openjdk.org  Mon Feb  3 17:07:53 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 3 Feb 2025 17:07:53 GMT
Subject: Integrated: 8342775: [Graal]
 java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME  thrown from the
 UncaughtExceptionHandler
In-Reply-To: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com>
References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com>
Message-ID: <UHCacU0pRUGwZvUCfwjow4IfJLtNooY-lHKfcDKrhEU=.527af85d-6fce-4139-a249-b118c6636e0d@github.com>

On Mon, 28 Oct 2024 18:45:59 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309.  In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure.  Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt.

This pull request has now been integrated.

Changeset: bb837d2f
Author:    Tom Rodriguez <never at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb837d2f9b636c05ff0c7733bc3d06c002974c17
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME  thrown from the UncaughtExceptionHandler

Reviewed-by: jpai, dholmes

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

PR: https://git.openjdk.org/jdk/pull/21745

From jpai at openjdk.org  Mon Feb  3 17:12:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Feb 2025 17:12:50 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <kKgnTqO7Zcifnc1TqDzej5WlJKvnY54-jHQgjLZXjZU=.22a7ff73-9682-4e8a-83f3-5bbc60a2b48c@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
 <kKgnTqO7Zcifnc1TqDzej5WlJKvnY54-jHQgjLZXjZU=.22a7ff73-9682-4e8a-83f3-5bbc60a2b48c@github.com>
Message-ID: <LIeJPlVTJGi66cljihHZCy8tBFGNd8qYJsQ2ZF_i8bs=.5f4773ee-8b16-41a5-8c51-2f0f3e2e4d50@github.com>

On Mon, 3 Feb 2025 17:04:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This concurrency problem also exists in the UTF16 scenario, so why only change to Latin1 here?

Do you mean there are additional commits that have been done in the JDK which introduce a similar issue related to array writes beyond their limit that need to be backed out?

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

PR Comment: https://git.openjdk.org/jdk/pull/23420#issuecomment-2631588160

From redestad at openjdk.org  Mon Feb  3 17:39:48 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 3 Feb 2025 17:39:48 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
Message-ID: <GY3E4RrVYZJa67-6xYszcfhY9LdMhs7Mx9DwtYIaq7k=.25165fd4-5d78-4ed6-a02b-c2e84d8f0246@github.com>

On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>> 
>> The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated. Furthermore, one part of that original change introduced a few internal methods. These internal methods were then used in few other places within the JDK through https://bugs.openjdk.org/browse/JDK-8343650. As a result, this backout PR also reverts the change that was done in JDK-8343650.
>> 
>> The backout was done as follows, using `git revert` against the 2 relevant commits:
>> 
>> 
>> git revert 74ae3c688b37e693e20eb4e17c631897c5464400
>> git revert 5890d9438bbde88b89070052926a2eafe13d7b42
>> 
>> The revert of `5890d9438bbde88b89070052926a2eafe13d7b42` wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.
>> 
>> tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.
>
> Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Revert "8333893: Optimization for StringBuilder append boolean & null"
>    
>    This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42.
>  - Revert "8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt"
>    
>    This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400.

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23420#pullrequestreview-2590593462

From liach at openjdk.org  Mon Feb  3 17:39:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Feb 2025 17:39:49 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
Message-ID: <GRFH0_g1T36Bqw9m_didSeYG5e4CMgErxwaGpbrtqBk=.b08883e4-fe36-41b7-93ea-8233474df3b2@github.com>

On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>> 
>> The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated. Furthermore, one part of that original change introduced a few internal methods. These internal methods were then used in few other places within the JDK through https://bugs.openjdk.org/browse/JDK-8343650. As a result, this backout PR also reverts the change that was done in JDK-8343650.
>> 
>> The backout was done as follows, using `git revert` against the 2 relevant commits:
>> 
>> 
>> git revert 74ae3c688b37e693e20eb4e17c631897c5464400
>> git revert 5890d9438bbde88b89070052926a2eafe13d7b42
>> 
>> The revert of `5890d9438bbde88b89070052926a2eafe13d7b42` wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.
>> 
>> tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.
>
> Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Revert "8333893: Optimization for StringBuilder append boolean & null"
>    
>    This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42.
>  - Revert "8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt"
>    
>    This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400.

Also for append(char): it uses putCharSB which does a check and calls unchecked putChar. putCharsAt is always checked.

src/java.base/share/classes/java/lang/StringUTF16.java line 1538:

> 1536:     public static int putCharsAt(byte[] value, int i, char c1, char c2, char c3, char c4) {
> 1537:         int end = i + 4;
> 1538:         checkBoundsBeginEnd(i, end, value);

We have this explicit check for null and true, false has another bound check. This backout version should be safe.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23420#pullrequestreview-2590596912
PR Review Comment: https://git.openjdk.org/jdk/pull/23420#discussion_r1939778610

From redestad at openjdk.org  Mon Feb  3 17:39:49 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 3 Feb 2025 17:39:49 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <kKgnTqO7Zcifnc1TqDzej5WlJKvnY54-jHQgjLZXjZU=.22a7ff73-9682-4e8a-83f3-5bbc60a2b48c@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
 <kKgnTqO7Zcifnc1TqDzej5WlJKvnY54-jHQgjLZXjZU=.22a7ff73-9682-4e8a-83f3-5bbc60a2b48c@github.com>
Message-ID: <fwPNaf6mI-zA1Vs06wjnFzLjivTPY_HfZ40b_CCTy5k=.c1915b58-168c-4a4e-b7db-3346437fef94@github.com>

On Mon, 3 Feb 2025 17:04:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
>> 
>>  - Revert "8333893: Optimization for StringBuilder append boolean & null"
>>    
>>    This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42.
>>  - Revert "8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt"
>>    
>>    This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400.
>
> This concurrency problem also exists in the UTF16 scenario, so why only change to Latin1 here?

@wenshao this re-instates the `checkBoundsBeginEnd(i, end, value);` in the UTF16 case that was removed by the issue being backed out, so we get back to a state where we have appropriate bounds checks on all array accesses.

An alternative to this backout would be to add `checkBoundsBeginEnd(i, end, value);` to all the `putCharsAt` methods, though it's unclear if that would undo the performance advantage. Better then to backout and - if possible - redo with a closer examination of the performance with a safer construct.

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

PR Comment: https://git.openjdk.org/jdk/pull/23420#issuecomment-2631644364

From jpai at openjdk.org  Mon Feb  3 17:45:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Feb 2025 17:45:57 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
Message-ID: <6XAQw2AHZiOnS2lGtFhGOhqMn1ebX7zCer7DUeBQSXQ=.b990b7ad-3bae-4e0d-8b8a-842d081ab827@github.com>

On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>> 
>> The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated. Furthermore, one part of that original change introduced a few internal methods. These internal methods were then used in few other places within the JDK through https://bugs.openjdk.org/browse/JDK-8343650. As a result, this backout PR also reverts the change that was done in JDK-8343650.
>> 
>> The backout was done as follows, using `git revert` against the 2 relevant commits:
>> 
>> 
>> git revert 74ae3c688b37e693e20eb4e17c631897c5464400
>> git revert 5890d9438bbde88b89070052926a2eafe13d7b42
>> 
>> The revert of `5890d9438bbde88b89070052926a2eafe13d7b42` wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.
>> 
>> tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.
>
> Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Revert "8333893: Optimization for StringBuilder append boolean & null"
>    
>    This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42.
>  - Revert "8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt"
>    
>    This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400.

Thank you Claes and Chen for the reviews. tier1, tier2 and tier3 testing is nearing completion without any failures. Could one of you approve that it's OK to integrate this trivial backout without waiting for 24 hours (the review process allows it https://openjdk.org/guide/#trivial-changes)? I will be integrating this as soon as the tier testing completes.

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

PR Comment: https://git.openjdk.org/jdk/pull/23420#issuecomment-2631660611

From coleenp at openjdk.org  Mon Feb  3 17:49:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:19 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
Message-ID: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>

The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.

There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.

Tested with tier1-8.

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

Commit messages:
 - Removed @Stable.
 - Fix JFR bug.
 - 8345678: Make Class.getModifiers() non-native.

Changes: https://git.openjdk.org/jdk/pull/22652/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346567
  Stats: 218 lines in 34 files changed: 57 ins; 139 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/22652.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22652/head:pull/22652

PR: https://git.openjdk.org/jdk/pull/22652

From liach at openjdk.org  Mon Feb  3 17:49:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <1kHVpYCOExfkn8UHTZNZT6zwjRj3MCXJD2LVcY0NTrg=.0644323b-5f40-4441-8c19-763105aaf08d@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

The change to java.lang.Class looks good.

Looking at #23396, we might need to filter this field too.

src/hotspot/share/classfile/javaClasses.cpp line 1504:

> 1502:   macro(_reflectionData_offset,      k, "reflectionData",      java_lang_ref_SoftReference_signature, false); \
> 1503:   macro(_signers_offset,             k, "signers",             object_array_signature, false); \
> 1504:   macro(_modifiers_offset,           k, vmSymbols::modifiers_name(), int_signature,    false)

Do we need a trailing semicolon here?

src/java.base/share/classes/java/lang/Class.java line 1315:

> 1313: 
> 1314:     // Set by the JVM when creating the instance of this java.lang.Class
> 1315:     private transient int modifiers;

If this is set by the JVM, can this be marked `final` so JIT compiler can trust this field? Also preferable if we can move this together with components/signers/classData fields.

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

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2490110846
PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2631658029
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1876630297
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1876627105

From coleenp at openjdk.org  Mon Feb  3 17:49:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <o2U4UlgxQKxF1RdTU6HARYpBGMYDRk1B3ZHeLCP7ZiQ=.67875d38-2a85-4fd9-a181-e6d765ab629c@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

> Looking at https://github.com/openjdk/jdk/pull/23396, we might need to filter this field too.

Yes, I agree.  This patch is a follow on to that one, so I'll add it to the same places when that one is merged in here.

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2631661716

From coleenp at openjdk.org  Mon Feb  3 17:49:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <1kHVpYCOExfkn8UHTZNZT6zwjRj3MCXJD2LVcY0NTrg=.0644323b-5f40-4441-8c19-763105aaf08d@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <1kHVpYCOExfkn8UHTZNZT6zwjRj3MCXJD2LVcY0NTrg=.0644323b-5f40-4441-8c19-763105aaf08d@github.com>
Message-ID: <e8V5_QLgWMgWjewNHqzQ9lk-HNa3RylbwnSE01ZHWMA=.781eb5c8-9a25-4670-8ba4-bbfe8e4b262c@github.com>

On Mon, 9 Dec 2024 19:46:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> src/hotspot/share/classfile/javaClasses.cpp line 1504:
> 
>> 1502:   macro(_reflectionData_offset,      k, "reflectionData",      java_lang_ref_SoftReference_signature, false); \
>> 1503:   macro(_signers_offset,             k, "signers",             object_array_signature, false); \
>> 1504:   macro(_modifiers_offset,           k, vmSymbols::modifiers_name(), int_signature,    false)
> 
> Do we need a trailing semicolon here?

yes. it is needed.

> src/java.base/share/classes/java/lang/Class.java line 1315:
> 
>> 1313: 
>> 1314:     // Set by the JVM when creating the instance of this java.lang.Class
>> 1315:     private transient int modifiers;
> 
> If this is set by the JVM, can this be marked `final` so JIT compiler can trust this field? Also preferable if we can move this together with components/signers/classData fields.

The JVM rearranges these fields so that's why I put it near the caller.  Let me check if final compiles.

Edit: it looks better with the other fields though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1876712191
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1876713323

From duke at openjdk.org  Mon Feb  3 17:49:20 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <e8V5_QLgWMgWjewNHqzQ9lk-HNa3RylbwnSE01ZHWMA=.781eb5c8-9a25-4670-8ba4-bbfe8e4b262c@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <1kHVpYCOExfkn8UHTZNZT6zwjRj3MCXJD2LVcY0NTrg=.0644323b-5f40-4441-8c19-763105aaf08d@github.com>
 <e8V5_QLgWMgWjewNHqzQ9lk-HNa3RylbwnSE01ZHWMA=.781eb5c8-9a25-4670-8ba4-bbfe8e4b262c@github.com>
Message-ID: <fah136x1eL92esnncQ2l8JVUMhkwg25xpjmZhE-Rkbk=.ce4ed4dd-3f56-4ac7-83ec-ebed54ee74a7@github.com>

On Mon, 9 Dec 2024 20:27:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 1504:
>> 
>>> 1502:   macro(_reflectionData_offset,      k, "reflectionData",      java_lang_ref_SoftReference_signature, false); \
>>> 1503:   macro(_signers_offset,             k, "signers",             object_array_signature, false); \
>>> 1504:   macro(_modifiers_offset,           k, vmSymbols::modifiers_name(), int_signature,    false)
>> 
>> Do we need a trailing semicolon here?
>
> yes. it is needed.

This is?**C++**, so?yes.
Suggestion:

  macro(_modifiers_offset,           k, vmSymbols::modifiers_name(), int_signature,    false);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1876794006

From coleenp at openjdk.org  Mon Feb  3 17:49:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <fah136x1eL92esnncQ2l8JVUMhkwg25xpjmZhE-Rkbk=.ce4ed4dd-3f56-4ac7-83ec-ebed54ee74a7@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <1kHVpYCOExfkn8UHTZNZT6zwjRj3MCXJD2LVcY0NTrg=.0644323b-5f40-4441-8c19-763105aaf08d@github.com>
 <e8V5_QLgWMgWjewNHqzQ9lk-HNa3RylbwnSE01ZHWMA=.781eb5c8-9a25-4670-8ba4-bbfe8e4b262c@github.com>
 <fah136x1eL92esnncQ2l8JVUMhkwg25xpjmZhE-Rkbk=.ce4ed4dd-3f56-4ac7-83ec-ebed54ee74a7@github.com>
Message-ID: <44DPWzTGxPDoyWwZFbAxE74-KrXChIvfusVws1N-uN0=.f346731b-c61e-468f-9f58-4dc6e2df35d2@github.com>

On Mon, 9 Dec 2024 21:35:42 GMT, ExE Boss <duke at openjdk.org> wrote:

>> yes. it is needed.
>
> This is?**C++**, so?yes.
> Suggestion:
> 
>   macro(_modifiers_offset,           k, vmSymbols::modifiers_name(), int_signature,    false);

I see, there's a trailing semi somewhere in the expansion of this macro so it compiles, but I added one in.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1878263513

From heidinga at openjdk.org  Mon Feb  3 17:49:20 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <5bMxhTRPqj-dMhr3FoSrym2ttWuzjWwtXAEcQHbF9Vg=.859ae29f-2530-4130-b108-d47c100ac19f@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

src/java.base/share/classes/java/lang/Class.java line 244:

> 242:         classLoader = loader;
> 243:         componentType = arrayComponentType;
> 244:         modifiers = 0;

The comment above about assigning a parameter to the field to prevent the JIT from assuming an incorrect default also should apply to the new `modifiers` field.  I think the constructor, which is never called, should also pass in a `dummyModifiers` value rather than using 0 directly

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1880689835

From coleenp at openjdk.org  Mon Feb  3 17:49:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <5bMxhTRPqj-dMhr3FoSrym2ttWuzjWwtXAEcQHbF9Vg=.859ae29f-2530-4130-b108-d47c100ac19f@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <5bMxhTRPqj-dMhr3FoSrym2ttWuzjWwtXAEcQHbF9Vg=.859ae29f-2530-4130-b108-d47c100ac19f@github.com>
Message-ID: <FqVaeVj-Bz008BPwuDXr4GUgrQg2T3-glsXYm-yZy8E=.3c3f5d89-90fc-4c4b-9d03-0d66cfdfbde2@github.com>

On Wed, 11 Dec 2024 18:15:57 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> src/java.base/share/classes/java/lang/Class.java line 244:
> 
>> 242:         classLoader = loader;
>> 243:         componentType = arrayComponentType;
>> 244:         modifiers = 0;
> 
> The comment above about assigning a parameter to the field to prevent the JIT from assuming an incorrect default also should apply to the new `modifiers` field.  I think the constructor, which is never called, should also pass in a `dummyModifiers` value rather than using 0 directly

Yes, definitely, didn't see that this is the right way to do this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1887157349

From duke at openjdk.org  Mon Feb  3 17:49:21 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 3 Feb 2025 17:49:21 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <-GEiPPAhFzy-uaUwIACYA7fZVCT3wkuVd-gtf9rrlnw=.de130f97-59bd-4581-a568-05d6238cf90a@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

src/java.base/share/classes/java/lang/Class.java line 1005:

> 1003:     private transient Object[] signers; // Read by VM, mutable
> 1004: 
> 1005:     @Stable

The?`modifiers`?field doesn?t?need to?be?`@Stable`:
Suggestion:

test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 65:

> 63:      */
> 64:     @Benchmark
> 65:     public int getModifiers() throws NoSuchMethodException {

The?only `Throwable`s that?can be?thrown by?calling `Class::getModifiers()` are?`Error`s (e.g.:?`StackOverflowError`) and?`RuntimeException`s (e.g.:?`NullPointerException`):
Suggestion:

    public int getModifiers() {

test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 71:

> 69:     Clazz[] clazzArray = new Clazz[1];
> 70:     @Benchmark
> 71:     public int getAppArrayModifiers() throws NoSuchMethodException {

Suggestion:

    public int getAppArrayModifiers() {

test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 81:

> 79:      */
> 80:     @Benchmark
> 81:     public int getArrayModifiers() throws NoSuchMethodException {

Suggestion:

    public int getArrayModifiers() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1888757754
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1888760732
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1888760967
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1888761412

From coleenp at openjdk.org  Mon Feb  3 17:49:21 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:21 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <-GEiPPAhFzy-uaUwIACYA7fZVCT3wkuVd-gtf9rrlnw=.de130f97-59bd-4581-a568-05d6238cf90a@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <-GEiPPAhFzy-uaUwIACYA7fZVCT3wkuVd-gtf9rrlnw=.de130f97-59bd-4581-a568-05d6238cf90a@github.com>
Message-ID: <f7t75uKmpCaoI-b5hUxSL2-6XRUyO7oXu4uXuqYQOgA=.f7fecd55-39f7-4b74-8aa1-723c58385121@github.com>

On Tue, 17 Dec 2024 15:54:48 GMT, ExE Boss <duke at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> src/java.base/share/classes/java/lang/Class.java line 1005:
> 
>> 1003:     private transient Object[] signers; // Read by VM, mutable
>> 1004: 
>> 1005:     @Stable
> 
> The?`modifiers`?field doesn?t?need to?be?`@Stable`:
> Suggestion:

I now don't know whether we want @Stable here or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1890866329

From vklang at openjdk.org  Mon Feb  3 17:49:21 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 3 Feb 2025 17:49:21 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

src/java.base/share/classes/java/lang/Class.java line 1006:

> 1004:     private final transient int modifiers;  // Set by the VM
> 1005: 
> 1006:     // package-private

@coleenp Could this field be @Stable, or does that only apply to `putfield`s?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1879797327

From liach at openjdk.org  Mon Feb  3 17:49:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Feb 2025 17:49:21 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
Message-ID: <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>

On Wed, 11 Dec 2024 10:24:03 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> src/java.base/share/classes/java/lang/Class.java line 1006:
> 
>> 1004:     private final transient int modifiers;  // Set by the VM
>> 1005: 
>> 1006:     // package-private
> 
> @coleenp Could this field be @Stable, or does that only apply to `putfield`s?

I don't think this needs to be stable - finals in java.lang is trusted by the JIT compiler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1880350790

From vklang at openjdk.org  Mon Feb  3 17:49:24 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 3 Feb 2025 17:49:24 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
Message-ID: <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>

On Wed, 11 Dec 2024 14:52:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 1006:
>> 
>>> 1004:     private final transient int modifiers;  // Set by the VM
>>> 1005: 
>>> 1006:     // package-private
>> 
>> @coleenp Could this field be @Stable, or does that only apply to `putfield`s?
>
> I don't think this needs to be stable - finals in java.lang is trusted by the JIT compiler.

Yeah, I was just thinking whether something set from inside the VM which is marked @Stable is constant-folded :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1880374750

From coleenp at openjdk.org  Mon Feb  3 17:49:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:24 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
 <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
Message-ID: <f05_My76F3A49SVKFI7chP2uMOn3nochpfYWbTxCwAw=.3fb9cf96-b0c1-47c7-9769-90d5b55be072@github.com>

On Wed, 11 Dec 2024 15:06:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> I don't think this needs to be stable - finals in java.lang is trusted by the JIT compiler.
>
> Yeah, I was just thinking whether something set from inside the VM which is marked @Stable is constant-folded :)

I don't think @Stable would hurt but final should provide the same guarantee.  It's set internally by the VM so there's no late setting. I don't know if this field implementation can constant fold in the case of Arrays which are (JVM_ACC_ABSTRACT | JVM_ACC_FINAL | JVM_ACC_PUBLIC).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1880663099

From heidinga at openjdk.org  Mon Feb  3 17:49:25 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 3 Feb 2025 17:49:25 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
 <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
Message-ID: <yjBy9m5yM18_XOZjEN8dn5osnTUPviOliyM_qNHoKgQ=.f9c43bc8-4bee-46bb-b466-7d471bfcd582@github.com>

On Wed, 11 Dec 2024 15:06:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> I don't think this needs to be stable - finals in java.lang is trusted by the JIT compiler.
>
> Yeah, I was just thinking whether something set from inside the VM which is marked @Stable is constant-folded :)

@viktorklang-ora `@Stable` is not about how the field was set, but about the JIT observing a  non-default value at compile time.  If it observes a non-default value, it can treat it as a compile time constant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1880692608

From vklang at openjdk.org  Mon Feb  3 17:49:25 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 3 Feb 2025 17:49:25 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <yjBy9m5yM18_XOZjEN8dn5osnTUPviOliyM_qNHoKgQ=.f9c43bc8-4bee-46bb-b466-7d471bfcd582@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
 <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
 <yjBy9m5yM18_XOZjEN8dn5osnTUPviOliyM_qNHoKgQ=.f9c43bc8-4bee-46bb-b466-7d471bfcd582@github.com>
Message-ID: <8Wx3xbbOnPXS5n1RuNaesqHbhKV3iLwrCVF0s6uWOrA=.cb20728e-e13c-4667-822b-3ba424cbc12f@github.com>

On Wed, 11 Dec 2024 18:17:43 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Yeah, I was just thinking whether something set from inside the VM which is marked @Stable is constant-folded :)
>
> @viktorklang-ora `@Stable` is not about how the field was set, but about the JIT observing a  non-default value at compile time.  If it observes a non-default value, it can treat it as a compile time constant.

@DanHeidinga Great explanation, thank you!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1881782322

From swen at openjdk.org  Mon Feb  3 17:52:46 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 17:52:46 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
Message-ID: <fngeQKqgH_hui-7xCv1oGN03o3EBDn_TsMoA00s0fkw=.e87f644e-c8e7-4e2a-b93c-a76c122888ad@github.com>

On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>> 
>> The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated. Furthermore, one part of that original change introduced a few internal methods. These internal methods were then used in few other places within the JDK through https://bugs.openjdk.org/browse/JDK-8343650. As a result, this backout PR also reverts the change that was done in JDK-8343650.
>> 
>> The backout was done as follows, using `git revert` against the 2 relevant commits:
>> 
>> 
>> git revert 74ae3c688b37e693e20eb4e17c631897c5464400
>> git revert 5890d9438bbde88b89070052926a2eafe13d7b42
>> 
>> The revert of `5890d9438bbde88b89070052926a2eafe13d7b42` wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.
>> 
>> tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.
>
> Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Revert "8333893: Optimization for StringBuilder append boolean & null"
>    
>    This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42.
>  - Revert "8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt"
>    
>    This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400.

Can you wait for me for a while? I am looking for other solutions that do not require a fallback.

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

PR Comment: https://git.openjdk.org/jdk/pull/23420#issuecomment-2631675846

From jpai at openjdk.org  Mon Feb  3 18:00:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Feb 2025 18:00:48 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <fngeQKqgH_hui-7xCv1oGN03o3EBDn_TsMoA00s0fkw=.e87f644e-c8e7-4e2a-b93c-a76c122888ad@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
 <fngeQKqgH_hui-7xCv1oGN03o3EBDn_TsMoA00s0fkw=.e87f644e-c8e7-4e2a-b93c-a76c122888ad@github.com>
Message-ID: <91DwI-6uK7tLyI1MCemdvDbDgaakD763G8X4V8OwgR4=.466cec61-85f5-4776-979f-ae0b43d23bce@github.com>

On Mon, 3 Feb 2025 17:50:23 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Can you wait for me for a while? I am looking for other solutions that do not require a fallback.

The updated fix/change (if any) doesn't have to be rushed and you can take longer to work on it with additional help and reviews from others. 

Once this backout is integrated into mainline, it will be backported to jdk24 (which is to be released in a few days). The risk of waiting for an additional/different fix is higher compared to a backout. So we intend to go ahead with the backout.

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

PR Comment: https://git.openjdk.org/jdk/pull/23420#issuecomment-2631690902

From swen at openjdk.org  Mon Feb  3 18:05:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 18:05:48 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
Message-ID: <SDulaqQnZuGB4DHfKKR5FYrsCTBosUbuM1J3PaYotP8=.ed080442-71a3-45dc-a4cb-420b30c0e8e5@github.com>

On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>> 
>> The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated. Furthermore, one part of that original change introduced a few internal methods. These internal methods were then used in few other places within the JDK through https://bugs.openjdk.org/browse/JDK-8343650. As a result, this backout PR also reverts the change that was done in JDK-8343650.
>> 
>> The backout was done as follows, using `git revert` against the 2 relevant commits:
>> 
>> 
>> git revert 74ae3c688b37e693e20eb4e17c631897c5464400
>> git revert 5890d9438bbde88b89070052926a2eafe13d7b42
>> 
>> The revert of `5890d9438bbde88b89070052926a2eafe13d7b42` wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.
>> 
>> tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.
>
> Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Revert "8333893: Optimization for StringBuilder append boolean & null"
>    
>    This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42.
>  - Revert "8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt"
>    
>    This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400.

https://github.com/openjdk/jdk/pull/23423
I submitted another PR where I reproduced the issue locally and this PR fixed the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/23420#issuecomment-2631702737

From naoto at openjdk.org  Mon Feb  3 18:08:46 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Feb 2025 18:08:46 GMT
Subject: RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v2]
In-Reply-To: <WsZgDc0x-v--FYgQyThleuAUZRha5hookrYV_Rra2oE=.33748369-aa18-4b1c-84cb-5297d120d19f@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
 <44mZCe1gb7oIVFrfWrX0QB01AC8MPanddHyguOkwF7U=.92b8bb69-94c8-4f87-8ee8-9f12f5f9d47a@github.com>
 <WsZgDc0x-v--FYgQyThleuAUZRha5hookrYV_Rra2oE=.33748369-aa18-4b1c-84cb-5297d120d19f@github.com>
Message-ID: <4wL9fyeYjujr4JKGG94IX60aqzgktbWiiORwiQxnIiQ=.6e16edb5-5566-425f-b0ca-4ffb2b232ac1@github.com>

On Mon, 3 Feb 2025 12:47:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   generalize format comment
>
> src/java.base/share/classes/java/util/Currency.java line 1182:
> 
>> 1180:         private static boolean isPastCutoverDate(String cutOver) {
>> 1181:             return System.currentTimeMillis() >
>> 1182:                     LocalDateTime.parse(cutOver.trim(), DateTimeFormatter.ISO_LOCAL_DATE_TIME)
> 
> Btw, do we really need this `trim()` call?
> It looks redundant. prop.date is result part of `m.group(4)` of this regexp:
> https://github.com/openjdk/jdk/blob/3f1d9b573546685215af06031656efe6f1429caf/src/java.base/share/classes/java/util/Currency.java#L255-L257
> `(\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2})`
> 
> I don't see how it could contain whitespace characters on start or end.

That seems to be correct to me

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23374#discussion_r1939814234

From duke at openjdk.org  Mon Feb  3 18:09:51 2025
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Mon, 3 Feb 2025 18:09:51 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
Message-ID: <4I1GV0W5jzwRthub-EQO7Cg329lQuJArIDqfVFnPRbc=.d7c5c80f-f179-42a2-ad3e-422fbdc37e8c@github.com>

On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>> 
>> The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated. Furthermore, one part of that original change introduced a few internal methods. These internal methods were then used in few other places within the JDK through https://bugs.openjdk.org/browse/JDK-8343650. As a result, this backout PR also reverts the change that was done in JDK-8343650.
>> 
>> The backout was done as follows, using `git revert` against the 2 relevant commits:
>> 
>> 
>> git revert 74ae3c688b37e693e20eb4e17c631897c5464400
>> git revert 5890d9438bbde88b89070052926a2eafe13d7b42
>> 
>> The revert of `5890d9438bbde88b89070052926a2eafe13d7b42` wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.
>> 
>> tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.
>
> Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Revert "8333893: Optimization for StringBuilder append boolean & null"
>    
>    This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42.
>  - Revert "8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt"
>    
>    This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/23420#pullrequestreview-2590656730

From jwilhelm at openjdk.org  Mon Feb  3 18:14:52 2025
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 3 Feb 2025 18:14:52 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <6XAQw2AHZiOnS2lGtFhGOhqMn1ebX7zCer7DUeBQSXQ=.b990b7ad-3bae-4e0d-8b8a-842d081ab827@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
 <6XAQw2AHZiOnS2lGtFhGOhqMn1ebX7zCer7DUeBQSXQ=.b990b7ad-3bae-4e0d-8b8a-842d081ab827@github.com>
Message-ID: <szUx96nc5a_NaqRf3_doBCkOuDiyrzb4vbhxHzEPGzQ=.20ad60ed-0245-4ec3-9fa0-9ae87a9b35a4@github.com>

On Mon, 3 Feb 2025 17:43:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Thank you Claes and Chen for the reviews. tier1, tier2 and tier3 testing is nearing completion without any failures. Could one of you approve that it's OK to integrate this trivial backout without waiting for 24 hours (the review process allows it https://openjdk.org/guide/#trivial-changes)? I will be integrating this as soon as the tier testing completes.

A backout is always considered a trivial change. See https://openjdk.org/guide/#backing-out-a-change

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

PR Comment: https://git.openjdk.org/jdk/pull/23420#issuecomment-2631720915

From jbhateja at openjdk.org  Mon Feb  3 18:14:56 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 3 Feb 2025 18:14:56 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v16]
In-Reply-To: <EC2coajO2bsqpsjUFgjuf-YXj23ENZeLj2ABtq4Sd74=.1e290b04-fcfc-4aaa-b80d-60cdbb0a529a@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <EC2coajO2bsqpsjUFgjuf-YXj23ENZeLj2ABtq4Sd74=.1e290b04-fcfc-4aaa-b80d-60cdbb0a529a@github.com>
Message-ID: <uwc5HqlrWh6v8Nmgng_Ar1monFTvmFnqOl7pA57b_gY=.95301efd-6e3d-486e-831f-694761ffcfdb@github.com>

On Thu, 30 Jan 2025 11:03:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java
>   
>   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>

Hi @PaulSandoz , @eme64 , All outstanding comments haven been addressed, please let me know if there are other comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2631719276

From swen at openjdk.org  Mon Feb  3 18:24:50 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 18:24:50 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
Message-ID: <gVW9NEr2VmN4zdOJY0v5cqaLDx_L1H0fpEC80Djh8D8=.74d70c02-0c20-4414-9753-13246462ff7c@github.com>

On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>> 
>> The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated. Furthermore, one part of that original change introduced a few internal methods. These internal methods were then used in few other places within the JDK through https://bugs.openjdk.org/browse/JDK-8343650. As a result, this backout PR also reverts the change that was done in JDK-8343650.
>> 
>> The backout was done as follows, using `git revert` against the 2 relevant commits:
>> 
>> 
>> git revert 74ae3c688b37e693e20eb4e17c631897c5464400
>> git revert 5890d9438bbde88b89070052926a2eafe13d7b42
>> 
>> The revert of `5890d9438bbde88b89070052926a2eafe13d7b42` wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.
>> 
>> tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.
>
> Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Revert "8333893: Optimization for StringBuilder append boolean & null"
>    
>    This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42.
>  - Revert "8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt"
>    
>    This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400.

Don't rush to roll back, the current rollback solution still has problems

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

PR Comment: https://git.openjdk.org/jdk/pull/23420#issuecomment-2631734673

From jpai at openjdk.org  Mon Feb  3 18:24:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Feb 2025 18:24:51 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
Message-ID: <XoMt9keLCn1r2CZ_mC1hReHRYRqLEJIPc2zhaQN153o=.0b93d224-ff7f-4eda-9973-784beaf5676e@github.com>

On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>> 
>> The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated. Furthermore, one part of that original change introduced a few internal methods. These internal methods were then used in few other places within the JDK through https://bugs.openjdk.org/browse/JDK-8343650. As a result, this backout PR also reverts the change that was done in JDK-8343650.
>> 
>> The backout was done as follows, using `git revert` against the 2 relevant commits:
>> 
>> 
>> git revert 74ae3c688b37e693e20eb4e17c631897c5464400
>> git revert 5890d9438bbde88b89070052926a2eafe13d7b42
>> 
>> The revert of `5890d9438bbde88b89070052926a2eafe13d7b42` wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.
>> 
>> tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.
>
> Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Revert "8333893: Optimization for StringBuilder append boolean & null"
>    
>    This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42.
>  - Revert "8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt"
>    
>    This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400.

Thank you all for the help on this one.

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

PR Comment: https://git.openjdk.org/jdk/pull/23420#issuecomment-2631740096

From jpai at openjdk.org  Mon Feb  3 18:24:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Feb 2025 18:24:52 GMT
Subject: Integrated: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null
In-Reply-To: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
Message-ID: <GrZdsSTfi6V313PudxNQ3IYDZvlvj__hSgaZerssb2Q=.ff562775-a14f-4a24-8ee8-ac3cd0931908@github.com>

On Mon, 3 Feb 2025 15:48:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?
> 
> The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated. Furthermore, one part of that original change introduced a few internal methods. These internal methods were then used in few other places within the JDK through https://bugs.openjdk.org/browse/JDK-8343650. As a result, this backout PR also reverts the change that was done in JDK-8343650.
> 
> The backout was done as follows, using `git revert` against the 2 relevant commits:
> 
> 
> git revert 74ae3c688b37e693e20eb4e17c631897c5464400
> git revert 5890d9438bbde88b89070052926a2eafe13d7b42
> 
> The revert of `5890d9438bbde88b89070052926a2eafe13d7b42` wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.
> 
> tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.

This pull request has now been integrated.

Changeset: 618c5eb2
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/618c5eb27b4c719afd577b690e6bcb21a45fcb0d
Stats:     169 lines in 6 files changed: 46 ins; 79 del; 44 mod

8349183: [BACKOUT] Optimization for StringBuilder append boolean & null
8349239: [BACKOUT] Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt

Reviewed-by: redestad, liach

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

PR: https://git.openjdk.org/jdk/pull/23420

From pminborg at openjdk.org  Mon Feb  3 18:34:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 3 Feb 2025 18:34:58 GMT
Subject: RFR: 8349238: Some more FFM benchmarks are broken
Message-ID: <-JJ06J2vBX5lLVm15KjCQX8xjulNHrfRkpN0Cp8pOZg=.ad278382-1d2e-4126-9584-282204b96c3a@github.com>

This PR proposes to fix an Unsafe issue in a benchmark.

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

Commit messages:
 - Add usage of Unsafe

Changes: https://git.openjdk.org/jdk/pull/23424/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23424&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349238
  Stats: 26 lines in 1 file changed: 25 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23424.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23424/head:pull/23424

PR: https://git.openjdk.org/jdk/pull/23424

From jpai at openjdk.org  Mon Feb  3 18:47:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Feb 2025 18:47:27 GMT
Subject: [jdk24] RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null
Message-ID: <uytjFeusf-_7CVTw67jW9wPi3m8gV2B1e35y_AhYqCo=.9418d4aa-69aa-48f5-af02-f46d339aefdf@github.com>

Can I please get a review of this backport of https://github.com/openjdk/jdk/pull/23420 into jdk24?

This proposes to bring in those same backouts into `jdk24` to prevent the issue noted in that PR description. jdk24 is in rampdown and this backport will require an approval. A approval request has been raised in https://bugs.openjdk.org/browse/JDK-8349183?focusedId=14746841&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14746841.

This backport into jdk24 wasn't clean due to a trivial merge conflict in `StringLatin1.java` file. That merge conflict was manually resolved (just like it was done against mainline). The git commands used to create this backport against jdk24 branch are:


<checkout fresh jdk24 branch>
git cherry-pick --no-commit 618c5eb27b4c719afd577b690e6bcb21a45fcb0d
<resolve merge conflict in StringLatin1.java>
git commit -m 'Backport 618c5eb27b4c719afd577b690e6bcb21a45fcb0d'


tier1, tier2 and tier3 testing is currently in progress with this change.

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

Commit messages:
 - Backport 618c5eb27b4c719afd577b690e6bcb21a45fcb0d

Changes: https://git.openjdk.org/jdk/pull/23425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23425&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349183
  Stats: 169 lines in 6 files changed: 46 ins; 79 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/23425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23425/head:pull/23425

PR: https://git.openjdk.org/jdk/pull/23425

From kvn at openjdk.org  Mon Feb  3 18:58:47 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 3 Feb 2025 18:58:47 GMT
Subject: [jdk24] RFR: 8349183: [BACKOUT] Optimization for StringBuilder
 append boolean & null
In-Reply-To: <uytjFeusf-_7CVTw67jW9wPi3m8gV2B1e35y_AhYqCo=.9418d4aa-69aa-48f5-af02-f46d339aefdf@github.com>
References: <uytjFeusf-_7CVTw67jW9wPi3m8gV2B1e35y_AhYqCo=.9418d4aa-69aa-48f5-af02-f46d339aefdf@github.com>
Message-ID: <fGnwl8cUZ8m_wZRnajMBoakV7BQBjwQd4ovCAOPjpZs=.11a9f418-9d3d-4c4f-8492-c65c1e6be0c3@github.com>

On Mon, 3 Feb 2025 18:41:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this backport of https://github.com/openjdk/jdk/pull/23420 into jdk24?
> 
> This proposes to bring in those same backouts into `jdk24` to prevent the issue noted in that PR description. jdk24 is in rampdown and this backport will require an approval. A approval request has been raised in https://bugs.openjdk.org/browse/JDK-8349183?focusedId=14746841&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14746841.
> 
> This backport into jdk24 wasn't clean due to a trivial merge conflict in `StringLatin1.java` file. That merge conflict was manually resolved (just like it was done against mainline). The git commands used to create this backport against jdk24 branch are:
> 
> 
> <checkout fresh jdk24 branch>
> git cherry-pick --no-commit 618c5eb27b4c719afd577b690e6bcb21a45fcb0d
> <resolve merge conflict in StringLatin1.java>
> git commit -m 'Backport 618c5eb27b4c719afd577b690e6bcb21a45fcb0d'
> 
> 
> tier1, tier2 and tier3 testing is currently in progress with this change.

@jaikiran  You need to get approval for JDK 24 backport.

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

PR Comment: https://git.openjdk.org/jdk/pull/23425#issuecomment-2631808683

From jlu at openjdk.org  Mon Feb  3 19:01:50 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 3 Feb 2025 19:01:50 GMT
Subject: RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v3]
In-Reply-To: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
Message-ID: <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>

> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`.
> 
> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise.

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

  reflect review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23374/files
  - new: https://git.openjdk.org/jdk/pull/23374/files/a71a31bc..f8073ae5

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

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

PR: https://git.openjdk.org/jdk/pull/23374

From aturbanov at openjdk.org  Mon Feb  3 19:01:50 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 3 Feb 2025 19:01:50 GMT
Subject: RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v3]
In-Reply-To: <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
 <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>
Message-ID: <La73ytGY_0uvDrgJVfTNme8udzGEZvNDCPKK3hrfWXE=.4d928189-4d21-4469-a726-ed0aa1d1b5e1@github.com>

On Mon, 3 Feb 2025 18:58:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`.
>> 
>> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

Marked as reviewed by aturbanov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/23374#pullrequestreview-2590758515

From jlu at openjdk.org  Mon Feb  3 19:01:51 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 3 Feb 2025 19:01:51 GMT
Subject: RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v2]
In-Reply-To: <4wL9fyeYjujr4JKGG94IX60aqzgktbWiiORwiQxnIiQ=.6e16edb5-5566-425f-b0ca-4ffb2b232ac1@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
 <44mZCe1gb7oIVFrfWrX0QB01AC8MPanddHyguOkwF7U=.92b8bb69-94c8-4f87-8ee8-9f12f5f9d47a@github.com>
 <WsZgDc0x-v--FYgQyThleuAUZRha5hookrYV_Rra2oE=.33748369-aa18-4b1c-84cb-5297d120d19f@github.com>
 <4wL9fyeYjujr4JKGG94IX60aqzgktbWiiORwiQxnIiQ=.6e16edb5-5566-425f-b0ca-4ffb2b232ac1@github.com>
Message-ID: <LWQFDuEWRbB5mXQc0p1pRlwLil93Oy1hrQqHpjBQcs4=.a9d90fb8-6270-48e6-bc43-e5305b3e8a94@github.com>

On Mon, 3 Feb 2025 18:05:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Currency.java line 1182:
>> 
>>> 1180:         private static boolean isPastCutoverDate(String cutOver) {
>>> 1181:             return System.currentTimeMillis() >
>>> 1182:                     LocalDateTime.parse(cutOver.trim(), DateTimeFormatter.ISO_LOCAL_DATE_TIME)
>> 
>> Btw, do we really need this `trim()` call?
>> It looks redundant. prop.date is result part of `m.group(4)` of this regexp:
>> https://github.com/openjdk/jdk/blob/3f1d9b573546685215af06031656efe6f1429caf/src/java.base/share/classes/java/util/Currency.java#L255-L257
>> `(\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2})`
>> 
>> I don't see how it could contain whitespace characters on start or end.
>
> That seems to be correct to me

Right, that previous `trim()` is unnecessary. Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23374#discussion_r1939875572

From swen at openjdk.org  Mon Feb  3 19:02:56 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 19:02:56 GMT
Subject: RFR: 8349183: [BACKOUT] Optimization for StringBuilder append
 boolean & null [v2]
In-Reply-To: <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
References: <Ui3mFVOAuPs2arcB_1cyXMs7cbfONb3Puw_oy4YyIkU=.e7edcaf5-fe17-4fd3-9410-b72ac2208c96@github.com>
 <mreMk2BS4Dn8a5htCDW_fKxSkrRwj7TgbFIBfgLpzgs=.3054caa1-6e08-4d2e-b374-e647a67f7962@github.com>
Message-ID: <Xaz2vXqRL2HO6v3BKzNBWdNfKH2jxo5VKse-TwbDpVM=.4a95d8d6-c3b7-4eb7-b06b-e3fbc151521b@github.com>

On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which backs out the commit that was introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>> 
>> The comment in the PR review of that issue https://github.com/openjdk/jdk/pull/19626#issuecomment-2628937397 explains what the issue is with the change that was integrated. Furthermore, one part of that original change introduced a few internal methods. These internal methods were then used in few other places within the JDK through https://bugs.openjdk.org/browse/JDK-8343650. As a result, this backout PR also reverts the change that was done in JDK-8343650.
>> 
>> The backout was done as follows, using `git revert` against the 2 relevant commits:
>> 
>> 
>> git revert 74ae3c688b37e693e20eb4e17c631897c5464400
>> git revert 5890d9438bbde88b89070052926a2eafe13d7b42
>> 
>> The revert of `5890d9438bbde88b89070052926a2eafe13d7b42` wasn't clean and I had to resolve a trivial conflict in `StringLatin1.java`.
>> 
>> tier1, tier2 and tier3 testing is currently in progress with this change. Once this is integrated into mainline, a corresponding backport will be done to `jdk24` branch with the requisite approvals.
>
> Jaikiran Pai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Revert "8333893: Optimization for StringBuilder append boolean & null"
>    
>    This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42.
>  - Revert "8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt"
>    
>    This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400.

The problem still exists, we need to complete another PR https://github.com/openjdk/jdk/pull/23427

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

PR Comment: https://git.openjdk.org/jdk/pull/23420#issuecomment-2631816765

From vyazici at openjdk.org  Mon Feb  3 19:10:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Feb 2025 19:10:34 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v3]
In-Reply-To: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
Message-ID: <WwJu_BWCh58tk_TexvfggGja3GQ4K7MyD2qiJAM-i0I=.4db2460d-1b83-400f-8c70-f0f18a5549ad@github.com>

> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
> 
> 
> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
> 
> 
> **Other highlights:**
> 
> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
> - `test.lib.Asserts::assertFileContentsEqual` is added

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

 - Replace forgotten `assertFileContentsEqual()` calls
 - Merge remote-tracking branch 'upstream/master' into LargeFile
 - Remove `assertFileContentsEqual()`
 - Move file content assertion to `test/lib/Asserts`
 - Move HTTP-specific temp. file methods to `test.lib.Utils`
 - Replace the `docs/test1` folder with dynamically created files
 - Employ `TestUtil::assertFilesEqual` in `sun.net.httpserver` tests
 - Improve `TestUtil::getAFile`
 - Improve `TestUtil::compareFiles`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23401/files
  - new: https://git.openjdk.org/jdk/pull/23401/files/421d19d4..a7c44540

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

  Stats: 8138 lines in 188 files changed: 1548 ins; 4470 del; 2120 mod
  Patch: https://git.openjdk.org/jdk/pull/23401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23401/head:pull/23401

PR: https://git.openjdk.org/jdk/pull/23401

From jpai at openjdk.org  Mon Feb  3 19:10:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Feb 2025 19:10:51 GMT
Subject: [jdk24] RFR: 8349183: [BACKOUT] Optimization for StringBuilder
 append boolean & null
In-Reply-To: <fGnwl8cUZ8m_wZRnajMBoakV7BQBjwQd4ovCAOPjpZs=.11a9f418-9d3d-4c4f-8492-c65c1e6be0c3@github.com>
References: <uytjFeusf-_7CVTw67jW9wPi3m8gV2B1e35y_AhYqCo=.9418d4aa-69aa-48f5-af02-f46d339aefdf@github.com>
 <fGnwl8cUZ8m_wZRnajMBoakV7BQBjwQd4ovCAOPjpZs=.11a9f418-9d3d-4c4f-8492-c65c1e6be0c3@github.com>
Message-ID: <deMzX7Wsh0cE-iG9-v81kL2uGDmwjHHSok6GTrwBd3M=.ec378f47-d1dc-41ee-896f-dd181a3d2e47@github.com>

On Mon, 3 Feb 2025 18:55:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> @jaikiran You need to get approval for JDK 24 backport.

Agreed. A approval request has already been raised https://bugs.openjdk.org/browse/JDK-8349183?focusedId=14746841&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14746841.

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

PR Comment: https://git.openjdk.org/jdk/pull/23425#issuecomment-2631838094

From naoto at openjdk.org  Mon Feb  3 19:10:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Feb 2025 19:10:48 GMT
Subject: RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v3]
In-Reply-To: <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
 <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>
Message-ID: <lE4zFHrxm1hr70SO7iTR4qhAm2x2ZmYGwWF5RdyDO60=.d5c1e672-f0c1-4c37-8b47-2fc3ceb5f042@github.com>

On Mon, 3 Feb 2025 19:01:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`.
>> 
>> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23374#pullrequestreview-2590777638

From bchristi at openjdk.org  Mon Feb  3 19:13:10 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 3 Feb 2025 19:13:10 GMT
Subject: RFR: 8349107: Remove RMI finalizers [v2]
In-Reply-To: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
References: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
Message-ID: <GBxj64AHg_40TFsAmS7nwWfICjXoTUt13CiAxK72e4Q=.bfbad393-1ca4-4746-9535-4f8e17fed265@github.com>

> 3 finalizers in RMI code can be removed, as they do not perform meaningful cleanup.
> 
> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**
> 
> `RegistryContext.finalize()` just calls `close()`. The `close()` method does not perform any cleanup per se, but rather "helps the garbage collector" by setting `environment` and `registry` to `null`.
> 
> 
> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.BindingEnumeration`**
> 
> `BindingEnumeration.finalize()` simply calls `close()` on the `ctx` field, itself a `RegistryContext` (and `close()` just "helps the GC.")
> 
> 
> **`src/java.rmi/share/classes/sun/rmi/log/LogInputStream`**
> 
> `LogInputStream` tracks its length with an int field, `length`. If `length` ever becomes == 0, `LogInputStream`'s methods will return without doing anything.
> 
> The finalizer calls `close()`, which just sets length = 0.
> 
> By the time a `LogInputStream` becomes unreachable and is finalized, it's a moot point whether length == 0, as no more methods can be called.
> If anything, this finalizer could cause a bug. If a `LogInputStream` were to became unreachable while a method were still running, the finalizer could set the length to 0 while method code is still running and expecting a length != 0.
> It's possible that there is a very long standing bug that `close()` should be calling `in.close()`, in which case this evaluation will need to be revisited.

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

 - Merge branch 'master' into rmF10Nnow
 - Remove finalizer from RMI LogInputStream
 - Remove finalizer from RMI RegistryContext.BindingEnumeration
 - Remove finalizer from RMI RegistryContext

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23406/files
  - new: https://git.openjdk.org/jdk/pull/23406/files/387aa517..b2257898

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

  Stats: 40438 lines in 2951 files changed: 18380 ins; 12171 del; 9887 mod
  Patch: https://git.openjdk.org/jdk/pull/23406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23406/head:pull/23406

PR: https://git.openjdk.org/jdk/pull/23406

From swen at openjdk.org  Mon Feb  3 19:19:05 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 19:19:05 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v2]
In-Reply-To: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
Message-ID: <mH-TYoP1Gje_6cwTNE7xB7Os4jBTyRAED4nX9QEa2Eg=.c1e7a548-7030-46d6-a6a4-61e446c25b5f@github.com>

> The following code can reproduce the problem, writing out of bounds causes JVM Crash
> 
> 
>    StringBuilder buf = new StringBuilder();
>     buf.append('?');
> 
>     final CountDownLatch latch = new CountDownLatch(10);
>     Runnable r = () -> {
>         for (int i = 0; i < 10000; i++) {
>             buf.setLength(0);
>             buf.trimToSize();
>             buf.append(123456789);
>         }
>         latch.countDown();
>     };
>     Thread[] threads = new Thread[10];
>     for (int i = 0; i < threads.length; i++) {
>         threads[i] = new Thread(r);
>     }
>     for (Thread t : threads) {
>         t.start();
>     }
>     latch.await();
> }
> 
> 
> This problem can be avoided by using the value of ensureCapacityInternal directly.

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

  fix append(int/long) crash

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23427/files
  - new: https://git.openjdk.org/jdk/pull/23427/files/ef62f48d..037973d5

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

  Stats: 21 lines in 1 file changed: 13 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23427.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23427/head:pull/23427

PR: https://git.openjdk.org/jdk/pull/23427

From vyazici at openjdk.org  Mon Feb  3 19:26:03 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Feb 2025 19:26:03 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v4]
In-Reply-To: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
Message-ID: <Wqz8Z4jFOpcSZLMelLBKVwiZdWX33-QWtp5jiGF-AF8=.911e5e47-075d-45a8-ab5d-17e17871552e@github.com>

> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
> 
> 
> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
> 
> 
> **Other highlights:**
> 
> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
> - `test.lib.Asserts::assertFileContentsEqual` is added

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Assert that multiple files can be served using the same `FileServerHandler`
 - Remove redundant `@build` dependencies

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23401/files
  - new: https://git.openjdk.org/jdk/pull/23401/files/a7c44540..4efc42f7

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

  Stats: 23 lines in 7 files changed: 10 ins; 7 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23401/head:pull/23401

PR: https://git.openjdk.org/jdk/pull/23401

From swen at openjdk.org  Mon Feb  3 19:38:02 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 19:38:02 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v3]
In-Reply-To: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
Message-ID: <p_91ELSNUi1Xibudx1sRlqmP9_wngSxhQRYO74t_TWg=.09348e9c-ac80-495e-ae43-6901af4587f7@github.com>

> The following code can reproduce the problem, writing out of bounds causes JVM Crash
> 
> 
>    StringBuilder buf = new StringBuilder();
>     buf.append('?');
> 
>     final CountDownLatch latch = new CountDownLatch(10);
>     Runnable r = () -> {
>         for (int i = 0; i < 10000; i++) {
>             buf.setLength(0);
>             buf.trimToSize();
>             buf.append(123456789);
>         }
>         latch.countDown();
>     };
>     Thread[] threads = new Thread[10];
>     for (int i = 0; i < threads.length; i++) {
>         threads[i] = new Thread(r);
>     }
>     for (Thread t : threads) {
>         t.start();
>     }
>     latch.await();
> }
> 
> 
> This problem can be avoided by using the value of ensureCapacityInternal directly.

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

  simplify

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23427/files
  - new: https://git.openjdk.org/jdk/pull/23427/files/037973d5..26c0cb4a

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

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

PR: https://git.openjdk.org/jdk/pull/23427

From ice1000kotlin at gmail.com  Mon Feb  3 20:16:57 2025
From: ice1000kotlin at gmail.com (Tesla Zhang)
Date: Mon, 3 Feb 2025 15:16:57 -0500
Subject: How do I create a `LocalVariableInfo`?
Message-ID: <CAM-iTuLRqedd1KswEcsuY_vWz69wOyNnXZ4Q0YDXjNy8+jm6Dw@mail.gmail.com>

I'm using classfile. It seems that the interface is sealed and either
implementations are not exported.

Best,
Tesla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250203/21b660d6/attachment-0001.htm>

From chen.l.liang at oracle.com  Mon Feb  3 20:21:16 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 3 Feb 2025 20:21:16 +0000
Subject: How do I create a `LocalVariableInfo`?
In-Reply-To: <CAM-iTuLRqedd1KswEcsuY_vWz69wOyNnXZ4Q0YDXjNy8+jm6Dw@mail.gmail.com>
References: <CAM-iTuLRqedd1KswEcsuY_vWz69wOyNnXZ4Q0YDXjNy8+jm6Dw@mail.gmail.com>
Message-ID: <SJ2PR10MB7669D37A2B0BBCAEA0A73D63A2F52@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Tesla,
In short, you can't. To write a local variable, the only way provided by the ClassFile API is to create a java.lang.classfile.instruction.LocalVariable, and send it to CodeBuilder::with, or just calling CodeBuilder::localVariable. The LocalVariableInfo interface exists to faithfully represent the contents of a LocalVariableTable attribute for class file parsing.

Regards,
Chen Liang
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Tesla Zhang <ice1000kotlin at gmail.com>
Sent: Monday, February 3, 2025 2:16 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: How do I create a `LocalVariableInfo`?

I'm using classfile. It seems that the interface is sealed and either implementations are not exported.

Best,
Tesla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250203/f67ec6d6/attachment.htm>

From vpaprotski at openjdk.org  Mon Feb  3 21:43:56 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 3 Feb 2025 21:43:56 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v5]
In-Reply-To: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
Message-ID: <iM9vtfQfDcasU0MRo3s7tqumBaSXt9Iupiaj_e_Haps=.b0642339-ecba-41f3-84be-7a71e65f2798@github.com>

> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
> 
> This PR fixes two issues:
> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
> 
> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
> 
> 
> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
> 
> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
> 
> ---
> 
> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)

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

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22673/files
  - new: https://git.openjdk.org/jdk/pull/22673/files/b1a712bf..2e372f29

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

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

PR: https://git.openjdk.org/jdk/pull/22673

From jlu at openjdk.org  Mon Feb  3 22:07:09 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 3 Feb 2025 22:07:09 GMT
Subject: RFR: 8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark
 fails
In-Reply-To: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
Message-ID: <hAWVsuqr6EluyiSDcKUfW8YvyruBd78XloUVbrrVFT8=.1d9b2ee0-1140-44d2-a721-5680a09cfb1d@github.com>

On Mon, 3 Feb 2025 07:49:21 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
> 
> 
>         TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
>         System.out.println(tz.getDisplayName());
>         System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
>         System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
> 
> 
> - Java 22 output:
> 
> 
> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> ECST
> ECT
> 
> 
> - Java 23 output:
> 
> 
> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> GMT-04:00
> GMT-05:00
> 
> 
> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.

Switch to universal time for the time-zone to generalize the benchmark looks good to me.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23414#pullrequestreview-2591146673

From naoto at openjdk.org  Mon Feb  3 22:14:15 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Feb 2025 22:14:15 GMT
Subject: RFR: 8337279: Optimize format instant [v14]
In-Reply-To: <F6H5U0MvgE9lpclMnE4B3QLUUHUlBQdZv2b8lwQlolw=.c74e89e9-e78e-47bf-b9e6-45d9d97fe32c@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <F6H5U0MvgE9lpclMnE4B3QLUUHUlBQdZv2b8lwQlolw=.c74e89e9-e78e-47bf-b9e6-45d9d97fe32c@github.com>
Message-ID: <rMFZ8MTB_bazVEoxNnOLgquz_mNbnPVCJ8J1YJEBQvU=.6865b569-968e-4daa-a901-5ac2bd741f87@github.com>

On Thu, 30 Jan 2025 15:11:28 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not import static, from @RogerRiggs

Looks good with some minor nits

test/micro/org/openjdk/bench/java/time/ToStringBench.java line 131:

> 129:         }
> 130:     }
> 131: }

Please add a new line at the end

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

PR Review: https://git.openjdk.org/jdk/pull/20353#pullrequestreview-2591171271
PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1940137524

From naoto at openjdk.org  Mon Feb  3 22:14:16 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Feb 2025 22:14:16 GMT
Subject: RFR: 8337279: Optimize format instant [v13]
In-Reply-To: <z0dIl7k4w_LeGq8-yhcn4-kUuScntNjfibrAP7hZ7rQ=.0f50e511-b800-46c6-982f-0cc6bcd0644b@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <qzW61a-0HEm3P6ZrqiFwDOCcbPbQa_0pw6hWEKQSqxU=.49eff62c-76ed-4c5d-b780-c62bfdbfc5e6@github.com>
 <VahYLNpYxH4wjZ-A9fF_h7H7Qqhit3kkAuvRVwIU6HI=.de864376-80c1-45ce-a968-43383ba80eab@github.com>
 <z0dIl7k4w_LeGq8-yhcn4-kUuScntNjfibrAP7hZ7rQ=.0f50e511-b800-46c6-982f-0cc6bcd0644b@github.com>
Message-ID: <X3UwNKk5JfxetCEwXDKBbEKhSXaRaoddNm93XMRhDa4=.4de7ded0-a46d-49b5-885d-bf979de5fc35@github.com>

On Thu, 30 Jan 2025 14:36:28 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/DateTimeHelper.java line 26:
>> 
>>> 24:  * questions.
>>> 25:  */
>>> 26: package jdk.internal.util;
>> 
>> Maybe `jdk.internal.time` would be appropriate.
>
> Currently, since we only have the DateTimeHelper class, we can wait until there are two or more classes before creating the jdk.internal.time package.

This utility class can be final, and have a private default constructor so that no instance can be created.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1940135372

From naoto at openjdk.org  Mon Feb  3 22:21:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Feb 2025 22:21:10 GMT
Subject: RFR: 8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark
 fails
In-Reply-To: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
Message-ID: <p1fT39ka23odYt3tgPLFxrHdihnSqAuHIwg7s75vA8M=.933a46e7-deb0-44a4-a7d9-1a92c970eaf2@github.com>

On Mon, 3 Feb 2025 07:49:21 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
> 
> 
>         TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
>         System.out.println(tz.getDisplayName());
>         System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
>         System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
> 
> 
> - Java 22 output:
> 
> 
> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> ECST
> ECT
> 
> 
> - Java 23 output:
> 
> 
> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> GMT-04:00
> GMT-05:00
> 
> 
> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.

The benchmark was provided with the fix to https://bugs.openjdk.org/browse/JDK-8304976, and most likely the failure was due to the removal of COMPAT locale provider. Would you double check the benchmark is relevant with your fix? Since UTC is a special time zone, so I just wanted to double check. If we need more practical short name, "PST" might not be a bad choice

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

PR Comment: https://git.openjdk.org/jdk/pull/23414#issuecomment-2632271474

From swen at openjdk.org  Mon Feb  3 22:31:10 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 22:31:10 GMT
Subject: RFR: 8337279: Optimize format instant [v15]
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <9ntqc-mXvifLuLvIuP8WVd2fcfz8kx3TSUiwLmHOqjA=.6e455335-2ff3-48ad-9ad4-b71193cf7f3e@github.com>

> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.

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

  from @natoj

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20353/files
  - new: https://git.openjdk.org/jdk/pull/20353/files/5924935e..5ca4d6e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=13-14

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

PR: https://git.openjdk.org/jdk/pull/20353

From swen at openjdk.org  Mon Feb  3 22:33:18 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 22:33:18 GMT
Subject: RFR: 8337279: Optimize format instant [v7]
In-Reply-To: <ZyLsa7o--VDmIlJS2vlhaTR2AQNg2Mo9Kyxh8DevTOg=.40c84a94-e863-4ba3-89b4-54617769e79f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <WR4VFQQBMNtkhd0I01eEVRTcY5fJOpNw3XDNsvNS2dc=.e2d72550-6ad5-4a85-8185-7880357b47c3@github.com>
 <ZyLsa7o--VDmIlJS2vlhaTR2AQNg2Mo9Kyxh8DevTOg=.40c84a94-e863-4ba3-89b4-54617769e79f@github.com>
Message-ID: <FW1S0UyFQCas48nYZG3pvFSMTLsEk136B9u5mDOqrn4=.b6389084-53b1-42c9-9e3b-31e13be7a65d@github.com>

On Tue, 3 Sep 2024 17:32:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
>> 
>>  - Speed up Instant.toString using JavaTimeAccess
>>  - add JavaTimeAccess SharedSecrets
>>  - Merge remote-tracking branch 'upstream/master' into optim_instant_fmt_202407
>>  - breaking out the printNano methods
>>  - copyright
>>  - Update src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>>    
>>    Co-authored-by: Stephen Colebourne <scolebourne at joda.org>
>>  - 1. fix handle fraction == -1
>>    2. Split two methods to make codeSize less than 325
>>  - add comment
>>  - optimize format instant
>
> I don't think using SharedSecret just for performance improvement and code size reduction is the right way, as the class is the last resort as the header says:
> 
>  * <p><strong>
>  * Usage of these APIs often means bad encapsulation designs,
>  * increased complexity and lack of sustainability.
>  * Use this only as a last resort!
>  * </strong>

Thank you @naotoj, these have been fixed, please help review again

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

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2632311871

From swen at openjdk.org  Tue Feb  4 00:34:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 00:34:58 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v5]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <kYX9e_pv3p_MaJNJms0hy6cbwGwRRR3SKhcqbUvmuno=.1be358b0-99fb-43f6-9995-39538a45ba50@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  speed up format via wrapper

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/c44d03b5..3b228eeb

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

  Stats: 128 lines in 2 files changed: 80 ins; 1 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

PR: https://git.openjdk.org/jdk/pull/23384

From swen at openjdk.org  Tue Feb  4 00:59:57 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 00:59:57 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v4]
In-Reply-To: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
Message-ID: <rGk1dYrHMZ-c-JLgCrWlB7F4j_hySZ9OVSx7EaCXmLs=.5c4a29ed-ead2-4d45-bce3-350428b3e853@github.com>

> The following code can reproduce the problem, writing out of bounds causes JVM Crash
> 
> 
>    StringBuilder buf = new StringBuilder();
>     buf.append('?');
> 
>     final CountDownLatch latch = new CountDownLatch(10);
>     Runnable r = () -> {
>         for (int i = 0; i < 10000; i++) {
>             buf.setLength(0);
>             buf.trimToSize();
>             buf.append(123456789);
>         }
>         latch.countDown();
>     };
>     Thread[] threads = new Thread[10];
>     for (int i = 0; i < threads.length; i++) {
>         threads[i] = new Thread(r);
>     }
>     for (Thread t : threads) {
>         t.start();
>     }
>     latch.await();
> }
> 
> 
> This problem can be avoided by using the value of ensureCapacityInternal directly.

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

  skip coder change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23427/files
  - new: https://git.openjdk.org/jdk/pull/23427/files/26c0cb4a..1c22ab43

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

  Stats: 19 lines in 1 file changed: 1 ins; 13 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23427.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23427/head:pull/23427

PR: https://git.openjdk.org/jdk/pull/23427

From syan at openjdk.org  Tue Feb  4 02:32:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Feb 2025 02:32:15 GMT
Subject: RFR: 8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark
 fails
In-Reply-To: <p1fT39ka23odYt3tgPLFxrHdihnSqAuHIwg7s75vA8M=.933a46e7-deb0-44a4-a7d9-1a92c970eaf2@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
 <p1fT39ka23odYt3tgPLFxrHdihnSqAuHIwg7s75vA8M=.933a46e7-deb0-44a4-a7d9-1a92c970eaf2@github.com>
Message-ID: <bMB3unbhpgcV7kGeJeA8ZPQpL8me4BSRpDaQYUDepKY=.c6635bf2-53c1-42bf-b77b-30811158d83f@github.com>

On Mon, 3 Feb 2025 22:18:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> most likely the failure was due to the removal of COMPAT locale provide

Yes. git bisect result shows that the failure was due to PR "8174269: Remove COMPAT locale data provider from JDK"
 
And, use jdk22, the difference between '-Djava.locale.providers=COMPAT' and '-Djava.locale.providers=CLDR' also convinced that.


~/software/jdk/temurin/jdk-22.0.2+9/bin/java -Djava.locale.providers=COMPAT ~/compiler-test/zzkk/TimeZoneTest.java 
Feb 04, 2025 10:19:51 AM sun.util.locale.provider.LocaleProviderAdapter <clinit>
WARNING: COMPAT locale provider will be removed in a future release
Ecuador Time
ECST
ECT



~/software/jdk/temurin/jdk-22.0.2+9/bin/java -Djava.locale.providers=CLDR ~/compiler-test/zzkk/TimeZoneTest.java 
Ecuador Time
GMT-05:00
GMT-05:00

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

PR Comment: https://git.openjdk.org/jdk/pull/23414#issuecomment-2632614374

From syan at openjdk.org  Tue Feb  4 02:40:59 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Feb 2025 02:40:59 GMT
Subject: RFR: 8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark
 fails [v2]
In-Reply-To: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
Message-ID: <GZedlVAX83lkQmbZj5hXc0-FAH0vXyMTfSaU5rg_tt4=.12301d1b-f5ee-4e78-ab96-c833a5ee1a24@github.com>

> Hi all,
> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
> 
> 
>         TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
>         System.out.println(tz.getDisplayName());
>         System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
>         System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
> 
> 
> - Java 22 output:
> 
> 
> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> ECST
> ECT
> 
> 
> - Java 23 output:
> 
> 
> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> GMT-04:00
> GMT-05:00
> 
> 
> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.

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

  Use PST instead of Z

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23414/files
  - new: https://git.openjdk.org/jdk/pull/23414/files/56fde9bc..7c84581e

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

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

PR: https://git.openjdk.org/jdk/pull/23414

From syan at openjdk.org  Tue Feb  4 02:40:59 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Feb 2025 02:40:59 GMT
Subject: RFR: 8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark
 fails
In-Reply-To: <p1fT39ka23odYt3tgPLFxrHdihnSqAuHIwg7s75vA8M=.933a46e7-deb0-44a4-a7d9-1a92c970eaf2@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
 <p1fT39ka23odYt3tgPLFxrHdihnSqAuHIwg7s75vA8M=.933a46e7-deb0-44a4-a7d9-1a92c970eaf2@github.com>
Message-ID: <Mqp5WS-5IBysmTr_intSFBnadAXlovwZXF8JoZEx1Ps=.51becfb7-34aa-402e-b566-f850f9c21248@github.com>

On Mon, 3 Feb 2025 22:18:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> If we need more practical short name, "PST" might not be a bad choice.

I think use "Pacific Standard Time - PST" is a more practical chioce. The PR has been updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/23414#issuecomment-2632673527

From duke at openjdk.org  Tue Feb  4 04:58:21 2025
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Tue, 4 Feb 2025 04:58:21 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11]
In-Reply-To: <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
Message-ID: <jRWIje35GMEuP5dU7ChtGwWg1J_LuECBiHf7piqA9vk=.6179020e-57fb-450e-a791-02abc31d1676@github.com>

On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @SuppressWarnings (serial)

Sorting of short/byte/char is almost finished

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2632878199

From redestad at openjdk.org  Tue Feb  4 06:40:27 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 4 Feb 2025 06:40:27 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v4]
In-Reply-To: <iO-RM60r0aP07jqp9eb_e0ZwmcPsuInrGCJONECwmCc=.bdc6cc86-4e02-4411-b37c-142dc3e08bc5@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
 <iO-RM60r0aP07jqp9eb_e0ZwmcPsuInrGCJONECwmCc=.bdc6cc86-4e02-4411-b37c-142dc3e08bc5@github.com>
Message-ID: <1S9GR7ljIJeddX-ITkVxrOePFgZ81NeN0cUDwrkCBSw=.9c38eb8b-417f-4f99-8b58-4de8d9ccf717@github.com>

On Mon, 3 Feb 2025 18:56:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   skip coder change
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 845:
> 
>> 843:         int spaceNeeded = count + DecimalDigits.stringSize(i);
>> 844:         byte[] value = ensureCapacityInternal(spaceNeeded);
>> 845:         if (isLatin1()) {
> 
> This is not safe. The ensureCapacityInternal can read coder == LATIN1 and allocate a small array, but this `isLatin1` can read coder == UTF16 and write a UTF16 number out of bounds.

A check that `spaceNeeded <= (value.length >> 1)`  in the `else` branch would be needed and might be a sufficient safeguard here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23427#discussion_r1940583666

From swen at openjdk.org  Tue Feb  4 07:57:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 07:57:06 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v6]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <9Ce6hvXSD06El0rkSCClTScKa4gpRz4MUODs8Ne5rXc=.580266b1-bd43-4774-add4-895a2c1707a2@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  add test and bug fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/3b228eeb..e5d3f83b

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

  Stats: 143 lines in 2 files changed: 128 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

PR: https://git.openjdk.org/jdk/pull/23384

From swen at openjdk.org  Tue Feb  4 08:05:20 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 08:05:20 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v7]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <NDmUTFj8thNY5YCjr61kMHJGFHkzx7coN0K3w66o-eg=.44edbab6-ae5e-43e6-bcef-fb57683233a6@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  add instance test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/e5d3f83b..b9e54912

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

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

PR: https://git.openjdk.org/jdk/pull/23384

From swen at openjdk.org  Tue Feb  4 08:08:54 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 08:08:54 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v8]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <ciIVpHuV02-ZU29tQDfsVGyfbAsoqSX9ml_QMHfpUL8=.17b41c2b-5f51-466b-9a7d-3577d8a606f0@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - code style
 - code style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/b9e54912..c5f35999

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

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

PR: https://git.openjdk.org/jdk/pull/23384

From swen at openjdk.org  Tue Feb  4 08:45:15 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 08:45:15 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v9]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <hYdMk5G3fLvHICPOVTkQdcL8fwoNDRMiBbdfyBzTBHk=.ecb3d285-5faa-412e-99ec-7a2d30958f49@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  more test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/c5f35999..101a2abc

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

  Stats: 172 lines in 1 file changed: 107 ins; 42 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

PR: https://git.openjdk.org/jdk/pull/23384

From epeter at openjdk.org  Tue Feb  4 08:52:15 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 4 Feb 2025 08:52:15 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v16]
In-Reply-To: <uwc5HqlrWh6v8Nmgng_Ar1monFTvmFnqOl7pA57b_gY=.95301efd-6e3d-486e-831f-694761ffcfdb@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <EC2coajO2bsqpsjUFgjuf-YXj23ENZeLj2ABtq4Sd74=.1e290b04-fcfc-4aaa-b80d-60cdbb0a529a@github.com>
 <uwc5HqlrWh6v8Nmgng_Ar1monFTvmFnqOl7pA57b_gY=.95301efd-6e3d-486e-831f-694761ffcfdb@github.com>
Message-ID: <_5bwBRKG8Zu7iywOJZ6WgUb6N4so1sAO6Ua8S0zQU94=.3200ef74-4e50-424b-a3da-637be63e3f0c@github.com>

On Mon, 3 Feb 2025 18:11:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java
>>   
>>   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
>
> Hi @PaulSandoz , @eme64 , All outstanding comments haven been addressed, please let me know if there are other comments.

@jatin-bhateja Testing is all green :green_circle: 
Doing a last pass over the code.

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

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2633248273

From swen at openjdk.org  Tue Feb  4 09:02:26 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 09:02:26 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v10]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <wE2UfxFRDQ5Qi8tPor2CliltTTBWHys6SfqvK0TjbjI=.e63089a8-9435-4ce7-9422-b0b0725a358c@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  refactor test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/101a2abc..5fb9dc52

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

  Stats: 117 lines in 1 file changed: 56 ins; 57 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

PR: https://git.openjdk.org/jdk/pull/23384

From epeter at openjdk.org  Tue Feb  4 09:03:17 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 4 Feb 2025 09:03:17 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v16]
In-Reply-To: <EC2coajO2bsqpsjUFgjuf-YXj23ENZeLj2ABtq4Sd74=.1e290b04-fcfc-4aaa-b80d-60cdbb0a529a@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <EC2coajO2bsqpsjUFgjuf-YXj23ENZeLj2ABtq4Sd74=.1e290b04-fcfc-4aaa-b80d-60cdbb0a529a@github.com>
Message-ID: <s2YfUR-OSsspzSE48zzcERjOKMj6nHJAYcqdupJJv4g=.01feb188-2d41-4b58-bee2-01f95bc73325@github.com>

On Thu, 30 Jan 2025 11:03:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java
>   
>   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>

src/hotspot/share/opto/convertnode.hpp line 222:

> 220: class ReinterpretS2HFNode : public Node {
> 221:   public:
> 222:   ReinterpretS2HFNode(Node* in1) : Node(0, in1) {}

Suggestion:

  ReinterpretS2HFNode(Node* in1) : Node(nullptr, in1) {}

Oh, just caught this. I think you should not use `0` here any more, check all other uses.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1940762320

From epeter at openjdk.org  Tue Feb  4 09:16:17 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 4 Feb 2025 09:16:17 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v16]
In-Reply-To: <EC2coajO2bsqpsjUFgjuf-YXj23ENZeLj2ABtq4Sd74=.1e290b04-fcfc-4aaa-b80d-60cdbb0a529a@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <EC2coajO2bsqpsjUFgjuf-YXj23ENZeLj2ABtq4Sd74=.1e290b04-fcfc-4aaa-b80d-60cdbb0a529a@github.com>
Message-ID: <mUgb99AYb-pdBKAx5Jy6TfGAWok7-DJ89A9m80L-yYc=.d51af39b-d84d-4daf-857d-513183b5262e@github.com>

On Thu, 30 Jan 2025 11:03:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java
>   
>   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>

Ooops, I found a few more details. But the C++ VM changes look really good now.

The Java changes I leave to @PaulSandoz

src/hotspot/share/opto/convertnode.cpp line 971:

> 969:       return true;
> 970:     default:
> 971:       return false;

Does this cover all cases? What about `FmaHF`?

src/hotspot/share/opto/convertnode.hpp line 234:

> 232: class ReinterpretHF2SNode : public Node {
> 233:   public:
> 234:   ReinterpretHF2SNode(Node* in1) : Node(0, in1) {}

Suggestion:

  ReinterpretHF2SNode(Node* in1) : Node(nullptr, in1) {}

src/hotspot/share/opto/divnode.cpp line 866:

> 864: // Dividing by self is 1.
> 865: // IF the divisor is 1, we are an identity on the dividend.
> 866: Node* DivHFNode::Identity(PhaseGVN* phase) {

Remove line with `isA_Copy`.

src/hotspot/share/opto/type.cpp line 1106:

> 1104:     if (_base == FloatBot || _base == FloatTop) return FLOAT;
> 1105:     if (_base == HalfFloatTop || _base == HalfFloatBot) return Type::BOTTOM;
> 1106:     if (_base == DoubleTop || _base == DoubleBot) return Type::BOTTOM;

If you already fixing the style, you should use curly braces as I said above ;)

src/hotspot/share/opto/type.cpp line 1472:

> 1470: //------------------------------meet-------------------------------------------
> 1471: // Compute the MEET of two types.  It returns a new Type object.
> 1472: const Type* TypeH::xmeet(const Type* t) const {

Suggestion:

//------------------------------xmeet-------------------------------------------
// Compute the MEET of two types.  It returns a new Type object.
const Type* TypeH::xmeet(const Type* t) const {

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

PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2592155651
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1940766035
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1940763403
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1940766624
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1940771256
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1940771662

From vklang at openjdk.org  Tue Feb  4 09:30:29 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 4 Feb 2025 09:30:29 GMT
Subject: RFR: 8349107: Remove RMI finalizers [v2]
In-Reply-To: <GBxj64AHg_40TFsAmS7nwWfICjXoTUt13CiAxK72e4Q=.bfbad393-1ca4-4746-9535-4f8e17fed265@github.com>
References: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
 <GBxj64AHg_40TFsAmS7nwWfICjXoTUt13CiAxK72e4Q=.bfbad393-1ca4-4746-9535-4f8e17fed265@github.com>
Message-ID: <pmE1miZNuQWC3fMG5ag9LbBuJGP4DTJ_XmFArX4R0Wk=.c874c1fe-9f33-437a-9897-ad14dcb2867c@github.com>

On Mon, 3 Feb 2025 19:13:10 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> 3 finalizers in RMI code can be removed, as they do not perform meaningful cleanup.
>> 
>> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**
>> 
>> `RegistryContext.finalize()` just calls `close()`. The `close()` method does not perform any cleanup per se, but rather "helps the garbage collector" by setting `environment` and `registry` to `null`.
>> 
>> 
>> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.BindingEnumeration`**
>> 
>> `BindingEnumeration.finalize()` simply calls `close()` on the `ctx` field, itself a `RegistryContext` (and `close()` just "helps the GC.")
>> 
>> 
>> **`src/java.rmi/share/classes/sun/rmi/log/LogInputStream`**
>> 
>> `LogInputStream` tracks its length with an int field, `length`. If `length` ever becomes == 0, `LogInputStream`'s methods will return without doing anything.
>> 
>> The finalizer calls `close()`, which just sets length = 0.
>> 
>> By the time a `LogInputStream` becomes unreachable and is finalized, it's a moot point whether length == 0, as no more methods can be called.
>> If anything, this finalizer could cause a bug. If a `LogInputStream` were to became unreachable while a method were still running, the finalizer could set the length to 0 while method code is still running and expecting a length != 0.
>> It's possible that there is a very long standing bug that `close()` should be calling `in.close()`, in which case this evaluation will need to be revisited.
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into rmF10Nnow
>  - Remove finalizer from RMI LogInputStream
>  - Remove finalizer from RMI RegistryContext.BindingEnumeration
>  - Remove finalizer from RMI RegistryContext

Nice work, @bchristi-git

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

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23406#pullrequestreview-2592223810

From pminborg at openjdk.org  Tue Feb  4 09:44:18 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 4 Feb 2025 09:44:18 GMT
Subject: RFR: 8349343: Add missing copyright messages in FFM benchmarks
Message-ID: <S-fqV46X_L0Tyduj9EM1End-JFKLGCV5azp92B5toI4=.b6c0e5f4-7958-439b-aad1-72fed8874ef5@github.com>

This PR proposes to add missing copyright headers to some FFM benchmarks.

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

Commit messages:
 - Add copyright headers

Changes: https://git.openjdk.org/jdk/pull/23433/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23433&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349343
  Stats: 184 lines in 8 files changed: 184 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23433.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23433/head:pull/23433

PR: https://git.openjdk.org/jdk/pull/23433

From pminborg at openjdk.org  Tue Feb  4 09:51:40 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 4 Feb 2025 09:51:40 GMT
Subject: RFR: 8349344: Clarify documentation of Arena.ofConfined
Message-ID: <uRzbPuT_TqSUM2HsGK9u192RC73lPsKlAtgUxUwcR68=.bc1ae678-0e4b-41fb-a374-fcdd94f92251@github.com>

This PR proposes to clarify the documentation for `Arena.ofConfined()`. It is proposed to say that segments allocated from the returned `Arena` can _only_ be accessed by the thread that created the `Arena` in the first place.

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

Commit messages:
 - Clarify docs for Arena.ofConfined()

Changes: https://git.openjdk.org/jdk/pull/23435/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23435&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349344
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23435.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23435/head:pull/23435

PR: https://git.openjdk.org/jdk/pull/23435

From jbhateja at openjdk.org  Tue Feb  4 10:05:09 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 4 Feb 2025 10:05:09 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v17]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <sgcWAEvXaWi40uFqPPJq-e6n3YsHb7agKBUrMBdqJSc=.48c41eab-6641-45b7-9765-400622894f4b@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

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

  Fixing typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/8207c9ff..82a42213

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=15-16

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

PR: https://git.openjdk.org/jdk/pull/22754

From jbhateja at openjdk.org  Tue Feb  4 10:05:11 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 4 Feb 2025 10:05:11 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v16]
In-Reply-To: <uwc5HqlrWh6v8Nmgng_Ar1monFTvmFnqOl7pA57b_gY=.95301efd-6e3d-486e-831f-694761ffcfdb@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <EC2coajO2bsqpsjUFgjuf-YXj23ENZeLj2ABtq4Sd74=.1e290b04-fcfc-4aaa-b80d-60cdbb0a529a@github.com>
 <uwc5HqlrWh6v8Nmgng_Ar1monFTvmFnqOl7pA57b_gY=.95301efd-6e3d-486e-831f-694761ffcfdb@github.com>
Message-ID: <eMGB03R4LnluDMT7cnMNKqOu2cf7KyTcnO-XaVtaxGc=.776c7039-5f69-481a-9a0a-f167486560ad@github.com>

On Mon, 3 Feb 2025 18:11:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java
>>   
>>   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
>
> Hi @PaulSandoz , @eme64 , All outstanding comments haven been addressed, please let me know if there are other comments.

> @jatin-bhateja Testing is all green ? Doing a last pass over the code.

Thanks @eme64, looking forward to your approval :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2633414710

From jbhateja at openjdk.org  Tue Feb  4 10:05:11 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 4 Feb 2025 10:05:11 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v16]
In-Reply-To: <mUgb99AYb-pdBKAx5Jy6TfGAWok7-DJ89A9m80L-yYc=.d51af39b-d84d-4daf-857d-513183b5262e@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <EC2coajO2bsqpsjUFgjuf-YXj23ENZeLj2ABtq4Sd74=.1e290b04-fcfc-4aaa-b80d-60cdbb0a529a@github.com>
 <mUgb99AYb-pdBKAx5Jy6TfGAWok7-DJ89A9m80L-yYc=.d51af39b-d84d-4daf-857d-513183b5262e@github.com>
Message-ID: <cZKkfnS-ra5Pmvto6pG-lfQ7WcpkKsncirRdbDnXRRk=.fc426cac-4fc7-49ca-b0fa-9b983b9246ca@github.com>

On Tue, 4 Feb 2025 09:03:09 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java
>>   
>>   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
>
> src/hotspot/share/opto/convertnode.cpp line 971:
> 
>> 969:       return true;
>> 970:     default:
>> 971:       return false;
> 
> Does this cover all cases? What about `FmaHF`?

FmaHF is a ternary operation and is intrinsified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1940855109

From djelinski at openjdk.org  Tue Feb  4 10:19:13 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 4 Feb 2025 10:19:13 GMT
Subject: RFR: 8349107: Remove RMI finalizers [v2]
In-Reply-To: <GBxj64AHg_40TFsAmS7nwWfICjXoTUt13CiAxK72e4Q=.bfbad393-1ca4-4746-9535-4f8e17fed265@github.com>
References: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
 <GBxj64AHg_40TFsAmS7nwWfICjXoTUt13CiAxK72e4Q=.bfbad393-1ca4-4746-9535-4f8e17fed265@github.com>
Message-ID: <xawk50IyO1Tmkhdfr7j0ye4lvwus2YJs7M9lJR29pHc=.3efc0429-99ed-4253-9be2-b4d31d1fb347@github.com>

On Mon, 3 Feb 2025 19:13:10 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> 3 finalizers in RMI code can be removed, as they do not perform meaningful cleanup.
>> 
>> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**
>> 
>> `RegistryContext.finalize()` just calls `close()`. The `close()` method does not perform any cleanup per se, but rather "helps the garbage collector" by setting `environment` and `registry` to `null`.
>> 
>> 
>> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.BindingEnumeration`**
>> 
>> `BindingEnumeration.finalize()` simply calls `close()` on the `ctx` field, itself a `RegistryContext` (and `close()` just "helps the GC.")
>> 
>> 
>> **`src/java.rmi/share/classes/sun/rmi/log/LogInputStream`**
>> 
>> `LogInputStream` tracks its length with an int field, `length`. If `length` ever becomes == 0, `LogInputStream`'s methods will return without doing anything.
>> 
>> The finalizer calls `close()`, which just sets length = 0.
>> 
>> By the time a `LogInputStream` becomes unreachable and is finalized, it's a moot point whether length == 0, as no more methods can be called.
>> If anything, this finalizer could cause a bug. If a `LogInputStream` were to became unreachable while a method were still running, the finalizer could set the length to 0 while method code is still running and expecting a length != 0.
>> It's possible that there is a very long standing bug that `close()` should be calling `in.close()`, in which case this evaluation will need to be revisited.
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into rmF10Nnow
>  - Remove finalizer from RMI LogInputStream
>  - Remove finalizer from RMI RegistryContext.BindingEnumeration
>  - Remove finalizer from RMI RegistryContext

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23406#pullrequestreview-2592355520

From rgiulietti at openjdk.org  Tue Feb  4 10:38:13 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 4 Feb 2025 10:38:13 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v9]
In-Reply-To: <TzNnxkav0HZx8rlPHw1LEbK6Hkt1-XejcTjZNosEp4Q=.e17eb37b-5ee9-4723-a199-90efae4cf3c7@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
 <wiRVRbwjV60Bbt5zQUwf1MtpHjt-YrN2KxKGVotHHVU=.9d93ab95-5fb2-4dee-83db-a8b52a647f06@github.com>
 <TzNnxkav0HZx8rlPHw1LEbK6Hkt1-XejcTjZNosEp4Q=.e17eb37b-5ee9-4723-a199-90efae4cf3c7@github.com>
Message-ID: <ViR5M4sWlaZrX57iVjTRSA1n5Lf9uVQi64iDNAQQJjg=.14dc3dc3-898d-414a-93a1-5cedc2efc644@github.com>

On Mon, 27 Jan 2025 20:07:29 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This line on a test is now failing because it's expecting a specific `NumberFormatException` message.
> 
> https://github.com/openjdk/jdk/blob/21feef32803b2593b097fb225c7a4c7cd46525da/test/jdk/com/sun/jdi/JdbExprTest.java#L114
> 
> I don't have much time to have a look during this week, though.

I think it is better to just change the expected message on https://github.com/openjdk/jdk/blob/21feef32803b2593b097fb225c7a4c7cd46525da/test/jdk/com/sun/jdi/JdbExprTest.java#L115 rather to introduce the hack in `NumberFormatException.forCharSequence`.

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

PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2633500053

From rgiulietti at openjdk.org  Tue Feb  4 10:38:18 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 4 Feb 2025 10:38:18 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v13]
In-Reply-To: <e9mfG7ub-X9TkBSwUSiq1DoE5bUXSCvKSxS0UnrOauU=.1f4ec4c7-0ba5-4759-b56b-a819e30aad4e@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
 <e9mfG7ub-X9TkBSwUSiq1DoE5bUXSCvKSxS0UnrOauU=.1f4ec4c7-0ba5-4759-b56b-a819e30aad4e@github.com>
Message-ID: <v2mN6jAqGeMsIFIyOGvfqebSpuRAl5n1A4iRYe8dwO0=.091ea4f6-46a2-4666-abd8-490ce4afc802@github.com>

On Sat, 1 Feb 2025 10:07:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
>> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
>> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
>> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>  - multiply 10
>  - copyright
>  - error message
>  - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>  - use &
>  - from @rgiulietti
>  - remove unused
>  - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - vector digit2
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/651ac3cc...1fb40bb9

src/java.base/share/classes/java/lang/Integer.java line 525:

> 523:             return parseInt0(s, radix);
> 524:         }
> 525:         int fc = value[0];

Suggestion:

        /* Accumulating negatively avoids surprises near MAX_VALUE */
        int fc = value[0];

src/java.base/share/classes/java/lang/Long.java line 561:

> 559:             return parseLong0(s, radix);
> 560:         }
> 561:         int fc = value[0];

Suggestion:

        /* Accumulating negatively avoids surprises near MAX_VALUE */
        int fc = value[0];

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1940916020
PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1940916196

From mcimadamore at openjdk.org  Tue Feb  4 10:46:09 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 4 Feb 2025 10:46:09 GMT
Subject: RFR: 8349238: Some more FFM benchmarks are broken
In-Reply-To: <-JJ06J2vBX5lLVm15KjCQX8xjulNHrfRkpN0Cp8pOZg=.ad278382-1d2e-4126-9584-282204b96c3a@github.com>
References: <-JJ06J2vBX5lLVm15KjCQX8xjulNHrfRkpN0Cp8pOZg=.ad278382-1d2e-4126-9584-282204b96c3a@github.com>
Message-ID: <5f8ZMqA845mc6EI5Ia3pA9KZ_I4jJ8bzEhD7M2J-MyQ=.cea0e6d4-1961-429e-89ed-ba51bbe40566@github.com>

On Mon, 3 Feb 2025 18:29:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to fix an Unsafe issue in a benchmark.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23424#pullrequestreview-2592423136

From dfuchs at openjdk.org  Tue Feb  4 10:59:14 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Feb 2025 10:59:14 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v4]
In-Reply-To: <Wqz8Z4jFOpcSZLMelLBKVwiZdWX33-QWtp5jiGF-AF8=.911e5e47-075d-45a8-ab5d-17e17871552e@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
 <Wqz8Z4jFOpcSZLMelLBKVwiZdWX33-QWtp5jiGF-AF8=.911e5e47-075d-45a8-ab5d-17e17871552e@github.com>
Message-ID: <StCYP496VXkElEXgFW7Eenk_8T8fM30pcuE168QNEcc=.de9d50ec-14b0-41cc-9d0a-19e528fce1c8@github.com>

On Mon, 3 Feb 2025 19:26:03 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
>> 
>> 
>> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
>> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
>> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
>> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
>> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
>> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
>> 
>> 
>> **Other highlights:**
>> 
>> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
>> - `test.lib.Asserts::assertFileContentsEqual` is added
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Assert that multiple files can be served using the same `FileServerHandler`
>  - Remove redundant `@build` dependencies

test/jdk/com/sun/net/httpserver/SelCacheTest.java line 77:

> 75:             s2 = HttpsServer.create(addr, 0);
> 76:             // Assert that both files share the same parent and can be served from the same `FileServerHandler`
> 77:             assert smallFilePath.getParent().equals(largeFilePath.getParent());

I see what you are doing here. On the one hand I thought that it would be better placed right after line 66, but on the other hand we want it inside the `try { }` so that files will be deleted on `finally` even if it fires. So LGTM.

test/jdk/com/sun/net/httpserver/SelCacheTest.java line 145:

> 143:         fout.close();
> 144: 
> 145:         if (count != filePath.toFile().length()) {

Maybe we could use assertEquals here for better diagnosability

test/jdk/com/sun/net/httpserver/SelCacheTest.java line 149:

> 147:         }
> 148:         Path tempPath = temp.toPath();
> 149:         assert Files.mismatch(filePath, tempPath) < 0;

I would suggest using `assertEquals` with -1 here to ensure that:

1. the test will fail if the files don't match even if asserts are disabled, and
2. we see at which place mismatch was detected in the exception message

test/jdk/com/sun/net/httpserver/Test1.java line 160:

> 158:         }
> 159:         Path tempPath = temp.toPath();
> 160:         assert Files.mismatch(filePath, tempPath) < 0;

Same suggestions WRT assertEquals here

test/jdk/com/sun/net/httpserver/Test12.java line 182:

> 180:                 }
> 181:                 Path tempPath = temp.toPath();
> 182:                 assert Files.mismatch(filePath, tempPath) < 0;

and here as well

test/jdk/com/sun/net/httpserver/Test13.java line 184:

> 182:                 }
> 183:                 Path tempPath = temp.toPath();
> 184:                 assert Files.mismatch(filePath, tempPath) < 0;

ditto

test/jdk/com/sun/net/httpserver/Test9.java line 202:

> 200:                 }
> 201:                 Path tempPath = temp.toPath();
> 202:                 assert Files.mismatch(filePath, tempPath) < 0;

And in all other places where this pattern appears in this PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940924335
PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940936508
PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940935266
PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940941328
PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940942729
PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940943725
PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1940945015

From pminborg at openjdk.org  Tue Feb  4 11:03:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 4 Feb 2025 11:03:14 GMT
Subject: Integrated: 8349238: Some more FFM benchmarks are broken
In-Reply-To: <-JJ06J2vBX5lLVm15KjCQX8xjulNHrfRkpN0Cp8pOZg=.ad278382-1d2e-4126-9584-282204b96c3a@github.com>
References: <-JJ06J2vBX5lLVm15KjCQX8xjulNHrfRkpN0Cp8pOZg=.ad278382-1d2e-4126-9584-282204b96c3a@github.com>
Message-ID: <KQyjDgLc8HA4xN8TldalAaEx21VAtB_IO8UFZNEHrXs=.d207b88c-1b0a-46a8-95a7-9f6ad59984cd@github.com>

On Mon, 3 Feb 2025 18:29:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to fix an Unsafe issue in a benchmark.

This pull request has now been integrated.

Changeset: 81126c20
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81126c20cbcab577d82e690d9cf1c1b738754a07
Stats:     26 lines in 1 file changed: 25 ins; 0 del; 1 mod

8349238: Some more FFM benchmarks are broken

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.org/jdk/pull/23424

From vyazici at openjdk.org  Tue Feb  4 12:04:47 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Feb 2025 12:04:47 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v5]
In-Reply-To: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
Message-ID: <_qLvq4ASmA4CnxrCk6DCmHsfbmpI1EZtJcXD5lNdz50=.cc678be8-ab5f-41f7-b6d9-c2d50dd73a14@github.com>

> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
> 
> 
> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
> 
> 
> **Other highlights:**
> 
> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
> - `test.lib.Asserts::assertFileContentsEqual` is added

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

  Replace `assert`s with conditionally thrown exceptions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23401/files
  - new: https://git.openjdk.org/jdk/pull/23401/files/4efc42f7..9c7c6af0

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

  Stats: 90 lines in 9 files changed: 47 ins; 21 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/23401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23401/head:pull/23401

PR: https://git.openjdk.org/jdk/pull/23401

From jvernee at openjdk.org  Tue Feb  4 12:13:08 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Feb 2025 12:13:08 GMT
Subject: RFR: 8349343: Add missing copyright messages in FFM benchmarks
In-Reply-To: <S-fqV46X_L0Tyduj9EM1End-JFKLGCV5azp92B5toI4=.b6c0e5f4-7958-439b-aad1-72fed8874ef5@github.com>
References: <S-fqV46X_L0Tyduj9EM1End-JFKLGCV5azp92B5toI4=.b6c0e5f4-7958-439b-aad1-72fed8874ef5@github.com>
Message-ID: <UOAzh626-kNTun2IVyB1lqk4kVvNjvKa-mguPXJIryM=.1dd76530-7d12-4c74-b42b-be9bf89ff829@github.com>

On Tue, 4 Feb 2025 09:40:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add missing copyright headers to some FFM benchmarks.

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23433#pullrequestreview-2592637362

From vyazici at openjdk.org  Tue Feb  4 12:17:12 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Feb 2025 12:17:12 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v4]
In-Reply-To: <StCYP496VXkElEXgFW7Eenk_8T8fM30pcuE168QNEcc=.de9d50ec-14b0-41cc-9d0a-19e528fce1c8@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
 <Wqz8Z4jFOpcSZLMelLBKVwiZdWX33-QWtp5jiGF-AF8=.911e5e47-075d-45a8-ab5d-17e17871552e@github.com>
 <StCYP496VXkElEXgFW7Eenk_8T8fM30pcuE168QNEcc=.de9d50ec-14b0-41cc-9d0a-19e528fce1c8@github.com>
Message-ID: <Gw9PfjtBoV76rDXO0yWZh_V8UcJDXBaCIouIuQDa98k=.ec65883d-5e98-4c1e-b808-e36aa1c9b6df@github.com>

On Tue, 4 Feb 2025 10:46:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Assert that multiple files can be served using the same `FileServerHandler`
>>  - Remove redundant `@build` dependencies
>
> test/jdk/com/sun/net/httpserver/SelCacheTest.java line 149:
> 
>> 147:         }
>> 148:         Path tempPath = temp.toPath();
>> 149:         assert Files.mismatch(filePath, tempPath) < 0;
> 
> I would suggest using `assertEquals` with -1 here to ensure that:
> 
> 1. the test will fail if the files don't match even if asserts are disabled, and
> 2. we see at which place mismatch was detected in the exception message

In 9c7c6af013e0495b08bcd248e30d83385bcc35b5,

- Used `Asserts::assertEquals` to compare `count` and `filePath.toFile().length()` (as you requested above)
- Replaced `assert Files.mismatch(...) < 0` with a **newly added** `Asserts::assertFileContentsEqual`

I opted for a new method (using `Files::mismatch` under the hood) since it

- Provides better diagnostics (source & target paths)
- Doesn't bother call-sites with `IOException`s (in line with JUnit, AssertJ, etc. assertions)
- Saves ~11 LoC at each call-site

@jaikiran, earlier you wanted me to remove `Asserts::assertFileContentsEqual` in favor of a check against `Files::mismatch`. I switched back to the old behavior, because of the advantages I shared above, plus we import `Asserts` for `assertEquals` anyway.

@dfuch, @jaikiran, I would appreciate your input before resolving this conversation.

> test/jdk/com/sun/net/httpserver/Test1.java line 160:
> 
>> 158:         }
>> 159:         Path tempPath = temp.toPath();
>> 160:         assert Files.mismatch(filePath, tempPath) < 0;
> 
> Same suggestions WRT assertEquals here

Fixed in 9c7c6af013e0495b08bcd248e30d83385bcc35b5.

> test/jdk/com/sun/net/httpserver/Test12.java line 182:
> 
>> 180:                 }
>> 181:                 Path tempPath = temp.toPath();
>> 182:                 assert Files.mismatch(filePath, tempPath) < 0;
> 
> and here as well

Fixed in 9c7c6af013e0495b08bcd248e30d83385bcc35b5.

> test/jdk/com/sun/net/httpserver/Test13.java line 184:
> 
>> 182:                 }
>> 183:                 Path tempPath = temp.toPath();
>> 184:                 assert Files.mismatch(filePath, tempPath) < 0;
> 
> ditto

Fixed in 9c7c6af013e0495b08bcd248e30d83385bcc35b5.

> test/jdk/com/sun/net/httpserver/Test9.java line 202:
> 
>> 200:                 }
>> 201:                 Path tempPath = temp.toPath();
>> 202:                 assert Files.mismatch(filePath, tempPath) < 0;
> 
> And in all other places where this pattern appears in this PR

Fixed in 9c7c6af013e0495b08bcd248e30d83385bcc35b5.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941055912
PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941056394
PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941056606
PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941056800
PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941056994

From viktor.klang at oracle.com  Tue Feb  4 12:41:01 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 4 Feb 2025 12:41:01 +0000
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
Message-ID: <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi,

The problem is that mapConcurrent cannot throw InterruptedException because that is a checked exception, so we cannot clear the interrupted flag and throw that exception.

So the updated semantics is to not cut the stream short but instead run to completion, restoring the interruption flag.

There exists a couple of alternatives to this approach which I am contemplating, but they need to be further explored before I consider moving forward with any of them.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Monday, 27 January 2025 17:00
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

It looks like the current fix ignores interruption.

I want to make sure my concern of it defeating cancellation is heard and understood.

The scenarios I worry about is for a mapConcurrent() that fans out to another method call, which internally calls mapConcurrent() as implementation detail.

An example:


List<RefundResponse> refundHelper(transaction) {
  transaction.creditCardAccounts.stream()
    .gather(mapConcurrent(acct -> service.refund(acct))
    .toList();
}

transactions.stream()
    .gather(mapConcurrent(transaction -> refundHelper(transaction));

It seems undesirable that in such a case all the service.refund() calls become non cancellable, because the only way the outer mapConcurrent() cancels the refundHelper() calls is through Thread.interrupt() the virtual threads that call refundHelper(), which would then be disabled by the inner mapConcurrent().

Does this example make sense to you? I can further explain if anything isn't clear.

But I want to make sure the decision to disable interruption is deliberate judgement call that such nested mapConcurrent() is unlikely,or not important.

Cheers,



On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

Please see: https://github.com/openjdk/jdk/pull/23100<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 26 January 2025 23:03
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: mapConcurrent() with InterruptedException

Checking in on what you've found out, Viktor.

From where we left off, I understand that you were looking at alternatives instead of silent truncation?

Have you reached any conclusion?

We touched on disallowing interruption during mapConcurrent(). I still have concerns with disabling cancellation, because it basically undoes this API note from the javadoc<https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>:


API Note:

In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements.
In reality, people will use mapConcurrent() to fan out rpcs. Sometimes these rpcs are just a single blocking call; yet sometimes they may themselves be a Structured Concurrency scope, with 2 or 3 rpcs that constitute a single logical operation. Under two conditions, cancellation is imho important semantic:

  1.  The downstream code uses filter().findFirst(), and when it sees an element, it will return and no longer needs the other pending rpcs to complete. If cancellation is disabled, these unnecessary rpcs will waste system resources.
  2.  One of the rpc throws and the Stream pipeline needs to propagate the exception. Again, if the other rpcs cannot be cancelled, we'll have many zombie rpcs.

Zombie rpcs may or may not be a deal breaker, depending on the specific use case. But for a JDK library, losing cancellation would have a negative impact on usability.

My 2c,


On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Ben,

Thanks for raising these questions?getting feedback is crucial in the Preview stage of features.

I wrote a reply to the Reddit thread so I'll just summarize here:

It is important to note that mapConcurrent() is not a part of the Structured Concurrency JEPs, so it is not designed to join SC scopes.

I'm currently experimenting with ignoring-but-restoring interrupts on the "calling thread" for mapConcurrent(), as well as capping work-in-progress to maxConcurrency (not only capping the concurrency but also the amount of completed-but-yet-to-be-pushed work). Both of these adjustments should increase predictability of behavior in the face of blocking operations with variable delays.

Another adjustment I'm looking at right now is to harden/improve the cleanup to wait for concurrent tasks to acknowledge cancellation, so that once the finisher is done executing the VTs are known to have terminated.

As for not preserving the encounter order, that would be a completely different thing, and I'd encourage you to experiment with that if that functionality would be interesting for your use-case(s).

Again, thanks for your feedback!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Friday, 3 January 2025 17:53
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: mapConcurrent() with InterruptedException

Hi Java Experts,

I sent this email incorrectly to loom-dev@ and was told on Reddit that core-libs-dev is the right list.

The question is about the behavior of mapConcurrent() when the thread is interrupted.

Currently mapConcurrent()'s finisher phase will re-interrupt the thread, then stop at whatever element that has already been processed and return.

This strikes me as a surprising behavior, because for example if I'm running:

   Stream.of(1, 2, 3)
        .gather(mapConcurrent(i -> i * 2))
        .toList()

and the thread is being interrupted, the result could be any of [2], [2, 4] or [2, 4, 6].

Since thread interruption is cooperative, there is no guarantee that the thread being interrupted will just abort. It's quite possible that it'll keep going and then will use for example [2] as the result of doubling the list of [1, 2, 3], which is imho incorrect.

In the Reddit<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks.

There had been discussion about alternative strategies:

  1.  Don't respond to interruption and just keep running to completion.
  2.  Re-interrupt thread and wrap the InterruptedException in a standard unchecked exception (StructuredConcurrencyInterruptedException?).

I have concerns with option 1 because it disables cancellation propagation when mapConcurrent() itself is used in a subtask of a parent mapConcurrent() or in a StructuredConcurrencyScope.

Both equivalent Future-composition async code, or C++'s fiber trees support cancellation propagation and imho it's a critical feature or else it's possible that a zombie thread is still sending RPCs long after the main thread has exited (failed, or falled back to some default action).

My arguments for option 2:

  1.  InterruptedException is more error prone than traditional checked exceptions for users to catch and handle. They can forget to re-interrupt the thread. It's so confusing that even seasoned programmers may not know they are supposed to re-interrupt the thread.
  2.  With Stream API using functional interfaces like Supplier, Function, the option of just tacking on "throws IE" isn't available to many users.
  3.  With Virtual Threads, it will be more acceptable, or even become common to do blocking calls from a stream operation (including but exclusive to mapConcurrent()). So the chance users are forced to deal with IE will become substantially higher.
  4.  Other APIs such as the Structured Concurrency API have already started wrapping system checked exceptions like ExecutionException, TimeoutException in unchecked exceptions ( join()<https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for example).
  5.  Imho, exceptions that we'd rather users not catch and handle but instead should mostly just propagate up as is, should be unchecked.

There is also a side discussion<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread?

Thank you and cheers!

Ben Yu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250204/245fa882/attachment-0001.htm>

From stuefe at openjdk.org  Tue Feb  4 12:41:10 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 4 Feb 2025 12:41:10 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v4]
In-Reply-To: <rGk1dYrHMZ-c-JLgCrWlB7F4j_hySZ9OVSx7EaCXmLs=.5c4a29ed-ead2-4d45-bce3-350428b3e853@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
 <rGk1dYrHMZ-c-JLgCrWlB7F4j_hySZ9OVSx7EaCXmLs=.5c4a29ed-ead2-4d45-bce3-350428b3e853@github.com>
Message-ID: <qZEriWU3W0LtGcSyB8kGwfhiw4ZKIF9lcmDr_0RJCu0=.39b2becf-87d0-469f-b446-f52dc18f7b71@github.com>

On Tue, 4 Feb 2025 00:59:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The following code can reproduce the problem, writing out of bounds causes JVM Crash
>> 
>> 
>>    StringBuilder buf = new StringBuilder();
>>     buf.append('?');
>> 
>>     final CountDownLatch latch = new CountDownLatch(10);
>>     Runnable r = () -> {
>>         for (int i = 0; i < 10000; i++) {
>>             buf.setLength(0);
>>             buf.trimToSize();
>>             buf.append(123456789);
>>         }
>>         latch.countDown();
>>     };
>>     Thread[] threads = new Thread[10];
>>     for (int i = 0; i < threads.length; i++) {
>>         threads[i] = new Thread(r);
>>     }
>>     for (Thread t : threads) {
>>         t.start();
>>     }
>>     latch.await();
>> }
>> 
>> 
>> This problem can be avoided by using the value of ensureCapacityInternal directly.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip coder change

I am confused about the description. How exactly is the JVM crashed? Does the interpreter or compiled code crash?

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

PR Comment: https://git.openjdk.org/jdk/pull/23427#issuecomment-2633788477

From syan at openjdk.org  Tue Feb  4 12:42:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Feb 2025 12:42:47 GMT
Subject: RFR: 8349358: [JMH] Cannot access class
 jdk.internal.vm.ContinuationScope
Message-ID: <FddiPGh35d9FmxlDMKD5Q-jar7KUNnRDCsF0HKc-RrM=.cbad68b4-b84e-4ec9-98d8-90f27a42d043@github.com>

Hi all,

Several JMH tests fails "cannot access class jdk.internal.vm.ContinuationScope (in module java.base) because module java.base does not export jdk.internal.vm to unnamed module". This PR add VM option `--add-exports=java.base/jdk.internal.vm=ALL-UNNAMED` to fix the JMH test bug.

Change has been verified locally, test-fix only, no risk.

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

Commit messages:
 - 8349358: [JMH] Cannot access class jdk.internal.vm.ContinuationScope

Changes: https://git.openjdk.org/jdk/pull/23437/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23437&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349358
  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23437/head:pull/23437

PR: https://git.openjdk.org/jdk/pull/23437

From alanb at openjdk.org  Tue Feb  4 13:33:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Feb 2025 13:33:09 GMT
Subject: RFR: 8349358: [JMH] Cannot access class
 jdk.internal.vm.ContinuationScope
In-Reply-To: <FddiPGh35d9FmxlDMKD5Q-jar7KUNnRDCsF0HKc-RrM=.cbad68b4-b84e-4ec9-98d8-90f27a42d043@github.com>
References: <FddiPGh35d9FmxlDMKD5Q-jar7KUNnRDCsF0HKc-RrM=.cbad68b4-b84e-4ec9-98d8-90f27a42d043@github.com>
Message-ID: <nd_fk8AESiuxHhK7T5lhKQ7gOaGNy7WZqEcOaJmbaFM=.328aa8e2-fc4d-4b40-829f-4fd79c8aa370@github.com>

On Tue, 4 Feb 2025 12:35:50 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Several JMH tests fails "cannot access class jdk.internal.vm.ContinuationScope (in module java.base) because module java.base does not export jdk.internal.vm to unnamed module". This PR add VM option `--add-exports=java.base/jdk.internal.vm=ALL-UNNAMED` to fix the JMH test bug.
> 
> Change has been verified locally, test-fix only, no risk.

These are left over from early development, need to decide if they should be removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23437#issuecomment-2633939977

From alanb at openjdk.org  Tue Feb  4 13:39:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Feb 2025 13:39:14 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <LmtPYlKPNV3CPRskziXNOotqOzQSuugz1KgkSYZkBx0=.9c87d177-b3e5-4bc4-8ce2-133ecd47dc9b@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

src/hotspot/share/oops/arrayKlass.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 1997, 2025, Oracle and/or its affiliates. All rights reserved.

arrayKlass.hpp isn't changed, is this left over from a previous iteration?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1941185550

From swen at openjdk.org  Tue Feb  4 13:39:28 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 13:39:28 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v11]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <pZyjbkMKNfkml8IbnMEy5oF3rwOnKHGG6J99sUA6PUw=.33c09e07-3d3a-4b8f-8e59-e568a01dda66@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  more use getInt & add more test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/5fb9dc52..e785189b

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

  Stats: 269 lines in 2 files changed: 242 ins; 8 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

PR: https://git.openjdk.org/jdk/pull/23384

From swen at openjdk.org  Tue Feb  4 13:46:11 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 13:46:11 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v4]
In-Reply-To: <rGk1dYrHMZ-c-JLgCrWlB7F4j_hySZ9OVSx7EaCXmLs=.5c4a29ed-ead2-4d45-bce3-350428b3e853@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
 <rGk1dYrHMZ-c-JLgCrWlB7F4j_hySZ9OVSx7EaCXmLs=.5c4a29ed-ead2-4d45-bce3-350428b3e853@github.com>
Message-ID: <9gIzKBJ0bPH1rA0YKMAsPJo40ZbW3Dj5vMFbRmlvL60=.43282ac0-27b2-40f2-832a-3e808ce929be@github.com>

On Tue, 4 Feb 2025 00:59:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The following code can reproduce the problem, writing out of bounds causes JVM Crash
>> 
>> 
>>    StringBuilder buf = new StringBuilder();
>>     buf.append('?');
>> 
>>     final CountDownLatch latch = new CountDownLatch(10);
>>     Runnable r = () -> {
>>         for (int i = 0; i < 10000; i++) {
>>             buf.setLength(0);
>>             buf.trimToSize();
>>             buf.append(123456789);
>>         }
>>         latch.countDown();
>>     };
>>     Thread[] threads = new Thread[10];
>>     for (int i = 0; i < threads.length; i++) {
>>         threads[i] = new Thread(r);
>>     }
>>     for (Thread t : threads) {
>>         t.start();
>>     }
>>     latch.await();
>> }
>> 
>> 
>> This problem can be avoided by using the value of ensureCapacityInternal directly.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip coder change

> ```java
>  StringBuilder buf = new StringBuilder();
>     buf.append('?');
> 
>     final CountDownLatch latch = new CountDownLatch(10);
>     Runnable r = () -> {
>         for (int i = 0; i < 10000; i++) {
>             buf.setLength(0);
>             buf.trimToSize();
>             buf.append(123456789);
>         }
>         latch.countDown();
>     };
>     Thread[] threads = new Thread[10];
>     for (int i = 0; i < threads.length; i++) {
>         threads[i] = new Thread(r);
>     }
>     for (Thread t : threads) {
>         t.start();
>     }
>     latch.await();
> ```

Will cause the JVM to exit directly, the error message is as follows

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0x0000000103b9d23c, pid=23348, tid=33539
#
# JRE version: OpenJDK Runtime Environment (25.0) (build 25-internal-adhoc.wenshao.jdkx)
# Java VM: OpenJDK 64-Bit Server VM (25-internal-adhoc.wenshao.jdkx, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# [thread 41731 also had an error]
V  [libjvm.dylib+0x41523c]  G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oopDesc*, markWord)+0x64
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
[thread 39683 also had an error]
# An error report file with more information is saved as:
# /Users/wenshao/Work/git/jdk_mico_bench/hs_err_pid23348.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

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

PR Comment: https://git.openjdk.org/jdk/pull/23427#issuecomment-2634006503

From alanb at openjdk.org  Tue Feb  4 14:00:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Feb 2025 14:00:13 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <Dfl0TA0afI1TwGuimErvPiKq5aj1ZoKAtRR2D3h1RKU=.9026a36e-34cf-4081-852c-da921d0de1e2@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

Good cleanup.

src/java.base/share/classes/java/lang/Class.java line 244:

> 242:         classLoader = loader;
> 243:         componentType = arrayComponentType;
> 244:         modifiers = dummyModifiers;

I realize this ctor isn't used but "dummyModifiers" looks very strange as parameter name when compared to the others, renaming it to something like "mods" would make it less confusing for anyone reading through this code.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2592938860
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1941220263

From swen at openjdk.org  Tue Feb  4 14:03:24 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 14:03:24 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v5]
In-Reply-To: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
Message-ID: <yg8rPVL_VWh4FuTN9xITcNZs18tJZVP087mQoFTaoek=.fe31a968-c0f2-4ebd-ac7f-822529ef310a@github.com>

> The following code can reproduce the problem, writing out of bounds causes JVM Crash
> 
> 
>          StringBuilder buf = new StringBuilder();
>         buf.append('?');
> 
>         Thread[] threads = new Thread[40];
>         final CountDownLatch latch = new CountDownLatch(threads.length);
>         Runnable r = () -> {
>             for (int i = 0; i < 1000000; i++) {
>                 buf.setLength(0);
>                 buf.trimToSize();
>                 buf.append(123456789123456789L);
>             }
>             latch.countDown();
>         };
> 
>         for (int i = 0; i < threads.length; i++) {
>             threads[i] = new Thread(r);
>         }
>         for (Thread t : threads) {
>             t.start();
>         }
>         latch.await();
> 
> 
> This problem can be avoided by using the value of ensureCapacityInternal directly.

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

  improved coder thread safe

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23427/files
  - new: https://git.openjdk.org/jdk/pull/23427/files/1c22ab43..955e8538

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

  Stats: 20 lines in 1 file changed: 14 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23427.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23427/head:pull/23427

PR: https://git.openjdk.org/jdk/pull/23427

From stuefe at openjdk.org  Tue Feb  4 14:03:24 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 4 Feb 2025 14:03:24 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v4]
In-Reply-To: <9gIzKBJ0bPH1rA0YKMAsPJo40ZbW3Dj5vMFbRmlvL60=.43282ac0-27b2-40f2-832a-3e808ce929be@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
 <rGk1dYrHMZ-c-JLgCrWlB7F4j_hySZ9OVSx7EaCXmLs=.5c4a29ed-ead2-4d45-bce3-350428b3e853@github.com>
 <9gIzKBJ0bPH1rA0YKMAsPJo40ZbW3Dj5vMFbRmlvL60=.43282ac0-27b2-40f2-832a-3e808ce929be@github.com>
Message-ID: <Cx3apacLJGTxXU4ByNxLt_D72DplFa3dy6Hc3-930B8=.c34d7f4a-d29b-4f27-95e0-d5f8fe544799@github.com>

On Tue, 4 Feb 2025 13:43:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   skip coder change
>
>> ```java
>>  StringBuilder buf = new StringBuilder();
>>     buf.append('?');
>> 
>>     final CountDownLatch latch = new CountDownLatch(10);
>>     Runnable r = () -> {
>>         for (int i = 0; i < 10000; i++) {
>>             buf.setLength(0);
>>             buf.trimToSize();
>>             buf.append(123456789);
>>         }
>>         latch.countDown();
>>     };
>>     Thread[] threads = new Thread[10];
>>     for (int i = 0; i < threads.length; i++) {
>>         threads[i] = new Thread(r);
>>     }
>>     for (Thread t : threads) {
>>         t.start();
>>     }
>>     latch.await();
>> ```
> 
> Will cause the JVM to exit directly, the error message is as follows
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0xa) at pc=0x0000000103b9d23c, pid=23348, tid=33539
> #
> # JRE version: OpenJDK Runtime Environment (25.0) (build 25-internal-adhoc.wenshao.jdkx)
> # Java VM: OpenJDK 64-Bit Server VM (25-internal-adhoc.wenshao.jdkx, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
> # Problematic frame:
> # [thread 41731 also had an error]
> V  [libjvm.dylib+0x41523c]  G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oopDesc*, markWord)+0x64
> #
> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> [thread 39683 also had an error]
> # An error report file with more information is saved as:
> # /Users/wenshao/Work/git/jdk_mico_bench/hs_err_pid23348.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #

@wenshao Thank you. This seems to be a GC problem. I adjusted the JBS issue accordingly. You set this to "24" as affected version, but if this is a mainline issue, please add 25 and if possible all other versions this occurs in. If possible, please attach an hs-err file or at least the crash stack.

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

PR Comment: https://git.openjdk.org/jdk/pull/23427#issuecomment-2634056307

From swen at openjdk.org  Tue Feb  4 14:03:24 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 14:03:24 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v5]
In-Reply-To: <1S9GR7ljIJeddX-ITkVxrOePFgZ81NeN0cUDwrkCBSw=.9c38eb8b-417f-4f99-8b58-4de8d9ccf717@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
 <iO-RM60r0aP07jqp9eb_e0ZwmcPsuInrGCJONECwmCc=.bdc6cc86-4e02-4411-b37c-142dc3e08bc5@github.com>
 <1S9GR7ljIJeddX-ITkVxrOePFgZ81NeN0cUDwrkCBSw=.9c38eb8b-417f-4f99-8b58-4de8d9ccf717@github.com>
Message-ID: <44iMoML_FB7M3yUGpMb9TUdX2Z8aR5bx3Nt-E1ATDIw=.68ce639d-c87f-46cf-8aa4-c44bd4bf2311@github.com>

On Tue, 4 Feb 2025 06:37:48 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 845:
>> 
>>> 843:         int spaceNeeded = count + DecimalDigits.stringSize(i);
>>> 844:         byte[] value = ensureCapacityInternal(spaceNeeded);
>>> 845:         if (isLatin1()) {
>> 
>> This is not safe. The ensureCapacityInternal can read coder == LATIN1 and allocate a small array, but this `isLatin1` can read coder == UTF16 and write a UTF16 number out of bounds.
>
> A check that `spaceNeeded <= (value.length >> 1)`  in the `else` branch would be needed and might be a sufficient safeguard here.

I made further improvements to improve the thread safety of the coder by passing the newCapacity method into the coder. I think this should be safe enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23427#discussion_r1941221475

From alanb at openjdk.org  Tue Feb  4 14:09:16 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Feb 2025 14:09:16 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]
In-Reply-To: <MvwTuFPKF_B6HWF6_L5yI06NvxTfLDKWoRufYKEU_8w=.a313ab4e-1ff8-4a03-a768-f43e8c38f993@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <SOWXVHkeYjR8PkoJydN2M9rD5R6_yB464izVGrjBcEo=.c3cbd9b0-0a45-4fdb-bc71-ce348f73af86@github.com>
 <MvwTuFPKF_B6HWF6_L5yI06NvxTfLDKWoRufYKEU_8w=.a313ab4e-1ff8-4a03-a768-f43e8c38f993@github.com>
Message-ID: <CxQeGbgbFQvte2g8TyIzgI6laS-EbiVpLiYBuPEG4fk=.d24c8dc3-7742-4dee-b13e-353c6a2d8a2d@github.com>

On Fri, 31 Jan 2025 17:16:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 2150:
>> 
>>> 2148:             }
>>> 2149: 
>>> 2150:             public ProtectionDomain protectionDomain(Class<?> c) {
>> 
>> This accessor has become pointless since the functinoal removal of SM, but it would be out of scope for this PR.
>
> Thanks for looking at this.  I didn't want to change this with this change.

There may need to be some follow-on cleanup, e.g. I'm wondering if Lookup.cachedProtectionDomain is needed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1941241449

From pminborg at openjdk.org  Tue Feb  4 14:13:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 4 Feb 2025 14:13:15 GMT
Subject: Integrated: 8349343: Add missing copyright messages in FFM benchmarks
In-Reply-To: <S-fqV46X_L0Tyduj9EM1End-JFKLGCV5azp92B5toI4=.b6c0e5f4-7958-439b-aad1-72fed8874ef5@github.com>
References: <S-fqV46X_L0Tyduj9EM1End-JFKLGCV5azp92B5toI4=.b6c0e5f4-7958-439b-aad1-72fed8874ef5@github.com>
Message-ID: <WmuniqKmIE8nEuaOJubIfNgco7qaelJlOhC42_aYiIs=.dee18cce-f47c-475f-94f6-eec1de223be1@github.com>

On Tue, 4 Feb 2025 09:40:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add missing copyright headers to some FFM benchmarks.

This pull request has now been integrated.

Changeset: beb43e26
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/beb43e2633900bb9ab3c975376fe5860b6d054e0
Stats:     184 lines in 8 files changed: 184 ins; 0 del; 0 mod

8349343: Add missing copyright messages in FFM benchmarks

Reviewed-by: jvernee

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

PR: https://git.openjdk.org/jdk/pull/23433

From swen at openjdk.org  Tue Feb  4 14:17:12 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 14:17:12 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v4]
In-Reply-To: <9gIzKBJ0bPH1rA0YKMAsPJo40ZbW3Dj5vMFbRmlvL60=.43282ac0-27b2-40f2-832a-3e808ce929be@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
 <rGk1dYrHMZ-c-JLgCrWlB7F4j_hySZ9OVSx7EaCXmLs=.5c4a29ed-ead2-4d45-bce3-350428b3e853@github.com>
 <9gIzKBJ0bPH1rA0YKMAsPJo40ZbW3Dj5vMFbRmlvL60=.43282ac0-27b2-40f2-832a-3e808ce929be@github.com>
Message-ID: <p_Lkp4W1pTF_pmg5FdNatpKE0HMXLHcbD_-tVBgz4xw=.7e578b65-5481-4ea7-8bc6-312a6c25e12e@github.com>

On Tue, 4 Feb 2025 13:43:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   skip coder change
>
> [hs_err_pid23348.log](https://github.com/user-attachments/files/18658266/hs_err_pid23348.log)
>> ```java
>>  StringBuilder buf = new StringBuilder();
>>     buf.append('?');
>> 
>>     final CountDownLatch latch = new CountDownLatch(10);
>>     Runnable r = () -> {
>>         for (int i = 0; i < 10000; i++) {
>>             buf.setLength(0);
>>             buf.trimToSize();
>>             buf.append(123456789);
>>         }
>>         latch.countDown();
>>     };
>>     Thread[] threads = new Thread[10];
>>     for (int i = 0; i < threads.length; i++) {
>>         threads[i] = new Thread(r);
>>     }
>>     for (Thread t : threads) {
>>         t.start();
>>     }
>>     latch.await();
>> ```
> 
> Will cause the JVM to exit directly, the error message is as follows
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0xa) at pc=0x0000000103b9d23c, pid=23348, tid=33539
> #
> # JRE version: OpenJDK Runtime Environment (25.0) (build 25-internal-adhoc.wenshao.jdkx)
> # Java VM: OpenJDK 64-Bit Server VM (25-internal-adhoc.wenshao.jdkx, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
> # Problematic frame:
> # [thread 41731 also had an error]
> V  [libjvm.dylib+0x41523c]  G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oopDesc*, markWord)+0x64
> #
> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> [thread 39683 also had an error]
> # An error report file with more information is saved as:
> # /Users/wenshao/Work/git/jdk_mico_bench/hs_err_pid23348.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #

> @wenshao Thank you. This seems to be a GC problem. I adjusted the JBS issue accordingly. You set this to "24" as affected version, but if this is a mainline issue, please add 25 and if possible all other versions this occurs in. If possible, please attach an hs-err file or at least the crash stack.


I added the hs-err file in the reply above. This is not a GC problem. The getChars method uses StringUTF16.putChar, which is equivalent to Unsafe.putChar. There is no out-of-bounds check. When concurrent, out-of-bounds writes will occur, causing JVM Crash.

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

PR Comment: https://git.openjdk.org/jdk/pull/23427#issuecomment-2634092952

From dfuchs at openjdk.org  Tue Feb  4 14:20:10 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Feb 2025 14:20:10 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v5]
In-Reply-To: <_qLvq4ASmA4CnxrCk6DCmHsfbmpI1EZtJcXD5lNdz50=.cc678be8-ab5f-41f7-b6d9-c2d50dd73a14@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
 <_qLvq4ASmA4CnxrCk6DCmHsfbmpI1EZtJcXD5lNdz50=.cc678be8-ab5f-41f7-b6d9-c2d50dd73a14@github.com>
Message-ID: <YDaqTXM4fijd4VOQw3G9g3RuBhhUQkWor2qg3DzbFD4=.610b56cd-37b5-4bf4-9709-6e8c1e47f35a@github.com>

On Tue, 4 Feb 2025 12:04:47 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
>> 
>> 
>> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
>> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
>> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
>> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
>> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
>> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
>> 
>> 
>> **Other highlights:**
>> 
>> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
>> - `test.lib.Asserts::assertFileContentsEqual` is added
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace `assert`s with conditionally thrown exceptions

Generally LGTM - still one place calling `assert Files.mismatch(..)...`

test/jdk/com/sun/net/httpserver/SelCacheTest.java line 80:

> 78:             s2 = HttpsServer.create(addr, 0);
> 79:             // Assert that both files share the same parent and can be served from the same `FileServerHandler`
> 80:             assertEquals(smallFilePath.getParent(), largeFilePath.getParent());

That's OK. You could have kept `assert` here as it should not happen and would point to an issue with the logic in the test. But assertEquals will show us both paths if that happens, which is a +.

test/jdk/java/net/httpclient/http2/FixedThreadPoolTest.java line 180:

> 178:                 });
> 179:         response.join();
> 180:         assert Files.mismatch(src, dest) < 0;

Missed call to `assertFileContentsEqual`?

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

PR Review: https://git.openjdk.org/jdk/pull/23401#pullrequestreview-2592973383
PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941241819
PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941256241

From vyazici at openjdk.org  Tue Feb  4 14:26:23 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Feb 2025 14:26:23 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v6]
In-Reply-To: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
Message-ID: <MEaVh56gQqp2517Z7lF9JHRj45sEbNSfqq1vt-brOYU=.145a5b62-0e0a-437f-a21f-87ad700e860f@github.com>

> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
> 
> 
> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
> 
> 
> **Other highlights:**
> 
> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
> - `test.lib.Asserts::assertFileContentsEqual` is added

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

  Add missing `assertFileContentsEqual` replacement to `FixedThreadPoolTest`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23401/files
  - new: https://git.openjdk.org/jdk/pull/23401/files/9c7c6af0..5e9b30f4

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

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

PR: https://git.openjdk.org/jdk/pull/23401

From vyazici at openjdk.org  Tue Feb  4 14:26:24 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Feb 2025 14:26:24 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v5]
In-Reply-To: <YDaqTXM4fijd4VOQw3G9g3RuBhhUQkWor2qg3DzbFD4=.610b56cd-37b5-4bf4-9709-6e8c1e47f35a@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
 <_qLvq4ASmA4CnxrCk6DCmHsfbmpI1EZtJcXD5lNdz50=.cc678be8-ab5f-41f7-b6d9-c2d50dd73a14@github.com>
 <YDaqTXM4fijd4VOQw3G9g3RuBhhUQkWor2qg3DzbFD4=.610b56cd-37b5-4bf4-9709-6e8c1e47f35a@github.com>
Message-ID: <o434D6SkKnmdG2ta9pDF9ZkZyf2TXzLpsC0bRslxQqI=.fd0c3ae7-7599-4b32-96d7-552c3e2de0ea@github.com>

On Tue, 4 Feb 2025 14:15:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace `assert`s with conditionally thrown exceptions
>
> test/jdk/java/net/httpclient/http2/FixedThreadPoolTest.java line 180:
> 
>> 178:                 });
>> 179:         response.join();
>> 180:         assert Files.mismatch(src, dest) < 0;
> 
> Missed call to `assertFileContentsEqual`?

Doh! :facepalm: Fixed in 5e9b30f431676c714cf81b85846f16c58c0dcdf6.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941272158

From vyazici at openjdk.org  Tue Feb  4 14:29:13 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Feb 2025 14:29:13 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v4]
In-Reply-To: <StCYP496VXkElEXgFW7Eenk_8T8fM30pcuE168QNEcc=.de9d50ec-14b0-41cc-9d0a-19e528fce1c8@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
 <Wqz8Z4jFOpcSZLMelLBKVwiZdWX33-QWtp5jiGF-AF8=.911e5e47-075d-45a8-ab5d-17e17871552e@github.com>
 <StCYP496VXkElEXgFW7Eenk_8T8fM30pcuE168QNEcc=.de9d50ec-14b0-41cc-9d0a-19e528fce1c8@github.com>
Message-ID: <joy_47ON8YecQdc-bonFbuu_IExfmTH7VIpRXlDrQ7g=.9bfadf7c-5d77-4973-8786-708a9091b703@github.com>

On Tue, 4 Feb 2025 10:47:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Assert that multiple files can be served using the same `FileServerHandler`
>>  - Remove redundant `@build` dependencies
>
> test/jdk/com/sun/net/httpserver/SelCacheTest.java line 145:
> 
>> 143:         fout.close();
>> 144: 
>> 145:         if (count != filePath.toFile().length()) {
> 
> Maybe we could use assertEquals here for better diagnosability

Fixed in 9c7c6af013e0495b08bcd248e30d83385bcc35b5.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23401#discussion_r1941277359

From coleenp at openjdk.org  Tue Feb  4 14:43:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Feb 2025 14:43:51 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

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

  Fix copyright and param name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22652/files
  - new: https://git.openjdk.org/jdk/pull/22652/files/8854fcc6..ff693418

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

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

PR: https://git.openjdk.org/jdk/pull/22652

From coleenp at openjdk.org  Tue Feb  4 14:43:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Feb 2025 14:43:51 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
Message-ID: <btZ1sRHlMDoKSoiu3JP2F6yQQ5RoyrjtqZ6U3x4SlPU=.24565830-b88c-4dea-9fd3-54ec09b5b1eb@github.com>

On Tue, 4 Feb 2025 14:40:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright and param name

Thank you for your comments, Alan.

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

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2593075666

From coleenp at openjdk.org  Tue Feb  4 14:43:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Feb 2025 14:43:51 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <LmtPYlKPNV3CPRskziXNOotqOzQSuugz1KgkSYZkBx0=.9c87d177-b3e5-4bc4-8ce2-133ecd47dc9b@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <LmtPYlKPNV3CPRskziXNOotqOzQSuugz1KgkSYZkBx0=.9c87d177-b3e5-4bc4-8ce2-133ecd47dc9b@github.com>
Message-ID: <JckEJXVxVdnyG0Y0fxLjskXIpeCZlGgxyxklrGA9tqE=.81e6ea77-c462-4b65-9b2c-6fd18d29f471@github.com>

On Tue, 4 Feb 2025 13:36:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright and param name
>
> src/hotspot/share/oops/arrayKlass.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 1997, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> arrayKlass.hpp isn't changed, is this left over from a previous iteration?

yes, it was something that my copyright script thought I changed from merging some previous changes.

> src/java.base/share/classes/java/lang/Class.java line 244:
> 
>> 242:         classLoader = loader;
>> 243:         componentType = arrayComponentType;
>> 244:         modifiers = dummyModifiers;
> 
> I realize this ctor isn't used but "dummyModifiers" looks very strange as parameter name when compared to the others, renaming it to something like "mods" would make it less confusing for anyone reading through this code.

I changed it to mods.  Thanks for the suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1941301152
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1941302820

From coleenp at openjdk.org  Tue Feb  4 15:02:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Feb 2025 15:02:11 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]
In-Reply-To: <CxQeGbgbFQvte2g8TyIzgI6laS-EbiVpLiYBuPEG4fk=.d24c8dc3-7742-4dee-b13e-353c6a2d8a2d@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <SOWXVHkeYjR8PkoJydN2M9rD5R6_yB464izVGrjBcEo=.c3cbd9b0-0a45-4fdb-bc71-ce348f73af86@github.com>
 <MvwTuFPKF_B6HWF6_L5yI06NvxTfLDKWoRufYKEU_8w=.a313ab4e-1ff8-4a03-a768-f43e8c38f993@github.com>
 <CxQeGbgbFQvte2g8TyIzgI6laS-EbiVpLiYBuPEG4fk=.d24c8dc3-7742-4dee-b13e-353c6a2d8a2d@github.com>
Message-ID: <HjRm9YSBznG8WiaMkb6CwaCD1uZWzCYjHIHpQvLYMLI=.04c0edb6-196e-402a-a864-91deb4d69bd3@github.com>

On Tue, 4 Feb 2025 14:06:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks for looking at this.  I didn't want to change this with this change.
>
> There may need to be some follow-on cleanup, e.g. I'm wondering if Lookup.cachedProtectionDomain is needed now.

One of the reasons I wanted to move this out of Hotspot as a native call is that it might make further work with ProtectionDomain easier to do all in Java, except there's still a bit of coupling in the JVM with the name of the class and that it's passed through defineClass (resolve_from_stream) and initialized in the mirror.  So I guess that's still a lot.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1941345990

From rriggs at openjdk.org  Tue Feb  4 15:06:18 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Feb 2025 15:06:18 GMT
Subject: [jdk24] RFR: 8349183: [BACKOUT] Optimization for StringBuilder
 append boolean & null
In-Reply-To: <uytjFeusf-_7CVTw67jW9wPi3m8gV2B1e35y_AhYqCo=.9418d4aa-69aa-48f5-af02-f46d339aefdf@github.com>
References: <uytjFeusf-_7CVTw67jW9wPi3m8gV2B1e35y_AhYqCo=.9418d4aa-69aa-48f5-af02-f46d339aefdf@github.com>
Message-ID: <PMEdYCD-1u-C2FoIhfuHfpumZId28V9rM3vv3FL_FWQ=.370533e1-6940-42af-a818-dc9e9286f98b@github.com>

On Mon, 3 Feb 2025 18:41:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this backport of https://github.com/openjdk/jdk/pull/23420 into jdk24?
> 
> This proposes to bring in those same backouts into `jdk24` to prevent the issue noted in that PR description. jdk24 is in rampdown and this backport will require an approval. A approval request has been raised in https://bugs.openjdk.org/browse/JDK-8349183?focusedId=14746841&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14746841.
> 
> This backport into jdk24 wasn't clean due to a trivial merge conflict in `StringLatin1.java` file. That merge conflict was manually resolved (just like it was done against mainline). The git commands used to create this backport against jdk24 branch are:
> 
> 
> <checkout fresh jdk24 branch>
> git cherry-pick --no-commit 618c5eb27b4c719afd577b690e6bcb21a45fcb0d
> <resolve merge conflict in StringLatin1.java>
> git commit -m 'Backport 618c5eb27b4c719afd577b690e6bcb21a45fcb0d'
> 
> 
> tier1, tier2 and tier3 testing is currently in progress with this change.

Looks good, thanks. A second reviewer might be useful.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23425#pullrequestreview-2593158723

From fabian at buildbuddy.io  Tue Feb  4 16:36:26 2025
From: fabian at buildbuddy.io (Fabian Meumertzheim)
Date: Tue, 4 Feb 2025 17:36:26 +0100
Subject: Adopting SequencedCollection via multi-release jars?
Message-ID: <CAHY-eHs9Vt-68sT1TfC9LBAkyveKwtM9O9O7LPNi57VV0V3OpQ@mail.gmail.com>

Guava provides immutable collections such as ImmutableList that are
naturally sequenced. It would be useful to integrate it with Java 21's
SequencedCollection interface. However, Guava needs to keep supporting
Java 11 for the foreseeable future.

An idea that may allow Guava to remain compatible but still adopt
SequencedCollection today would be to have classes implement a
vendored and renamed version of the SequencedCollection interface and
"override" it with an interface that extends the actual
SequencedCollection interface in the 21 subdirectory of a
multi-release JAR. However, the JAR specification states that:

"The public API exported by the classes in a multi-release JAR file
must be exactly the same across versions, ..."

Would the public API be considered to be identical in the case where
only the hierarchy of implemented interfaces changes? If not, is there
another supported way for a class to start implementing
SequencedCollection while remaining compatible with JDK versions that
don't provide the interface yet?

Best,
Fabian

From dfuchs at openjdk.org  Tue Feb  4 16:38:14 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Feb 2025 16:38:14 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v6]
In-Reply-To: <MEaVh56gQqp2517Z7lF9JHRj45sEbNSfqq1vt-brOYU=.145a5b62-0e0a-437f-a21f-87ad700e860f@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
 <MEaVh56gQqp2517Z7lF9JHRj45sEbNSfqq1vt-brOYU=.145a5b62-0e0a-437f-a21f-87ad700e860f@github.com>
Message-ID: <MWZO4JBd2RFg_f3Uaj1vHE_sdhp5B5KOVoU7pEPlRGw=.4c5e1ce6-c2ca-463f-969b-0a2bfdd9be6f@github.com>

On Tue, 4 Feb 2025 14:26:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
>> 
>> 
>> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
>> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
>> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
>> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
>> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
>> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
>> 
>> 
>> **Other highlights:**
>> 
>> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
>> - `test.lib.Asserts::assertFileContentsEqual` is added
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing `assertFileContentsEqual` replacement to `FixedThreadPoolTest`

Approving subject to tier2 still passing and tests keeping stable.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23401#pullrequestreview-2593438203

From alanb at openjdk.org  Tue Feb  4 16:40:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Feb 2025 16:40:10 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]
In-Reply-To: <HjRm9YSBznG8WiaMkb6CwaCD1uZWzCYjHIHpQvLYMLI=.04c0edb6-196e-402a-a864-91deb4d69bd3@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <SOWXVHkeYjR8PkoJydN2M9rD5R6_yB464izVGrjBcEo=.c3cbd9b0-0a45-4fdb-bc71-ce348f73af86@github.com>
 <MvwTuFPKF_B6HWF6_L5yI06NvxTfLDKWoRufYKEU_8w=.a313ab4e-1ff8-4a03-a768-f43e8c38f993@github.com>
 <CxQeGbgbFQvte2g8TyIzgI6laS-EbiVpLiYBuPEG4fk=.d24c8dc3-7742-4dee-b13e-353c6a2d8a2d@github.com>
 <HjRm9YSBznG8WiaMkb6CwaCD1uZWzCYjHIHpQvLYMLI=.04c0edb6-196e-402a-a864-91deb4d69bd3@github.com>
Message-ID: <LFWlDa9-UElLC3ANqbToOlHoaZBdDkitpzeAAQ1h61g=.944a60c7-f7d1-47ab-94af-d69d4cdc82fa@github.com>

On Tue, 4 Feb 2025 14:59:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There may need to be some follow-on cleanup, e.g. I'm wondering if Lookup.cachedProtectionDomain is needed now.
>
> One of the reasons I wanted to move this out of Hotspot as a native call is that it might make further work with ProtectionDomain easier to do all in Java, except there's still a bit of coupling in the JVM with the name of the class and that it's passed through defineClass (resolve_from_stream) and initialized in the mirror.  So I guess that's still a lot.

Aside from JVMTI (CFLH for example), is there anything left in the VM that needs this? The last param to JVM_DefineClassWithSource has the location from the code source if available.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1941523958

From coleenp at openjdk.org  Tue Feb  4 16:59:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Feb 2025 16:59:10 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]
In-Reply-To: <LFWlDa9-UElLC3ANqbToOlHoaZBdDkitpzeAAQ1h61g=.944a60c7-f7d1-47ab-94af-d69d4cdc82fa@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <SOWXVHkeYjR8PkoJydN2M9rD5R6_yB464izVGrjBcEo=.c3cbd9b0-0a45-4fdb-bc71-ce348f73af86@github.com>
 <MvwTuFPKF_B6HWF6_L5yI06NvxTfLDKWoRufYKEU_8w=.a313ab4e-1ff8-4a03-a768-f43e8c38f993@github.com>
 <CxQeGbgbFQvte2g8TyIzgI6laS-EbiVpLiYBuPEG4fk=.d24c8dc3-7742-4dee-b13e-353c6a2d8a2d@github.com>
 <HjRm9YSBznG8WiaMkb6CwaCD1uZWzCYjHIHpQvLYMLI=.04c0edb6-196e-402a-a864-91deb4d69bd3@github.com>
 <LFWlDa9-UElLC3ANqbToOlHoaZBdDkitpzeAAQ1h61g=.944a60c7-f7d1-47ab-94af-d69d4cdc82fa@github.com>
Message-ID: <AJfrwbufV-R4ZyyH3aGupcDPvgjSsWwH5kE3za4o8y0=.4a05c30f-9b26-4aee-8ff1-563f778f6ec9@github.com>

On Tue, 4 Feb 2025 16:37:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> One of the reasons I wanted to move this out of Hotspot as a native call is that it might make further work with ProtectionDomain easier to do all in Java, except there's still a bit of coupling in the JVM with the name of the class and that it's passed through defineClass (resolve_from_stream) and initialized in the mirror.  So I guess that's still a lot.
>
> Aside from JVMTI (CFLH for example), is there anything left in the VM that needs this? The last param to JVM_DefineClassWithSource has the location from the code source if available.

The VM doesn't need this but it carries it around because it's a parameter to JVM_DefineClass and DefineClassWithSource (second to last parameter).  CFLH and CDS from what I can tell have it for the same purpose - ultimately to assign it into the mirror.
There are some remaining code in the compilers (ci).  Not sure if they are needed without studying it more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1941554835

From jlu at openjdk.org  Tue Feb  4 17:10:26 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Feb 2025 17:10:26 GMT
Subject: Integrated: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String)
In-Reply-To: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
Message-ID: <1SUczs6H4opt4d_-G8-xA6rrtWPx6EjXRG_V681PseI=.87f65cc9-4754-4b31-9465-801aa2a580fe@github.com>

On Thu, 30 Jan 2025 19:27:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`.
> 
> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise.

This pull request has now been integrated.

Changeset: 250ff86d
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/250ff86dc86f73dbf7c944d9b5a792c4bdfeef0d
Stats:     14 lines in 1 file changed: 2 ins; 3 del; 9 mod

8349000: Performance improvement for Currency.isPastCutoverDate(String)

Reviewed-by: naoto, aturbanov

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

PR: https://git.openjdk.org/jdk/pull/23374

From jlu at openjdk.org  Tue Feb  4 17:10:26 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Feb 2025 17:10:26 GMT
Subject: RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v3]
In-Reply-To: <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
 <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>
Message-ID: <gyivtJhehehJkd6wUwrM-jQe4n91RA8vY_OLIuwHXH8=.76018146-3c51-468e-80bc-cf6e8cbc243f@github.com>

On Mon, 3 Feb 2025 19:01:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`.
>> 
>> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23374#issuecomment-2634568025

From liach at openjdk.org  Tue Feb  4 17:35:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Feb 2025 17:35:18 GMT
Subject: [jdk24] RFR: 8349183: [BACKOUT] Optimization for StringBuilder
 append boolean & null
In-Reply-To: <uytjFeusf-_7CVTw67jW9wPi3m8gV2B1e35y_AhYqCo=.9418d4aa-69aa-48f5-af02-f46d339aefdf@github.com>
References: <uytjFeusf-_7CVTw67jW9wPi3m8gV2B1e35y_AhYqCo=.9418d4aa-69aa-48f5-af02-f46d339aefdf@github.com>
Message-ID: <4rawtnCH36CRxVore9tgTbpYYRiEcLo6R49z1bBpJGQ=.bbe418af-c9f0-4287-aa98-794a54572410@github.com>

On Mon, 3 Feb 2025 18:41:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this backport of https://github.com/openjdk/jdk/pull/23420 into jdk24?
> 
> This proposes to bring in those same backouts into `jdk24` to prevent the issue noted in that PR description. jdk24 is in rampdown and this backport will require an approval. A approval request has been raised in https://bugs.openjdk.org/browse/JDK-8349183?focusedId=14746841&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14746841.
> 
> This backport into jdk24 wasn't clean due to a trivial merge conflict in `StringLatin1.java` file. That merge conflict was manually resolved (just like it was done against mainline). The git commands used to create this backport against jdk24 branch are:
> 
> 
> <checkout fresh jdk24 branch>
> git cherry-pick --no-commit 618c5eb27b4c719afd577b690e6bcb21a45fcb0d
> <resolve merge conflict in StringLatin1.java>
> git commit -m 'Backport 618c5eb27b4c719afd577b690e6bcb21a45fcb0d'
> 
> 
> tier1, tier2 and tier3 testing is currently in progress with this change.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23425#pullrequestreview-2593574823

From liach at openjdk.org  Tue Feb  4 17:48:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Feb 2025 17:48:13 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v5]
In-Reply-To: <yg8rPVL_VWh4FuTN9xITcNZs18tJZVP087mQoFTaoek=.fe31a968-c0f2-4ebd-ac7f-822529ef310a@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
 <yg8rPVL_VWh4FuTN9xITcNZs18tJZVP087mQoFTaoek=.fe31a968-c0f2-4ebd-ac7f-822529ef310a@github.com>
Message-ID: <WI5hYlQUUv6PnIUgQjQ-HlowaORSmbSSoe6U8xrZ6d8=.f0129643-76f1-4a4b-bb11-c3031aea396a@github.com>

On Tue, 4 Feb 2025 14:03:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The following code can reproduce the problem, writing out of bounds causes JVM Crash
>> 
>> 
>>          StringBuilder buf = new StringBuilder();
>>         buf.append('?');
>> 
>>         Thread[] threads = new Thread[40];
>>         final CountDownLatch latch = new CountDownLatch(threads.length);
>>         Runnable r = () -> {
>>             for (int i = 0; i < 1000000; i++) {
>>                 buf.setLength(0);
>>                 buf.trimToSize();
>>                 buf.append(123456789123456789L);
>>             }
>>             latch.countDown();
>>         };
>> 
>>         for (int i = 0; i < threads.length; i++) {
>>             threads[i] = new Thread(r);
>>         }
>>         for (Thread t : threads) {
>>             t.start();
>>         }
>>         latch.await();
>> 
>> 
>> This problem can be avoided by using the value of ensureCapacityInternal directly.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improved coder thread safe

On a second examination, I find this is caused by #22023, which is not in 24. And I cannot replicate the oob write on 24. I have updated the affected version to 25 as a result, and updated the caused-by link in the JBS issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/23427#issuecomment-2634659498

From naoto at openjdk.org  Tue Feb  4 18:00:32 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Feb 2025 18:00:32 GMT
Subject: RFR: 8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark
 fails [v2]
In-Reply-To: <GZedlVAX83lkQmbZj5hXc0-FAH0vXyMTfSaU5rg_tt4=.12301d1b-f5ee-4e78-ab96-c833a5ee1a24@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
 <GZedlVAX83lkQmbZj5hXc0-FAH0vXyMTfSaU5rg_tt4=.12301d1b-f5ee-4e78-ab96-c833a5ee1a24@github.com>
Message-ID: <-w3oDImLp6wG2SQgcxbktW3_nwPCJQx_C96SSu02bNY=.87a7bd37-54d8-4edd-b827-794ba9ea4b43@github.com>

On Tue, 4 Feb 2025 02:40:59 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
>> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
>> 
>> 
>>         TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
>>         System.out.println(tz.getDisplayName());
>>         System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
>>         System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
>> 
>> 
>> - Java 22 output:
>> 
>> 
>> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
>> Ecuador Time
>> ECST
>> ECT
>> 
>> 
>> - Java 23 output:
>> 
>> 
>> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
>> Ecuador Time
>> GMT-04:00
>> GMT-05:00
>> 
>> 
>> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use PST instead of Z

LGTM. Thanks for the update

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23414#pullrequestreview-2593642191

From rriggs at openjdk.org  Tue Feb  4 18:13:18 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Feb 2025 18:13:18 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v5]
In-Reply-To: <yg8rPVL_VWh4FuTN9xITcNZs18tJZVP087mQoFTaoek=.fe31a968-c0f2-4ebd-ac7f-822529ef310a@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
 <yg8rPVL_VWh4FuTN9xITcNZs18tJZVP087mQoFTaoek=.fe31a968-c0f2-4ebd-ac7f-822529ef310a@github.com>
Message-ID: <wy1NjqXRAXBocspJqK31pFBunBN8cnX5V2d1oLRdyec=.3fa077d1-601c-415b-ab22-4fe827e98576@github.com>

On Tue, 4 Feb 2025 14:03:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The following code can reproduce the problem, writing out of bounds causes JVM Crash
>> 
>> 
>>          StringBuilder buf = new StringBuilder();
>>         buf.append('?');
>> 
>>         Thread[] threads = new Thread[40];
>>         final CountDownLatch latch = new CountDownLatch(threads.length);
>>         Runnable r = () -> {
>>             for (int i = 0; i < 1000000; i++) {
>>                 buf.setLength(0);
>>                 buf.trimToSize();
>>                 buf.append(123456789123456789L);
>>             }
>>             latch.countDown();
>>         };
>> 
>>         for (int i = 0; i < threads.length; i++) {
>>             threads[i] = new Thread(r);
>>         }
>>         for (Thread t : threads) {
>>             t.start();
>>         }
>>         latch.await();
>> 
>> 
>> This problem can be avoided by using the value of ensureCapacityInternal directly.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improved coder thread safe

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 253:

> 251:      * If {@code minimumCapacity} is non positive due to numeric
> 252:      * overflow, this method throws {@code OutOfMemoryError}.
> 253:      */

Complete the javadoc with the @param tags and descriptions.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 256:

> 254:     private byte[] ensureCapacityInternal(int minimumCapacity, byte coder) {
> 255:         // overflow-conscious code
> 256:         byte[] value = this.value;

Shadowing `value` is a bug prone, pick a new name.

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 278:

> 276:      *         greater than (Integer.MAX_VALUE >> coder)
> 277:      */
> 278:     private static int newCapacity(int minCapacity, byte[] value, byte coder) {

1.  Only the current length is needed and should be the argument.
2. Add the @param tags for the new arguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23427#discussion_r1941675018
PR Review Comment: https://git.openjdk.org/jdk/pull/23427#discussion_r1941673018
PR Review Comment: https://git.openjdk.org/jdk/pull/23427#discussion_r1941669127

From naoto at openjdk.org  Tue Feb  4 18:16:27 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Feb 2025 18:16:27 GMT
Subject: RFR: 8337279: Optimize format instant [v15]
In-Reply-To: <9ntqc-mXvifLuLvIuP8WVd2fcfz8kx3TSUiwLmHOqjA=.6e455335-2ff3-48ad-9ad4-b71193cf7f3e@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <9ntqc-mXvifLuLvIuP8WVd2fcfz8kx3TSUiwLmHOqjA=.6e455335-2ff3-48ad-9ad4-b71193cf7f3e@github.com>
Message-ID: <-HS2Rx0PAEZEOHmLhuAK20_Joeg6cC4tk9xJ5stImXE=.e0291528-dd80-4201-876c-9a0fe23d007f@github.com>

On Mon, 3 Feb 2025 22:31:10 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @natoj

Looks good. I confirmed the changes passed tier1-3 tests.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20353#pullrequestreview-2593676894

From smarks at openjdk.org  Tue Feb  4 18:29:28 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 4 Feb 2025 18:29:28 GMT
Subject: RFR: 8349107: Remove RMI finalizers [v2]
In-Reply-To: <GBxj64AHg_40TFsAmS7nwWfICjXoTUt13CiAxK72e4Q=.bfbad393-1ca4-4746-9535-4f8e17fed265@github.com>
References: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
 <GBxj64AHg_40TFsAmS7nwWfICjXoTUt13CiAxK72e4Q=.bfbad393-1ca4-4746-9535-4f8e17fed265@github.com>
Message-ID: <1Db2oe41BYak-NDwYvLG3tcSkSY59ZadurujthWVlKU=.45a3a81b-50d5-4a58-9750-847dc2f0188b@github.com>

On Mon, 3 Feb 2025 19:13:10 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> 3 finalizers in RMI code can be removed, as they do not perform meaningful cleanup.
>> 
>> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**
>> 
>> `RegistryContext.finalize()` just calls `close()`. The `close()` method does not perform any cleanup per se, but rather "helps the garbage collector" by setting `environment` and `registry` to `null`.
>> 
>> 
>> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.BindingEnumeration`**
>> 
>> `BindingEnumeration.finalize()` simply calls `close()` on the `ctx` field, itself a `RegistryContext` (and `close()` just "helps the GC.")
>> 
>> 
>> **`src/java.rmi/share/classes/sun/rmi/log/LogInputStream`**
>> 
>> `LogInputStream` tracks its length with an int field, `length`. If `length` ever becomes == 0, `LogInputStream`'s methods will return without doing anything.
>> 
>> The finalizer calls `close()`, which just sets length = 0.
>> 
>> By the time a `LogInputStream` becomes unreachable and is finalized, it's a moot point whether length == 0, as no more methods can be called.
>> If anything, this finalizer could cause a bug. If a `LogInputStream` were to became unreachable while a method were still running, the finalizer could set the length to 0 while method code is still running and expecting a length != 0.
>> It's possible that there is a very long standing bug that `close()` should be calling `in.close()`, in which case this evaluation will need to be revisited.
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into rmF10Nnow
>  - Remove finalizer from RMI LogInputStream
>  - Remove finalizer from RMI RegistryContext.BindingEnumeration
>  - Remove finalizer from RMI RegistryContext

> It's possible that there is a very long standing bug that close() should be calling in.close(), in which case this evaluation will need to be revisited.

I don't think this is an issue. The only user of LogInputStream appears to be in [ReliableLog](https://github.com/openjdk/jdk/blob/bad39b6d8892ba9b86bc81bf01108a1df617defb/src/java.rmi/share/classes/sun/rmi/log/ReliableLog.java#L754), which creates an input stream, wraps it in a LogInputStream one or more times, and then closes the input stream in a finally-block. Thus LogInputStream isn't responsible for closing the input stream.

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

PR Comment: https://git.openjdk.org/jdk/pull/23406#issuecomment-2634747157

From joehw at openjdk.org  Tue Feb  4 18:36:39 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 4 Feb 2025 18:36:39 GMT
Subject: RFR: 8344925: translet-name ignored when package-name is also set
Message-ID: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>

Fix an issue where the translet-name is incorrectly set when the package-name is also specified.

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

Commit messages:
 - update copyright
 - 8344925: translet-name ignored when package-name is also set

Changes: https://git.openjdk.org/jdk/pull/23446/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23446&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344925
  Stats: 174 lines in 4 files changed: 166 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23446.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23446/head:pull/23446

PR: https://git.openjdk.org/jdk/pull/23446

From jvernee at openjdk.org  Tue Feb  4 18:39:23 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Feb 2025 18:39:23 GMT
Subject: RFR: 8349344: Clarify documentation of Arena.ofConfined
In-Reply-To: <uRzbPuT_TqSUM2HsGK9u192RC73lPsKlAtgUxUwcR68=.bc1ae678-0e4b-41fb-a374-fcdd94f92251@github.com>
References: <uRzbPuT_TqSUM2HsGK9u192RC73lPsKlAtgUxUwcR68=.bc1ae678-0e4b-41fb-a374-fcdd94f92251@github.com>
Message-ID: <ApBv4MabAJgDgl7hh8fYT6j9gpgeBTH8UP9dQrrSuRM=.557d9e73-08d7-4cf2-9f1b-d7254881b620@github.com>

On Tue, 4 Feb 2025 09:46:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to clarify the documentation for `Arena.ofConfined()`. It is proposed to say that segments allocated from the returned `Arena` can _only_ be accessed by the thread that created the `Arena` in the first place.

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23435#pullrequestreview-2593736433

From smarks at openjdk.org  Tue Feb  4 19:06:15 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 4 Feb 2025 19:06:15 GMT
Subject: RFR: 8349107: Remove RMI finalizers [v2]
In-Reply-To: <GBxj64AHg_40TFsAmS7nwWfICjXoTUt13CiAxK72e4Q=.bfbad393-1ca4-4746-9535-4f8e17fed265@github.com>
References: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
 <GBxj64AHg_40TFsAmS7nwWfICjXoTUt13CiAxK72e4Q=.bfbad393-1ca4-4746-9535-4f8e17fed265@github.com>
Message-ID: <WgD24bUwquhDo307wW2fq59LHCANIiTmqM17s3CDPrU=.5f620474-b6ce-4481-8b04-85a47fb87dd9@github.com>

On Mon, 3 Feb 2025 19:13:10 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> 3 finalizers in RMI code can be removed, as they do not perform meaningful cleanup.
>> 
>> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**
>> 
>> `RegistryContext.finalize()` just calls `close()`. The `close()` method does not perform any cleanup per se, but rather "helps the garbage collector" by setting `environment` and `registry` to `null`.
>> 
>> 
>> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.BindingEnumeration`**
>> 
>> `BindingEnumeration.finalize()` simply calls `close()` on the `ctx` field, itself a `RegistryContext` (and `close()` just "helps the GC.")
>> 
>> 
>> **`src/java.rmi/share/classes/sun/rmi/log/LogInputStream`**
>> 
>> `LogInputStream` tracks its length with an int field, `length`. If `length` ever becomes == 0, `LogInputStream`'s methods will return without doing anything.
>> 
>> The finalizer calls `close()`, which just sets length = 0.
>> 
>> By the time a `LogInputStream` becomes unreachable and is finalized, it's a moot point whether length == 0, as no more methods can be called.
>> If anything, this finalizer could cause a bug. If a `LogInputStream` were to became unreachable while a method were still running, the finalizer could set the length to 0 while method code is still running and expecting a length != 0.
>> It's possible that there is a very long standing bug that `close()` should be calling `in.close()`, in which case this evaluation will need to be revisited.
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into rmF10Nnow
>  - Remove finalizer from RMI LogInputStream
>  - Remove finalizer from RMI RegistryContext.BindingEnumeration
>  - Remove finalizer from RMI RegistryContext

Marked as reviewed by smarks (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23406#pullrequestreview-2593794098

From epeter at openjdk.org  Tue Feb  4 19:09:35 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 4 Feb 2025 19:09:35 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v17]
In-Reply-To: <sgcWAEvXaWi40uFqPPJq-e6n3YsHb7agKBUrMBdqJSc=.48c41eab-6641-45b7-9765-400622894f4b@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <sgcWAEvXaWi40uFqPPJq-e6n3YsHb7agKBUrMBdqJSc=.48c41eab-6641-45b7-9765-400622894f4b@github.com>
Message-ID: <yXDCPe78DaMicuW5NvRvjnYXbq7VGOpReHXS3DwmXm8=.e570b318-11a6-43fe-89c7-e42f7315dd5a@github.com>

On Tue, 4 Feb 2025 10:05:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing typos

Thanks @jatin-bhateja for all your patience, this really took a while ? 

It looks good to me - again I'm only reviewing the C++ VM changes, so someone else has to review the Java changes.

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2593800414

From epeter at openjdk.org  Tue Feb  4 19:09:36 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 4 Feb 2025 19:09:36 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v16]
In-Reply-To: <cZKkfnS-ra5Pmvto6pG-lfQ7WcpkKsncirRdbDnXRRk=.fc426cac-4fc7-49ca-b0fa-9b983b9246ca@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <EC2coajO2bsqpsjUFgjuf-YXj23ENZeLj2ABtq4Sd74=.1e290b04-fcfc-4aaa-b80d-60cdbb0a529a@github.com>
 <mUgb99AYb-pdBKAx5Jy6TfGAWok7-DJ89A9m80L-yYc=.d51af39b-d84d-4daf-857d-513183b5262e@github.com>
 <cZKkfnS-ra5Pmvto6pG-lfQ7WcpkKsncirRdbDnXRRk=.fc426cac-4fc7-49ca-b0fa-9b983b9246ca@github.com>
Message-ID: <7WobCDj_e4Sw1CEYr3EVfgHTxJoxBfiFR63WwrzDDzs=.27e926d0-23e6-4231-a677-fdfd683083be@github.com>

On Tue, 4 Feb 2025 09:56:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/convertnode.cpp line 971:
>> 
>>> 969:       return true;
>>> 970:     default:
>>> 971:       return false;
>> 
>> Does this cover all cases? What about `FmaHF`?
>
> FmaHF is a ternary operation and is intrinsified.

Ah, right. My bad ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1941748224

From liach at openjdk.org  Tue Feb  4 19:21:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Feb 2025 19:21:44 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v17]
In-Reply-To: <sgcWAEvXaWi40uFqPPJq-e6n3YsHb7agKBUrMBdqJSc=.48c41eab-6641-45b7-9765-400622894f4b@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <sgcWAEvXaWi40uFqPPJq-e6n3YsHb7agKBUrMBdqJSc=.48c41eab-6641-45b7-9765-400622894f4b@github.com>
Message-ID: <7oq7j2pYG9ToDNcGyVWrphH_wFyvPRX2kl3qxgQYBss=.449139d7-e3a8-4587-b5ce-a5f7f9f5b613@github.com>

On Tue, 4 Feb 2025 10:05:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing typos

src/java.base/share/classes/jdk/internal/vm/vector/Float16Math.java line 42:

> 40:     }
> 41: 
> 42:     public interface Float16TernaryMathOp {

Is there a reason we don't write the default impl explicitly in this class, but ask for a lambda for an implementation? Each intrinsified method only has one default impl, so I think we can just inline that into the method body here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1941764924

From vyazici at openjdk.org  Tue Feb  4 20:27:16 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Feb 2025 20:27:16 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v6]
In-Reply-To: <MEaVh56gQqp2517Z7lF9JHRj45sEbNSfqq1vt-brOYU=.145a5b62-0e0a-437f-a21f-87ad700e860f@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
 <MEaVh56gQqp2517Z7lF9JHRj45sEbNSfqq1vt-brOYU=.145a5b62-0e0a-437f-a21f-87ad700e860f@github.com>
Message-ID: <kmUYDP2Y8cNiBplZS8eQL7F3JxYQzwTnknxuIN6vaHo=.53cdcd73-0703-49b2-ba56-5c9c26a14039@github.com>

On Tue, 4 Feb 2025 14:26:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
>> 
>> 
>> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
>> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
>> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
>> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
>> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
>> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
>> 
>> 
>> **Other highlights:**
>> 
>> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
>> - `test.lib.Asserts::assertFileContentsEqual` is added
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing `assertFileContentsEqual` replacement to `FixedThreadPoolTest`

Successful `tier{1,2}` test run reports on 5e9b30f431676c714cf81b85846f16c58c0dcdf6 is attached to the ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/23401#issuecomment-2634983113

From darcy at openjdk.org  Tue Feb  4 20:39:18 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Feb 2025 20:39:18 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v4]
In-Reply-To: <JENdZLiCWbHnkdjyhqKGyjZxHcq2byLXXj1YRwi_X18=.a94901e5-cc33-4aa8-8f89-16a4fdb9c361@github.com>
References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
 <JENdZLiCWbHnkdjyhqKGyjZxHcq2byLXXj1YRwi_X18=.a94901e5-cc33-4aa8-8f89-16a4fdb9c361@github.com>
Message-ID: <LLSIV357F0LytgmHwKakt4xjTiH4RulMxtC9YOCIQxo=.5f27b421-a594-4058-8c54-91250a078f22@github.com>

On Sat, 1 Feb 2025 08:42:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>  - remove getChars(long, int, char[])
>  - copyright
>  - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>  - simplify and comments
>  - simplify
>  - simplify
>  - code style
>  - revert change
>  - bug fix
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/651ac3cc...f9af0b02

Can we please have a pause on the sequence of "make XYZ toString faster" PRs until there is some wider discussion of goals, etc.? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/23310#issuecomment-2635015226

From archie.cobbs at gmail.com  Tue Feb  4 21:37:38 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 4 Feb 2025 15:37:38 -0600
Subject: RFR: 8315585: Optimization for decimal to string [v4]
In-Reply-To: <LLSIV357F0LytgmHwKakt4xjTiH4RulMxtC9YOCIQxo=.5f27b421-a594-4058-8c54-91250a078f22@github.com>
References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
 <JENdZLiCWbHnkdjyhqKGyjZxHcq2byLXXj1YRwi_X18=.a94901e5-cc33-4aa8-8f89-16a4fdb9c361@github.com>
 <LLSIV357F0LytgmHwKakt4xjTiH4RulMxtC9YOCIQxo=.5f27b421-a594-4058-8c54-91250a078f22@github.com>
Message-ID: <CANSoFxvT6+Px5O7aJPkiRHwVxXErR9jxyoJnogQ1gQ_XOjJuww@mail.gmail.com>

On Tue, Feb 4, 2025 at 2:40?PM Joe Darcy <darcy at openjdk.org> wrote:

> Can we please have a pause on the sequence of "make XYZ toString faster"
> PRs until there is some wider discussion of goals, etc.? Thanks.
>

I agree with this sentiment... It was surprising to see how easily a VM
crash can sneak in.

There is always a trade-off between A and B, where:

A = Code clarity, robustness vs. future changes, friendliness to new
developers, minimizing obscure bugs (and security holes), etc...
B = Performance

Where should the line be drawn? Personally (as a Java user) I'd accept 1%
slower vs. 1% less likely to crash any day...

Performance is important but there should be some general guidelines and
maybe some specific policies. E.g. should there be a higher number of
reviews required whenever Unsafe is used purely for performance reasons?

It's also worth pondering what's implied by the Java team evangelizing to
the rest of the world to stop using Unsafe, while at the same time adding
it more and more ourselves (when not strictly required). In theory we
should instead be eating our own dog food (or better yet, improving its
quality).

Also: when does it become more appropriate to address a performance issue
in Hotspot instead of in Java source? If some optimization eliminates an
array range check that is clearly not needed, it might be feasible (and
much more widely beneficial) to teach Hotstpot how to figure that out
itself, etc.

Just some random thoughts...

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250204/116c8508/attachment.htm>

From swen at openjdk.org  Tue Feb  4 22:35:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 22:35:51 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v6]
In-Reply-To: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
Message-ID: <OvrRvUx7P28vBiFEC7qI1DiBhlJYIvyCx-Mlt2heqD8=.17770448-fbfb-4213-a0e1-825b1817e356@github.com>

> The following code can reproduce the problem, writing out of bounds causes JVM Crash
> 
> 
>          StringBuilder buf = new StringBuilder();
>         buf.append('?');
> 
>         Thread[] threads = new Thread[40];
>         final CountDownLatch latch = new CountDownLatch(threads.length);
>         Runnable r = () -> {
>             for (int i = 0; i < 1000000; i++) {
>                 buf.setLength(0);
>                 buf.trimToSize();
>                 buf.append(123456789123456789L);
>             }
>             latch.countDown();
>         };
> 
>         for (int i = 0; i < threads.length; i++) {
>             threads[i] = new Thread(r);
>         }
>         for (Thread t : threads) {
>             t.start();
>         }
>         latch.await();
> 
> 
> This problem can be avoided by using the value of ensureCapacityInternal directly.

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

  from @RogerRiggs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23427/files
  - new: https://git.openjdk.org/jdk/pull/23427/files/955e8538..5f8a8d53

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

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

PR: https://git.openjdk.org/jdk/pull/23427

From bchristi at openjdk.org  Tue Feb  4 22:40:18 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 4 Feb 2025 22:40:18 GMT
Subject: RFR: 8349107: Remove RMI finalizers [v2]
In-Reply-To: <GBxj64AHg_40TFsAmS7nwWfICjXoTUt13CiAxK72e4Q=.bfbad393-1ca4-4746-9535-4f8e17fed265@github.com>
References: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
 <GBxj64AHg_40TFsAmS7nwWfICjXoTUt13CiAxK72e4Q=.bfbad393-1ca4-4746-9535-4f8e17fed265@github.com>
Message-ID: <ajyl6KZfkj1KFxeduB6MfI_5JwPhcwVHUM69R89YIkY=.6a4c41cd-709f-4423-b05c-6f8110253e7d@github.com>

On Mon, 3 Feb 2025 19:13:10 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> 3 finalizers in RMI code can be removed, as they do not perform meaningful cleanup.
>> 
>> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**
>> 
>> `RegistryContext.finalize()` just calls `close()`. The `close()` method does not perform any cleanup per se, but rather "helps the garbage collector" by setting `environment` and `registry` to `null`.
>> 
>> 
>> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.BindingEnumeration`**
>> 
>> `BindingEnumeration.finalize()` simply calls `close()` on the `ctx` field, itself a `RegistryContext` (and `close()` just "helps the GC.")
>> 
>> 
>> **`src/java.rmi/share/classes/sun/rmi/log/LogInputStream`**
>> 
>> `LogInputStream` tracks its length with an int field, `length`. If `length` ever becomes == 0, `LogInputStream`'s methods will return without doing anything.
>> 
>> The finalizer calls `close()`, which just sets length = 0.
>> 
>> By the time a `LogInputStream` becomes unreachable and is finalized, it's a moot point whether length == 0, as no more methods can be called.
>> If anything, this finalizer could cause a bug. If a `LogInputStream` were to became unreachable while a method were still running, the finalizer could set the length to 0 while method code is still running and expecting a length != 0.
>> It's possible that there is a very long standing bug that `close()` should be calling `in.close()`, in which case this evaluation will need to be revisited.
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into rmF10Nnow
>  - Remove finalizer from RMI LogInputStream
>  - Remove finalizer from RMI RegistryContext.BindingEnumeration
>  - Remove finalizer from RMI RegistryContext

Thanks for the reviews ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23406#issuecomment-2635223268

From bchristi at openjdk.org  Tue Feb  4 22:40:19 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 4 Feb 2025 22:40:19 GMT
Subject: Integrated: 8349107: Remove RMI finalizers
In-Reply-To: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
References: <Zfylf8-iQcmq-L87rhNPZWyecxEzVlBbmHgmlup-zjU=.867dd5de-2b23-4a10-8400-85ee9ec01550@github.com>
Message-ID: <G7No4ePK7XPvHbjuteVrbg8eWgW_udh64pBBAjvVnwk=.f8f57dda-b244-4eb6-bc9e-2fe8a0c4c132@github.com>

On Sat, 1 Feb 2025 00:11:31 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> 3 finalizers in RMI code can be removed, as they do not perform meaningful cleanup.
> 
> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**
> 
> `RegistryContext.finalize()` just calls `close()`. The `close()` method does not perform any cleanup per se, but rather "helps the garbage collector" by setting `environment` and `registry` to `null`.
> 
> 
> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.BindingEnumeration`**
> 
> `BindingEnumeration.finalize()` simply calls `close()` on the `ctx` field, itself a `RegistryContext` (and `close()` just "helps the GC.")
> 
> 
> **`src/java.rmi/share/classes/sun/rmi/log/LogInputStream`**
> 
> `LogInputStream` tracks its length with an int field, `length`. If `length` ever becomes == 0, `LogInputStream`'s methods will return without doing anything.
> 
> The finalizer calls `close()`, which just sets length = 0.
> 
> By the time a `LogInputStream` becomes unreachable and is finalized, it's a moot point whether length == 0, as no more methods can be called.
> If anything, this finalizer could cause a bug. If a `LogInputStream` were to became unreachable while a method were still running, the finalizer could set the length to 0 while method code is still running and expecting a length != 0.
> It's possible that there is a very long standing bug that `close()` should be calling `in.close()`, in which case this evaluation will need to be revisited.

This pull request has now been integrated.

Changeset: d222c186
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d222c186a6c5a282e9ef143fac3568351ad7b9d7
Stats:     20 lines in 2 files changed: 0 ins; 19 del; 1 mod

8349107: Remove RMI finalizers

Reviewed-by: rriggs, vklang, djelinski, smarks

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

PR: https://git.openjdk.org/jdk/pull/23406

From swen at openjdk.org  Tue Feb  4 22:48:56 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 22:48:56 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v7]
In-Reply-To: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
Message-ID: <CN47Erfdo5ARdtDB-ib63_6X5Q3t3OodOOB4XHkTLtY=.b1a3431b-8557-4bc5-8344-fba9214e29f2@github.com>

> The following code can reproduce the problem, writing out of bounds causes JVM Crash
> 
> 
>          StringBuilder buf = new StringBuilder();
>         buf.append('?');
> 
>         Thread[] threads = new Thread[40];
>         final CountDownLatch latch = new CountDownLatch(threads.length);
>         Runnable r = () -> {
>             for (int i = 0; i < 1000000; i++) {
>                 buf.setLength(0);
>                 buf.trimToSize();
>                 buf.append(123456789123456789L);
>             }
>             latch.countDown();
>         };
> 
>         for (int i = 0; i < threads.length; i++) {
>             threads[i] = new Thread(r);
>         }
>         for (Thread t : threads) {
>             t.start();
>         }
>         latch.await();
> 
> 
> This problem can be avoided by using the value of ensureCapacityInternal directly.

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

  from @RogerRiggs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23427/files
  - new: https://git.openjdk.org/jdk/pull/23427/files/5f8a8d53..379ab3a8

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

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

PR: https://git.openjdk.org/jdk/pull/23427

From swen at openjdk.org  Tue Feb  4 22:54:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 22:54:48 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v8]
In-Reply-To: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
Message-ID: <a-y1EzAJTiAKoelqGW4JL8ZOfDCC2c_MJPQgjnzE43A=.3465034d-d1cd-4c1b-bdfe-dcfb71487666@github.com>

> The following code can reproduce the problem, writing out of bounds causes JVM Crash
> 
> 
>          StringBuilder buf = new StringBuilder();
>         buf.append('?');
> 
>         Thread[] threads = new Thread[40];
>         final CountDownLatch latch = new CountDownLatch(threads.length);
>         Runnable r = () -> {
>             for (int i = 0; i < 1000000; i++) {
>                 buf.setLength(0);
>                 buf.trimToSize();
>                 buf.append(123456789123456789L);
>             }
>             latch.countDown();
>         };
> 
>         for (int i = 0; i < threads.length; i++) {
>             threads[i] = new Thread(r);
>         }
>         for (Thread t : threads) {
>             t.start();
>         }
>         latch.await();
> 
> 
> This problem can be avoided by using the value of ensureCapacityInternal directly.

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

  fx comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23427/files
  - new: https://git.openjdk.org/jdk/pull/23427/files/379ab3a8..9bf1330d

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

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

PR: https://git.openjdk.org/jdk/pull/23427

From swen at openjdk.org  Tue Feb  4 23:02:24 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 23:02:24 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v9]
In-Reply-To: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
Message-ID: <9eWh_15ds2-wCAojKrCz2s4SeB-QAPi4Mj12XttS6_8=.5c67c531-ade1-441a-ae0d-2be95bcd1556@github.com>

> The following code can reproduce the problem, writing out of bounds causes JVM Crash
> 
> 
>          StringBuilder buf = new StringBuilder();
>         buf.append('?');
> 
>         Thread[] threads = new Thread[40];
>         final CountDownLatch latch = new CountDownLatch(threads.length);
>         Runnable r = () -> {
>             for (int i = 0; i < 1000000; i++) {
>                 buf.setLength(0);
>                 buf.trimToSize();
>                 buf.append(123456789123456789L);
>             }
>             latch.countDown();
>         };
> 
>         for (int i = 0; i < threads.length; i++) {
>             threads[i] = new Thread(r);
>         }
>         for (Thread t : threads) {
>             t.start();
>         }
>         latch.await();
> 
> 
> This problem can be avoided by using the value of ensureCapacityInternal directly.

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

  Complete the javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23427/files
  - new: https://git.openjdk.org/jdk/pull/23427/files/9bf1330d..729a29d7

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

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

PR: https://git.openjdk.org/jdk/pull/23427

From swen at openjdk.org  Tue Feb  4 23:02:24 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 23:02:24 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v8]
In-Reply-To: <a-y1EzAJTiAKoelqGW4JL8ZOfDCC2c_MJPQgjnzE43A=.3465034d-d1cd-4c1b-bdfe-dcfb71487666@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
 <a-y1EzAJTiAKoelqGW4JL8ZOfDCC2c_MJPQgjnzE43A=.3465034d-d1cd-4c1b-bdfe-dcfb71487666@github.com>
Message-ID: <V2lMJazp8ayl9IwhuXzMf0CxL2zZEOu9hnuxMT9K7AI=.689ba744-1b76-457b-bfa8-62e49a7e7f80@github.com>

On Tue, 4 Feb 2025 22:54:48 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The following code can reproduce the problem, writing out of bounds causes JVM Crash
>> 
>> 
>>          StringBuilder buf = new StringBuilder();
>>         buf.append('?');
>> 
>>         Thread[] threads = new Thread[40];
>>         final CountDownLatch latch = new CountDownLatch(threads.length);
>>         Runnable r = () -> {
>>             for (int i = 0; i < 1000000; i++) {
>>                 buf.setLength(0);
>>                 buf.trimToSize();
>>                 buf.append(123456789123456789L);
>>             }
>>             latch.countDown();
>>         };
>> 
>>         for (int i = 0; i < threads.length; i++) {
>>             threads[i] = new Thread(r);
>>         }
>>         for (Thread t : threads) {
>>             t.start();
>>         }
>>         latch.await();
>> 
>> 
>> This problem can be avoided by using the value of ensureCapacityInternal directly.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fx comments

Thanks @RogerRiggs, your suggestion is great, I have fixed it, please help me review it again.

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

PR Comment: https://git.openjdk.org/jdk/pull/23427#issuecomment-2635254981

From swen at openjdk.org  Tue Feb  4 23:25:16 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 23:25:16 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v4]
In-Reply-To: <JENdZLiCWbHnkdjyhqKGyjZxHcq2byLXXj1YRwi_X18=.a94901e5-cc33-4aa8-8f89-16a4fdb9c361@github.com>
References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
 <JENdZLiCWbHnkdjyhqKGyjZxHcq2byLXXj1YRwi_X18=.a94901e5-cc33-4aa8-8f89-16a4fdb9c361@github.com>
Message-ID: <OuPjhqT8MhzedE6GjsbHHh2WgmRIyGdgmtgYQ2yta6I=.b2d4ee54-4b4c-4ed0-95e7-4bab92666d50@github.com>

On Sat, 1 Feb 2025 08:42:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>  - remove getChars(long, int, char[])
>  - copyright
>  - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>  - simplify and comments
>  - simplify
>  - simplify
>  - code style
>  - revert change
>  - bug fix
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/651ac3cc...f9af0b02

I think you are talking about the problem of PR #23420, which is caused by the use of thread-unsafe StringBuilder in multi-threaded scenarios. This problem is very obscure and I didn't consider it before. I have started to solve this problem and have submitted PR #23427. After it is completed, I will continue to submit PR to redo PR #19626 in a thread-safe way.

The above problem does not affect toString, because it only occurs when StringBuilder is used in a multi-threaded scenario.

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

PR Comment: https://git.openjdk.org/jdk/pull/23310#issuecomment-2635284370

From swen at openjdk.org  Tue Feb  4 23:44:38 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 23:44:38 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v14]
In-Reply-To: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
Message-ID: <lJGaFZdjw0aBKWb35RiDNNRGF-IOiQdePWb3NyvqDtQ=.fb7af52a-95fe-4b00-be96-4928ba62a0ab@github.com>

> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/Long.java
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - Update src/java.base/share/classes/java/lang/Integer.java
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22919/files
  - new: https://git.openjdk.org/jdk/pull/22919/files/1fb40bb9..40b9fafa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=12-13

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

PR: https://git.openjdk.org/jdk/pull/22919

From swen at openjdk.org  Wed Feb  5 00:19:31 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 5 Feb 2025 00:19:31 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v15]
In-Reply-To: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
Message-ID: <NzakYtXz3t3oZN9DUIDvfqlKuSZctKb7SN3crDdU73g=.d1489dbe-037e-44c2-83b6-6f99b557861e@github.com>

> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.

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

  fix JdbExprTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22919/files
  - new: https://git.openjdk.org/jdk/pull/22919/files/40b9fafa..27024407

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=13-14

  Stats: 19 lines in 4 files changed: 0 ins; 16 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919

PR: https://git.openjdk.org/jdk/pull/22919

From dlong at openjdk.org  Wed Feb  5 01:13:20 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 01:13:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
Message-ID: <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>

On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright and param name

test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 73:

> 71:     public int getAppArrayModifiers() {
> 72:         return clazzArray.getClass().getModifiers();
> 73:     }

I'm guessing this is the benchmark that shows an extra load.  How about adding a benchmark that makes the Clazz[] final or @Stable, and see if that makes the extra load go away?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1942114565

From syan at openjdk.org  Wed Feb  5 02:20:18 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Feb 2025 02:20:18 GMT
Subject: RFR: 8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark
 fails [v2]
In-Reply-To: <GZedlVAX83lkQmbZj5hXc0-FAH0vXyMTfSaU5rg_tt4=.12301d1b-f5ee-4e78-ab96-c833a5ee1a24@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
 <GZedlVAX83lkQmbZj5hXc0-FAH0vXyMTfSaU5rg_tt4=.12301d1b-f5ee-4e78-ab96-c833a5ee1a24@github.com>
Message-ID: <yfntlS_Nqac6j1U1wjCpXYW9j83bSg8Us9xtKQweQkY=.463fb4bd-79be-4425-99cf-6e96f4ef00e0@github.com>

On Tue, 4 Feb 2025 02:40:59 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
>> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
>> 
>> 
>>         TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
>>         System.out.println(tz.getDisplayName());
>>         System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
>>         System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
>> 
>> 
>> - Java 22 output:
>> 
>> 
>> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
>> Ecuador Time
>> ECST
>> ECT
>> 
>> 
>> - Java 23 output:
>> 
>> 
>> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
>> Ecuador Time
>> GMT-04:00
>> GMT-05:00
>> 
>> 
>> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use PST instead of Z

Thanks all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23414#issuecomment-2635551383

From syan at openjdk.org  Wed Feb  5 02:20:19 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Feb 2025 02:20:19 GMT
Subject: Integrated: 8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark
 fails
In-Reply-To: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
Message-ID: <MRXYgdTqM042GMwEHeR5HphOsysrNzu-n_ZDX3_FO5k=.0ca88be1-f61d-49bc-859b-dff896ba719a@github.com>

On Mon, 3 Feb 2025 07:49:21 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
> 
> 
>         TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
>         System.out.println(tz.getDisplayName());
>         System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
>         System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
> 
> 
> - Java 22 output:
> 
> 
> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> ECST
> ECT
> 
> 
> - Java 23 output:
> 
> 
> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> GMT-04:00
> GMT-05:00
> 
> 
> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: a51e6699
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a51e6699b497564de65620a36dc38437ca87cb32
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark fails

Reviewed-by: naoto, jlu

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

PR: https://git.openjdk.org/jdk/pull/23414

From asemenyuk at openjdk.org  Wed Feb  5 02:50:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 5 Feb 2025 02:50:02 GMT
Subject: RFR: 8346434: Add test for non-automatic service binding
Message-ID: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>

Added a test case to JLinkOptionsTest to test that jpackage doesn't bind services in app's runtime by default.

The test builds two app images for the same app. One with the default jlink options and another with `--bind-services` jlink option. The test compares module lists from both runtimes. The expected result is that the runtime built with `--bind-services` jlink option has additional modules.

The PR must be integrated after https://github.com/openjdk/jdk/pull/22644. Otherwise, the newly added test will fail.

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

Commit messages:
 - Merge branch 'master' into JDK-8346434
 - Trailing whitespace removed
 - Merge branch 'master' into JDK-8346434
 - Copyright year updated
 - 8346434: Add test for non-automatic service binding

Changes: https://git.openjdk.org/jdk/pull/23047/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23047&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346434
  Stats: 79 lines in 3 files changed: 58 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/23047.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23047/head:pull/23047

PR: https://git.openjdk.org/jdk/pull/23047

From duke at openjdk.org  Wed Feb  5 02:50:02 2025
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Wed, 5 Feb 2025 02:50:02 GMT
Subject: RFR: 8346434: Add test for non-automatic service binding
In-Reply-To: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
References: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
Message-ID: <uYnXpmE3U3mi9oE4I3iHX32LHNhMMloT_l0QLDXPEnY=.8a0b2dd0-0656-40a7-b6cb-ea97a750a738@github.com>

On Fri, 10 Jan 2025 21:23:22 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Added a test case to JLinkOptionsTest to test that jpackage doesn't bind services in app's runtime by default.
> 
> The test builds two app images for the same app. One with the default jlink options and another with `--bind-services` jlink option. The test compares module lists from both runtimes. The expected result is that the runtime built with `--bind-services` jlink option has additional modules.
> 
> The PR must be integrated after https://github.com/openjdk/jdk/pull/22644. Otherwise, the newly added test will fail.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/23047#pullrequestreview-2544634651

From asemenyuk at openjdk.org  Wed Feb  5 02:50:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 5 Feb 2025 02:50:02 GMT
Subject: RFR: 8346434: Add test for non-automatic service binding
In-Reply-To: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
References: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
Message-ID: <Bt1fmZpW19aqI6L-WmBFJdcvSA60ufxjpsFZTPLH4rY=.9053e727-285c-4166-8f43-ad8af9f58f77@github.com>

On Fri, 10 Jan 2025 21:23:22 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Added a test case to JLinkOptionsTest to test that jpackage doesn't bind services in app's runtime by default.
> 
> The test builds two app images for the same app. One with the default jlink options and another with `--bind-services` jlink option. The test compares module lists from both runtimes. The expected result is that the runtime built with `--bind-services` jlink option has additional modules.
> 
> The PR must be integrated after https://github.com/openjdk/jdk/pull/22644. Otherwise, the newly added test will fail.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/23047#issuecomment-2635580094

From almatvee at openjdk.org  Wed Feb  5 03:28:19 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 5 Feb 2025 03:28:19 GMT
Subject: RFR: 8346434: Add test for non-automatic service binding
In-Reply-To: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
References: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
Message-ID: <_lXGnrUqAl2SLKORbrD35lLvMZeQCr98Iwxz_ZkNgHU=.871ae877-1434-413f-95da-21187a2b1f63@github.com>

On Fri, 10 Jan 2025 21:23:22 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Added a test case to JLinkOptionsTest to test that jpackage doesn't bind services in app's runtime by default.
> 
> The test builds two app images for the same app. One with the default jlink options and another with `--bind-services` jlink option. The test compares module lists from both runtimes. The expected result is that the runtime built with `--bind-services` jlink option has additional modules.
> 
> The PR must be integrated after https://github.com/openjdk/jdk/pull/22644. Otherwise, the newly added test will fail.

test/jdk/tools/jpackage/share/JLinkOptionsTest.java line 175:

> 173:                 .setExecutable(cmd.appLauncherPath().toAbsolutePath())
> 174:                 .addArguments("--print-modules")
> 175:                 .executeAndRepeatUntilExitCode(0, attempts,

Is there any reason why we need to repeat execution?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23047#discussion_r1942195448

From asemenyuk at openjdk.org  Wed Feb  5 03:38:47 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 5 Feb 2025 03:38:47 GMT
Subject: RFR: 8333569: jpackage tests must run app launchers with retries on
 Linux only
Message-ID: <3I9ZwMk-JcV5lGCOuc9eWNllgYOYesmlHrYjwHUAglA=.05d0ba81-a35c-4de8-8133-d3abea67650d@github.com>

Run app launchers in jpackage tests with retries on Linux only. Run them without retries on other platforms.

Supplementary remove `HelloApp.AppOutputVerifier.removePathEnvVar()` function. It sets an unused member field and is a leftover from [JDK-8347300](https://bugs.openjdk.org/browse/JDK-8347300) fix. This change has no functional impact; it cleans unused code.

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

Commit messages:
 - 8333569: jpackage tests must run app launchers with retries on Linux only

Changes: https://git.openjdk.org/jdk/pull/23454/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23454&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333569
  Stats: 42 lines in 3 files changed: 15 ins; 18 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23454.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23454/head:pull/23454

PR: https://git.openjdk.org/jdk/pull/23454

From jpai at openjdk.org  Wed Feb  5 04:56:14 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Feb 2025 04:56:14 GMT
Subject: [jdk24] RFR: 8349183: [BACKOUT] Optimization for StringBuilder
 append boolean & null
In-Reply-To: <uytjFeusf-_7CVTw67jW9wPi3m8gV2B1e35y_AhYqCo=.9418d4aa-69aa-48f5-af02-f46d339aefdf@github.com>
References: <uytjFeusf-_7CVTw67jW9wPi3m8gV2B1e35y_AhYqCo=.9418d4aa-69aa-48f5-af02-f46d339aefdf@github.com>
Message-ID: <ibqCXOVQlKjpurbOEOncUKAjSr4xW-QA4QaGQs_bF5k=.caa6d26a-1bdc-4501-8fb0-5c770e52f277@github.com>

On Mon, 3 Feb 2025 18:41:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this backport of https://github.com/openjdk/jdk/pull/23420 into jdk24?
> 
> This proposes to bring in those same backouts into `jdk24` to prevent the issue noted in that PR description. jdk24 is in rampdown and this backport will require an approval. A approval request has been raised in https://bugs.openjdk.org/browse/JDK-8349183?focusedId=14746841&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14746841.
> 
> This backport into jdk24 wasn't clean due to a trivial merge conflict in `StringLatin1.java` file. That merge conflict was manually resolved (just like it was done against mainline). The git commands used to create this backport against jdk24 branch are:
> 
> 
> <checkout fresh jdk24 branch>
> git cherry-pick --no-commit 618c5eb27b4c719afd577b690e6bcb21a45fcb0d
> <resolve merge conflict in StringLatin1.java>
> git commit -m 'Backport 618c5eb27b4c719afd577b690e6bcb21a45fcb0d'
> 
> 
> tier1, tier2 and tier3 testing is currently in progress with this change.

Thank you Roger and Chen for the reviews.

Approval for backporting the 2 issues, linked to this PR, into jdk24 has now been granted. I've run tier1 through tier6 with these changes in our CI and that has completed without related issues. tier7 and tier8 are progressing fine too.

I'll go ahead and integrate this shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/23425#issuecomment-2635699537

From dholmes at openjdk.org  Wed Feb  5 05:39:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Feb 2025 05:39:14 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]
In-Reply-To: <syxVRD9ASKql288dZ8hdYJjliScymiDGldc7fSoEAiU=.d4084758-4fb0-496f-a7bb-ad0093129f11@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <syxVRD9ASKql288dZ8hdYJjliScymiDGldc7fSoEAiU=.d4084758-4fb0-496f-a7bb-ad0093129f11@github.com>
Message-ID: <rnBxm-eKFKaOGdMay4i94tiSB28d_9s6SOrfGAnrTZk=.875ea4cd-2d71-4139-997c-ef1f1a0fd59d@github.com>

On Mon, 3 Feb 2025 16:11:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test that knows which fields are hidden from reflection in jvmci.

src/java.base/share/classes/java/lang/Class.java line 239:

> 237:      * generated.
> 238:      */
> 239:     private Class(ClassLoader loader, Class<?> arrayComponentType, ProtectionDomain pd) {

If this constructor is not used then why do we need to add the PD argument, rather than just set it to null? For that matter why do we even need the field if nothing is ever setting it? I'm missing something here.

src/java.base/share/classes/java/lang/Class.java line 2701:

> 2699: 
> 2700:     @Stable
> 2701:     private transient final ProtectionDomain protectionDomain;

Isn't `@Stable` superfluous with a final field?

src/java.base/share/classes/java/lang/Class.java line 2722:

> 2720:      */
> 2721:     public ProtectionDomain getProtectionDomain() {
> 2722:         if (protectionDomain == null) {

Does this imply the class is a primitive class?

test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java line 205:

> 203: 
> 204:     /**
> 205:      * Test that some Class fields cannot be make accessible.

Suggestion:

     * Test that some Class fields cannot be made accessible.

test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java line 216:

> 214: 
> 215:         assertTrue(pd == null);
> 216:     }

Suggestion:

    public void testJavaLangClassFields() throws Exception {
        try {
            // This field is explicitly hidden from reflection.
            Class.class.getDeclaredField("protectionDomain");
            assertTrue(false);
        } catch (NoSuchFieldException expected) { }
    }

The above is more in-style with the other test cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1942271834
PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1942261857
PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1942270930
PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1942265829
PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1942268434

From jpai at openjdk.org  Wed Feb  5 06:09:11 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Feb 2025 06:09:11 GMT
Subject: RFR: 8349344: Clarify documentation of Arena.ofConfined
In-Reply-To: <uRzbPuT_TqSUM2HsGK9u192RC73lPsKlAtgUxUwcR68=.bc1ae678-0e4b-41fb-a374-fcdd94f92251@github.com>
References: <uRzbPuT_TqSUM2HsGK9u192RC73lPsKlAtgUxUwcR68=.bc1ae678-0e4b-41fb-a374-fcdd94f92251@github.com>
Message-ID: <po_bcRaa_T1UcK7t-hxdpOXEP9Mh6ypY8lNX5ObRFPo=.0778bc53-1e9f-4a66-b94d-d58476433d76@github.com>

On Tue, 4 Feb 2025 09:46:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to clarify the documentation for `Arena.ofConfined()`. It is proposed to say that segments allocated from the returned `Arena` can _only_ be accessed by the thread that created the `Arena` in the first place.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23435#pullrequestreview-2594709188

From jpai at openjdk.org  Wed Feb  5 06:54:21 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Feb 2025 06:54:21 GMT
Subject: [jdk24] Integrated: 8349183: [BACKOUT] Optimization for StringBuilder
 append boolean & null
In-Reply-To: <uytjFeusf-_7CVTw67jW9wPi3m8gV2B1e35y_AhYqCo=.9418d4aa-69aa-48f5-af02-f46d339aefdf@github.com>
References: <uytjFeusf-_7CVTw67jW9wPi3m8gV2B1e35y_AhYqCo=.9418d4aa-69aa-48f5-af02-f46d339aefdf@github.com>
Message-ID: <V9CpCNxsm1Z0tvGS031B76t5NW2rYn-isQrg4-IBwGk=.45295c8b-52cb-4324-8355-a6e5a16ed6f5@github.com>

On Mon, 3 Feb 2025 18:41:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this backport of https://github.com/openjdk/jdk/pull/23420 into jdk24?
> 
> This proposes to bring in those same backouts into `jdk24` to prevent the issue noted in that PR description. jdk24 is in rampdown and this backport will require an approval. A approval request has been raised in https://bugs.openjdk.org/browse/JDK-8349183?focusedId=14746841&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14746841.
> 
> This backport into jdk24 wasn't clean due to a trivial merge conflict in `StringLatin1.java` file. That merge conflict was manually resolved (just like it was done against mainline). The git commands used to create this backport against jdk24 branch are:
> 
> 
> <checkout fresh jdk24 branch>
> git cherry-pick --no-commit 618c5eb27b4c719afd577b690e6bcb21a45fcb0d
> <resolve merge conflict in StringLatin1.java>
> git commit -m 'Backport 618c5eb27b4c719afd577b690e6bcb21a45fcb0d'
> 
> 
> tier1, tier2 and tier3 testing is currently in progress with this change.

This pull request has now been integrated.

Changeset: f0837b21
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0837b218317c7ac6e031a93381da3caa93946aa
Stats:     169 lines in 6 files changed: 46 ins; 79 del; 44 mod

8349183: [BACKOUT] Optimization for StringBuilder append boolean & null
8349239: [BACKOUT] Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt

Reviewed-by: rriggs, liach
Backport-of: 618c5eb27b4c719afd577b690e6bcb21a45fcb0d

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

PR: https://git.openjdk.org/jdk/pull/23425

From jbhateja at openjdk.org  Wed Feb  5 07:09:15 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 5 Feb 2025 07:09:15 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v17]
In-Reply-To: <7oq7j2pYG9ToDNcGyVWrphH_wFyvPRX2kl3qxgQYBss=.449139d7-e3a8-4587-b5ce-a5f7f9f5b613@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <sgcWAEvXaWi40uFqPPJq-e6n3YsHb7agKBUrMBdqJSc=.48c41eab-6641-45b7-9765-400622894f4b@github.com>
 <7oq7j2pYG9ToDNcGyVWrphH_wFyvPRX2kl3qxgQYBss=.449139d7-e3a8-4587-b5ce-a5f7f9f5b613@github.com>
Message-ID: <ze1zyGCZkepWitVWvZyFvdqYUSPo0cJA-bX1pyo58mc=.113254e4-fa71-4ca6-91d2-2929dfe94e45@github.com>

On Tue, 4 Feb 2025 19:18:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing typos
>
> src/java.base/share/classes/jdk/internal/vm/vector/Float16Math.java line 42:
> 
>> 40:     }
>> 41: 
>> 42:     public interface Float16TernaryMathOp {
> 
> Is there a reason we don't write the default impl explicitly in this class, but ask for a lambda for an implementation? Each intrinsified method only has one default impl, so I think we can just inline that into the method body here.

This wrapper class is part of java.base module and only contains intrinsic entry points for APIs defined in Float16 class which is part of an incubation module. Thus, exposing intrinsic fallback code through lambda keeps the interface clean while actual API logic and comments around it remains intact in Float16 class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1942344948

From syan at openjdk.org  Wed Feb  5 07:53:18 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Feb 2025 07:53:18 GMT
Subject: [jdk24] Withdrawn: 8347038: [JMH] jdk.incubator.vector.SpiltReplicate
 fails NoClassDefFoundError
In-Reply-To: <P02Qlvs092QKmxY6m2SAMHUIgCDx9X3czfVhf6C972o=.555415fd-bb31-45c7-9f3d-9b13e1289bf2@github.com>
References: <P02Qlvs092QKmxY6m2SAMHUIgCDx9X3czfVhf6C972o=.555415fd-bb31-45c7-9f3d-9b13e1289bf2@github.com>
Message-ID: <PDY6Osr7LaWmnZJqwcmP4CokcS0LfWwdbIADvbbgh0U=.88b195c4-9524-45ab-bae3-5f3e6a6cf837@github.com>

On Tue, 7 Jan 2025 15:14:18 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4d8fb807](https://github.com/openjdk/jdk/commit/4d8fb80732fd17352c36254c6dfc1be5dbfbacf1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24.
> 
> The commit being backported was authored by SendaoYan on 7 Jan 2025 and was reviewed by Paul Sandoz. Fix the JMH test bug, test-fix only, no risk.
> 
> Thanks!

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/22949

From syan at openjdk.org  Wed Feb  5 07:53:18 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Feb 2025 07:53:18 GMT
Subject: [jdk24] RFR: 8347038: [JMH] jdk.incubator.vector.SpiltReplicate
 fails NoClassDefFoundError
In-Reply-To: <P02Qlvs092QKmxY6m2SAMHUIgCDx9X3czfVhf6C972o=.555415fd-bb31-45c7-9f3d-9b13e1289bf2@github.com>
References: <P02Qlvs092QKmxY6m2SAMHUIgCDx9X3czfVhf6C972o=.555415fd-bb31-45c7-9f3d-9b13e1289bf2@github.com>
Message-ID: <qEI5bT3ipGpsoNlxEHDbzGkj4K3hmnSjSx1TG5LIoH0=.a5840277-0883-4eb5-bdfd-3ca560f31682@github.com>

On Tue, 7 Jan 2025 15:14:18 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4d8fb807](https://github.com/openjdk/jdk/commit/4d8fb80732fd17352c36254c6dfc1be5dbfbacf1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24.
> 
> The commit being backported was authored by SendaoYan on 7 Jan 2025 and was reviewed by Paul Sandoz. Fix the JMH test bug, test-fix only, no risk.
> 
> Thanks!

Seems we need to backport [jdk24u](https://github.com/openjdk/jdk24u/pull/47) instead of jdk24. I think we should close this backport PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/22949#issuecomment-2635986603

From syan at openjdk.org  Wed Feb  5 09:04:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Feb 2025 09:04:58 GMT
Subject: RFR: 8345155: Add /native to native test in FFM
Message-ID: <sZv1i8MFu4Hedp6TOhErsjlP9fzakMMjWa_XWUkpQuQ=.fc469a70-a737-456c-9827-d465981433d0@github.com>

Hi all,

This PR add `/native` keyword in the test header for FFM tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.

I runed all the FFM tests without `-nativepath` argument and find the fail tests. This will find all the FFM tests which missing '/native' flag.

Change has been verified locally, test-fix, no risk.

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

Commit messages:
 - 8345155: Add /native to native test in FFM

Changes: https://git.openjdk.org/jdk/pull/23458/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23458&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345155
  Stats: 76 lines in 34 files changed: 0 ins; 0 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/23458.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23458/head:pull/23458

PR: https://git.openjdk.org/jdk/pull/23458

From mcimadamore at openjdk.org  Wed Feb  5 10:08:09 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 5 Feb 2025 10:08:09 GMT
Subject: RFR: 8345155: Add /native to native test in FFM
In-Reply-To: <sZv1i8MFu4Hedp6TOhErsjlP9fzakMMjWa_XWUkpQuQ=.fc469a70-a737-456c-9827-d465981433d0@github.com>
References: <sZv1i8MFu4Hedp6TOhErsjlP9fzakMMjWa_XWUkpQuQ=.fc469a70-a737-456c-9827-d465981433d0@github.com>
Message-ID: <dMRjbXK-Y9FI7hjKIQC5Sf4KavxdSIe8cLYb_IGwGzE=.a8e069ab-0ca7-4b44-8e5d-e832fa4efa0a@github.com>

On Wed, 5 Feb 2025 08:59:10 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR add `/native` keyword in the test header for FFM tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the FFM tests without `-nativepath` argument and find the fail tests. This will find all the FFM tests which missing '/native' flag.
> 
> Change has been verified locally, test-fix, no risk.

Good work. We also have a TestMatrix which is a manual test - but that one does seem to already have `/native`

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23458#pullrequestreview-2595195979

From mcimadamore at openjdk.org  Wed Feb  5 10:09:11 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 5 Feb 2025 10:09:11 GMT
Subject: RFR: 8349344: Clarify documentation of Arena.ofConfined
In-Reply-To: <uRzbPuT_TqSUM2HsGK9u192RC73lPsKlAtgUxUwcR68=.bc1ae678-0e4b-41fb-a374-fcdd94f92251@github.com>
References: <uRzbPuT_TqSUM2HsGK9u192RC73lPsKlAtgUxUwcR68=.bc1ae678-0e4b-41fb-a374-fcdd94f92251@github.com>
Message-ID: <BTtHLVSvv-gRr9NgLvYVIRUZl3kTlbox5cnw5gDCQRY=.a5bfb707-4f7e-4d6c-bbac-230ecce07f9e@github.com>

On Tue, 4 Feb 2025 09:46:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to clarify the documentation for `Arena.ofConfined()`. It is proposed to say that segments allocated from the returned `Arena` can _only_ be accessed by the thread that created the `Arena` in the first place.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23435#pullrequestreview-2595197421

From mcimadamore at openjdk.org  Wed Feb  5 10:21:11 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 5 Feb 2025 10:21:11 GMT
Subject: RFR: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment [v3]
In-Reply-To: <t92orma4IJsSWsrUMBkkuQtP5e0X7pZ1F1E6NMC1O3U=.6ab41c4e-5462-41bf-b072-fab3aa6bb103@github.com>
References: <sj7WfOT2Mc3mZa4jt5PI8z_tQtM2FNUT-RZ3F67hY2w=.60995a4e-6cb4-4d3b-9ecf-ce31cad1c33e@github.com>
 <5bAs8hhqvy-c776n0_9Xqw6n8quA-c_a59ii-nWFhuE=.2eae9a1b-b46a-4626-9ac5-3ee35a34b82c@github.com>
 <YduWHDK_lawPwbwOIfzhLbJr6Mkv1xDe11qrNOe1gcM=.55fa23e5-7f7f-4171-a90f-10d12af1c914@github.com>
 <4T4xAZGj1lmd8-KBdRCsBF5oltxC0mQzseUIJGTKaCE=.f71ab6fc-a247-45af-9000-9d1288bdf5d4@github.com>
 <_wjpvTZLmQbjFr0fWIJnB8hyZo0PDFnfnmTDeh7ujXo=.64334ac1-d6bd-45f3-a1c3-a4da05053768@github.com>
 <t92orma4IJsSWsrUMBkkuQtP5e0X7pZ1F1E6NMC1O3U=.6ab41c4e-5462-41bf-b072-fab3aa6bb103@github.com>
Message-ID: <CZjbOYY2xR9dD0elNlcQpBB1HleE5vGQh3y1cLlpBhE=.39e1b958-2aa4-4b2f-a053-d31d93c25871@github.com>

On Sat, 25 Jan 2025 02:32:56 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> But the address is immediately converted to memory segment using MemorySegment::ofAddress, which is what the linker does anyway?
>
> Only the return value of `CALLOC` is converted to `MemorySegment` in an equivalent way, I believe passing a `MemorySegment` to a downcall involves acquiring the corresponding segment? As a result, `FREE` is made to accept the raw address, and `CALLOC` is changed in the same manner for consistency.

Yes, passing segments to a downcall will acquire -- but if the segment is a wrapper around a long (a zero-length memory segment), its scope is the global scope, and acquire is a no-op. Stepping back what worries me with the changes in this benchmark is that we're replacing idiomatic FFM code with very low-level code which seems less representative of code people would write. Maybe if we need a dedicated benchmark to ensure there's no escaping in the innards of the API impl, we should write one specifically for that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22610#discussion_r1942600291

From sgehwolf at openjdk.org  Wed Feb  5 10:50:11 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 5 Feb 2025 10:50:11 GMT
Subject: RFR: 8344925: translet-name ignored when package-name is also set
In-Reply-To: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
References: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
Message-ID: <GoDsAmJ4JIoMyjcB0OxalGnfxboFQKrU_dlC9_g3fkw=.519061a0-7e50-4490-aa86-b8a624b3260f@github.com>

On Tue, 4 Feb 2025 18:30:34 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an issue where the translet-name is incorrectly set when the package-name is also specified.

@JoeWang-Java Have you seen https://git.openjdk.org/jdk/pull/22425?

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

PR Comment: https://git.openjdk.org/jdk/pull/23446#issuecomment-2636380469

From sgehwolf at openjdk.org  Wed Feb  5 11:00:10 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 5 Feb 2025 11:00:10 GMT
Subject: RFR: 8344925: translet-name ignored when package-name is also set
In-Reply-To: <GoDsAmJ4JIoMyjcB0OxalGnfxboFQKrU_dlC9_g3fkw=.519061a0-7e50-4490-aa86-b8a624b3260f@github.com>
References: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
 <GoDsAmJ4JIoMyjcB0OxalGnfxboFQKrU_dlC9_g3fkw=.519061a0-7e50-4490-aa86-b8a624b3260f@github.com>
Message-ID: <uOk3nctNL3ytpqgVPZ00vc4pcVH4PdA33xV2wuFrWLk=.1e705598-3a47-403b-bebe-bfd7629e1a54@github.com>

On Wed, 5 Feb 2025 10:47:27 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> @JoeWang-Java Have you seen https://git.openjdk.org/jdk/pull/22425?

Just mentioning since it looks like a duplicate proposal.

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

PR Comment: https://git.openjdk.org/jdk/pull/23446#issuecomment-2636402802

From rgiulietti at openjdk.org  Wed Feb  5 12:28:13 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Feb 2025 12:28:13 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v15]
In-Reply-To: <NzakYtXz3t3oZN9DUIDvfqlKuSZctKb7SN3crDdU73g=.d1489dbe-037e-44c2-83b6-6f99b557861e@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
 <NzakYtXz3t3oZN9DUIDvfqlKuSZctKb7SN3crDdU73g=.d1489dbe-037e-44c2-83b6-6f99b557861e@github.com>
Message-ID: <9YscIlbn-fQ3xQJjO_K4CUrAOIqmumcOBQSVA2v4CzA=.50fdd8f6-3da1-4a01-863b-228ecb7cfe37@github.com>

On Wed, 5 Feb 2025 00:19:31 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
>> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
>> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
>> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix JdbExprTest

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 143:

> 141:      * @return If both characters are numbers, return d0 * 10 + d1, otherwise return -1
> 142:      */
> 143:     @ForceInline

Can we leave this out? From the doc: "This annotation must be used sparingly."
I tried without and on M1 performance does not seem to be affected.

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 175:

> 173:          */
> 174:         int d;
> 175:         short x = UNSAFE.getShortUnaligned(str, Unsafe.ARRAY_BYTE_BASE_OFFSET + offset, false);

@wenshao I'm a bit worried about the use of Unsafe here.

This method is `public` (although in an internal package), and while it is used correctly in this PR, there's no warning in the doc that `str` and `offset` must come from a trusted caller that ensures that they are safe to use with, well..., Unsafe.

Did you consider safer alternatives, like usage of `VarHandle`, even if that might mean a slight performance degradation?

test/jdk/com/sun/jdi/JdbExprTest.java line 115:

> 113:                 .shouldMatch("InvalidTypeException: .* convert 2147483648 to int");
> 114:         execCommand(JdbCommand.set("JdbExprTestTarg.anInt", "0x8000000000000000L"))
> 115:                 .shouldContain("java.lang.NumberFormatException: Error at index 15 in: \"8000000000000000\"");

Copyright year should be adjusted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1942751206
PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1942775434
PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1942778070

From swen at openjdk.org  Wed Feb  5 12:58:49 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 5 Feb 2025 12:58:49 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v16]
In-Reply-To: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
Message-ID: <hko0nLsg05AtoDvC8US_qviXWiZT_2Ouc218qOD3ggo=.2dd2ce2f-2b37-4d4a-b18f-05f49beb396c@github.com>

> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.

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

  copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22919/files
  - new: https://git.openjdk.org/jdk/pull/22919/files/27024407..0c43e9ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=14-15

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

PR: https://git.openjdk.org/jdk/pull/22919

From pminborg at openjdk.org  Wed Feb  5 13:27:04 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Feb 2025 13:27:04 GMT
Subject: RFR: 8348556: Inlining fails earlier for MemorySegment::reinterpret
Message-ID: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>

This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.

Tested and passed tier1-3

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

Commit messages:
 - Add @ForceInline annotations and restructure some methods

Changes: https://git.openjdk.org/jdk/pull/23460/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23460&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348556
  Stats: 57 lines in 1 file changed: 26 ins; 4 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/23460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23460/head:pull/23460

PR: https://git.openjdk.org/jdk/pull/23460

From pminborg at openjdk.org  Wed Feb  5 13:27:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Feb 2025 13:27:05 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret
In-Reply-To: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
Message-ID: <X7Bafc1ifm5pvgMz4-lLlNo_SUDhpVBBkW9s-gK_-wQ=.123a1c9d-0b22-44bc-a04d-23021a278b14@github.com>

On Wed, 5 Feb 2025 10:17:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
> 
> Tested and passed tier1-3

src/java.base/share/classes/java/lang/Module.java line 281:

> 279:         @ForceInline
> 280:         private static boolean isNativeAccessEnabled(Module target) {
> 281:             return target.enableNativeAccess || UNSAFE.getBooleanVolatile(target, FIELD_OFFSET);

Tries plain memory semantics first.

src/java.base/share/classes/java/lang/Module.java line 311:

> 309: 
> 310:     @DontInline
> 311:     void ensureNativeAccessSlowPath(Class<?> owner,

This is slow anyhow so we do not need it to be inlined.

src/java.base/share/classes/java/lang/Module.java line 488:

> 486:         // if other is an unnamed module then check if this module reads
> 487:         // all unnamed modules
> 488:         return !other.isNamed()

This is a drive-by simplification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r1942603002
PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r1942606189
PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r1942604940

From rgiulietti at openjdk.org  Wed Feb  5 13:31:14 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Feb 2025 13:31:14 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v15]
In-Reply-To: <9YscIlbn-fQ3xQJjO_K4CUrAOIqmumcOBQSVA2v4CzA=.50fdd8f6-3da1-4a01-863b-228ecb7cfe37@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
 <NzakYtXz3t3oZN9DUIDvfqlKuSZctKb7SN3crDdU73g=.d1489dbe-037e-44c2-83b6-6f99b557861e@github.com>
 <9YscIlbn-fQ3xQJjO_K4CUrAOIqmumcOBQSVA2v4CzA=.50fdd8f6-3da1-4a01-863b-228ecb7cfe37@github.com>
Message-ID: <cqw-tPgrHE-H-tVAj9yN5NwOjUCKfUeJC7inmfKH8nM=.16a8bc0e-d537-43e5-95c4-a2e6bc7a7946@github.com>

On Wed, 5 Feb 2025 12:17:42 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix JdbExprTest
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 175:
> 
>> 173:          */
>> 174:         int d;
>> 175:         short x = UNSAFE.getShortUnaligned(str, Unsafe.ARRAY_BYTE_BASE_OFFSET + offset, false);
> 
> @wenshao I'm a bit worried about the use of Unsafe here.
> 
> This method is `public` (although in an internal package), and while it is used correctly in this PR, there's no warning in the doc that `str` and `offset` must come from a trusted caller that ensures that they are safe to use with, well..., Unsafe.
> 
> Did you consider safer alternatives, like usage of `VarHandle`, even if that might mean a slight performance degradation?

Never mind, `VarHandle` cannot be used in this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1942947089

From pminborg at openjdk.org  Wed Feb  5 13:51:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Feb 2025 13:51:14 GMT
Subject: Integrated: 8349344: Clarify documentation of Arena.ofConfined
In-Reply-To: <uRzbPuT_TqSUM2HsGK9u192RC73lPsKlAtgUxUwcR68=.bc1ae678-0e4b-41fb-a374-fcdd94f92251@github.com>
References: <uRzbPuT_TqSUM2HsGK9u192RC73lPsKlAtgUxUwcR68=.bc1ae678-0e4b-41fb-a374-fcdd94f92251@github.com>
Message-ID: <sxNPFd4pZHaY09UrXpanGEaoIBwTLHhyYwtBqPVQCM4=.d5f67505-c0e9-470c-a087-93ccb60f7a18@github.com>

On Tue, 4 Feb 2025 09:46:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to clarify the documentation for `Arena.ofConfined()`. It is proposed to say that segments allocated from the returned `Arena` can _only_ be accessed by the thread that created the `Arena` in the first place.

This pull request has now been integrated.

Changeset: 2ff8440c
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ff8440c76bb090634ecf4e6faa523498fd1d9f3
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8349344: Clarify documentation of Arena.ofConfined

Reviewed-by: jvernee, jpai, mcimadamore

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

PR: https://git.openjdk.org/jdk/pull/23435

From pminborg at openjdk.org  Wed Feb  5 13:55:09 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Feb 2025 13:55:09 GMT
Subject: RFR: 8345155: Add /native to native test in FFM
In-Reply-To: <sZv1i8MFu4Hedp6TOhErsjlP9fzakMMjWa_XWUkpQuQ=.fc469a70-a737-456c-9827-d465981433d0@github.com>
References: <sZv1i8MFu4Hedp6TOhErsjlP9fzakMMjWa_XWUkpQuQ=.fc469a70-a737-456c-9827-d465981433d0@github.com>
Message-ID: <2xCXiUB2ogS8vviZcLeaEWq1uX_EwUQYkjR23qApdpE=.b6158d21-fd5b-43df-ace6-97f23c279b0e@github.com>

On Wed, 5 Feb 2025 08:59:10 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR add `/native` keyword in the test header for FFM tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the FFM tests without `-nativepath` argument and find the fail tests. This will find all the FFM tests which missing '/native' flag.
> 
> Change has been verified locally, test-fix, no risk.

Thanks for fixing this issue!

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23458#pullrequestreview-2595847242

From rgiulietti at openjdk.org  Wed Feb  5 14:06:19 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Feb 2025 14:06:19 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v16]
In-Reply-To: <hko0nLsg05AtoDvC8US_qviXWiZT_2Ouc218qOD3ggo=.2dd2ce2f-2b37-4d4a-b18f-05f49beb396c@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
 <hko0nLsg05AtoDvC8US_qviXWiZT_2Ouc218qOD3ggo=.2dd2ce2f-2b37-4d4a-b18f-05f49beb396c@github.com>
Message-ID: <Yqv_Y-V8xbcFBcyXBmpqtRpHGG7vRvL4wVvjfqxzfhE=.e85772c8-a6f8-4115-ae17-4a75f10b442f@github.com>

On Wed, 5 Feb 2025 12:58:49 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
>> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
>> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
>> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 138:

> 136: 
> 137:     /**
> 138:      * Determine whether the two strings in bytes are both numbers. If they are, return d0 * 10 + d1, otherwise return -1

This is confusing: two strings?
Also, "digits" would be better than "numbers".
Finally, d0 and d1 are not defined here.

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 144:

> 142:      */
> 143:     @ForceInline
> 144:     public static int digit2(byte[] str, int offset) {

Suggestion:

    public static int digit2(byte[] str, int offset) {
        // Used by trusted callers.  Assumes all necessary bounds checks have been done by the caller.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1943003191
PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1943003383

From alanb at openjdk.org  Wed Feb  5 14:21:16 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Feb 2025 14:21:16 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret
In-Reply-To: <X7Bafc1ifm5pvgMz4-lLlNo_SUDhpVBBkW9s-gK_-wQ=.123a1c9d-0b22-44bc-a04d-23021a278b14@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
 <X7Bafc1ifm5pvgMz4-lLlNo_SUDhpVBBkW9s-gK_-wQ=.123a1c9d-0b22-44bc-a04d-23021a278b14@github.com>
Message-ID: <of7U9Z3k6E53ifuiKKXTUkyal8QovuX1Rrn6LQgwchg=.89c11057-1b4c-426a-9549-d3290afa8840@github.com>

On Wed, 5 Feb 2025 10:20:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
>> 
>> Tested and passed tier1-3
>
> src/java.base/share/classes/java/lang/Module.java line 488:
> 
>> 486:         // if other is an unnamed module then check if this module reads
>> 487:         // all unnamed modules
>> 488:         return !other.isNamed()
> 
> This is a drive-by simplification.

Can you revert this, the original code was easier to read.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r1943023700

From alanb at openjdk.org  Wed Feb  5 14:21:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Feb 2025 14:21:15 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret
In-Reply-To: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
Message-ID: <CiKDk493a2TUStP4xWsv6Q_rzMeHhr7V_4yPTeBQug8=.5c1ad5b2-1329-4359-b00a-b9158e11c87c@github.com>

On Wed, 5 Feb 2025 10:17:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
> 
> Tested and passed tier1-3

src/java.base/share/classes/java/lang/Module.java line 344:

> 342:     }
> 343: 
> 344:     private String mod(Class<?> currentClass) {

Can you try to find a better name for this method as mod will be read as "modifiers" or "module name" and it's either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r1943028162

From pminborg at openjdk.org  Wed Feb  5 14:34:54 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Feb 2025 14:34:54 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v3]
In-Reply-To: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
Message-ID: <dn86GzYdgR-kgMdXeiX9yV77DY9y7tQvfNqAnwh6Buk=.2133576d-3781-4761-92bc-00d059be5b7c@github.com>

> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
> 
> Tested and passed tier1-3

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

  Revert change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23460/files
  - new: https://git.openjdk.org/jdk/pull/23460/files/3d6a5fc5..ca1dcbdd

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

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

PR: https://git.openjdk.org/jdk/pull/23460

From pminborg at openjdk.org  Wed Feb  5 14:43:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Feb 2025 14:43:52 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v4]
In-Reply-To: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
Message-ID: <yUlY6ni_YHl4r-vnp81oNN5sxTH2Q0lSU5v9GZgEOvI=.043aaaa6-c630-4877-a497-17cda7fa279b@github.com>

> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
> 
> Tested and passed tier1-3

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Remove reformatting
 - Remove file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23460/files
  - new: https://git.openjdk.org/jdk/pull/23460/files/ca1dcbdd..c095eb18

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

  Stats: 159 lines in 2 files changed: 0 ins; 158 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23460/head:pull/23460

PR: https://git.openjdk.org/jdk/pull/23460

From pminborg at openjdk.org  Wed Feb  5 14:31:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 5 Feb 2025 14:31:56 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v2]
In-Reply-To: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
Message-ID: <JZBfPTxKoRtdejtUib_lesQk49XCYE3f_Y1FcsPoV5w=.4cd3d37b-1596-4b30-a8a7-2c88fe99874e@github.com>

> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
> 
> Tested and passed tier1-3

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

  Rename method and variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23460/files
  - new: https://git.openjdk.org/jdk/pull/23460/files/6cda7623..3d6a5fc5

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

  Stats: 167 lines in 2 files changed: 158 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23460/head:pull/23460

PR: https://git.openjdk.org/jdk/pull/23460

From stuefe at openjdk.org  Wed Feb  5 15:12:11 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 5 Feb 2025 15:12:11 GMT
Subject: RFR: 8349241: Fix the concurrent execution JVM crash of
 StringBuilder::append(int/long) [v8]
In-Reply-To: <V2lMJazp8ayl9IwhuXzMf0CxL2zZEOu9hnuxMT9K7AI=.689ba744-1b76-457b-bfa8-62e49a7e7f80@github.com>
References: <gM_EuQ-A0O-ZFgEgaRut8EL1ZSxyX51VBs9fhvIl2SI=.81a65924-c4f1-4c51-8cb8-bbbd0c5f86b3@github.com>
 <a-y1EzAJTiAKoelqGW4JL8ZOfDCC2c_MJPQgjnzE43A=.3465034d-d1cd-4c1b-bdfe-dcfb71487666@github.com>
 <V2lMJazp8ayl9IwhuXzMf0CxL2zZEOu9hnuxMT9K7AI=.689ba744-1b76-457b-bfa8-62e49a7e7f80@github.com>
Message-ID: <WqErFssaDwAkKBfv_opuAYt2p9eDnEqhk1luDxYeDu8=.7243c66f-a585-4ad7-a48e-6aa690675298@github.com>

On Tue, 4 Feb 2025 22:59:55 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fx comments
>
> Thanks @RogerRiggs, your suggestion is great, I have fixed it, please help me review it again.

> > @wenshao Thank you. This seems to be a GC problem. I adjusted the JBS issue accordingly. You set this to "24" as affected version, but if this is a mainline issue, please add 25 and if possible all other versions this occurs in. If possible, please attach an hs-err file or at least the crash stack.
> 
> I added the hs-err file in the reply above. This is not a GC problem. The getChars method uses StringUTF16.putChar, which is equivalent to Unsafe.putChar. There is no out-of-bounds check. When concurrent, out-of-bounds writes will occur, causing JVM Crash.

@wenshao I see. Yes, you are right. Interesting - I was not aware of JDK code using unsafe-like put calls internally.

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

PR Comment: https://git.openjdk.org/jdk/pull/23427#issuecomment-2637132895

From yujige at gmail.com  Wed Feb  5 15:24:21 2025
From: yujige at gmail.com (Jige Yu)
Date: Wed, 5 Feb 2025 07:24:21 -0800
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>

Thanks Viktor!

I understand the problem.

The main reason I asked is because I want to understand how the core Java
team thinks of throwing an unchecked exception.

As explained above, I consider losing cancellability a big deal, a deal
breaker even. And I thought throwing unchecked is more acceptable. Because
the most common reason the mapConcurrent() VT can be interrupted is due to
cancellation from a parent mapConcurrent(), or a parent Structured
Concurrency scope. The cancellation could be either from an organic
exception, or from the downstream not needing more elements, like maybe due
to findFirst() already getting an element.

In both cases, since the concurrent operation is already cancelled (result
ignored), what exception pops up to the top level isn't that big of a deal
(perhaps only a log record will be seen?)

But if the core Java team considers it a bad idea, I would love to learn
and adjust.

On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> Hi,
>
> The problem is that mapConcurrent cannot throw InterruptedException
> because that is a checked exception, so we cannot clear the interrupted
> flag and throw that exception.
>
> So the updated semantics is to not cut the stream short but instead run to
> completion, restoring the interruption flag.
>
> There exists a couple of alternatives to this approach which I am
> contemplating, but they need to be further explored before I consider
> moving forward with any of them.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 27 January 2025 17:00
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> It looks like the current fix ignores interruption.
>
> I want to make sure my concern of it defeating cancellation is heard and
> understood.
>
> The scenarios I worry about is for a mapConcurrent() that fans out to
> another method call, which internally calls mapConcurrent() as
> implementation detail.
>
> An example:
>
> List<RefundResponse> refundHelper(transaction) {
>   transaction.creditCardAccounts.stream()
>     .gather(mapConcurrent(acct -> service.refund(acct))
>     .toList();
> }
>
> transactions.stream()
>     .gather(mapConcurrent(transaction -> refundHelper(transaction));
>
>
> It seems undesirable that in such a case all the service.refund() calls
> become non cancellable, because the only way the outer mapConcurrent()
> cancels the refundHelper() calls is through Thread.interrupt() the virtual
> threads that call refundHelper(), which would then be disabled by the inner
> mapConcurrent().
>
> Does this example make sense to you? I can further explain if anything
> isn't clear.
>
> But I want to make sure the decision to disable interruption is deliberate
> judgement call that such nested mapConcurrent() is unlikely,or not
> important.
>
> Cheers,
>
>
>
> On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi!
>
> Please see: https://github.com/openjdk/jdk/pull/23100
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Sunday, 26 January 2025 23:03
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: mapConcurrent() with InterruptedException
>
> Checking in on what you've found out, Viktor.
>
> From where we left off, I understand that you were looking at alternatives
> instead of silent truncation?
>
> Have you reached any conclusion?
>
> We touched on disallowing interruption during mapConcurrent(). I still
> have concerns with disabling cancellation, because it basically undoes this
> API note from the javadoc
> <https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>
> :
>
> API Note: In progress tasks will be attempted to be cancelled, on a
> best-effort basis, in situations where the downstream no longer wants to
> receive any more elements.
> In reality, people will use mapConcurrent() to fan out rpcs. Sometimes
> these rpcs are just a single blocking call; yet sometimes they may
> themselves be a Structured Concurrency scope, with 2 or 3 rpcs that
> constitute a single logical operation. Under two conditions, cancellation
> is imho important semantic:
>
>    1. The downstream code uses filter().findFirst(), and when it sees an
>    element, it will return and no longer needs the other pending rpcs to
>    complete. If cancellation is disabled, these unnecessary rpcs will waste
>    system resources.
>    2. One of the rpc throws and the Stream pipeline needs to propagate
>    the exception. Again, if the other rpcs cannot be cancelled, we'll have
>    many zombie rpcs.
>
> Zombie rpcs may or may not be a deal breaker, depending on the specific
> use case. But for a JDK library, losing cancellation would have a negative
> impact on usability.
>
> My 2c,
>
>
> On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi Ben,
>
> Thanks for raising these questions?getting feedback is crucial in the
> Preview stage of features.
>
> I wrote a reply to the Reddit thread so I'll just summarize here:
>
> It is important to note that *mapConcurrent()* is not a part of the
> Structured Concurrency JEPs, so it is not designed to join SC scopes.
>
> I'm currently experimenting with ignoring-but-restoring interrupts on the
> "calling thread" for *mapConcurrent()*, as well as capping
> work-in-progress to *maxConcurrency* (not only capping the concurrency
> but also the amount of completed-but-yet-to-be-pushed work). Both of these
> adjustments should increase predictability of behavior in the face of
> blocking operations with variable delays.
>
> Another adjustment I'm looking at right now is to harden/improve the
> cleanup to wait for concurrent tasks to acknowledge cancellation, so that
> once the finisher is done executing the VTs are known to have terminated.
>
> As for not preserving the encounter order, that would be a completely
> different thing, and I'd encourage you to experiment with that if that
> functionality would be interesting for your use-case(s).
>
> Again, thanks for your feedback!
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Friday, 3 January 2025 17:53
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* mapConcurrent() with InterruptedException
>
> Hi Java Experts,
>
> I sent this email incorrectly to loom-dev@ and was told on Reddit that
> core-libs-dev is the right list.
>
> The question is about the behavior of mapConcurrent() when the thread is
> interrupted.
>
> Currently mapConcurrent()'s finisher phase will re-interrupt the thread,
> then stop at whatever element that has already been processed and return.
>
> This strikes me as a surprising behavior, because for example if I'm
> running:
>
>    Stream.of(1, 2, 3)
>         .gather(mapConcurrent(i -> i * 2))
>         .toList()
>
> and the thread is being interrupted, the result could be any of [2], [2,
> 4] or [2, 4, 6].
>
> Since thread interruption is cooperative, there is no guarantee that the
> thread being interrupted will just abort. It's quite possible that it'll
> keep going and then will use for example [2] as the result of doubling the
> list of [1, 2, 3], which is imho incorrect.
>
> In the Reddit
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread,
> someone argued that interruption rarely happens so it's more of a
> theoretical issue. But interruption can easily happen in Structured
> Concurrency or in mapConcurrent() itself if any subtask has failed in order
> to cancel/interrupt the other ongoing tasks.
>
> There had been discussion about alternative strategies:
>
>    1. Don't respond to interruption and just keep running to completion.
>    2. Re-interrupt thread and wrap the InterruptedException in a standard
>    unchecked exception (StructuredConcurrencyInterruptedException?).
>
>
> I have concerns with option 1 because it disables cancellation propagation
> when mapConcurrent() itself is used in a subtask of a parent
> mapConcurrent() or in a StructuredConcurrencyScope.
>
> Both equivalent Future-composition async code, or C++'s fiber trees
> support cancellation propagation and imho it's a critical feature or else
> it's possible that a zombie thread is still sending RPCs long after the
> main thread has exited (failed, or falled back to some default action).
>
> My arguments for option 2:
>
>    1. InterruptedException is more error prone than traditional checked
>    exceptions for *users* to catch and handle. They can forget to
>    re-interrupt the thread. It's so confusing that even seasoned programmers
>    may not know they are *supposed to* re-interrupt the thread.
>    2. With Stream API using functional interfaces like Supplier,
>    Function, the option of just tacking on "throws IE" isn't available to many
>    users.
>    3. With Virtual Threads, it will be more acceptable, or even become
>    common to do blocking calls from a stream operation (including but
>    exclusive to mapConcurrent()). So the chance users are forced to deal with
>    IE will become substantially higher.
>    4. Other APIs such as the Structured Concurrency API have already
>    started wrapping system checked exceptions like ExecutionException,
>    TimeoutException in unchecked exceptions ( join()
>    <https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for
>    example).
>    5. Imho, exceptions that we'd rather users not catch and handle but
>    instead should mostly just propagate up as is, should be unchecked.
>
> There is also a side discussion
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about
> whether mapConcurrent() is better off preserving input order or push to
> downstream as soon as an element is computed. I'd love to discuss that
> topic too but maybe it's better to start a separate thread?
>
> Thank you and cheers!
>
> Ben Yu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250205/342ea7b0/attachment-0001.htm>

From dfuchs at openjdk.org  Wed Feb  5 15:54:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Feb 2025 15:54:16 GMT
Subject: RFR: 8336017: Deprecate java.util.logging.LoggingMXBean,
 its implementation, and accessor method for removal
In-Reply-To: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
References: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
Message-ID: <-8DxvKP7B4LKHHSptr4dIoSs0npdXvTjxRsCuMpTWqs=.f0105578-7d55-4e2d-a0e3-e3183823ca66@github.com>

On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982 in JDK 9.
> 
> These deprecations should be uprated to state they are for future removal.
> 
> java.util.logging.Logging (implements LoggingMXBean) should also be deprecated for removal.

The implementation of PlatformLoggingMXBean uses reflection to access the LoggingMXBean instance provided by the LogManager. If I am not mistaken what is proposed for removal here is actively used under the hood by the PlatformLoggingMXBean implementation - which means we cannot actually remove it?

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

PR Comment: https://git.openjdk.org/jdk/pull/23271#issuecomment-2637310374

From viktor.klang at oracle.com  Wed Feb  5 16:18:23 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 5 Feb 2025 16:18:23 +0000
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
Message-ID: <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Jige,

I opened an issue to track the concern, and I have proposed a change which seems to align well with how parallel streams behave under caller thread interruption.

I've opened the following PR for review:
https://github.com/openjdk/jdk/pull/23467

If you are able to make a local OpenJDK build with that solution you could check if it addresses your use-cases (or not).
[https://opengraph.githubassets.com/00e04f8a63bde12217df087df7ef8edee563adf7e925d07c75bdeae092180094/openjdk/jdk/pull/23467]<https://github.com/openjdk/jdk/pull/23467>
8349462: Gatherers.mapConcurrent could support async interrupts by viktorklang-ora ? Pull Request #23467 ? openjdk/jdk<https://github.com/openjdk/jdk/pull/23467>
This change is likely going to need some extra verbiage in the spec for mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how parallel streams work in conjunction with interrup...
github.com


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Wednesday, 5 February 2025 16:24
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

I understand the problem.

The main reason I asked is because I want to understand how the core Java team thinks of throwing an unchecked exception.

As explained above, I consider losing cancellability a big deal, a deal breaker even. And I thought throwing unchecked is more acceptable. Because the most common reason the mapConcurrent() VT can be interrupted is due to cancellation from a parent mapConcurrent(), or a parent Structured Concurrency scope. The cancellation could be either from an organic exception, or from the downstream not needing more elements, like maybe due to findFirst() already getting an element.

In both cases, since the concurrent operation is already cancelled (result ignored), what exception pops up to the top level isn't that big of a deal (perhaps only a log record will be seen?)

But if the core Java team considers it a bad idea, I would love to learn and adjust.

On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi,

The problem is that mapConcurrent cannot throw InterruptedException because that is a checked exception, so we cannot clear the interrupted flag and throw that exception.

So the updated semantics is to not cut the stream short but instead run to completion, restoring the interruption flag.

There exists a couple of alternatives to this approach which I am contemplating, but they need to be further explored before I consider moving forward with any of them.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 27 January 2025 17:00
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

It looks like the current fix ignores interruption.

I want to make sure my concern of it defeating cancellation is heard and understood.

The scenarios I worry about is for a mapConcurrent() that fans out to another method call, which internally calls mapConcurrent() as implementation detail.

An example:


List<RefundResponse> refundHelper(transaction) {
  transaction.creditCardAccounts.stream()
    .gather(mapConcurrent(acct -> service.refund(acct))
    .toList();
}

transactions.stream()
    .gather(mapConcurrent(transaction -> refundHelper(transaction));

It seems undesirable that in such a case all the service.refund() calls become non cancellable, because the only way the outer mapConcurrent() cancels the refundHelper() calls is through Thread.interrupt() the virtual threads that call refundHelper(), which would then be disabled by the inner mapConcurrent().

Does this example make sense to you? I can further explain if anything isn't clear.

But I want to make sure the decision to disable interruption is deliberate judgement call that such nested mapConcurrent() is unlikely,or not important.

Cheers,



On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

Please see: https://github.com/openjdk/jdk/pull/23100<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 26 January 2025 23:03
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: mapConcurrent() with InterruptedException

Checking in on what you've found out, Viktor.

From where we left off, I understand that you were looking at alternatives instead of silent truncation?

Have you reached any conclusion?

We touched on disallowing interruption during mapConcurrent(). I still have concerns with disabling cancellation, because it basically undoes this API note from the javadoc<https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>:


API Note:

In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements.
In reality, people will use mapConcurrent() to fan out rpcs. Sometimes these rpcs are just a single blocking call; yet sometimes they may themselves be a Structured Concurrency scope, with 2 or 3 rpcs that constitute a single logical operation. Under two conditions, cancellation is imho important semantic:

  1.  The downstream code uses filter().findFirst(), and when it sees an element, it will return and no longer needs the other pending rpcs to complete. If cancellation is disabled, these unnecessary rpcs will waste system resources.
  2.  One of the rpc throws and the Stream pipeline needs to propagate the exception. Again, if the other rpcs cannot be cancelled, we'll have many zombie rpcs.

Zombie rpcs may or may not be a deal breaker, depending on the specific use case. But for a JDK library, losing cancellation would have a negative impact on usability.

My 2c,


On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Ben,

Thanks for raising these questions?getting feedback is crucial in the Preview stage of features.

I wrote a reply to the Reddit thread so I'll just summarize here:

It is important to note that mapConcurrent() is not a part of the Structured Concurrency JEPs, so it is not designed to join SC scopes.

I'm currently experimenting with ignoring-but-restoring interrupts on the "calling thread" for mapConcurrent(), as well as capping work-in-progress to maxConcurrency (not only capping the concurrency but also the amount of completed-but-yet-to-be-pushed work). Both of these adjustments should increase predictability of behavior in the face of blocking operations with variable delays.

Another adjustment I'm looking at right now is to harden/improve the cleanup to wait for concurrent tasks to acknowledge cancellation, so that once the finisher is done executing the VTs are known to have terminated.

As for not preserving the encounter order, that would be a completely different thing, and I'd encourage you to experiment with that if that functionality would be interesting for your use-case(s).

Again, thanks for your feedback!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Friday, 3 January 2025 17:53
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: mapConcurrent() with InterruptedException

Hi Java Experts,

I sent this email incorrectly to loom-dev@ and was told on Reddit that core-libs-dev is the right list.

The question is about the behavior of mapConcurrent() when the thread is interrupted.

Currently mapConcurrent()'s finisher phase will re-interrupt the thread, then stop at whatever element that has already been processed and return.

This strikes me as a surprising behavior, because for example if I'm running:

   Stream.of(1, 2, 3)
        .gather(mapConcurrent(i -> i * 2))
        .toList()

and the thread is being interrupted, the result could be any of [2], [2, 4] or [2, 4, 6].

Since thread interruption is cooperative, there is no guarantee that the thread being interrupted will just abort. It's quite possible that it'll keep going and then will use for example [2] as the result of doubling the list of [1, 2, 3], which is imho incorrect.

In the Reddit<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks.

There had been discussion about alternative strategies:

  1.  Don't respond to interruption and just keep running to completion.
  2.  Re-interrupt thread and wrap the InterruptedException in a standard unchecked exception (StructuredConcurrencyInterruptedException?).

I have concerns with option 1 because it disables cancellation propagation when mapConcurrent() itself is used in a subtask of a parent mapConcurrent() or in a StructuredConcurrencyScope.

Both equivalent Future-composition async code, or C++'s fiber trees support cancellation propagation and imho it's a critical feature or else it's possible that a zombie thread is still sending RPCs long after the main thread has exited (failed, or falled back to some default action).

My arguments for option 2:

  1.  InterruptedException is more error prone than traditional checked exceptions for users to catch and handle. They can forget to re-interrupt the thread. It's so confusing that even seasoned programmers may not know they are supposed to re-interrupt the thread.
  2.  With Stream API using functional interfaces like Supplier, Function, the option of just tacking on "throws IE" isn't available to many users.
  3.  With Virtual Threads, it will be more acceptable, or even become common to do blocking calls from a stream operation (including but exclusive to mapConcurrent()). So the chance users are forced to deal with IE will become substantially higher.
  4.  Other APIs such as the Structured Concurrency API have already started wrapping system checked exceptions like ExecutionException, TimeoutException in unchecked exceptions ( join()<https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for example).
  5.  Imho, exceptions that we'd rather users not catch and handle but instead should mostly just propagate up as is, should be unchecked.

There is also a side discussion<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread?

Thank you and cheers!

Ben Yu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250205/075c14fe/attachment-0001.htm>

From kevinw at openjdk.org  Wed Feb  5 16:20:57 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 5 Feb 2025 16:20:57 GMT
Subject: RFR: 8336017: Deprecate java.util.logging.LoggingMXBean,
 its implementation, and accessor method for removal
In-Reply-To: <-8DxvKP7B4LKHHSptr4dIoSs0npdXvTjxRsCuMpTWqs=.f0105578-7d55-4e2d-a0e3-e3183823ca66@github.com>
References: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
 <-8DxvKP7B4LKHHSptr4dIoSs0npdXvTjxRsCuMpTWqs=.f0105578-7d55-4e2d-a0e3-e3183823ca66@github.com>
Message-ID: <7LhVkP-yhPE8sCte6OKiH8MLcgy8ud7iYXM6J-8CjWQ=.e389ffc4-0d12-443c-b16c-1244cff79b82@github.com>

On Wed, 5 Feb 2025 15:51:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982 in JDK 9.
>> 
>> These deprecations should be uprated to state they are for future removal.
>> 
>> java.util.logging.Logging (implements LoggingMXBean) should also be deprecated for removal.
>
> The implementation of PlatformLoggingMXBean uses reflection to access the LoggingMXBean instance provided by the LogManager. If I am not mistaken what is proposed for removal here is actively used under the hood by the PlatformLoggingMXBean implementation - which means we cannot actually remove it?

Hi @dfuch -

What is proposed here is that java.util.logging.LoggingMXBean should be marked for removal.

Having both PlatformLoggingMXBean and LoggingMXBean in existence is confusing. 

Actual removal is not trivial, as yes the "new" PlatformLoggingMXBean is dependent on the existing LoggingMXBean implementation.

(Looking inside LoggingMXBean and seeing the actual implementations that accesses LogManager is also confusing.)

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

PR Comment: https://git.openjdk.org/jdk/pull/23271#issuecomment-2637389915

From vklang at openjdk.org  Wed Feb  5 16:21:20 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 5 Feb 2025 16:21:20 GMT
Subject: RFR: 8349462: Gatherers.mapConcurrent could support async interrupts
Message-ID: <MiGjmr0ni-K6kF_bTwR2qMEEMal2Q8xSRPMgOHMcld0=.41bd792f-c20b-4a8e-8cfd-08121e06ddef@github.com>

This change is likely going to need some extra verbiage in the spec for mapConcurrent, and thus a CSR.
This behavior aligns mapConcurrent with how parallel streams work in conjunction with interruptions of the caller thread.

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

Commit messages:
 - Enabling the async interruption test for parallel streams as well
 - Adds support for async interruption / cancellation of Gatherers.mapConcurrent

Changes: https://git.openjdk.org/jdk/pull/23467/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23467&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349462
  Stats: 52 lines in 2 files changed: 20 ins; 11 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/23467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23467/head:pull/23467

PR: https://git.openjdk.org/jdk/pull/23467

From swen at openjdk.org  Wed Feb  5 16:21:47 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 5 Feb 2025 16:21:47 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v17]
In-Reply-To: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
Message-ID: <MogByl_LFGh0oAYhtEEciRBDeYn6PULXzpB5jnVPdXY=.ced60964-6e0a-42d7-ba77-75c210f37981@github.com>

> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - fix comments
 - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22919/files
  - new: https://git.openjdk.org/jdk/pull/22919/files/0c43e9ae..c8f514f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=15-16

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

PR: https://git.openjdk.org/jdk/pull/22919

From duke at openjdk.org  Wed Feb  5 16:38:15 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 5 Feb 2025 16:38:15 GMT
Subject: RFR: 8346946: Allow class loaders to bind to layers for service
 loading
In-Reply-To: <0BSZVYQ1bTJbPjGfcmK8OWw4hWl10_0ooq3EZuubNvg=.c68a7dc6-1801-48c4-b610-2cff1ddd4635@github.com>
References: <0BSZVYQ1bTJbPjGfcmK8OWw4hWl10_0ooq3EZuubNvg=.c68a7dc6-1801-48c4-b610-2cff1ddd4635@github.com>
Message-ID: <lGgOCWnRyWY9E3vHcpLIz3_EXifMwQRjCnobMQQ-74Y=.c0d6d408-9b31-4a8e-b770-a6365b723600@github.com>

On Thu, 2 Jan 2025 17:13:17 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> When loading services by class loader (`ServiceLoader.load(Class,ClassLoader)`), the module layers bound to the given class loader are searched for services, along with the layers bound to class loader's parent, and so on. For non-hierarchical class loader arrangements, this breaks down because the parent class loader of non-hierarchical class loaders is typically `null` (i.e. the boot class loader), while the class loader might have multiple dependency class loaders which replace the role of parent.
> 
> Add an API to `ClassLoader` which allows additional layers to be bound to the class loader for the purpose of service loading by class loader, without affecting reliable configuration of modules (see [JDK-8346439](https://bugs.openjdk.org/browse/JDK-8346439)), which allows non-hierarchical class loaders to resolve service providers in dependency class loaders.

The discussion on `jigsaw-dev` relating to this issue has fizzled out to a degree, but I'm hoping for some progress yet later.

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

PR Comment: https://git.openjdk.org/jdk/pull/22905#issuecomment-2637439424

From rgiulietti at openjdk.org  Wed Feb  5 16:51:14 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Feb 2025 16:51:14 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v17]
In-Reply-To: <MogByl_LFGh0oAYhtEEciRBDeYn6PULXzpB5jnVPdXY=.ced60964-6e0a-42d7-ba77-75c210f37981@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
 <MogByl_LFGh0oAYhtEEciRBDeYn6PULXzpB5jnVPdXY=.ced60964-6e0a-42d7-ba77-75c210f37981@github.com>
Message-ID: <_ZHmRNXFpLIuQA4H0WAKJXBjMVGb6IaSDici_j2rNno=.24f7be8b-b429-4274-9271-e70892062c9d@github.com>

On Wed, 5 Feb 2025 16:21:47 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
>> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
>> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
>> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix comments
>  - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 138:

> 136: 
> 137:     /**
> 138:      * Determine whether the two character in str are both digits. If they are, return (str[off] - '0') * 10 + (str[off] - '0'), otherwise return -1

`off` -> `offset`
The second index should be `offset + 1`.
Same in the `@return` clause.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1943313957

From rgiulietti at openjdk.org  Wed Feb  5 16:51:16 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Feb 2025 16:51:16 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v15]
In-Reply-To: <9YscIlbn-fQ3xQJjO_K4CUrAOIqmumcOBQSVA2v4CzA=.50fdd8f6-3da1-4a01-863b-228ecb7cfe37@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
 <NzakYtXz3t3oZN9DUIDvfqlKuSZctKb7SN3crDdU73g=.d1489dbe-037e-44c2-83b6-6f99b557861e@github.com>
 <9YscIlbn-fQ3xQJjO_K4CUrAOIqmumcOBQSVA2v4CzA=.50fdd8f6-3da1-4a01-863b-228ecb7cfe37@github.com>
Message-ID: <_s004kWQvTaOtjsvPaSzJN1LbNdF4zD_KzU-Z_lVzZk=.d5c7a1b2-70ed-4c5e-b0c0-584bb1e09f7d@github.com>

On Wed, 5 Feb 2025 12:03:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix JdbExprTest
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 143:
> 
>> 141:      * @return If both characters are numbers, return d0 * 10 + d1, otherwise return -1
>> 142:      */
>> 143:     @ForceInline
> 
> Can we leave this out? From the doc: "This annotation must be used sparingly."
> I tried without and on M1 performance does not seem to be affected.

Again, can we avoid `@ForceInline`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1943315049

From swen at openjdk.org  Wed Feb  5 17:01:32 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 5 Feb 2025 17:01:32 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v18]
In-Reply-To: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
Message-ID: <-G2JiiRWhJub7plFoYx3O61O4xgZSKoqFgAlP0sQePY=.e06fef9f-5ec2-42f1-aaf4-3b3abd82785d@github.com>

> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.

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

  fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22919/files
  - new: https://git.openjdk.org/jdk/pull/22919/files/c8f514f2..a4181b08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=16-17

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

PR: https://git.openjdk.org/jdk/pull/22919

From swen at openjdk.org  Wed Feb  5 17:01:33 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 5 Feb 2025 17:01:33 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v15]
In-Reply-To: <_s004kWQvTaOtjsvPaSzJN1LbNdF4zD_KzU-Z_lVzZk=.d5c7a1b2-70ed-4c5e-b0c0-584bb1e09f7d@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
 <NzakYtXz3t3oZN9DUIDvfqlKuSZctKb7SN3crDdU73g=.d1489dbe-037e-44c2-83b6-6f99b557861e@github.com>
 <9YscIlbn-fQ3xQJjO_K4CUrAOIqmumcOBQSVA2v4CzA=.50fdd8f6-3da1-4a01-863b-228ecb7cfe37@github.com>
 <_s004kWQvTaOtjsvPaSzJN1LbNdF4zD_KzU-Z_lVzZk=.d5c7a1b2-70ed-4c5e-b0c0-584bb1e09f7d@github.com>
Message-ID: <9xDRX2gtnID2qcMJGZRyhmdHWCQOxA0stKzd3k6IkNs=.8d5b69fa-043f-486e-b8e9-b5375ed9853b@github.com>

On Wed, 5 Feb 2025 16:48:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 143:
>> 
>>> 141:      * @return If both characters are numbers, return d0 * 10 + d1, otherwise return -1
>>> 142:      */
>>> 143:     @ForceInline
>> 
>> Can we leave this out? From the doc: "This annotation must be used sparingly."
>> I tried without and on M1 performance does not seem to be affected.
>
> Again, can we avoid `@ForceInline`?

The codeSize of the digit2 method is 56, greater than C1 MaxInline 35. I was worried about the performance in the early runtime, so I added @ForceInline

>> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 175:
>> 
>>> 173:          */
>>> 174:         int d;
>>> 175:         short x = UNSAFE.getShortUnaligned(str, Unsafe.ARRAY_BYTE_BASE_OFFSET + offset, false);
>> 
>> @wenshao I'm a bit worried about the use of Unsafe here.
>> 
>> This method is `public` (although in an internal package), and while it is used correctly in this PR, there's no warning in the doc that `str` and `offset` must come from a trusted caller that ensures that they are safe to use with, well..., Unsafe.
>> 
>> Did you consider safer alternatives, like usage of `VarHandle`, even if that might mean a slight performance degradation?
>
> Never mind, `VarHandle` cannot be used in this case.

Using VarHandle in this scenario may affect JVM startup performance

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1943325107
PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1943328441

From swen at openjdk.org  Wed Feb  5 17:06:57 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 5 Feb 2025 17:06:57 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v19]
In-Reply-To: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
Message-ID: <QrgMhkd02a2XjQWEC-lxm0hqRhcrc3kcXFQV_c3G3M0=.05db60a1-4184-45e2-ae8f-8beee48e7d0b@github.com>

> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.

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

  remove ForceInline

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22919/files
  - new: https://git.openjdk.org/jdk/pull/22919/files/a4181b08..3a555c5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=17-18

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

PR: https://git.openjdk.org/jdk/pull/22919

From coleenp at openjdk.org  Wed Feb  5 17:57:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Feb 2025 17:57:29 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v5]
In-Reply-To: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
Message-ID: <AKYfWWvD5swMFVmt2c0zHTMd7d1q8b2kjcONoZP3Lp4=.56ce146a-a9e9-4d01-9fcb-8fb76b4b90d1@github.com>

> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.

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

 - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Remove @Stable annotation for final field.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23396/files
  - new: https://git.openjdk.org/jdk/pull/23396/files/d04b808f..6bb7fe6e

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

  Stats: 9 lines in 2 files changed: 1 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23396/head:pull/23396

PR: https://git.openjdk.org/jdk/pull/23396

From coleenp at openjdk.org  Wed Feb  5 17:57:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Feb 2025 17:57:31 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]
In-Reply-To: <rnBxm-eKFKaOGdMay4i94tiSB28d_9s6SOrfGAnrTZk=.875ea4cd-2d71-4139-997c-ef1f1a0fd59d@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <syxVRD9ASKql288dZ8hdYJjliScymiDGldc7fSoEAiU=.d4084758-4fb0-496f-a7bb-ad0093129f11@github.com>
 <rnBxm-eKFKaOGdMay4i94tiSB28d_9s6SOrfGAnrTZk=.875ea4cd-2d71-4139-997c-ef1f1a0fd59d@github.com>
Message-ID: <as8AhJFiM7kItFtO_ryI9gtRMyedA3SBBPMU53jA32A=.f1630384-852e-4273-83ff-52783e8a4699@github.com>

On Wed, 5 Feb 2025 05:35:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test that knows which fields are hidden from reflection in jvmci.
>
> src/java.base/share/classes/java/lang/Class.java line 239:
> 
>> 237:      * generated.
>> 238:      */
>> 239:     private Class(ClassLoader loader, Class<?> arrayComponentType, ProtectionDomain pd) {
> 
> If this constructor is not used then why do we need to add the PD argument, rather than just set it to null? For that matter why do we even need the field if nothing is ever setting it? I'm missing something here.

@DanHeidinga suggested this for my other PR as a convention that's used for the j.l.Class constructor.

> src/java.base/share/classes/java/lang/Class.java line 2701:
> 
>> 2699: 
>> 2700:     @Stable
>> 2701:     private transient final ProtectionDomain protectionDomain;
> 
> Isn't `@Stable` superfluous with a final field?

Yes, I thought I removed it but that was probably the other PR.

> src/java.base/share/classes/java/lang/Class.java line 2722:
> 
>> 2720:      */
>> 2721:     public ProtectionDomain getProtectionDomain() {
>> 2722:         if (protectionDomain == null) {
> 
> Does this imply the class is a primitive class?

No I believe classes that are bootstrap classes don't generally have a protection domain.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1943394960
PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1943393526
PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1943394193

From liach at openjdk.org  Wed Feb  5 18:00:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Feb 2025 18:00:55 GMT
Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location
 [v2]
In-Reply-To: <QUMCGq-Mw5eFs_d0Sl4Q5Hm7Hhr3pP45CA2AmMXbUhQ=.5c5dcdbf-3d81-4b64-8edf-7e933f00509e@github.com>
References: <QUMCGq-Mw5eFs_d0Sl4Q5Hm7Hhr3pP45CA2AmMXbUhQ=.5c5dcdbf-3d81-4b64-8edf-7e933f00509e@github.com>
Message-ID: <pvy8rpgrO7FnbgvKG4JLpBF49H8CZQE2Ac139pz1qjE=.475f447d-9eb1-4122-aa5d-f3381d184cb3@github.com>

> Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version.
> 
> Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity.
> 
> The new methods are all in `AccessFlag.Location`:
> - `Set<AccessFlag> flags()`
> - `int flagsMask()`
> - `Set<AccessFlag> flags(ClassFileFormatVersion)`
> - `int flagsMask(ClassFileFormatVersion)`
> 
> Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly.
> 
> Testing: Tier 1-3

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

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-location-accessors
 - More links
 - ClassLoading order, Typos in NPE test
 - 8347471: Provide valid flags and mask in AccessFlag.Location

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23095/files
  - new: https://git.openjdk.org/jdk/pull/23095/files/fa362054..27faa8b2

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

  Stats: 62560 lines in 3881 files changed: 30110 ins; 16410 del; 16040 mod
  Patch: https://git.openjdk.org/jdk/pull/23095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23095/head:pull/23095

PR: https://git.openjdk.org/jdk/pull/23095

From joehw at openjdk.org  Wed Feb  5 18:04:15 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 5 Feb 2025 18:04:15 GMT
Subject: RFR: 8344925: translet-name ignored,
 when package-name is also set via TransformerFactory.setAttribute
In-Reply-To: <kfTrynEd2-z8GfOCuvUOiY1VAOd2yO-qrGhGLCWLHmo=.dd17a46e-055c-4206-b129-39ad143ac474@github.com>
References: <kfTrynEd2-z8GfOCuvUOiY1VAOd2yO-qrGhGLCWLHmo=.dd17a46e-055c-4206-b129-39ad143ac474@github.com>
Message-ID: <TEeFRuc_jIWaVyd5ZvQPUn_zsxTzSDEDJLjkAcDU5Gs=.82562650-6d11-4a6f-bfcb-b1d54ca66328@github.com>

On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng <duke at openjdk.org> wrote:

> ?String)
> 
> This bug seems from the improper handling of package and class name initialization in `XSLTC` since there is a default value of  `_packageName` with `die.verwandlung`. This fix is just adjusting to call `setPackageName` before `setClassName`.
> 
> I've done the tire1 and tire2 tests. The tire1 tests passed and tire2 reports
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  
>>> jtreg:test/hotspot/jtreg:tier2                      745   744     1     0 <<
>>> jtreg:test/jdk:tier2                               4142  4137     2     3 <<
>    jtreg:test/langtools:tier2                           12    12     0     0  
>    jtreg:test/jaxp:tier2                               514   514     0     0  
>    jtreg:test/docs:tier2                                 1     1     0     0  
> ==============================
> TEST FAILURE
> 
> 
> The failed tests are
> 
> JT Harness : Tests that failed
> runtime/Thread/ThreadCountLimit.java#id0: Stress test that reaches the process limit for thread count, or time limit.
> 
> JT Harness : Tests that failed
> java/net/InetAddress/CheckJNI.java: java -Xcheck:jni failing in net code on Solaris / [Datagram]Socket.getLocalAddress() failure
> java/net/Socket/LinkLocal.java: Connecting to a link-local IPv6 address should not causes a SocketException to be thrown.
> 
> JT Harness : Tests that had errors
> java/net/URL/EarlyOrDelayedParsing.java: URL built-in protocol handlers should parse the URL early to avoid constructing URLs for which openConnection would later throw an exception, when possible.
> java/net/ipv6tests/UdpTest.java: IPv6 support for Windows XP and 2003 server.
> java/nio/channels/DatagramChannel/SendReceiveMaxSize.java: Check that it is possible to send and receive datagrams of maximum size on macOS.

Sorry I missed your PR. Please note that, the right procedure to take over an issue is to ask the person assigned to the bug, get the bug assigned to you before starting any work, that would avoid confusion and duplicate work.

If you plan to work on any patch in the future, please remember to add a test. If a test is not necessary, add the relevant label.

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

PR Comment: https://git.openjdk.org/jdk/pull/22425#issuecomment-2637650741

From joehw at openjdk.org  Wed Feb  5 18:05:36 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 5 Feb 2025 18:05:36 GMT
Subject: RFR: 8344925: translet-name ignored when package-name is also set
In-Reply-To: <uOk3nctNL3ytpqgVPZ00vc4pcVH4PdA33xV2wuFrWLk=.1e705598-3a47-403b-bebe-bfd7629e1a54@github.com>
References: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
 <GoDsAmJ4JIoMyjcB0OxalGnfxboFQKrU_dlC9_g3fkw=.519061a0-7e50-4490-aa86-b8a624b3260f@github.com>
 <uOk3nctNL3ytpqgVPZ00vc4pcVH4PdA33xV2wuFrWLk=.1e705598-3a47-403b-bebe-bfd7629e1a54@github.com>
Message-ID: <hxB6_7R75K-f9MKXfEYlFrE7KJo-vos4itfDjdFg2oA=.be3eba27-3c43-4282-a624-06d50b916440@github.com>

On Wed, 5 Feb 2025 10:57:14 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > @JoeWang-Java Have you seen https://git.openjdk.org/jdk/pull/22425?
> 
> Just mentioning since it looks like a duplicate proposal.

Indeed, I missed that. The right procedure to take over an issue is to ask the person assigned to the bug, that would avoid any confusion and duplicate effort. Unfortunately, he never asked me.

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

PR Comment: https://git.openjdk.org/jdk/pull/23446#issuecomment-2637653971

From rgiulietti at openjdk.org  Wed Feb  5 18:20:18 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 5 Feb 2025 18:20:18 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v10]
In-Reply-To: <18GzgCOHLT1CTN5AQ2sPo58GFSUCsFkBhRoNKvKHPak=.7e2f566f-ae7d-470c-9c9b-3f638d2fc4f5@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
 <uGzHnFfK6QQKyggBNfk-vLbbrqzCq2gEG49rO7TpONQ=.c5165b56-7102-4401-adc9-8c482254bae3@github.com>
 <18GzgCOHLT1CTN5AQ2sPo58GFSUCsFkBhRoNKvKHPak=.7e2f566f-ae7d-470c-9c9b-3f638d2fc4f5@github.com>
Message-ID: <rzy7VIj42K-_bNw3ljGXM30sC-qt9c8iXNrN9D7wsEc=.c2c79bc6-b062-47a0-bc8c-32e6f3273199@github.com>

On Tue, 28 Jan 2025 19:39:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   error message
>
> Ran tier 1-3 for latest commit as of comment. No failure besides a known one in serviceability.

@liach I think that the usage of Unsafe is correct in the context of this PR. Can you have a look?

(Unfortunately, since this code is used early in the VM startup, we can't use safer alternatives like `VarHandle` or `ByteArray`, short of reading the bytes individually with ordinary array access.)

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

PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2637685876

From yujige at gmail.com  Wed Feb  5 18:20:37 2025
From: yujige at gmail.com (Jige Yu)
Date: Wed, 5 Feb 2025 10:20:37 -0800
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>

Oh good call!

I forgot to check what parallel streams do upon interruption (didn't think
they do any blocking calls, but at least the main thread must block).

On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> Hi Jige,
>
> I opened an issue to track the concern, and I have proposed a change which
> seems to align well with how parallel streams behave under caller thread
> interruption.
>
> I've opened the following PR for review:
> https://github.com/openjdk/jdk/pull/23467
>
> If you are able to make a local OpenJDK build with that solution you could
> check if it addresses your use-cases (or not).
> <https://github.com/openjdk/jdk/pull/23467>
> 8349462: Gatherers.mapConcurrent could support async interrupts by
> viktorklang-ora ? Pull Request #23467 ? openjdk/jdk
> <https://github.com/openjdk/jdk/pull/23467>
> This change is likely going to need some extra verbiage in the spec for
> mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how
> parallel streams work in conjunction with interrup...
> github.com
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 5 February 2025 16:24
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> I understand the problem.
>
> The main reason I asked is because I want to understand how the core Java
> team thinks of throwing an unchecked exception.
>
> As explained above, I consider losing cancellability a big deal, a deal
> breaker even. And I thought throwing unchecked is more acceptable. Because
> the most common reason the mapConcurrent() VT can be interrupted is due to
> cancellation from a parent mapConcurrent(), or a parent Structured
> Concurrency scope. The cancellation could be either from an organic
> exception, or from the downstream not needing more elements, like maybe due
> to findFirst() already getting an element.
>
> In both cases, since the concurrent operation is already cancelled (result
> ignored), what exception pops up to the top level isn't that big of a deal
> (perhaps only a log record will be seen?)
>
> But if the core Java team considers it a bad idea, I would love to learn
> and adjust.
>
> On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi,
>
> The problem is that mapConcurrent cannot throw InterruptedException
> because that is a checked exception, so we cannot clear the interrupted
> flag and throw that exception.
>
> So the updated semantics is to not cut the stream short but instead run to
> completion, restoring the interruption flag.
>
> There exists a couple of alternatives to this approach which I am
> contemplating, but they need to be further explored before I consider
> moving forward with any of them.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 27 January 2025 17:00
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> It looks like the current fix ignores interruption.
>
> I want to make sure my concern of it defeating cancellation is heard and
> understood.
>
> The scenarios I worry about is for a mapConcurrent() that fans out to
> another method call, which internally calls mapConcurrent() as
> implementation detail.
>
> An example:
>
> List<RefundResponse> refundHelper(transaction) {
>   transaction.creditCardAccounts.stream()
>     .gather(mapConcurrent(acct -> service.refund(acct))
>     .toList();
> }
>
> transactions.stream()
>     .gather(mapConcurrent(transaction -> refundHelper(transaction));
>
>
> It seems undesirable that in such a case all the service.refund() calls
> become non cancellable, because the only way the outer mapConcurrent()
> cancels the refundHelper() calls is through Thread.interrupt() the virtual
> threads that call refundHelper(), which would then be disabled by the inner
> mapConcurrent().
>
> Does this example make sense to you? I can further explain if anything
> isn't clear.
>
> But I want to make sure the decision to disable interruption is deliberate
> judgement call that such nested mapConcurrent() is unlikely,or not
> important.
>
> Cheers,
>
>
>
> On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi!
>
> Please see: https://github.com/openjdk/jdk/pull/23100
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Sunday, 26 January 2025 23:03
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: mapConcurrent() with InterruptedException
>
> Checking in on what you've found out, Viktor.
>
> From where we left off, I understand that you were looking at alternatives
> instead of silent truncation?
>
> Have you reached any conclusion?
>
> We touched on disallowing interruption during mapConcurrent(). I still
> have concerns with disabling cancellation, because it basically undoes this
> API note from the javadoc
> <https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>
> :
>
> API Note: In progress tasks will be attempted to be cancelled, on a
> best-effort basis, in situations where the downstream no longer wants to
> receive any more elements.
> In reality, people will use mapConcurrent() to fan out rpcs. Sometimes
> these rpcs are just a single blocking call; yet sometimes they may
> themselves be a Structured Concurrency scope, with 2 or 3 rpcs that
> constitute a single logical operation. Under two conditions, cancellation
> is imho important semantic:
>
>    1. The downstream code uses filter().findFirst(), and when it sees an
>    element, it will return and no longer needs the other pending rpcs to
>    complete. If cancellation is disabled, these unnecessary rpcs will waste
>    system resources.
>    2. One of the rpc throws and the Stream pipeline needs to propagate
>    the exception. Again, if the other rpcs cannot be cancelled, we'll have
>    many zombie rpcs.
>
> Zombie rpcs may or may not be a deal breaker, depending on the specific
> use case. But for a JDK library, losing cancellation would have a negative
> impact on usability.
>
> My 2c,
>
>
> On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi Ben,
>
> Thanks for raising these questions?getting feedback is crucial in the
> Preview stage of features.
>
> I wrote a reply to the Reddit thread so I'll just summarize here:
>
> It is important to note that *mapConcurrent()* is not a part of the
> Structured Concurrency JEPs, so it is not designed to join SC scopes.
>
> I'm currently experimenting with ignoring-but-restoring interrupts on the
> "calling thread" for *mapConcurrent()*, as well as capping
> work-in-progress to *maxConcurrency* (not only capping the concurrency
> but also the amount of completed-but-yet-to-be-pushed work). Both of these
> adjustments should increase predictability of behavior in the face of
> blocking operations with variable delays.
>
> Another adjustment I'm looking at right now is to harden/improve the
> cleanup to wait for concurrent tasks to acknowledge cancellation, so that
> once the finisher is done executing the VTs are known to have terminated.
>
> As for not preserving the encounter order, that would be a completely
> different thing, and I'd encourage you to experiment with that if that
> functionality would be interesting for your use-case(s).
>
> Again, thanks for your feedback!
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Friday, 3 January 2025 17:53
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* mapConcurrent() with InterruptedException
>
> Hi Java Experts,
>
> I sent this email incorrectly to loom-dev@ and was told on Reddit that
> core-libs-dev is the right list.
>
> The question is about the behavior of mapConcurrent() when the thread is
> interrupted.
>
> Currently mapConcurrent()'s finisher phase will re-interrupt the thread,
> then stop at whatever element that has already been processed and return.
>
> This strikes me as a surprising behavior, because for example if I'm
> running:
>
>    Stream.of(1, 2, 3)
>         .gather(mapConcurrent(i -> i * 2))
>         .toList()
>
> and the thread is being interrupted, the result could be any of [2], [2,
> 4] or [2, 4, 6].
>
> Since thread interruption is cooperative, there is no guarantee that the
> thread being interrupted will just abort. It's quite possible that it'll
> keep going and then will use for example [2] as the result of doubling the
> list of [1, 2, 3], which is imho incorrect.
>
> In the Reddit
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread,
> someone argued that interruption rarely happens so it's more of a
> theoretical issue. But interruption can easily happen in Structured
> Concurrency or in mapConcurrent() itself if any subtask has failed in order
> to cancel/interrupt the other ongoing tasks.
>
> There had been discussion about alternative strategies:
>
>    1. Don't respond to interruption and just keep running to completion.
>    2. Re-interrupt thread and wrap the InterruptedException in a standard
>    unchecked exception (StructuredConcurrencyInterruptedException?).
>
>
> I have concerns with option 1 because it disables cancellation propagation
> when mapConcurrent() itself is used in a subtask of a parent
> mapConcurrent() or in a StructuredConcurrencyScope.
>
> Both equivalent Future-composition async code, or C++'s fiber trees
> support cancellation propagation and imho it's a critical feature or else
> it's possible that a zombie thread is still sending RPCs long after the
> main thread has exited (failed, or falled back to some default action).
>
> My arguments for option 2:
>
>    1. InterruptedException is more error prone than traditional checked
>    exceptions for *users* to catch and handle. They can forget to
>    re-interrupt the thread. It's so confusing that even seasoned programmers
>    may not know they are *supposed to* re-interrupt the thread.
>    2. With Stream API using functional interfaces like Supplier,
>    Function, the option of just tacking on "throws IE" isn't available to many
>    users.
>    3. With Virtual Threads, it will be more acceptable, or even become
>    common to do blocking calls from a stream operation (including but
>    exclusive to mapConcurrent()). So the chance users are forced to deal with
>    IE will become substantially higher.
>    4. Other APIs such as the Structured Concurrency API have already
>    started wrapping system checked exceptions like ExecutionException,
>    TimeoutException in unchecked exceptions ( join()
>    <https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for
>    example).
>    5. Imho, exceptions that we'd rather users not catch and handle but
>    instead should mostly just propagate up as is, should be unchecked.
>
> There is also a side discussion
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about
> whether mapConcurrent() is better off preserving input order or push to
> downstream as soon as an element is computed. I'd love to discuss that
> topic too but maybe it's better to start a separate thread?
>
> Thank you and cheers!
>
> Ben Yu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250205/d05e1f74/attachment-0001.htm>

From liach at openjdk.org  Wed Feb  5 18:22:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Feb 2025 18:22:11 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v5]
In-Reply-To: <AKYfWWvD5swMFVmt2c0zHTMd7d1q8b2kjcONoZP3Lp4=.56ce146a-a9e9-4d01-9fcb-8fb76b4b90d1@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <AKYfWWvD5swMFVmt2c0zHTMd7d1q8b2kjcONoZP3Lp4=.56ce146a-a9e9-4d01-9fcb-8fb76b4b90d1@github.com>
Message-ID: <SPm-ZzgudH49l4wnYjBdkbMQ1w3f8UU85XgGZ3sgxhw=.696b013f-053c-46a4-8f87-a85e14e14e8d@github.com>

On Wed, 5 Feb 2025 17:57:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Remove @Stable annotation for final field.

The core library changes look good. Need some other reviewer to verify the VM changes.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23396#pullrequestreview-2596620084

From coleenp at openjdk.org  Wed Feb  5 19:06:17 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Feb 2025 19:06:17 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v5]
In-Reply-To: <AKYfWWvD5swMFVmt2c0zHTMd7d1q8b2kjcONoZP3Lp4=.56ce146a-a9e9-4d01-9fcb-8fb76b4b90d1@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <AKYfWWvD5swMFVmt2c0zHTMd7d1q8b2kjcONoZP3Lp4=.56ce146a-a9e9-4d01-9fcb-8fb76b4b90d1@github.com>
Message-ID: <Hc20yBtt0WFqaKwG0KdGzOacBmpkne1nSaELbR4KgnU=.3008a9ab-a3ff-4da7-8b65-bd2d5d7e93ce@github.com>

On Wed, 5 Feb 2025 17:57:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Remove @Stable annotation for final field.

Thanks Chen for the review.  Hotspot generally also requires two reviewers, so I await David and other's review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2637788306

From asemenyuk at openjdk.org  Wed Feb  5 19:51:04 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 5 Feb 2025 19:51:04 GMT
Subject: RFR: 8346434: Add test for non-automatic service binding
In-Reply-To: <_lXGnrUqAl2SLKORbrD35lLvMZeQCr98Iwxz_ZkNgHU=.871ae877-1434-413f-95da-21187a2b1f63@github.com>
References: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
 <_lXGnrUqAl2SLKORbrD35lLvMZeQCr98Iwxz_ZkNgHU=.871ae877-1434-413f-95da-21187a2b1f63@github.com>
Message-ID: <NNVKNLl9Kvu9_e08J99WWRkMOSKtByFGAiH9sqiz3mc=.58f6d272-afb0-41d5-85a2-000595dc52cd@github.com>

On Wed, 5 Feb 2025 03:25:46 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Added a test case to JLinkOptionsTest to test that jpackage doesn't bind services in app's runtime by default.
>> 
>> The test builds two app images for the same app. One with the default jlink options and another with `--bind-services` jlink option. The test compares module lists from both runtimes. The expected result is that the runtime built with `--bind-services` jlink option has additional modules.
>> 
>> The PR must be integrated after https://github.com/openjdk/jdk/pull/22644. Otherwise, the newly added test will fail.
>
> test/jdk/tools/jpackage/share/JLinkOptionsTest.java line 175:
> 
>> 173:                 .setExecutable(cmd.appLauncherPath().toAbsolutePath())
>> 174:                 .addArguments("--print-modules")
>> 175:                 .executeAndRepeatUntilExitCode(0, attempts,
> 
> Is there any reason why we need to repeat execution?

Yes, launchers in tests are executed multiple times because they may sporadically crash due to an unidentified issue with JVM termination.

Usually, launchers are not explicitly executed in the tests. They are executed as a part of `JPackageCommand.executeAndAssertHelloAppImageCreated()` call, which attempts to run them multiple times if necessary.

In this test, launcher is explicitly executed and the setup to run it multiple times if needed is explicit.

This setup copies a setup to run launchers from [HelloApp.AppOutputVerifier.execute()](https://github.com/openjdk/jdk/blob/379c3f99665829c5d8c373d1fb324dc7ef4d84cf/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java#L441)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23047#discussion_r1943572376

From coleenp at openjdk.org  Wed Feb  5 19:51:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Feb 2025 19:51:06 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>
Message-ID: <0ZM_vg_dAmbdbeoIeZ8ylBUDj_4_jxM-aE6IKoH6ykM=.69c7554f-5e2b-40b9-8d1a-abe147548dbb@github.com>

On Wed, 5 Feb 2025 01:10:39 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright and param name
>
> test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 73:
> 
>> 71:     public int getAppArrayModifiers() {
>> 72:         return clazzArray.getClass().getModifiers();
>> 73:     }
> 
> I'm guessing this is the benchmark that shows an extra load.  How about adding a benchmark that makes the Clazz[] final or @Stable, and see if that makes the extra load go away?

Name                      Cnt  Base   Error   Test   Error  Unit  Change
getAppArrayModifiers       30 0.923 ? 0.004  1.260 ? 0.001 ns/op   0.73x (p = 0.000*)
getAppArrayModifiersFinal  30 0.922 ? 0.000  1.260 ? 0.001 ns/op   0.73x (p = 0.000*)

No it doesn't really help.  There's still an extra load.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943569183

From asemenyuk at openjdk.org  Wed Feb  5 19:51:05 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 5 Feb 2025 19:51:05 GMT
Subject: RFR: 8333569: jpackage tests must run app launchers with retries
 on Linux only
In-Reply-To: <3I9ZwMk-JcV5lGCOuc9eWNllgYOYesmlHrYjwHUAglA=.05d0ba81-a35c-4de8-8133-d3abea67650d@github.com>
References: <3I9ZwMk-JcV5lGCOuc9eWNllgYOYesmlHrYjwHUAglA=.05d0ba81-a35c-4de8-8133-d3abea67650d@github.com>
Message-ID: <-YQrnqSIVXYGF6IeJi-aHJRcTeY3bQ_jpiOZzCpIOYc=.0c0f3c3d-597c-4173-a7ae-2ddd77342386@github.com>

On Wed, 5 Feb 2025 03:34:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Run app launchers in jpackage tests with retries on Linux only. Run them without retries on other platforms.
> 
> Supplementary remove `HelloApp.AppOutputVerifier.removePathEnvVar()` function. It sets an unused member field and is a leftover from [JDK-8347300](https://bugs.openjdk.org/browse/JDK-8347300) fix. This change has no functional impact; it cleans unused code.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/23454#issuecomment-2637854027

From dfuchs at openjdk.org  Wed Feb  5 19:51:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Feb 2025 19:51:04 GMT
Subject: RFR: 8336017: Deprecate java.util.logging.LoggingMXBean,
 its implementation, and accessor method for removal
In-Reply-To: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
References: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
Message-ID: <le5kgz7HLkpgfzk-x8eX3v9YaMCnr1ElkTp8ZnaKlFw=.ac972aec-195b-41e4-96e1-f6d9b8a0f385@github.com>

On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982 in JDK 9.
> 
> These deprecations should be uprated to state they are for future removal.
> 
> java.util.logging.Logging (implements LoggingMXBean) should also be deprecated for removal.

Maybe a first step should be to stop using the API that are proposed for removal internally. When nothing uses them (except other things that are also proposed for removal), then we can proceed by marking the APIs as deprecated for removal?

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

PR Comment: https://git.openjdk.org/jdk/pull/23271#issuecomment-2637860005

From asemenyuk at openjdk.org  Wed Feb  5 20:09:51 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 5 Feb 2025 20:09:51 GMT
Subject: RFR: 8346434: Add test for non-automatic service binding [v2]
In-Reply-To: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
References: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
Message-ID: <oFkh52DE6Kg5t1tODR8oke3W_SAlL6eQpQ7mGFzkFVI=.02fa84ac-1582-4f89-9269-a1c6f40bfd7f@github.com>

> Added a test case to JLinkOptionsTest to test that jpackage doesn't bind services in app's runtime by default.
> 
> The test builds two app images for the same app. One with the default jlink options and another with `--bind-services` jlink option. The test compares module lists from both runtimes. The expected result is that the runtime built with `--bind-services` jlink option has additional modules.
> 
> The PR must be integrated after https://github.com/openjdk/jdk/pull/22644. Otherwise, the newly added test will fail.

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

  Use HelloApp.assertApp() to run a launcher

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23047/files
  - new: https://git.openjdk.org/jdk/pull/23047/files/029fcde1..284c1439

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

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

PR: https://git.openjdk.org/jdk/pull/23047

From asemenyuk at openjdk.org  Wed Feb  5 20:12:12 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 5 Feb 2025 20:12:12 GMT
Subject: RFR: 8346434: Add test for non-automatic service binding [v2]
In-Reply-To: <NNVKNLl9Kvu9_e08J99WWRkMOSKtByFGAiH9sqiz3mc=.58f6d272-afb0-41d5-85a2-000595dc52cd@github.com>
References: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
 <_lXGnrUqAl2SLKORbrD35lLvMZeQCr98Iwxz_ZkNgHU=.871ae877-1434-413f-95da-21187a2b1f63@github.com>
 <NNVKNLl9Kvu9_e08J99WWRkMOSKtByFGAiH9sqiz3mc=.58f6d272-afb0-41d5-85a2-000595dc52cd@github.com>
Message-ID: <fIrE7AG8eCc2lDDinrhWOpVtfk-bwRtC7-Fba_YRU2M=.d22c59e1-506f-40e4-8332-a9631a26bd4f@github.com>

On Wed, 5 Feb 2025 19:44:54 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> test/jdk/tools/jpackage/share/JLinkOptionsTest.java line 175:
>> 
>>> 173:                 .setExecutable(cmd.appLauncherPath().toAbsolutePath())
>>> 174:                 .addArguments("--print-modules")
>>> 175:                 .executeAndRepeatUntilExitCode(0, attempts,
>> 
>> Is there any reason why we need to repeat execution?
>
> Yes, launchers in tests are executed multiple times because they may sporadically crash due to an unidentified issue with JVM termination.
> 
> Usually, launchers are not explicitly executed in the tests. They are executed as a part of `JPackageCommand.executeAndAssertHelloAppImageCreated()` call, which attempts to run them multiple times if necessary.
> 
> In this test, launcher is explicitly executed and the setup to run it multiple times if needed is explicit.
> 
> This setup copies a setup to run launchers from [HelloApp.AppOutputVerifier.execute()](https://github.com/openjdk/jdk/blob/379c3f99665829c5d8c373d1fb324dc7ef4d84cf/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java#L441)

I reworked this part using `HelloApp.assertApp()` function. It wraps restart details.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23047#discussion_r1943600965

From dlong at openjdk.org  Wed Feb  5 20:26:16 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 20:26:16 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <0ZM_vg_dAmbdbeoIeZ8ylBUDj_4_jxM-aE6IKoH6ykM=.69c7554f-5e2b-40b9-8d1a-abe147548dbb@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>
 <0ZM_vg_dAmbdbeoIeZ8ylBUDj_4_jxM-aE6IKoH6ykM=.69c7554f-5e2b-40b9-8d1a-abe147548dbb@github.com>
Message-ID: <0efX7bcHNl5p1RoF3VnqZIabdavsGosuMI14cZPDzbQ=.2bde6bbf-a59b-4f5b-9c68-7a8a258b2ee5@github.com>

On Wed, 5 Feb 2025 19:42:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 73:
>> 
>>> 71:     public int getAppArrayModifiers() {
>>> 72:         return clazzArray.getClass().getModifiers();
>>> 73:     }
>> 
>> I'm guessing this is the benchmark that shows an extra load.  How about adding a benchmark that makes the Clazz[] final or @Stable, and see if that makes the extra load go away?
>
> Name                      Cnt  Base   Error   Test   Error  Unit  Change
> getAppArrayModifiers       30 0.923 ? 0.004  1.260 ? 0.001 ns/op   0.73x (p = 0.000*)
> getAppArrayModifiersFinal  30 0.922 ? 0.000  1.260 ? 0.001 ns/op   0.73x (p = 0.000*)
> 
> No it doesn't really help.  There's still an extra load.

OK, if the extra load turns out to be a problem in the future, we could look into why the compilers are generating the load when the Class is known/constant.  If the old intrinsic was able to pull the constant out of the Klass, then surely we can do the same and pull the value from the Class field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943616021

From jlu at openjdk.org  Wed Feb  5 21:30:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 5 Feb 2025 21:30:40 GMT
Subject: RFR: 8349493: Replace sun.util.locale.ParseStatus usage with
 java.text.ParsePosition
Message-ID: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>

Please review this PR which removes  _sun.util.locale.ParseStatus_ which is a Locale helper class used for parsing language tags.

Such usages should be replaced by _java.text.ParsePosition_ which has almost 1 to 1 behavior. Note that this cleanup changes the exception message in `Locale.caseFoldLanguageTag(String)` to no longer be prepended by `"Ill formed tag: "`. As such, a CSR is filed to address the compatibility aspect.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/23474/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23474&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349493
  Stats: 137 lines in 3 files changed: 12 ins; 78 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/23474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23474/head:pull/23474

PR: https://git.openjdk.org/jdk/pull/23474

From dlong at openjdk.org  Wed Feb  5 21:29:12 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 21:29:12 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
Message-ID: <1yPHOj_hANp7ZvMfmgi6lRkpokgNNaUSc09FJfZvWk8=.bfcf2780-4afe-4253-ae0b-e3bc6ab7ee86@github.com>

On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright and param name

src/hotspot/share/compiler/compileLog.cpp line 116:

> 114:         print(" unloaded='1'");
> 115:       } else {
> 116:         print(" flags='%d'", klass->access_flags());

There may be tools that parse the log file and get confused by this change.  Maybe we should also change the label from "flags" to "access flags".

src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp line 350:

> 348:   writer->write(mark_symbol(klass, leakp));
> 349:   writer->write(package_id(klass, leakp));
> 350:   writer->write(klass->compute_modifier_flags());

Isn't this much more expensive than grabbing the value from the mirror, especially if we have to iterate over inner classes?

src/hotspot/share/oops/instanceKlass.hpp line 1128:

> 1126: #endif
> 1127: 
> 1128:   int compute_modifier_flags() const;

I don't see why this can't stay u2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943680670
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943679056
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943682936

From dlong at openjdk.org  Wed Feb  5 21:43:14 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 21:43:14 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
Message-ID: <NvrhD47QIH5G8TfOihEL7SyCjPdfd2jP6mOI5gyDBXo=.9d21e6b9-e527-437a-a90b-37fc7a6b7472@github.com>

On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright and param name

src/hotspot/share/opto/memnode.cpp line 2458:

> 2456:           return TypePtr::NULL_PTR;
> 2457:         }
> 2458:         // ???

I suspect that we still need this code to support intrinsics like LibraryCallKit::inline_native_classID() and maybe other users of this field, but the comment below no longer makes sense.

src/hotspot/share/opto/memnode.cpp line 2459:

> 2457:         }
> 2458:         // ???
> 2459:         // (Folds up the 1st indirection in aClassConstant.getModifiers().)

Suggestion:

        // Fold up the load of the hidden field

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943695585
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943696867

From dlong at openjdk.org  Wed Feb  5 21:47:12 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 21:47:12 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <8Wx3xbbOnPXS5n1RuNaesqHbhKV3iLwrCVF0s6uWOrA=.cb20728e-e13c-4667-822b-3ba424cbc12f@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
 <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
 <yjBy9m5yM18_XOZjEN8dn5osnTUPviOliyM_qNHoKgQ=.f9c43bc8-4bee-46bb-b466-7d471bfcd582@github.com>
 <8Wx3xbbOnPXS5n1RuNaesqHbhKV3iLwrCVF0s6uWOrA=.cb20728e-e13c-4667-822b-3ba424cbc12f@github.com>
Message-ID: <yuiSOJZCDOCs2H5MHBg5FZnJYjy4XxsEnRy87qL8DFg=.1d5fac0f-8695-4e26-ac3f-0d787421607f@github.com>

On Thu, 12 Dec 2024 10:16:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> @viktorklang-ora `@Stable` is not about how the field was set, but about the JIT observing a  non-default value at compile time.  If it observes a non-default value, it can treat it as a compile time constant.
>
> @DanHeidinga Great explanation, thank you!

If Class had other fields smaller than `int`, would be consider making this something like `char` to save space (allowing all the sub-word fields to be compacted)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943701237

From dlong at openjdk.org  Wed Feb  5 21:53:11 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 21:53:11 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
Message-ID: <yTbRwO_J0qBiFJYLzUj0UUqfZFFJJJk0FvwVY1V11mk=.360808a6-849f-4487-9176-60957be5d811@github.com>

On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright and param name

Overall looks good to me.  Please ask @iwanowww to review compiler changes.

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

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2597046622

From almatvee at openjdk.org  Wed Feb  5 22:25:10 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 5 Feb 2025 22:25:10 GMT
Subject: RFR: 8333569: jpackage tests must run app launchers with retries
 on Linux only
In-Reply-To: <3I9ZwMk-JcV5lGCOuc9eWNllgYOYesmlHrYjwHUAglA=.05d0ba81-a35c-4de8-8133-d3abea67650d@github.com>
References: <3I9ZwMk-JcV5lGCOuc9eWNllgYOYesmlHrYjwHUAglA=.05d0ba81-a35c-4de8-8133-d3abea67650d@github.com>
Message-ID: <MscdSkT4Y4lpzPTN7f17wYix457JMUPluWGNTIkWds0=.a964c4ac-c649-4bd6-955c-282e659cf8e7@github.com>

On Wed, 5 Feb 2025 03:34:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Run app launchers in jpackage tests with retries on Linux only. Run them without retries on other platforms.
> 
> Supplementary remove `HelloApp.AppOutputVerifier.removePathEnvVar()` function. It sets an unused member field and is a leftover from [JDK-8347300](https://bugs.openjdk.org/browse/JDK-8347300) fix. This change has no functional impact; it cleans unused code.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23454#pullrequestreview-2597127677

From almatvee at openjdk.org  Wed Feb  5 22:27:10 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 5 Feb 2025 22:27:10 GMT
Subject: RFR: 8346434: Add test for non-automatic service binding [v2]
In-Reply-To: <oFkh52DE6Kg5t1tODR8oke3W_SAlL6eQpQ7mGFzkFVI=.02fa84ac-1582-4f89-9269-a1c6f40bfd7f@github.com>
References: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
 <oFkh52DE6Kg5t1tODR8oke3W_SAlL6eQpQ7mGFzkFVI=.02fa84ac-1582-4f89-9269-a1c6f40bfd7f@github.com>
Message-ID: <YhfxKRtib7gDC9Sw5lGph_zxrft3yzbOqKK6XhuAIws=.95844de6-cc4c-45b5-854f-458bcd8a470d@github.com>

On Wed, 5 Feb 2025 20:09:51 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Added a test case to JLinkOptionsTest to test that jpackage doesn't bind services in app's runtime by default.
>> 
>> The test builds two app images for the same app. One with the default jlink options and another with `--bind-services` jlink option. The test compares module lists from both runtimes. The expected result is that the runtime built with `--bind-services` jlink option has additional modules.
>> 
>> The PR must be integrated after https://github.com/openjdk/jdk/pull/22644. Otherwise, the newly added test will fail.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use HelloApp.assertApp() to run a launcher

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23047#pullrequestreview-2597130644

From naoto at openjdk.org  Wed Feb  5 22:55:11 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Feb 2025 22:55:11 GMT
Subject: RFR: 8349493: Replace sun.util.locale.ParseStatus usage with
 java.text.ParsePosition
In-Reply-To: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
References: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
Message-ID: <s4BOef0QBtEIxDMuhglPadEJkFSm0CvQTc0J5BFnV4M=.06662615-0959-4bf7-9606-280a276f04b5@github.com>

On Wed, 5 Feb 2025 21:25:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes  _sun.util.locale.ParseStatus_ which is a Locale helper class used for parsing language tags.
> 
> Such usages should be replaced by _java.text.ParsePosition_ which has almost 1 to 1 behavior. Note that this cleanup changes the exception message in `Locale.caseFoldLanguageTag(String)` to no longer be prepended by `"Ill formed tag: "`. As such, a CSR is filed to address the compatibility aspect.

Looks good. Nice cleanup. I don't think changing the exception message requires a CSR though.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 423:

> 421:             throw new IllformedLocaleException(String.format("Ill formed tag:" +
> 422:                     " %s", sts.errorMsg));
> 423:         }

If we want to keep the existing behavior, catch the ILE and throw a new one with the prepending text, but I think that won't be necessary.

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

PR Review: https://git.openjdk.org/jdk/pull/23474#pullrequestreview-2597166661
PR Review Comment: https://git.openjdk.org/jdk/pull/23474#discussion_r1943783817

From jlu at openjdk.org  Wed Feb  5 23:02:19 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 5 Feb 2025 23:02:19 GMT
Subject: RFR: 8349493: Replace sun.util.locale.ParseStatus usage with
 java.text.ParsePosition
In-Reply-To: <s4BOef0QBtEIxDMuhglPadEJkFSm0CvQTc0J5BFnV4M=.06662615-0959-4bf7-9606-280a276f04b5@github.com>
References: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
 <s4BOef0QBtEIxDMuhglPadEJkFSm0CvQTc0J5BFnV4M=.06662615-0959-4bf7-9606-280a276f04b5@github.com>
Message-ID: <hmmKu6nsY9KQTM15s1W-pwq00yu0gElk1nJiEOJCmSM=.c35cf120-afb5-4077-8743-16b5c38a9ac6@github.com>

On Wed, 5 Feb 2025 22:51:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which removes  _sun.util.locale.ParseStatus_ which is a Locale helper class used for parsing language tags.
>> 
>> Such usages should be replaced by _java.text.ParsePosition_ which has almost 1 to 1 behavior. Note that this cleanup changes the exception message in `Locale.caseFoldLanguageTag(String)` to no longer be prepended by `"Ill formed tag: "`. As such, a CSR is filed to address the compatibility aspect.
>
> src/java.base/share/classes/sun/util/locale/LanguageTag.java line 423:
> 
>> 421:             throw new IllformedLocaleException(String.format("Ill formed tag:" +
>> 422:                     " %s", sts.errorMsg));
>> 423:         }
> 
> If we want to keep the existing behavior, catch the ILE and throw a new one with the prepending text, but I think that won't be necessary.

Yes, I didn't think it was needed to do that, the existing message should already have enough details. I filed the CSR just in case, I'll withdraw it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23474#discussion_r1943790683

From liach at openjdk.org  Wed Feb  5 23:08:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Feb 2025 23:08:23 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v19]
In-Reply-To: <QrgMhkd02a2XjQWEC-lxm0hqRhcrc3kcXFQV_c3G3M0=.05db60a1-4184-45e2-ae8f-8beee48e7d0b@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
 <QrgMhkd02a2XjQWEC-lxm0hqRhcrc3kcXFQV_c3G3M0=.05db60a1-4184-45e2-ae8f-8beee48e7d0b@github.com>
Message-ID: <osETMMfY584rkOuN0fuJhD9pkaQKqtyQ2B2oBdOHX7U=.3c7902e2-11f6-492f-b7cc-ecd49541976c@github.com>

On Wed, 5 Feb 2025 17:06:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
>> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
>> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
>> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ForceInline

I have made a patch to move the multi-byte read/write access code to ByteArray, and have VarHandle delegate to it instead: https://github.com/openjdk/jdk/compare/master...liachmodded:jdk:cleanup/bytearray?expand=1

I am currently running it through tier 1-5 tests. Will create a PR if the tests look good.

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

PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2638232636

From asemenyuk at openjdk.org  Wed Feb  5 23:23:43 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 5 Feb 2025 23:23:43 GMT
Subject: RFR: 8346434: Add test for non-automatic service binding [v3]
In-Reply-To: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
References: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
Message-ID: <Fukn51e6hgV_TjeSBY0gz0ni_0YFDX268NKF6GgMwS4=.e2d8abd7-edc7-4eb8-8d89-7de90ef402bf@github.com>

> Added a test case to JLinkOptionsTest to test that jpackage doesn't bind services in app's runtime by default.
> 
> The test builds two app images for the same app. One with the default jlink options and another with `--bind-services` jlink option. The test compares module lists from both runtimes. The expected result is that the runtime built with `--bind-services` jlink option has additional modules.
> 
> The PR must be integrated after https://github.com/openjdk/jdk/pull/22644. Otherwise, the newly added test will fail.

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

 - Merge branch 'master' into JDK-8346434
 - Use HelloApp.assertApp() to run a launcher
 - Merge branch 'master' into JDK-8346434
 - Trailing whitespace removed
 - Merge branch 'master' into JDK-8346434
 - Copyright year updated
 - 8346434: Add test for non-automatic service binding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23047/files
  - new: https://git.openjdk.org/jdk/pull/23047/files/284c1439..6d6e0442

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

  Stats: 5695 lines in 298 files changed: 1949 ins; 2552 del; 1194 mod
  Patch: https://git.openjdk.org/jdk/pull/23047.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23047/head:pull/23047

PR: https://git.openjdk.org/jdk/pull/23047

From asemenyuk at openjdk.org  Wed Feb  5 23:27:27 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 5 Feb 2025 23:27:27 GMT
Subject: Integrated: 8333569: jpackage tests must run app launchers with
 retries on Linux only
In-Reply-To: <3I9ZwMk-JcV5lGCOuc9eWNllgYOYesmlHrYjwHUAglA=.05d0ba81-a35c-4de8-8133-d3abea67650d@github.com>
References: <3I9ZwMk-JcV5lGCOuc9eWNllgYOYesmlHrYjwHUAglA=.05d0ba81-a35c-4de8-8133-d3abea67650d@github.com>
Message-ID: <cr8kODRxsS4ZLoolv4-XhQcOXehRqhZKKYkqLHzD5vM=.a14f23e6-50a9-4a12-92e6-9ffbb5404e02@github.com>

On Wed, 5 Feb 2025 03:34:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Run app launchers in jpackage tests with retries on Linux only. Run them without retries on other platforms.
> 
> Supplementary remove `HelloApp.AppOutputVerifier.removePathEnvVar()` function. It sets an unused member field and is a leftover from [JDK-8347300](https://bugs.openjdk.org/browse/JDK-8347300) fix. This change has no functional impact; it cleans unused code.

This pull request has now been integrated.

Changeset: aad6664b
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aad6664bb6d2b311b3e0cb056afaa9b6534bdbbb
Stats:     42 lines in 3 files changed: 15 ins; 18 del; 9 mod

8333569: jpackage tests must run app launchers with retries on Linux only

Reviewed-by: almatvee

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

PR: https://git.openjdk.org/jdk/pull/23454

From duke at openjdk.org  Wed Feb  5 23:36:00 2025
From: duke at openjdk.org (Nicole Xu)
Date: Wed, 5 Feb 2025 23:36:00 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to
 IndexOutOfBoundsException
Message-ID: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>

Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86 and AArch64 with the following error:


java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249


The variable `long256_arr_idx` is misused when indexing  'LongVector l2, l3, l4, l5' in function `maskedLogicOperationsLongKernel()`. 'long256_arr_idx' increases by 4 every time the benchmark runs and ensures the incremented value remains within the bounds of the array. However, for `LongVector.SPECIES_512`, it loads 8 numbers from the array each time the benchmark runs, resulting in an out-of-range indexing issue.

Hence, we revised the index variables from `long256_arr_idx` to `long512_arr_idx`, which has a stride of 8, to ensure that the loaded vector is inside of the array boundary for all vector species. This is also consistent with other kernel functions.

Additionally, some defined but unused variables have been removed.

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

Commit messages:
 - 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException

Changes: https://git.openjdk.org/jdk/pull/22963/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22963&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346954
  Stats: 14 lines in 1 file changed: 0 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/22963.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22963/head:pull/22963

PR: https://git.openjdk.org/jdk/pull/22963

From duke at openjdk.org  Wed Feb  5 23:36:00 2025
From: duke at openjdk.org (Nicole Xu)
Date: Wed, 5 Feb 2025 23:36:00 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
Message-ID: <nkxuqicv9akCbWyyDbaZkm2oRuYVv99bPqblgeYBlFE=.0efb59a6-4f7f-4a7b-8f30-7ffa0a3341ef@github.com>

On Wed, 8 Jan 2025 09:04:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86 and AArch64 with the following error:
> 
> 
> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
> 
> 
> The variable `long256_arr_idx` is misused when indexing  'LongVector l2, l3, l4, l5' in function `maskedLogicOperationsLongKernel()`. 'long256_arr_idx' increases by 4 every time the benchmark runs and ensures the incremented value remains within the bounds of the array. However, for `LongVector.SPECIES_512`, it loads 8 numbers from the array each time the benchmark runs, resulting in an out-of-range indexing issue.
> 
> Hence, we revised the index variables from `long256_arr_idx` to `long512_arr_idx`, which has a stride of 8, to ensure that the loaded vector is inside of the array boundary for all vector species. This is also consistent with other kernel functions.
> 
> Additionally, some defined but unused variables have been removed.

I am a member of Nvidia Java compiler team.

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

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2577153564

From duke at openjdk.org  Wed Feb  5 23:36:00 2025
From: duke at openjdk.org (Nicole Xu)
Date: Wed, 5 Feb 2025 23:36:00 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <nkxuqicv9akCbWyyDbaZkm2oRuYVv99bPqblgeYBlFE=.0efb59a6-4f7f-4a7b-8f30-7ffa0a3341ef@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <nkxuqicv9akCbWyyDbaZkm2oRuYVv99bPqblgeYBlFE=.0efb59a6-4f7f-4a7b-8f30-7ffa0a3341ef@github.com>
Message-ID: <P1P0Mo0SsHnn-OK4vAZJScUdAATYgXlTeDH74YkCGWk=.89fd7e15-1353-48c5-b199-bbc6b4ea6a07@github.com>

On Wed, 8 Jan 2025 09:08:55 GMT, Nicole Xu <duke at openjdk.org> wrote:

> I am a member of Nvidia Java compiler team.

BTW, Nvidia has signed the OCA recently. Please help to check. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2581667116

From epeter at openjdk.org  Wed Feb  5 23:36:00 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 5 Feb 2025 23:36:00 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
Message-ID: <ljxrhzoRck0LUkRbHYC_0hfPXiW_L1vuw0K7B8lKUKY=.fea555f9-651a-47a1-8c98-b33470d85a8b@github.com>

On Wed, 8 Jan 2025 09:04:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86 and AArch64 with the following error:
> 
> 
> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
> 
> 
> The variable `long256_arr_idx` is misused when indexing  'LongVector l2, l3, l4, l5' in function `maskedLogicOperationsLongKernel()`. 'long256_arr_idx' increases by 4 every time the benchmark runs and ensures the incremented value remains within the bounds of the array. However, for `LongVector.SPECIES_512`, it loads 8 numbers from the array each time the benchmark runs, resulting in an out-of-range indexing issue.
> 
> Hence, we revised the index variables from `long256_arr_idx` to `long512_arr_idx`, which has a stride of 8, to ensure that the loaded vector is inside of the array boundary for all vector species. This is also consistent with other kernel functions.
> 
> Additionally, some defined but unused variables have been removed.

@jatin-bhateja Could you have a look at these changes? You wrote the test originally.

Oh, the OCA-verify is still stuck. I'm sorry about that ? 
I pinged my manager @TobiHartmann , he will reach out to see what's the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2597602723
PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2634806377

From epeter at openjdk.org  Wed Feb  5 23:36:00 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 5 Feb 2025 23:36:00 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <P1P0Mo0SsHnn-OK4vAZJScUdAATYgXlTeDH74YkCGWk=.89fd7e15-1353-48c5-b199-bbc6b4ea6a07@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <nkxuqicv9akCbWyyDbaZkm2oRuYVv99bPqblgeYBlFE=.0efb59a6-4f7f-4a7b-8f30-7ffa0a3341ef@github.com>
 <P1P0Mo0SsHnn-OK4vAZJScUdAATYgXlTeDH74YkCGWk=.89fd7e15-1353-48c5-b199-bbc6b4ea6a07@github.com>
Message-ID: <Flsuk0FDGDsZXO0A9Fs2nxc1HYC4KZ62x5DfORzr8sg=.53837325-6547-4817-97e0-e19c3bcd11b4@github.com>

On Fri, 10 Jan 2025 03:25:01 GMT, Nicole Xu <duke at openjdk.org> wrote:

>> I am a member of Nvidia Java compiler team.
>
>> I am a member of Nvidia Java compiler team.
> 
> BTW, Nvidia has signed the OCA recently. Please help to check. Thanks.

@xyyNicole I see this has been in OCA-verify mode for 2 weeks. I reached out internally and hope this can go through soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2606527743

From liach at openjdk.org  Wed Feb  5 23:45:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Feb 2025 23:45:25 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
Message-ID: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>

`MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.

To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

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

Commit messages:
 - Update bug id
 - copyright years and comments
 - Consolidate multi-byte io into ByteArray

Changes: https://git.openjdk.org/jdk/pull/23478/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23478&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349503
  Stats: 2042 lines in 17 files changed: 714 ins; 1134 del; 194 mod
  Patch: https://git.openjdk.org/jdk/pull/23478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23478/head:pull/23478

PR: https://git.openjdk.org/jdk/pull/23478

From asemenyuk at openjdk.org  Thu Feb  6 01:42:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Feb 2025 01:42:10 GMT
Subject: RFR: 8349504: Support platform-specific JUnit tests in jpackage
Message-ID: <RoY-ZAqVAK_Ji8E9r9D85U0faCdEPlAsQtBms8TCvo4=.53c71b25-24bd-43d3-8995-32f5308893a9@github.com>

Move junit tests to `share` subfolder.

Adjust `TEST.properties` to grant full access to classes in all `jdk.jpackage` module packages. Otherwise, jtreg picks access config from the parent [`TEST.properties`](https://github.com/openjdk/jdk/blob/aad6664bb6d2b311b3e0cb056afaa9b6534bdbbb/test/jdk/tools/jpackage/TEST.properties), which allows full access to `jdk.jpackage.internal` package only.

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

Commit messages:
 - Move shared junit tests from "junit" to "junit/share" folder in preparation for adding platform-specific junit tests

Changes: https://git.openjdk.org/jdk/pull/23479/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349504
  Stats: 7 lines in 10 files changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23479/head:pull/23479

PR: https://git.openjdk.org/jdk/pull/23479

From asemenyuk at openjdk.org  Thu Feb  6 01:42:11 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Feb 2025 01:42:11 GMT
Subject: RFR: 8349504: Support platform-specific JUnit tests in jpackage
In-Reply-To: <RoY-ZAqVAK_Ji8E9r9D85U0faCdEPlAsQtBms8TCvo4=.53c71b25-24bd-43d3-8995-32f5308893a9@github.com>
References: <RoY-ZAqVAK_Ji8E9r9D85U0faCdEPlAsQtBms8TCvo4=.53c71b25-24bd-43d3-8995-32f5308893a9@github.com>
Message-ID: <q7CSP-WKTHb-IRokLLjNSo7ZoXsoxi8uliA6F7it43E=.fbbbb7cd-dcd2-4f24-aec6-c62c2272aac0@github.com>

On Wed, 5 Feb 2025 23:51:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Move junit tests to `share` subfolder.
> 
> Adjust `TEST.properties` to grant full access to classes in all `jdk.jpackage` module packages. Otherwise, jtreg picks access config from the parent [`TEST.properties`](https://github.com/openjdk/jdk/blob/aad6664bb6d2b311b3e0cb056afaa9b6534bdbbb/test/jdk/tools/jpackage/TEST.properties), which allows full access to `jdk.jpackage.internal` package only.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/23479#issuecomment-2638431956

From dholmes at openjdk.org  Thu Feb  6 01:52:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 01:52:57 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and
 parsing
Message-ID: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>

This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.

JDK-8348190: Framework for tracing makefile inclusion and parsing

The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.

Thanks.

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

Commit messages:
 - Revert "8348190: Framework for tracing makefile inclusion and parsing"

Changes: https://git.openjdk.org/jdk/pull/23481/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23481&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349511
  Stats: 2717 lines in 273 files changed: 501 ins; 1663 del; 553 mod
  Patch: https://git.openjdk.org/jdk/pull/23481.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23481/head:pull/23481

PR: https://git.openjdk.org/jdk/pull/23481

From darcy at openjdk.org  Thu Feb  6 02:04:15 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Feb 2025 02:04:15 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

Approving clean backout.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23481#pullrequestreview-2597463613

From naoto at openjdk.org  Thu Feb  6 02:14:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Feb 2025 02:14:10 GMT
Subject: RFR: 8349493: Replace sun.util.locale.ParseStatus usage with
 java.text.ParsePosition
In-Reply-To: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
References: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
Message-ID: <gjhWPLhaHGu3ubT4wL4m3O6S3qZ5jsOT3RYbxpL0CME=.8327a3f2-51ed-4e6b-9d62-e6fa78ca11a7@github.com>

On Wed, 5 Feb 2025 21:25:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes  _sun.util.locale.ParseStatus_ which is a Locale helper class used for parsing language tags.
> 
> Such usages should be replaced by _java.text.ParsePosition_ which has almost 1 to 1 behavior. Note that this cleanup changes the exception message in `Locale.caseFoldLanguageTag(String)` to no longer be prepended by `"Ill formed tag: "`. As such, a CSR is filed to address the compatibility aspect.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23474#pullrequestreview-2597486343

From almatvee at openjdk.org  Thu Feb  6 02:16:13 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 6 Feb 2025 02:16:13 GMT
Subject: RFR: 8349504: Support platform-specific JUnit tests in jpackage
In-Reply-To: <RoY-ZAqVAK_Ji8E9r9D85U0faCdEPlAsQtBms8TCvo4=.53c71b25-24bd-43d3-8995-32f5308893a9@github.com>
References: <RoY-ZAqVAK_Ji8E9r9D85U0faCdEPlAsQtBms8TCvo4=.53c71b25-24bd-43d3-8995-32f5308893a9@github.com>
Message-ID: <-a6DBGCR1FJ1gucI6Yy8QfZzD5w9hNHMh7tKUw9RbiY=.0877f721-3fd0-4d92-9cab-698f5350e6ec@github.com>

On Wed, 5 Feb 2025 23:51:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Move junit tests to `share` subfolder.
> 
> Adjust `TEST.properties` to grant full access to classes in all `jdk.jpackage` module packages. Otherwise, jtreg picks access config from the parent [`TEST.properties`](https://github.com/openjdk/jdk/blob/aad6664bb6d2b311b3e0cb056afaa9b6534bdbbb/test/jdk/tools/jpackage/TEST.properties), which allows full access to `jdk.jpackage.internal` package only.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23479#pullrequestreview-2597487823

From asemenyuk at openjdk.org  Thu Feb  6 02:29:49 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Feb 2025 02:29:49 GMT
Subject: RFR: 8346434: Add test for non-automatic service binding [v4]
In-Reply-To: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
References: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
Message-ID: <9DP6YzfVz5n-xGoKcck8VDB4vL24YYEdMDYPMM8YcwM=.db05f748-4e6c-42f3-bfcf-b2bb5e8812e2@github.com>

> Added a test case to JLinkOptionsTest to test that jpackage doesn't bind services in app's runtime by default.
> 
> The test builds two app images for the same app. One with the default jlink options and another with `--bind-services` jlink option. The test compares module lists from both runtimes. The expected result is that the runtime built with `--bind-services` jlink option has additional modules.
> 
> The PR must be integrated after https://github.com/openjdk/jdk/pull/22644. Otherwise, the newly added test will fail.

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

 - Merge branch 'master' into JDK-8346434
 - Merge branch 'master' into JDK-8346434
 - Merge branch 'master' into JDK-8346434
 - Use HelloApp.assertApp() to run a launcher
 - Merge branch 'master' into JDK-8346434
 - Trailing whitespace removed
 - Merge branch 'master' into JDK-8346434
 - Copyright year updated
 - 8346434: Add test for non-automatic service binding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23047/files
  - new: https://git.openjdk.org/jdk/pull/23047/files/6d6e0442..6a54a352

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

  Stats: 91 lines in 11 files changed: 18 ins; 20 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/23047.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23047/head:pull/23047

PR: https://git.openjdk.org/jdk/pull/23047

From asemenyuk at openjdk.org  Thu Feb  6 02:30:18 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Feb 2025 02:30:18 GMT
Subject: Integrated: 8349504: Support platform-specific JUnit tests in jpackage
In-Reply-To: <RoY-ZAqVAK_Ji8E9r9D85U0faCdEPlAsQtBms8TCvo4=.53c71b25-24bd-43d3-8995-32f5308893a9@github.com>
References: <RoY-ZAqVAK_Ji8E9r9D85U0faCdEPlAsQtBms8TCvo4=.53c71b25-24bd-43d3-8995-32f5308893a9@github.com>
Message-ID: <PH05C7rGsgzAwzaxyBGgUCa4ZSNH_vmb8Gpn6rJTa1g=.bdf63976-f201-44a2-923f-ada86db5c2d4@github.com>

On Wed, 5 Feb 2025 23:51:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Move junit tests to `share` subfolder.
> 
> Adjust `TEST.properties` to grant full access to classes in all `jdk.jpackage` module packages. Otherwise, jtreg picks access config from the parent [`TEST.properties`](https://github.com/openjdk/jdk/blob/aad6664bb6d2b311b3e0cb056afaa9b6534bdbbb/test/jdk/tools/jpackage/TEST.properties), which allows full access to `jdk.jpackage.internal` package only.

This pull request has now been integrated.

Changeset: 5e1cc082
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e1cc0825938527bd7011ade8b237e34c821862c
Stats:     7 lines in 10 files changed: 5 ins; 0 del; 2 mod

8349504: Support platform-specific JUnit tests in jpackage

Reviewed-by: almatvee

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

PR: https://git.openjdk.org/jdk/pull/23479

From dholmes at openjdk.org  Thu Feb  6 02:44:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:44:08 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
 <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>
Message-ID: <AWJoVSTeygOR6BO1A3fQOGLPGVzlF6zuRNMw4TMiVZc=.cf4c9f9e-75b8-45ef-b295-8fb57846fa24@github.com>

On Thu, 6 Feb 2025 02:01:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>> 
>> JDK-8348190: Framework for tracing makefile inclusion and parsing
>> 
>> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
>> 
>> Thanks.
>
> Approving clean backout.

Thanks @jddarcy !

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

PR Comment: https://git.openjdk.org/jdk/pull/23481#issuecomment-2638687813

From mikael at openjdk.org  Thu Feb  6 02:54:17 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 6 Feb 2025 02:54:17 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23481#pullrequestreview-2597531112

From dholmes at openjdk.org  Thu Feb  6 02:54:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:54:18 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
 <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>
Message-ID: <o_LWA-N7-KZ6e3MLu8U2GOcgFRK6rgW58IWj5sGK_6s=.12f73a3c-70ce-49c3-b486-1585990fefac@github.com>

On Thu, 6 Feb 2025 02:48:21 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>> 
>> JDK-8348190: Framework for tracing makefile inclusion and parsing
>> 
>> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
>> 
>> Thanks.
>
> Marked as reviewed by mikael (Reviewer).

Thanks @vidmik !

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

PR Comment: https://git.openjdk.org/jdk/pull/23481#issuecomment-2638701374

From dholmes at openjdk.org  Thu Feb  6 02:54:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:54:18 GMT
Subject: Integrated: 8349511: [BACKOUT] Framework for tracing makefile
 inclusion and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <aWuh7nyeGLH2h82Pk0IN4KD8wwSrAXkioaZ_EWlOWN4=.5e1f6202-37f7-4b5a-a36a-2adf4ca85b10@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 64bd8d25
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2
Stats:     2717 lines in 273 files changed: 501 ins; 1663 del; 553 mod

8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

Reviewed-by: darcy, mikael

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

PR: https://git.openjdk.org/jdk/pull/23481

From liach at openjdk.org  Thu Feb  6 04:40:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Feb 2025 04:40:11 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <0efX7bcHNl5p1RoF3VnqZIabdavsGosuMI14cZPDzbQ=.2bde6bbf-a59b-4f5b-9c68-7a8a258b2ee5@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>
 <0ZM_vg_dAmbdbeoIeZ8ylBUDj_4_jxM-aE6IKoH6ykM=.69c7554f-5e2b-40b9-8d1a-abe147548dbb@github.com>
 <0efX7bcHNl5p1RoF3VnqZIabdavsGosuMI14cZPDzbQ=.2bde6bbf-a59b-4f5b-9c68-7a8a258b2ee5@github.com>
Message-ID: <7KdNVSXLx0N027uyQgtUuN82VpXTlyPpPOnBv3sqYRs=.6b549b56-36f9-4ab3-8469-4779d93dd1e7@github.com>

On Wed, 5 Feb 2025 20:23:05 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Name                      Cnt  Base   Error   Test   Error  Unit  Change
>> getAppArrayModifiers       30 0.923 ? 0.004  1.260 ? 0.001 ns/op   0.73x (p = 0.000*)
>> getAppArrayModifiersFinal  30 0.922 ? 0.000  1.260 ? 0.001 ns/op   0.73x (p = 0.000*)
>> 
>> No it doesn't really help.  There's still an extra load.
>
> OK, if the extra load turns out to be a problem in the future, we could look into why the compilers are generating the load when the Class is known/constant.  If the old intrinsic was able to pull the constant out of the Klass, then surely we can do the same and pull the value from the Class field.

Does `static final` help here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944083490

From dholmes at openjdk.org  Thu Feb  6 06:17:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 06:17:11 GMT
Subject: RFR: 8349462: Gatherers.mapConcurrent could support async
 interrupts
In-Reply-To: <MiGjmr0ni-K6kF_bTwR2qMEEMal2Q8xSRPMgOHMcld0=.41bd792f-c20b-4a8e-8cfd-08121e06ddef@github.com>
References: <MiGjmr0ni-K6kF_bTwR2qMEEMal2Q8xSRPMgOHMcld0=.41bd792f-c20b-4a8e-8cfd-08121e06ddef@github.com>
Message-ID: <PHP2ol4qLhs_cn-Sj19BbgEYcqwVL7sKnkzq766viBU=.b6f79067-f64d-4480-8977-ff116ebe3036@github.com>

On Wed, 5 Feb 2025 16:14:41 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change is likely going to need some extra verbiage in the spec for mapConcurrent, and thus a CSR.
> This behavior aligns mapConcurrent with how parallel streams work in conjunction with interruptions of the caller thread.

src/java.base/share/classes/java/util/stream/Gatherers.java line 432:

> 430:                                 } catch (InterruptedException ie) {
> 431:                                     // We ignore interrupts here because we cannot proceed
> 432:                                     // until all spawned threads have exited

Why discard instead of keeping existing deferral? Swallowing interrupt requests generally breaks cancellation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23467#discussion_r1944157403

From dholmes at openjdk.org  Thu Feb  6 07:32:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 07:32:12 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]
In-Reply-To: <as8AhJFiM7kItFtO_ryI9gtRMyedA3SBBPMU53jA32A=.f1630384-852e-4273-83ff-52783e8a4699@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <syxVRD9ASKql288dZ8hdYJjliScymiDGldc7fSoEAiU=.d4084758-4fb0-496f-a7bb-ad0093129f11@github.com>
 <rnBxm-eKFKaOGdMay4i94tiSB28d_9s6SOrfGAnrTZk=.875ea4cd-2d71-4139-997c-ef1f1a0fd59d@github.com>
 <as8AhJFiM7kItFtO_ryI9gtRMyedA3SBBPMU53jA32A=.f1630384-852e-4273-83ff-52783e8a4699@github.com>
Message-ID: <6TuFE5mx8jXm2donAE_cM3I5UXCaB1eKrpCyp7qk0wM=.1c585567-cf27-4d3e-bca9-4aa7a556942c@github.com>

On Wed, 5 Feb 2025 17:41:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 239:
>> 
>>> 237:      * generated.
>>> 238:      */
>>> 239:     private Class(ClassLoader loader, Class<?> arrayComponentType, ProtectionDomain pd) {
>> 
>> If this constructor is not used then why do we need to add the PD argument, rather than just set it to null? For that matter why do we even need the field if nothing is ever setting it? I'm missing something here.
>
> @DanHeidinga suggested this for my other PR as a convention that's used for the j.l.Class constructor.

I am still missing what can actually set a PD here, sorry. ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1944230577

From syan at openjdk.org  Thu Feb  6 09:36:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 6 Feb 2025 09:36:15 GMT
Subject: RFR: 8345155: Add /native to native test in FFM
In-Reply-To: <sZv1i8MFu4Hedp6TOhErsjlP9fzakMMjWa_XWUkpQuQ=.fc469a70-a737-456c-9827-d465981433d0@github.com>
References: <sZv1i8MFu4Hedp6TOhErsjlP9fzakMMjWa_XWUkpQuQ=.fc469a70-a737-456c-9827-d465981433d0@github.com>
Message-ID: <Hge4czCmvgu97OClKGDvKALpnuUMnUMxH1W8eI6Fl2Y=.2f985e6c-5266-48ba-8bb8-26bedb0aa656@github.com>

On Wed, 5 Feb 2025 08:59:10 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR add `/native` keyword in the test header for FFM tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the FFM tests without `-nativepath` argument and find the fail tests. This will find all the FFM tests which missing '/native' flag.
> 
> Change has been verified locally, test-fix, no risk.

Thanks all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23458#issuecomment-2639271278

From syan at openjdk.org  Thu Feb  6 09:36:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 6 Feb 2025 09:36:15 GMT
Subject: Integrated: 8345155: Add /native to native test in FFM
In-Reply-To: <sZv1i8MFu4Hedp6TOhErsjlP9fzakMMjWa_XWUkpQuQ=.fc469a70-a737-456c-9827-d465981433d0@github.com>
References: <sZv1i8MFu4Hedp6TOhErsjlP9fzakMMjWa_XWUkpQuQ=.fc469a70-a737-456c-9827-d465981433d0@github.com>
Message-ID: <yeGUloFb5izDRDCU4XNwWfTP5Aq5rFfKoR5sUjAdeAw=.26b6c0e7-03f4-4748-aa68-fc1d4ee1e978@github.com>

On Wed, 5 Feb 2025 08:59:10 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR add `/native` keyword in the test header for FFM tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the FFM tests without `-nativepath` argument and find the fail tests. This will find all the FFM tests which missing '/native' flag.
> 
> Change has been verified locally, test-fix, no risk.

This pull request has now been integrated.

Changeset: acb46ddb
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/acb46ddb8901a4e96238de217d3e7931f381b699
Stats:     76 lines in 34 files changed: 0 ins; 0 del; 76 mod

8345155: Add /native to native test in FFM

Reviewed-by: mcimadamore, pminborg

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

PR: https://git.openjdk.org/jdk/pull/23458

From vklang at openjdk.org  Thu Feb  6 10:43:17 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 6 Feb 2025 10:43:17 GMT
Subject: RFR: 8349462: Gatherers.mapConcurrent could support async
 interrupts
In-Reply-To: <MiGjmr0ni-K6kF_bTwR2qMEEMal2Q8xSRPMgOHMcld0=.41bd792f-c20b-4a8e-8cfd-08121e06ddef@github.com>
References: <MiGjmr0ni-K6kF_bTwR2qMEEMal2Q8xSRPMgOHMcld0=.41bd792f-c20b-4a8e-8cfd-08121e06ddef@github.com>
Message-ID: <1n1kqZXljW8ocxLQvYW0IzcrhQA0g5-EYcEk9XclWBo=.1f940508-0def-4740-9034-3fc30ff75a09@github.com>

On Wed, 5 Feb 2025 16:14:41 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change is likely going to need some extra verbiage in the spec for mapConcurrent, and thus a CSR.
> This behavior aligns mapConcurrent with how parallel streams work in conjunction with interruptions of the caller thread.

Closing to re-examine difference/alignment in behavior between parallel Streams and mapConcurrent.

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

PR Comment: https://git.openjdk.org/jdk/pull/23467#issuecomment-2639451110

From vklang at openjdk.org  Thu Feb  6 10:43:19 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 6 Feb 2025 10:43:19 GMT
Subject: RFR: 8349462: Gatherers.mapConcurrent could support async
 interrupts
In-Reply-To: <PHP2ol4qLhs_cn-Sj19BbgEYcqwVL7sKnkzq766viBU=.b6f79067-f64d-4480-8977-ff116ebe3036@github.com>
References: <MiGjmr0ni-K6kF_bTwR2qMEEMal2Q8xSRPMgOHMcld0=.41bd792f-c20b-4a8e-8cfd-08121e06ddef@github.com>
 <PHP2ol4qLhs_cn-Sj19BbgEYcqwVL7sKnkzq766viBU=.b6f79067-f64d-4480-8977-ff116ebe3036@github.com>
Message-ID: <EJIi5X7K1oxCFYxXVhXK-_uEH__k3N_U52jpq1rNClc=.ce51f843-ed42-41d5-8a9a-643cf00eebfe@github.com>

On Thu, 6 Feb 2025 06:14:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This change is likely going to need some extra verbiage in the spec for mapConcurrent, and thus a CSR.
>> This behavior aligns mapConcurrent with how parallel streams work in conjunction with interruptions of the caller thread.
>
> src/java.base/share/classes/java/util/stream/Gatherers.java line 432:
> 
>> 430:                                 } catch (InterruptedException ie) {
>> 431:                                     // We ignore interrupts here because we cannot proceed
>> 432:                                     // until all spawned threads have exited
> 
> Why discard instead of keeping existing deferral? Swallowing interrupt requests generally breaks cancellation.

@dholmes-ora Good question. It is to avoid the situation where re-interruption and/or timing of interrupt leads to difference in behavior. But your question led me to re-examing an assumption so I might have to reconsider the best path forward. In the meantime I'll close the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23467#discussion_r1944497629

From vklang at openjdk.org  Thu Feb  6 10:43:19 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 6 Feb 2025 10:43:19 GMT
Subject: Withdrawn: 8349462: Gatherers.mapConcurrent could support async
 interrupts
In-Reply-To: <MiGjmr0ni-K6kF_bTwR2qMEEMal2Q8xSRPMgOHMcld0=.41bd792f-c20b-4a8e-8cfd-08121e06ddef@github.com>
References: <MiGjmr0ni-K6kF_bTwR2qMEEMal2Q8xSRPMgOHMcld0=.41bd792f-c20b-4a8e-8cfd-08121e06ddef@github.com>
Message-ID: <FlkB4jKm_3FYFn-Sx7xtrmUo4UVdJWwELDpXl652_pM=.b5c0248b-9ca8-4a71-a550-5c12ee5c3ee8@github.com>

On Wed, 5 Feb 2025 16:14:41 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change is likely going to need some extra verbiage in the spec for mapConcurrent, and thus a CSR.
> This behavior aligns mapConcurrent with how parallel streams work in conjunction with interruptions of the caller thread.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/23467

From jpai at openjdk.org  Thu Feb  6 10:44:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Feb 2025 10:44:51 GMT
Subject: Integrated: 8349537: Bad copyright in TestArrayStructs.java
In-Reply-To: <ThmeHr_Ck8Icy4RYqjdc1wllt8eamiLlgx4fmtdeo14=.03274618-3cbb-4e18-886a-fb0ebaecab17@github.com>
References: <ThmeHr_Ck8Icy4RYqjdc1wllt8eamiLlgx4fmtdeo14=.03274618-3cbb-4e18-886a-fb0ebaecab17@github.com>
Message-ID: <9RCcm-74xD3eCriqziLaJb7-orO-Rx0od_qQdfo7cw4=.09e02ba1-933d-4b6c-8114-1c83fe9e9cad@github.com>

On Thu, 6 Feb 2025 10:33:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Added missing comma.
> 
> Thanks,
> Tobias

Looks good and trivial to me.

The new updated looks good and trivial too.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23489#pullrequestreview-2598279120
PR Review: https://git.openjdk.org/jdk/pull/23489#pullrequestreview-2598293251

From thartmann at openjdk.org  Thu Feb  6 10:44:51 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 6 Feb 2025 10:44:51 GMT
Subject: Integrated: 8349537: Bad copyright in TestArrayStructs.java
Message-ID: <ThmeHr_Ck8Icy4RYqjdc1wllt8eamiLlgx4fmtdeo14=.03274618-3cbb-4e18-886a-fb0ebaecab17@github.com>

Added missing comma.

Thanks,
Tobias

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

Commit messages:
 - And another one
 - 8349537: Bad copyright in TestArrayStructs.java

Changes: https://git.openjdk.org/jdk/pull/23489/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23489&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349537
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23489.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23489/head:pull/23489

PR: https://git.openjdk.org/jdk/pull/23489

From thartmann at openjdk.org  Thu Feb  6 10:44:51 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 6 Feb 2025 10:44:51 GMT
Subject: Integrated: 8349537: Bad copyright in TestArrayStructs.java
In-Reply-To: <ThmeHr_Ck8Icy4RYqjdc1wllt8eamiLlgx4fmtdeo14=.03274618-3cbb-4e18-886a-fb0ebaecab17@github.com>
References: <ThmeHr_Ck8Icy4RYqjdc1wllt8eamiLlgx4fmtdeo14=.03274618-3cbb-4e18-886a-fb0ebaecab17@github.com>
Message-ID: <EuC3ay9eIoZF8bsAY6lV5IJhnWNK4ou0M9dQvozvtxU=.c57c6151-5983-4dc6-b3d7-f7336a5a18f7@github.com>

On Thu, 6 Feb 2025 10:33:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Added missing comma.
> 
> Thanks,
> Tobias

Thanks for the quick review!

Thanks again!

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

PR Comment: https://git.openjdk.org/jdk/pull/23489#issuecomment-2639437494
PR Comment: https://git.openjdk.org/jdk/pull/23489#issuecomment-2639449711

From thartmann at openjdk.org  Thu Feb  6 10:44:51 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 6 Feb 2025 10:44:51 GMT
Subject: Integrated: 8349537: Bad copyright in TestArrayStructs.java
In-Reply-To: <ThmeHr_Ck8Icy4RYqjdc1wllt8eamiLlgx4fmtdeo14=.03274618-3cbb-4e18-886a-fb0ebaecab17@github.com>
References: <ThmeHr_Ck8Icy4RYqjdc1wllt8eamiLlgx4fmtdeo14=.03274618-3cbb-4e18-886a-fb0ebaecab17@github.com>
Message-ID: <Um3Vz1AynCY4Q7xM62wPBibNM5pdMSH-tcFUGtWH6TQ=.1f7293b7-6285-477e-a71c-6ecc1e62b7bc@github.com>

On Thu, 6 Feb 2025 10:33:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Added missing comma.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 4618993e
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4618993e27c806e5b349de98c020a91475727d65
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8349537: Bad copyright in TestArrayStructs.java

Reviewed-by: jpai

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

PR: https://git.openjdk.org/jdk/pull/23489

From viktor.klang at oracle.com  Thu Feb  6 10:51:23 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 6 Feb 2025 10:51:23 +0000
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
Message-ID: <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>

I think alignment in behavior between parallel Stream and mapConcurrent in terms of how interruptions are handled is a possible path forward.

I decided to close the PR for now as I realized my parallel Stream example had misled me regarding its exception throwing, so I'll need to go back and refine the solution.

It still seems solvable though.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Wednesday, 5 February 2025 19:20
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Oh good call!

I forgot to check what parallel streams do upon interruption (didn't think they do any blocking calls, but at least the main thread must block).

On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Jige,

I opened an issue to track the concern, and I have proposed a change which seems to align well with how parallel streams behave under caller thread interruption.

I've opened the following PR for review:
https://github.com/openjdk/jdk/pull/23467<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>

If you are able to make a local OpenJDK build with that solution you could check if it addresses your use-cases (or not).
[https://opengraph.githubassets.com/00e04f8a63bde12217df087df7ef8edee563adf7e925d07c75bdeae092180094/openjdk/jdk/pull/23467]<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
8349462: Gatherers.mapConcurrent could support async interrupts by viktorklang-ora ? Pull Request #23467 ? openjdk/jdk<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
This change is likely going to need some extra verbiage in the spec for mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how parallel streams work in conjunction with interrup...
github.com<https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 5 February 2025 16:24
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

I understand the problem.

The main reason I asked is because I want to understand how the core Java team thinks of throwing an unchecked exception.

As explained above, I consider losing cancellability a big deal, a deal breaker even. And I thought throwing unchecked is more acceptable. Because the most common reason the mapConcurrent() VT can be interrupted is due to cancellation from a parent mapConcurrent(), or a parent Structured Concurrency scope. The cancellation could be either from an organic exception, or from the downstream not needing more elements, like maybe due to findFirst() already getting an element.

In both cases, since the concurrent operation is already cancelled (result ignored), what exception pops up to the top level isn't that big of a deal (perhaps only a log record will be seen?)

But if the core Java team considers it a bad idea, I would love to learn and adjust.

On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi,

The problem is that mapConcurrent cannot throw InterruptedException because that is a checked exception, so we cannot clear the interrupted flag and throw that exception.

So the updated semantics is to not cut the stream short but instead run to completion, restoring the interruption flag.

There exists a couple of alternatives to this approach which I am contemplating, but they need to be further explored before I consider moving forward with any of them.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 27 January 2025 17:00
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

It looks like the current fix ignores interruption.

I want to make sure my concern of it defeating cancellation is heard and understood.

The scenarios I worry about is for a mapConcurrent() that fans out to another method call, which internally calls mapConcurrent() as implementation detail.

An example:


List<RefundResponse> refundHelper(transaction) {
  transaction.creditCardAccounts.stream()
    .gather(mapConcurrent(acct -> service.refund(acct))
    .toList();
}

transactions.stream()
    .gather(mapConcurrent(transaction -> refundHelper(transaction));

It seems undesirable that in such a case all the service.refund() calls become non cancellable, because the only way the outer mapConcurrent() cancels the refundHelper() calls is through Thread.interrupt() the virtual threads that call refundHelper(), which would then be disabled by the inner mapConcurrent().

Does this example make sense to you? I can further explain if anything isn't clear.

But I want to make sure the decision to disable interruption is deliberate judgement call that such nested mapConcurrent() is unlikely,or not important.

Cheers,



On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

Please see: https://github.com/openjdk/jdk/pull/23100<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 26 January 2025 23:03
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: mapConcurrent() with InterruptedException

Checking in on what you've found out, Viktor.

From where we left off, I understand that you were looking at alternatives instead of silent truncation?

Have you reached any conclusion?

We touched on disallowing interruption during mapConcurrent(). I still have concerns with disabling cancellation, because it basically undoes this API note from the javadoc<https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>:


API Note:

In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements.
In reality, people will use mapConcurrent() to fan out rpcs. Sometimes these rpcs are just a single blocking call; yet sometimes they may themselves be a Structured Concurrency scope, with 2 or 3 rpcs that constitute a single logical operation. Under two conditions, cancellation is imho important semantic:

  1.  The downstream code uses filter().findFirst(), and when it sees an element, it will return and no longer needs the other pending rpcs to complete. If cancellation is disabled, these unnecessary rpcs will waste system resources.
  2.  One of the rpc throws and the Stream pipeline needs to propagate the exception. Again, if the other rpcs cannot be cancelled, we'll have many zombie rpcs.

Zombie rpcs may or may not be a deal breaker, depending on the specific use case. But for a JDK library, losing cancellation would have a negative impact on usability.

My 2c,


On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Ben,

Thanks for raising these questions?getting feedback is crucial in the Preview stage of features.

I wrote a reply to the Reddit thread so I'll just summarize here:

It is important to note that mapConcurrent() is not a part of the Structured Concurrency JEPs, so it is not designed to join SC scopes.

I'm currently experimenting with ignoring-but-restoring interrupts on the "calling thread" for mapConcurrent(), as well as capping work-in-progress to maxConcurrency (not only capping the concurrency but also the amount of completed-but-yet-to-be-pushed work). Both of these adjustments should increase predictability of behavior in the face of blocking operations with variable delays.

Another adjustment I'm looking at right now is to harden/improve the cleanup to wait for concurrent tasks to acknowledge cancellation, so that once the finisher is done executing the VTs are known to have terminated.

As for not preserving the encounter order, that would be a completely different thing, and I'd encourage you to experiment with that if that functionality would be interesting for your use-case(s).

Again, thanks for your feedback!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Friday, 3 January 2025 17:53
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: mapConcurrent() with InterruptedException

Hi Java Experts,

I sent this email incorrectly to loom-dev@ and was told on Reddit that core-libs-dev is the right list.

The question is about the behavior of mapConcurrent() when the thread is interrupted.

Currently mapConcurrent()'s finisher phase will re-interrupt the thread, then stop at whatever element that has already been processed and return.

This strikes me as a surprising behavior, because for example if I'm running:

   Stream.of(1, 2, 3)
        .gather(mapConcurrent(i -> i * 2))
        .toList()

and the thread is being interrupted, the result could be any of [2], [2, 4] or [2, 4, 6].

Since thread interruption is cooperative, there is no guarantee that the thread being interrupted will just abort. It's quite possible that it'll keep going and then will use for example [2] as the result of doubling the list of [1, 2, 3], which is imho incorrect.

In the Reddit<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks.

There had been discussion about alternative strategies:

  1.  Don't respond to interruption and just keep running to completion.
  2.  Re-interrupt thread and wrap the InterruptedException in a standard unchecked exception (StructuredConcurrencyInterruptedException?).

I have concerns with option 1 because it disables cancellation propagation when mapConcurrent() itself is used in a subtask of a parent mapConcurrent() or in a StructuredConcurrencyScope.

Both equivalent Future-composition async code, or C++'s fiber trees support cancellation propagation and imho it's a critical feature or else it's possible that a zombie thread is still sending RPCs long after the main thread has exited (failed, or falled back to some default action).

My arguments for option 2:

  1.  InterruptedException is more error prone than traditional checked exceptions for users to catch and handle. They can forget to re-interrupt the thread. It's so confusing that even seasoned programmers may not know they are supposed to re-interrupt the thread.
  2.  With Stream API using functional interfaces like Supplier, Function, the option of just tacking on "throws IE" isn't available to many users.
  3.  With Virtual Threads, it will be more acceptable, or even become common to do blocking calls from a stream operation (including but exclusive to mapConcurrent()). So the chance users are forced to deal with IE will become substantially higher.
  4.  Other APIs such as the Structured Concurrency API have already started wrapping system checked exceptions like ExecutionException, TimeoutException in unchecked exceptions ( join()<https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for example).
  5.  Imho, exceptions that we'd rather users not catch and handle but instead should mostly just propagate up as is, should be unchecked.

There is also a side discussion<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread?

Thank you and cheers!

Ben Yu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250206/c79d4d00/attachment-0001.htm>

From coleenp at openjdk.org  Thu Feb  6 12:11:14 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 12:11:14 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <yuiSOJZCDOCs2H5MHBg5FZnJYjy4XxsEnRy87qL8DFg=.1d5fac0f-8695-4e26-ac3f-0d787421607f@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
 <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
 <yjBy9m5yM18_XOZjEN8dn5osnTUPviOliyM_qNHoKgQ=.f9c43bc8-4bee-46bb-b466-7d471bfcd582@github.com>
 <8Wx3xbbOnPXS5n1RuNaesqHbhKV3iLwrCVF0s6uWOrA=.cb20728e-e13c-4667-822b-3ba424cbc12f@github.com>
 <yuiSOJZCDOCs2H5MHBg5FZnJYjy4XxsEnRy87qL8DFg=.1d5fac0f-8695-4e26-ac3f-0d787421607f@github.com>
Message-ID: <4aAX8rSEcvkeYteaJUXHfVEzBbNGwGlhDLIz548dFcs=.616fa7dd-d5bf-42d5-aca0-0bea0b5591d0@github.com>

On Wed, 5 Feb 2025 21:44:37 GMT, Dean Long <dlong at openjdk.org> wrote:

>> @DanHeidinga Great explanation, thank you!
>
> If Class had other fields smaller than `int`, would be consider making this something like `char` to save space (allowing all the sub-word fields to be compacted)?

I thought of doing this since I made modifiers u2 in the Hotspot code just previously, but all the Java code refers to this as an int.  And I didn't see other fields to compact it with.  Maybe if access_flags are moved we could make them both char (not short since they're unsigned).  It feels weird to not have unsigned short to my C++ eyes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944613105

From coleenp at openjdk.org  Thu Feb  6 12:15:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 12:15:13 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]
In-Reply-To: <6TuFE5mx8jXm2donAE_cM3I5UXCaB1eKrpCyp7qk0wM=.1c585567-cf27-4d3e-bca9-4aa7a556942c@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <syxVRD9ASKql288dZ8hdYJjliScymiDGldc7fSoEAiU=.d4084758-4fb0-496f-a7bb-ad0093129f11@github.com>
 <rnBxm-eKFKaOGdMay4i94tiSB28d_9s6SOrfGAnrTZk=.875ea4cd-2d71-4139-997c-ef1f1a0fd59d@github.com>
 <as8AhJFiM7kItFtO_ryI9gtRMyedA3SBBPMU53jA32A=.f1630384-852e-4273-83ff-52783e8a4699@github.com>
 <6TuFE5mx8jXm2donAE_cM3I5UXCaB1eKrpCyp7qk0wM=.1c585567-cf27-4d3e-bca9-4aa7a556942c@github.com>
Message-ID: <nX9vDm85JyvkMKXgWyk_hQbg8Sh0hEaUKfK4uNpKmDE=.34340f7f-2484-42fb-91cf-d47147c33195@github.com>

On Thu, 6 Feb 2025 07:29:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @DanHeidinga suggested this for my other PR as a convention that's used for the j.l.Class constructor.
>
> I am still missing what can actually set a PD here, sorry. ??

Because the field is final, it has to be initialized in the constructor in Java code.  My initial patch for modifiers chose to initialize to zero but that's not quite correct.  The constructor cannot be called nor can it be made accessible with setAccessible().   So the constructor for java.lang.Class is essentially the Hotspot code JavaClasses::create_mirror().  This is where the PD is assigned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1944618468

From rgiulietti at openjdk.org  Thu Feb  6 12:16:11 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 6 Feb 2025 12:16:11 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <Bh31yb9xNkCWAW0XkAen5i4e_hvBJkYFsjNIcL5Ybjs=.7e9077dd-f8a3-4479-85bd-6e61b35aa746@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

What about dropping "BE" from all big-endian method names?
This would reduces the number of files to review in `java.io` to 0 (admittedly, it's a rather mechanical review).
I know this would be less symmetrical, but...

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 53:

> 51: 
> 52:     public static char getCharBO(byte[] array, int index, boolean big) {
> 53:         Preconditions.checkIndex(index, array.length - Character.BYTES + 1, Preconditions.AIOOBE_FORMATTER);

Suggestion:

        Preconditions.checkIndex(index, array.length - (Character.BYTES - 1), Preconditions.AIOOBE_FORMATTER);


Similarly for all cases below.

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

PR Comment: https://git.openjdk.org/jdk/pull/23478#issuecomment-2639657316
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944571743

From coleenp at openjdk.org  Thu Feb  6 13:13:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 13:13:29 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
Message-ID: <gqMJXQpP6idR6RS6bHOqE8D6JI8mlg5JpqZDcCc0L7o=.590b8dd1-a70f-4af4-88be-3fb205b8870c@github.com>

On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright and param name

Thank you for the detailed comments.

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

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2598534835

From coleenp at openjdk.org  Thu Feb  6 13:13:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 13:13:29 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v3]
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <eZJdUNeSPci8TGUYqbi99392SJYBoDfBV2YSQWJleaI=.4f05072f-5d2d-4a6d-81b1-333305cd07c1@github.com>

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

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

  Update src/hotspot/share/opto/memnode.cpp
  
  Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22652/files
  - new: https://git.openjdk.org/jdk/pull/22652/files/ff693418..f92620eb

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

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

PR: https://git.openjdk.org/jdk/pull/22652

From coleenp at openjdk.org  Thu Feb  6 13:13:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 13:13:30 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <7KdNVSXLx0N027uyQgtUuN82VpXTlyPpPOnBv3sqYRs=.6b549b56-36f9-4ab3-8469-4779d93dd1e7@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>
 <0ZM_vg_dAmbdbeoIeZ8ylBUDj_4_jxM-aE6IKoH6ykM=.69c7554f-5e2b-40b9-8d1a-abe147548dbb@github.com>
 <0efX7bcHNl5p1RoF3VnqZIabdavsGosuMI14cZPDzbQ=.2bde6bbf-a59b-4f5b-9c68-7a8a258b2ee5@github.com>
 <7KdNVSXLx0N027uyQgtUuN82VpXTlyPpPOnBv3sqYRs=.6b549b56-36f9-4ab3-8469-4779d93dd1e7@github.com>
Message-ID: <fIDzS3_DxYMZA78UX_HiBqnAPvUcE2qhBfw30T2hrv4=.d65d867b-2a38-49b7-ba1b-8284ae19e7d2@github.com>

On Thu, 6 Feb 2025 04:37:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> OK, if the extra load turns out to be a problem in the future, we could look into why the compilers are generating the load when the Class is known/constant.  If the old intrinsic was able to pull the constant out of the Klass, then surely we can do the same and pull the value from the Class field.
>
> Does `static final` help here?

Yes.  Yes it does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944694824

From coleenp at openjdk.org  Thu Feb  6 13:13:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 13:13:29 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <1yPHOj_hANp7ZvMfmgi6lRkpokgNNaUSc09FJfZvWk8=.bfcf2780-4afe-4253-ae0b-e3bc6ab7ee86@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <1yPHOj_hANp7ZvMfmgi6lRkpokgNNaUSc09FJfZvWk8=.bfcf2780-4afe-4253-ae0b-e3bc6ab7ee86@github.com>
Message-ID: <H3qkoCqZwtAyXL1ZWdPnuzvkV3ZRUuM565siUlSO4lM=.2339a020-bf74-41a4-adbf-2273284d06b6@github.com>

On Wed, 5 Feb 2025 21:24:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright and param name
>
> src/hotspot/share/compiler/compileLog.cpp line 116:
> 
>> 114:         print(" unloaded='1'");
>> 115:       } else {
>> 116:         print(" flags='%d'", klass->access_flags());
> 
> There may be tools that parse the log file and get confused by this change.  Maybe we should also change the label from "flags" to "access flags".

Okay, I wanted to remove the one use of ciKlass::modifier_flags() and the field with this change, but I'll add it back since I added a Klass::modifier_flags() function.

> src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp line 350:
> 
>> 348:   writer->write(mark_symbol(klass, leakp));
>> 349:   writer->write(package_id(klass, leakp));
>> 350:   writer->write(klass->compute_modifier_flags());
> 
> Isn't this much more expensive than grabbing the value from the mirror, especially if we have to iterate over inner classes?

I was trying not to add a Klass::modifier_flags function, but now I have.

> src/hotspot/share/opto/memnode.cpp line 2458:
> 
>> 2456:           return TypePtr::NULL_PTR;
>> 2457:         }
>> 2458:         // ???
> 
> I suspect that we still need this code to support intrinsics like LibraryCallKit::inline_native_classID() and maybe other users of this field, but the comment below no longer makes sense.

Thank you for noticing the ??? that I left in and the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944651499
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944640356
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944697467

From coleenp at openjdk.org  Thu Feb  6 13:23:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 13:23:54 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v4]
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <4ruwzJXM3Jgy0rbobE3PPNAH4k8c10_4zAi6mCmc4Lw=.ccf7c825-4ffc-49fb-bc42-3c0168c1dcf8@github.com>

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

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

  Add Klass::modifier_flags to look in the mirror, restore ciKlass::modifier_flags, add benchmark.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22652/files
  - new: https://git.openjdk.org/jdk/pull/22652/files/f92620eb..85026362

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

  Stats: 28 lines in 7 files changed: 26 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22652.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22652/head:pull/22652

PR: https://git.openjdk.org/jdk/pull/22652

From rgiulietti at openjdk.org  Thu Feb  6 14:09:13 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 6 Feb 2025 14:09:13 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <x2haSwVHMihhu6JZXvMj3r3RnQVbLF3n94boptanIBM=.b63e6cc4-2ff5-49f6-9a92-a0feae5758c2@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

test/jdk/jdk/internal/util/ByteArray/Types.java line 27:

> 25:  * @test
> 26:  * @bug 8349503
> 27:  * @library /test/lib

Suggestion:

 * @library /test/lib
 * @key randomness

test/jdk/jdk/internal/util/ByteArray/Types.java line 64:

> 62:                 new ReadCase<>("u2", ByteArray::getUnsignedShortBO, ByteArray::getUnsignedShortBE, ByteArray::getUnsignedShortLE, 2, u2 -> ((u2 >> Byte.SIZE) & 0xFF) | ((u2 << Byte.SIZE) & 0xFF00), Comparator.naturalOrder()),
> 63:                 new ReadCase<>("int", ByteArray::getIntBO, ByteArray::getIntBE, ByteArray::getIntLE, Integer.BYTES, Integer::reverseBytes, Comparator.naturalOrder()),
> 64:                 new ReadCase<>("float", ByteArray::getFloatBO, ByteArray::getFloatBE, ByteArray::getFloatLE, Float.BYTES, null, Comparator.comparing(Float::floatToRawIntBits)),

Would it be possible to have a local `reverseBytes` for `float` and `double` as well?

test/jdk/jdk/internal/util/ByteArray/Types.java line 124:

> 122:                 new WriteCase<>("int", ByteArray::setIntBO, ByteArray::setIntBE, ByteArray::setIntLE, Integer.BYTES, List.of(42)),
> 123:                 new WriteCase<>("float", ByteArray::setFloatBO, ByteArray::setFloatBE, ByteArray::setFloatLE, Float.BYTES, List.of(Float.NaN, Float.intBitsToFloat(0x7FF23847))),
> 124:                 new WriteCase<>("float raw", ByteArray::setFloatRawBO, ByteArray::setFloatRawBE, ByteArray::setFloatRawLE, Float.BYTES, List.of(1.0F)),

Raw seems to be exercised only on unproblematic cases, not on NaNs.

Similarly for "double raw".

test/jdk/jdk/internal/util/ByteArray/Types.java line 152:

> 150:         assertThrows(IndexOutOfBoundsException.class, () -> leWriter.set(arr, arrayLen - size + 1, value));
> 151: 
> 152:         int index = 0;

This is always 0.

test/jdk/jdk/internal/util/ByteArray/Types.java line 173:

> 171:             var arrBe1 = arr.clone();
> 172:             beWriter.set(arrBe1, index, v1);
> 173:             assertArrayEquals(arrBe, arrBe1);

What about the little-endian case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944742266
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944786100
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944783068
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944769063
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944772926

From asemenyuk at openjdk.org  Thu Feb  6 14:13:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Feb 2025 14:13:15 GMT
Subject: Integrated: 8346434: Add test for non-automatic service binding
In-Reply-To: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
References: <YgYJptHKIfS93Iqw-MZi21xmo-8Y4-leKwiX5oZ2GBI=.61ca57a7-caf6-4e90-883b-8e0f54ac8ff0@github.com>
Message-ID: <DeT6bBKUjiC8hOyzDS4JfwMqcQWewcEdF9RnJItmBRU=.5e9b9a6e-bcee-4d5c-8a10-523c08dffda3@github.com>

On Fri, 10 Jan 2025 21:23:22 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Added a test case to JLinkOptionsTest to test that jpackage doesn't bind services in app's runtime by default.
> 
> The test builds two app images for the same app. One with the default jlink options and another with `--bind-services` jlink option. The test compares module lists from both runtimes. The expected result is that the runtime built with `--bind-services` jlink option has additional modules.
> 
> The PR must be integrated after https://github.com/openjdk/jdk/pull/22644. Otherwise, the newly added test will fail.

This pull request has now been integrated.

Changeset: 2093bb74
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2093bb74676620c416e42fb94b6f5a482700926b
Stats:     70 lines in 3 files changed: 49 ins; 10 del; 11 mod

8346434: Add test for non-automatic service binding

Reviewed-by: almatvee

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

PR: https://git.openjdk.org/jdk/pull/23047

From pminborg at openjdk.org  Thu Feb  6 14:28:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Feb 2025 14:28:11 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <En1fQAmnypO9c23r8ncpx9_VlO1NRAW9XcRMz59BTM4=.ab82b928-4c04-40f7-a686-b8de36b4cea2@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 57:

> 55:     }
> 56: 
> 57:     public static short getShortBO(byte[] array, int index, boolean big) {

If we have methods `getShortBE` and `getShortLE` then perhaps this method should just be called `getShort`.

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 62:

> 60:     }
> 61: 
> 62:     public static int getIntBO(byte[] array, int index, boolean big) {

I suggest to rename `big` to `bigEndian` to use the same naming conventions as in `Unsafe`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944819768
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944817837

From coleenp at openjdk.org  Thu Feb  6 14:31:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 14:31:28 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v5]
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <Rnq14bXvkpbsJQdX-PF9uNr86akoq0ujgHPrFBLfIqY=.0278cab5-71ed-4a80-a751-e38248928e2e@github.com>

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

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

  Make compute_modifiers return u2.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22652/files
  - new: https://git.openjdk.org/jdk/pull/22652/files/85026362..146e2551

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

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22652.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22652/head:pull/22652

PR: https://git.openjdk.org/jdk/pull/22652

From coleenp at openjdk.org  Thu Feb  6 14:31:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 14:31:29 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <1yPHOj_hANp7ZvMfmgi6lRkpokgNNaUSc09FJfZvWk8=.bfcf2780-4afe-4253-ae0b-e3bc6ab7ee86@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <1yPHOj_hANp7ZvMfmgi6lRkpokgNNaUSc09FJfZvWk8=.bfcf2780-4afe-4253-ae0b-e3bc6ab7ee86@github.com>
Message-ID: <9iIj0xWClD_H4U0MiEUrQGqeIgjyFdC4tuN0sAP9kUo=.1c11d464-4380-4954-9e9f-c40872acff24@github.com>

On Wed, 5 Feb 2025 21:26:29 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright and param name
>
> src/hotspot/share/oops/instanceKlass.hpp line 1128:
> 
>> 1126: #endif
>> 1127: 
>> 1128:   int compute_modifier_flags() const;
> 
> I don't see why this can't stay u2.

I had some compilation error for conversion that has disappeared into the either with u2, so I've restored them to u2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944825437

From psandoz at openjdk.org  Thu Feb  6 14:33:11 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 6 Feb 2025 14:33:11 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <yaJWeScAM3bCyZx8Tg7SYFdRlXHsPufTXUEOFjf7zss=.a7e82b8d-4b5b-4f4c-97de-067d386913be@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

This looks reasonable, not looked in detail at all of it. Although i understand the motivation can you please revert the changes to VarHandle. VarHandle is intended to be as thin as possible safe wrapper around unsafe. This PR changes how this is for one particular kind of handle thus differing from the others, and it also creates an indirection with a potential independently moving part.

Also, some guidance in Java on ByteArray would be useful on when to use it e.g., enumerating the cases such as early execution of the JVM etc.

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

PR Review: https://git.openjdk.org/jdk/pull/23478#pullrequestreview-2598852813

From pminborg at openjdk.org  Thu Feb  6 14:33:12 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Feb 2025 14:33:12 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <evAenTOjoERTQqzy0mFSRfPw3pkiKTJGAGWWtUXBFnc=.288e0965-3e4b-4b91-946c-351d89c976f5@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 131:

> 129:     // BE methods
> 130: 
> 131:     public static char getCharBE(byte[] array, int offset) {

I think it is worth making the effort to document these methods as they are used across the JDK. We could just take the docs from the old class and modify it slightly.

src/java.desktop/share/classes/javax/imageio/stream/ImageInputStreamImpl.java line 245:

> 243:             throw new EOFException();
> 244:         }
> 245:         return (byteOrder == ByteOrder.BIG_ENDIAN)

This could just be `ByteArray.getShortBO(byteBuff, 0, byteOrder == ByteOrder.BIG_ENDIAN)`. Same for the others.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944825706
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944828604

From pminborg at openjdk.org  Thu Feb  6 14:36:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Feb 2025 14:36:14 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <bxO42XUIIjw5Pju8039DcZoQI-WAwOD6hN2Jvz0397c=.8215bc1b-e843-450b-9c5d-1395b419e98a@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

test/jdk/jdk/internal/util/ByteArray/Types.java line 82:

> 80:         byte[] arr = new byte[arrayLen];
> 81: 
> 82:         assertThrows(NullPointerException.class, () -> orderedReader.get(null, 0, true));

I suggest breaking out the invariant tests in a separate test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944834882

From alanb at openjdk.org  Thu Feb  6 14:36:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Feb 2025 14:36:14 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v5]
In-Reply-To: <AKYfWWvD5swMFVmt2c0zHTMd7d1q8b2kjcONoZP3Lp4=.56ce146a-a9e9-4d01-9fcb-8fb76b4b90d1@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <AKYfWWvD5swMFVmt2c0zHTMd7d1q8b2kjcONoZP3Lp4=.56ce146a-a9e9-4d01-9fcb-8fb76b4b90d1@github.com>
Message-ID: <ZCPqZJZMge18qWYr8forvtyJ4nljCII84NOtQFfl7Q0=.3473465c-ff5c-41ad-a046-f579c89c05ea@github.com>

On Wed, 5 Feb 2025 17:57:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Remove @Stable annotation for final field.

test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java line 213:

> 211:             assertTrue(false);
> 212:         } catch (NoSuchFieldException expected) { }
> 213:     }

The test is about accessibility, it's checking for IllegalAccessException and InaccessibleObjectException. So not the right place to test that a field is hidden from core reflection. Can you look at test/jdk/internal/reflect/Reflection/Filtering.java as that is probably the right place to list the protectionDomain field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1944834044

From rriggs at openjdk.org  Thu Feb  6 14:39:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Feb 2025 14:39:11 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <0DK9LJKJvNPIUaWuV8y8U6t6W0YmmVG7VqyZlpr_q2Y=.b7e801fa-070a-40ce-ac66-a266544b6425@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

It would have been useful to get agreement on the concept and the naming before committing to the implementation.

The BE/BO/LE are noise in the API.  The little endian cases are a minority and should attract more attention in the API.
The network byte-order/big-endian cases should keep the simple names.

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

PR Comment: https://git.openjdk.org/jdk/pull/23478#issuecomment-2640004192

From viktor.klang at oracle.com  Thu Feb  6 14:47:34 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 6 Feb 2025 14:47:34 +0000
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>

After some more investigation it seems tractable to propagate interruption of the caller in sequential mode, but parallel mode will require much bigger considerations.

I made a comment to that effect on the JBS issue: https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Viktor Klang <viktor.klang at oracle.com>
Sent: Thursday, 6 February 2025 11:51
To: Jige Yu <yujige at gmail.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

I think alignment in behavior between parallel Stream and mapConcurrent in terms of how interruptions are handled is a possible path forward.

I decided to close the PR for now as I realized my parallel Stream example had misled me regarding its exception throwing, so I'll need to go back and refine the solution.

It still seems solvable though.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Wednesday, 5 February 2025 19:20
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Oh good call!

I forgot to check what parallel streams do upon interruption (didn't think they do any blocking calls, but at least the main thread must block).

On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Jige,

I opened an issue to track the concern, and I have proposed a change which seems to align well with how parallel streams behave under caller thread interruption.

I've opened the following PR for review:
https://github.com/openjdk/jdk/pull/23467<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>

If you are able to make a local OpenJDK build with that solution you could check if it addresses your use-cases (or not).
[https://opengraph.githubassets.com/00e04f8a63bde12217df087df7ef8edee563adf7e925d07c75bdeae092180094/openjdk/jdk/pull/23467]<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
8349462: Gatherers.mapConcurrent could support async interrupts by viktorklang-ora ? Pull Request #23467 ? openjdk/jdk<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
This change is likely going to need some extra verbiage in the spec for mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how parallel streams work in conjunction with interrup...
github.com<https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 5 February 2025 16:24
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

I understand the problem.

The main reason I asked is because I want to understand how the core Java team thinks of throwing an unchecked exception.

As explained above, I consider losing cancellability a big deal, a deal breaker even. And I thought throwing unchecked is more acceptable. Because the most common reason the mapConcurrent() VT can be interrupted is due to cancellation from a parent mapConcurrent(), or a parent Structured Concurrency scope. The cancellation could be either from an organic exception, or from the downstream not needing more elements, like maybe due to findFirst() already getting an element.

In both cases, since the concurrent operation is already cancelled (result ignored), what exception pops up to the top level isn't that big of a deal (perhaps only a log record will be seen?)

But if the core Java team considers it a bad idea, I would love to learn and adjust.

On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi,

The problem is that mapConcurrent cannot throw InterruptedException because that is a checked exception, so we cannot clear the interrupted flag and throw that exception.

So the updated semantics is to not cut the stream short but instead run to completion, restoring the interruption flag.

There exists a couple of alternatives to this approach which I am contemplating, but they need to be further explored before I consider moving forward with any of them.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 27 January 2025 17:00
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

It looks like the current fix ignores interruption.

I want to make sure my concern of it defeating cancellation is heard and understood.

The scenarios I worry about is for a mapConcurrent() that fans out to another method call, which internally calls mapConcurrent() as implementation detail.

An example:


List<RefundResponse> refundHelper(transaction) {
  transaction.creditCardAccounts.stream()
    .gather(mapConcurrent(acct -> service.refund(acct))
    .toList();
}

transactions.stream()
    .gather(mapConcurrent(transaction -> refundHelper(transaction));

It seems undesirable that in such a case all the service.refund() calls become non cancellable, because the only way the outer mapConcurrent() cancels the refundHelper() calls is through Thread.interrupt() the virtual threads that call refundHelper(), which would then be disabled by the inner mapConcurrent().

Does this example make sense to you? I can further explain if anything isn't clear.

But I want to make sure the decision to disable interruption is deliberate judgement call that such nested mapConcurrent() is unlikely,or not important.

Cheers,



On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

Please see: https://github.com/openjdk/jdk/pull/23100<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 26 January 2025 23:03
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: mapConcurrent() with InterruptedException

Checking in on what you've found out, Viktor.

From where we left off, I understand that you were looking at alternatives instead of silent truncation?

Have you reached any conclusion?

We touched on disallowing interruption during mapConcurrent(). I still have concerns with disabling cancellation, because it basically undoes this API note from the javadoc<https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>:


API Note:

In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements.
In reality, people will use mapConcurrent() to fan out rpcs. Sometimes these rpcs are just a single blocking call; yet sometimes they may themselves be a Structured Concurrency scope, with 2 or 3 rpcs that constitute a single logical operation. Under two conditions, cancellation is imho important semantic:

  1.  The downstream code uses filter().findFirst(), and when it sees an element, it will return and no longer needs the other pending rpcs to complete. If cancellation is disabled, these unnecessary rpcs will waste system resources.
  2.  One of the rpc throws and the Stream pipeline needs to propagate the exception. Again, if the other rpcs cannot be cancelled, we'll have many zombie rpcs.

Zombie rpcs may or may not be a deal breaker, depending on the specific use case. But for a JDK library, losing cancellation would have a negative impact on usability.

My 2c,


On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Ben,

Thanks for raising these questions?getting feedback is crucial in the Preview stage of features.

I wrote a reply to the Reddit thread so I'll just summarize here:

It is important to note that mapConcurrent() is not a part of the Structured Concurrency JEPs, so it is not designed to join SC scopes.

I'm currently experimenting with ignoring-but-restoring interrupts on the "calling thread" for mapConcurrent(), as well as capping work-in-progress to maxConcurrency (not only capping the concurrency but also the amount of completed-but-yet-to-be-pushed work). Both of these adjustments should increase predictability of behavior in the face of blocking operations with variable delays.

Another adjustment I'm looking at right now is to harden/improve the cleanup to wait for concurrent tasks to acknowledge cancellation, so that once the finisher is done executing the VTs are known to have terminated.

As for not preserving the encounter order, that would be a completely different thing, and I'd encourage you to experiment with that if that functionality would be interesting for your use-case(s).

Again, thanks for your feedback!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Friday, 3 January 2025 17:53
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: mapConcurrent() with InterruptedException

Hi Java Experts,

I sent this email incorrectly to loom-dev@ and was told on Reddit that core-libs-dev is the right list.

The question is about the behavior of mapConcurrent() when the thread is interrupted.

Currently mapConcurrent()'s finisher phase will re-interrupt the thread, then stop at whatever element that has already been processed and return.

This strikes me as a surprising behavior, because for example if I'm running:

   Stream.of(1, 2, 3)
        .gather(mapConcurrent(i -> i * 2))
        .toList()

and the thread is being interrupted, the result could be any of [2], [2, 4] or [2, 4, 6].

Since thread interruption is cooperative, there is no guarantee that the thread being interrupted will just abort. It's quite possible that it'll keep going and then will use for example [2] as the result of doubling the list of [1, 2, 3], which is imho incorrect.

In the Reddit<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks.

There had been discussion about alternative strategies:

  1.  Don't respond to interruption and just keep running to completion.
  2.  Re-interrupt thread and wrap the InterruptedException in a standard unchecked exception (StructuredConcurrencyInterruptedException?).

I have concerns with option 1 because it disables cancellation propagation when mapConcurrent() itself is used in a subtask of a parent mapConcurrent() or in a StructuredConcurrencyScope.

Both equivalent Future-composition async code, or C++'s fiber trees support cancellation propagation and imho it's a critical feature or else it's possible that a zombie thread is still sending RPCs long after the main thread has exited (failed, or falled back to some default action).

My arguments for option 2:

  1.  InterruptedException is more error prone than traditional checked exceptions for users to catch and handle. They can forget to re-interrupt the thread. It's so confusing that even seasoned programmers may not know they are supposed to re-interrupt the thread.
  2.  With Stream API using functional interfaces like Supplier, Function, the option of just tacking on "throws IE" isn't available to many users.
  3.  With Virtual Threads, it will be more acceptable, or even become common to do blocking calls from a stream operation (including but exclusive to mapConcurrent()). So the chance users are forced to deal with IE will become substantially higher.
  4.  Other APIs such as the Structured Concurrency API have already started wrapping system checked exceptions like ExecutionException, TimeoutException in unchecked exceptions ( join()<https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for example).
  5.  Imho, exceptions that we'd rather users not catch and handle but instead should mostly just propagate up as is, should be unchecked.

There is also a side discussion<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread?

Thank you and cheers!

Ben Yu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250206/1256bd3a/attachment-0001.htm>

From alanb at openjdk.org  Thu Feb  6 15:01:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Feb 2025 15:01:28 GMT
Subject: RFR: 8349189: Speed up DateTime parse & format via Class File API
 [v11]
In-Reply-To: <pZyjbkMKNfkml8IbnMEy5oF3rwOnKHGG6J99sUA6PUw=.33c09e07-3d3a-4b8f-8e59-e568a01dda66@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
 <pZyjbkMKNfkml8IbnMEy5oF3rwOnKHGG6J99sUA6PUw=.33c09e07-3d3a-4b8f-8e59-e568a01dda66@github.com>
Message-ID: <pWYS-bIas8bbNzBEG4gf9B7pF4rDEXeddUitdqeoi1o=.8a083501-9001-4a7f-947c-2376e1296a32@github.com>

On Tue, 4 Feb 2025 13:39:28 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
>> 
>> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
>> 
>> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
>> 
>> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
>> 
>> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more use getInt & add more test

I've set the number of reviewers to at least 2 as there is a lot of complexity proposed here and one Reviewer will not be sufficient. Before spending any time on this, maintainers in this area will need to consider whether the complexity is worth it and whether resources should be taken from larger projects to review the proposed changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/23384#issuecomment-2636511769

From vklang at openjdk.org  Thu Feb  6 15:05:31 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 6 Feb 2025 15:05:31 GMT
Subject: Integrated: 8347842: ThreadPoolExecutor specification discusses
 RuntimePermission
In-Reply-To: <dAFSdkLUXego1MjE59zkavYOoN7tj4CyoXrO8PZUGdM=.54dea67a-df48-4e49-94fe-945708c1e1b7@github.com>
References: <dAFSdkLUXego1MjE59zkavYOoN7tj4CyoXrO8PZUGdM=.54dea67a-df48-4e49-94fe-945708c1e1b7@github.com>
Message-ID: <DCT2ZTKsAonXjT1WLnOx73WQq8WT28e0tPXCuVwr5Ws=.706db518-1741-44c9-9f69-7372257dd00c@github.com>

On Thu, 16 Jan 2025 13:46:16 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Removes ThreadPoolExecutor javadoc which mentions RuntimePermission.

This pull request has now been integrated.

Changeset: 5ec1aae2
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ec1aae21e80d86c55df28a86935f50ae77f7b41
Stats:     6 lines in 1 file changed: 0 ins; 5 del; 1 mod

8347842: ThreadPoolExecutor specification discusses RuntimePermission

Reviewed-by: alanb, jpai

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

PR: https://git.openjdk.org/jdk/pull/23156

From kevin.bourrillion at oracle.com  Thu Feb  6 15:29:01 2025
From: kevin.bourrillion at oracle.com (Kevin Bourrillion)
Date: Thu, 6 Feb 2025 15:29:01 +0000
Subject: Adopting SequencedCollection via multi-release jars?
In-Reply-To: <CAHY-eHs9Vt-68sT1TfC9LBAkyveKwtM9O9O7LPNi57VV0V3OpQ@mail.gmail.com>
References: <CAHY-eHs9Vt-68sT1TfC9LBAkyveKwtM9O9O7LPNi57VV0V3OpQ@mail.gmail.com>
Message-ID: <F36E051D-6ED0-4639-AD84-76319F35C740@oracle.com>

Thanks Fabian!

I am trying to get a conversation going about this, and I really appreciate this prod. The fact that a library API like Guava's still can?t use APIs from Java 9 (7 years later) is pretty sad.

I am pretty sure there won't be any quick fixes, but I do think we need to push on this somehow.

I hope I can come back with something useful to say, but it will probably take some time.




> On Feb 4, 2025, at 8:36?AM, Fabian Meumertzheim <fabian at buildbuddy.io> wrote:
> 
> Guava provides immutable collections such as ImmutableList that are
> naturally sequenced. It would be useful to integrate it with Java 21's
> SequencedCollection interface. However, Guava needs to keep supporting
> Java 11 for the foreseeable future.
> 
> An idea that may allow Guava to remain compatible but still adopt
> SequencedCollection today would be to have classes implement a
> vendored and renamed version of the SequencedCollection interface and
> "override" it with an interface that extends the actual
> SequencedCollection interface in the 21 subdirectory of a
> multi-release JAR. However, the JAR specification states that:
> 
> "The public API exported by the classes in a multi-release JAR file
> must be exactly the same across versions, ..."
> 
> Would the public API be considered to be identical in the case where
> only the hierarchy of implemented interfaces changes? If not, is there
> another supported way for a class to start implementing
> SequencedCollection while remaining compatible with JDK versions that
> don't provide the interface yet?
> 
> Best,
> Fabian


From duke at openjdk.org  Thu Feb  6 15:37:44 2025
From: duke at openjdk.org (kabutz)
Date: Thu, 6 Feb 2025 15:37:44 GMT
Subject: RFR: 8349543: LinkedBlockingDeque does not immediately throw
 InterrruptedException in put/take
Message-ID: <Da_VhZrKMVCSNPN6BSYHrYLsU3MnehmJZcI0ZJUzaJ8=.eb25a512-e279-47f4-ae14-11c965f204cd@github.com>

The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.

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

Commit messages:
 - Added test to check that putFirst(), putLast(), takeFirst() and takeLast() all throw InterruptedException immediately if the thread is interrupted.
 - Used lockInterruptibly() to cause InterruptedException if thread is already interrupted when putXXX() and takeXXX() are called

Changes: https://git.openjdk.org/jdk/pull/23464/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23464&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349543
  Stats: 74 lines in 2 files changed: 58 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/23464.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23464/head:pull/23464

PR: https://git.openjdk.org/jdk/pull/23464

From dl at openjdk.org  Thu Feb  6 15:37:44 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 6 Feb 2025 15:37:44 GMT
Subject: RFR: 8349543: LinkedBlockingDeque does not immediately throw
 InterrruptedException in put/take
In-Reply-To: <Da_VhZrKMVCSNPN6BSYHrYLsU3MnehmJZcI0ZJUzaJ8=.eb25a512-e279-47f4-ae14-11c965f204cd@github.com>
References: <Da_VhZrKMVCSNPN6BSYHrYLsU3MnehmJZcI0ZJUzaJ8=.eb25a512-e279-47f4-ae14-11c965f204cd@github.com>
Message-ID: <44wMBdipUdWdEPJFBhMD1PNrjdG3l1x66e1RUlg5v3o=.c1958d92-db7c-418c-bb7a-ea5fb07fc70a@github.com>

On Wed, 5 Feb 2025 15:36:15 GMT, kabutz <duke at openjdk.org> wrote:

> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.

Thanks for finding this. The only question is whether we believe that any existing usage might depend on current behavior, and if so should it be done anyway?

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

PR Comment: https://git.openjdk.org/jdk/pull/23464#issuecomment-2637728302

From pminborg at openjdk.org  Thu Feb  6 15:38:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Feb 2025 15:38:56 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v4]
In-Reply-To: <yUlY6ni_YHl4r-vnp81oNN5sxTH2Q0lSU5v9GZgEOvI=.043aaaa6-c630-4877-a497-17cda7fa279b@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
 <yUlY6ni_YHl4r-vnp81oNN5sxTH2Q0lSU5v9GZgEOvI=.043aaaa6-c630-4877-a497-17cda7fa279b@github.com>
Message-ID: <NX-9vG6ZC3D8s_OSQdL4ibOTw2h7cLhlo0mCjfE1vxE=.34e0c383-c9f5-44e4-8818-804a86d75817@github.com>

On Wed, 5 Feb 2025 14:43:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
>> 
>> There are also some changes in other classes (notably `j.l.Object`) which, if implemented, can take us four additional levels of inlining. However, there is a tradeoff with adding `@ForceInline` and just trying to get as deep as possible for a specific use case is probably not the best idea. 
>> 
>> So, we should discuss which of the proposed changes (if any), we'd like to integrate.
>> 
>> Tested and passed tier1-3
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove reformatting
>  - Remove file

Baseline:

Benchmark                            (offsetCount)  (segmentSize)   Mode  Cnt        Score       Error  Units
FFMVarHandleInlineTest.t0_reference           2048           1024  thrpt   25  1552613.262 ? 14295.035  ops/s
FFMVarHandleInlineTest.t1_level8              2048           1024  thrpt   25  1558465.228 ?  8458.874  ops/s
FFMVarHandleInlineTest.t2_level9              2048           1024  thrpt   25  1542009.100 ? 10240.173  ops/s
FFMVarHandleInlineTest.t3_level10             2048           1024  thrpt   25  1553407.503 ? 10834.133  ops/s
FFMVarHandleInlineTest.t4_level11             2048           1024  thrpt   25    87666.558 ?   765.848  ops/s. <-- We hit the inline limit here


Patch:

Benchmark                         (offsetCount)  (segmentSize)   Mode  Cnt        Score       Error  Units
FFMVarHandleInlineTest.t_level14           2048           1024  thrpt    6  1522770.197 ? 47791.455  ops/s
FFMVarHandleInlineTest.t_level15           2048           1024  thrpt    6     3368.237 ?   127.196  ops/s

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

PR Comment: https://git.openjdk.org/jdk/pull/23460#issuecomment-2640142513

From pminborg at openjdk.org  Thu Feb  6 15:38:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Feb 2025 15:38:56 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v5]
In-Reply-To: <xqfw_TApQqTiLL0dfsE1vON8QhoSXF7H-B5dyZk014E=.c722bf33-8775-480e-a37f-8a72fdbbdbcf@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
 <xqfw_TApQqTiLL0dfsE1vON8QhoSXF7H-B5dyZk014E=.c722bf33-8775-480e-a37f-8a72fdbbdbcf@github.com>
Message-ID: <wWxrM3-NHfshF26NV_t9RHLBoniTussXP6pKYqrlWPU=.635029a6-a468-4962-9af6-d87c611d37a5@github.com>

On Thu, 6 Feb 2025 15:35:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
>> 
>> There are also some changes in other classes (notably `j.l.Object`) which, if implemented, can take us four additional levels of inlining. However, there is a tradeoff with adding `@ForceInline` and just trying to get as deep as possible for a specific use case is probably not the best idea. 
>> 
>> So, we should discuss which of the proposed changes (if any), we'd like to integrate.
>> 
>> Tested and passed tier1-3
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more @ForceInline and a benchmark

src/java.base/share/classes/java/lang/Object.java line 44:

> 42:      * Constructs a new object.
> 43:      */
> 44:     @ForceInline

What is the implication of this?

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 3570:

> 3568:      * @since 9
> 3569:      */
> 3570:     @ForceInline

These annotations are not totally out of the question as the corresponding methods (e.g. `public final long getLongUnaligned(Object o, long offset)` are `@IntrinsicCandidate` and will indeed be inlined because of that. So, this creates symmetry with respect to inlining.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r1944931865
PR Review Comment: https://git.openjdk.org/jdk/pull/23460#discussion_r1944936570

From pminborg at openjdk.org  Thu Feb  6 15:38:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Feb 2025 15:38:56 GMT
Subject: RFR: 8348556: Inlining fails earlier for
 MemorySegment::reinterpret [v5]
In-Reply-To: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
References: <3LuKBc-mbghi2A2-OnXrJD5zwvOm8URerns7Ud0Zz4c=.583514d1-d0fc-4005-b810-f4db92fcb60c@github.com>
Message-ID: <xqfw_TApQqTiLL0dfsE1vON8QhoSXF7H-B5dyZk014E=.c722bf33-8775-480e-a37f-8a72fdbbdbcf@github.com>

> This PR proposes to add some `@ForceInline` annotations in the `Module` class in order to assist inlining of FFM var/method handles.
> 
> There are also some changes in other classes (notably `j.l.Object`) which, if implemented, can take us four additional levels of inlining. However, there is a tradeoff with adding `@ForceInline` and just trying to get as deep as possible for a specific use case is probably not the best idea. 
> 
> So, we should discuss which of the proposed changes (if any), we'd like to integrate.
> 
> Tested and passed tier1-3

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

  Add more @ForceInline and a benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23460/files
  - new: https://git.openjdk.org/jdk/pull/23460/files/c095eb18..7a2f7f89

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

  Stats: 340 lines in 8 files changed: 333 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23460/head:pull/23460

PR: https://git.openjdk.org/jdk/pull/23460

From duke at openjdk.org  Thu Feb  6 16:02:09 2025
From: duke at openjdk.org (kabutz)
Date: Thu, 6 Feb 2025 16:02:09 GMT
Subject: RFR: 8349543: LinkedBlockingDeque does not immediately throw
 InterrruptedException in put/take
In-Reply-To: <44wMBdipUdWdEPJFBhMD1PNrjdG3l1x66e1RUlg5v3o=.c1958d92-db7c-418c-bb7a-ea5fb07fc70a@github.com>
References: <Da_VhZrKMVCSNPN6BSYHrYLsU3MnehmJZcI0ZJUzaJ8=.eb25a512-e279-47f4-ae14-11c965f204cd@github.com>
 <44wMBdipUdWdEPJFBhMD1PNrjdG3l1x66e1RUlg5v3o=.c1958d92-db7c-418c-bb7a-ea5fb07fc70a@github.com>
Message-ID: <kDkeiRuo4fXXgcqryZE_CFv-bueZHSch_hMomWqaWZc=.d18c6cc4-2871-4726-91b7-cb7d26c5a364@github.com>

On Wed, 5 Feb 2025 18:38:40 GMT, Doug Lea <dl at openjdk.org> wrote:

> Thanks for finding this. The only question is whether we believe that any existing usage might depend on current behavior, and if so should it be done anyway?

Good question - your call Doug.

LinkedBlockingDeque's comment is the same as LInkedBlockingQueue's (inherited from BlockingQueue): "@throws InterruptedException if interrupted while waiting" - however all the other classes that do throw this InterruptedException would do so on entry, even if we are not technically waiting.

Other examples where this behaviour is consistent is LinkedTransferQueue.take(), PriorityBlockingQueue.take(), etc.:


import java.util.concurrent.*;

public class InterruptionsIgnoredOnTakeOtherQueues {
    public static void main(String... args) throws InterruptedException {
        // Ensure that take() immediately throws an InterruptedException
        // if the thread is interrupted for other BlockingQueues
        try (var pool = Executors.newSingleThreadExecutor()) {
            var success = pool.submit(() -> {
                test(new LinkedTransferQueue<>());
                test(new PriorityBlockingQueue<>());
                test(new ArrayBlockingQueue<>(10));
                test(new LinkedBlockingQueue<>());
                return null;
            });
            try {
                success.get();
            } catch (ExecutionException e) {
                try {
                    throw e.getCause();
                } catch (Error | RuntimeException unchecked) {
                    throw unchecked;
                } catch (Throwable cause) {
                    throw new AssertionError(cause);
                }
            }
        }
    }

    private static void test(BlockingQueue<Integer> queue) {
        queue.add(42);
        Thread.currentThread().interrupt();
        try {
            queue.take();
            fail("Expected InterruptedException in " + queue.getClass().getSimpleName() + ".take()");
        } catch (InterruptedException expected) {
            // good that's what we want
        }
    }

    private static void fail(String message) {
        throw new AssertionError(message);
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/23464#issuecomment-2640235199

From yujige at gmail.com  Thu Feb  6 16:04:23 2025
From: yujige at gmail.com (Jige Yu)
Date: Thu, 6 Feb 2025 08:04:23 -0800
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>

Sorry, did the PR stop using Semaphore?

I had naively thought that mapConcurrent() will keep a buffer of Future of
all currently-running concurrent tasks (it can be a ConcurrentMap<TaskKey,
Future> if we don't have to ensure FIFO).

Upon interruption, the main thread can call .cancel(true) on all pending
Futures; optionally join with the VTs (if we need to block until all VTs
exit); then propagate exception.

Upon completion, each task just removes itself from the ConcurrentMap.

Just in case it adds anything.



On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> After some more investigation it seems tractable to propagate interruption
> of the caller in sequential mode, but parallel mode will require much
> bigger considerations.
>
> I made a comment to that effect on the JBS issue:
> https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Viktor Klang <viktor.klang at oracle.com>
> *Sent:* Thursday, 6 February 2025 11:51
> *To:* Jige Yu <yujige at gmail.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> I think alignment in behavior between parallel Stream and mapConcurrent in
> terms of how interruptions are handled is a possible path forward.
>
> I decided to close the PR for now as I realized my parallel Stream example
> had misled me regarding its exception throwing, so I'll need to go back and
> refine the solution.
>
> It still seems solvable though.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 5 February 2025 19:20
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Oh good call!
>
> I forgot to check what parallel streams do upon interruption (didn't think
> they do any blocking calls, but at least the main thread must block).
>
> On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi Jige,
>
> I opened an issue to track the concern, and I have proposed a change which
> seems to align well with how parallel streams behave under caller thread
> interruption.
>
> I've opened the following PR for review:
> https://github.com/openjdk/jdk/pull/23467
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
>
> If you are able to make a local OpenJDK build with that solution you could
> check if it addresses your use-cases (or not).
>
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> 8349462: Gatherers.mapConcurrent could support async interrupts by
> viktorklang-ora ? Pull Request #23467 ? openjdk/jdk
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
> This change is likely going to need some extra verbiage in the spec for
> mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how
> parallel streams work in conjunction with interrup...
> github.com
> <https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Wednesday, 5 February 2025 16:24
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> I understand the problem.
>
> The main reason I asked is because I want to understand how the core Java
> team thinks of throwing an unchecked exception.
>
> As explained above, I consider losing cancellability a big deal, a deal
> breaker even. And I thought throwing unchecked is more acceptable. Because
> the most common reason the mapConcurrent() VT can be interrupted is due to
> cancellation from a parent mapConcurrent(), or a parent Structured
> Concurrency scope. The cancellation could be either from an organic
> exception, or from the downstream not needing more elements, like maybe due
> to findFirst() already getting an element.
>
> In both cases, since the concurrent operation is already cancelled (result
> ignored), what exception pops up to the top level isn't that big of a deal
> (perhaps only a log record will be seen?)
>
> But if the core Java team considers it a bad idea, I would love to learn
> and adjust.
>
> On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi,
>
> The problem is that mapConcurrent cannot throw InterruptedException
> because that is a checked exception, so we cannot clear the interrupted
> flag and throw that exception.
>
> So the updated semantics is to not cut the stream short but instead run to
> completion, restoring the interruption flag.
>
> There exists a couple of alternatives to this approach which I am
> contemplating, but they need to be further explored before I consider
> moving forward with any of them.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Monday, 27 January 2025 17:00
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: mapConcurrent() with InterruptedException
>
> Thanks Viktor!
>
> It looks like the current fix ignores interruption.
>
> I want to make sure my concern of it defeating cancellation is heard and
> understood.
>
> The scenarios I worry about is for a mapConcurrent() that fans out to
> another method call, which internally calls mapConcurrent() as
> implementation detail.
>
> An example:
>
> List<RefundResponse> refundHelper(transaction) {
>   transaction.creditCardAccounts.stream()
>     .gather(mapConcurrent(acct -> service.refund(acct))
>     .toList();
> }
>
> transactions.stream()
>     .gather(mapConcurrent(transaction -> refundHelper(transaction));
>
>
> It seems undesirable that in such a case all the service.refund() calls
> become non cancellable, because the only way the outer mapConcurrent()
> cancels the refundHelper() calls is through Thread.interrupt() the virtual
> threads that call refundHelper(), which would then be disabled by the inner
> mapConcurrent().
>
> Does this example make sense to you? I can further explain if anything
> isn't clear.
>
> But I want to make sure the decision to disable interruption is deliberate
> judgement call that such nested mapConcurrent() is unlikely,or not
> important.
>
> Cheers,
>
>
>
> On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi!
>
> Please see: https://github.com/openjdk/jdk/pull/23100
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* Jige Yu <yujige at gmail.com>
> *Sent:* Sunday, 26 January 2025 23:03
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: mapConcurrent() with InterruptedException
>
> Checking in on what you've found out, Viktor.
>
> From where we left off, I understand that you were looking at alternatives
> instead of silent truncation?
>
> Have you reached any conclusion?
>
> We touched on disallowing interruption during mapConcurrent(). I still
> have concerns with disabling cancellation, because it basically undoes this
> API note from the javadoc
> <https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>
> :
>
> API Note: In progress tasks will be attempted to be cancelled, on a
> best-effort basis, in situations where the downstream no longer wants to
> receive any more elements.
> In reality, people will use mapConcurrent() to fan out rpcs. Sometimes
> these rpcs are just a single blocking call; yet sometimes they may
> themselves be a Structured Concurrency scope, with 2 or 3 rpcs that
> constitute a single logical operation. Under two conditions, cancellation
> is imho important semantic:
>
>    1. The downstream code uses filter().findFirst(), and when it sees an
>    element, it will return and no longer needs the other pending rpcs to
>    complete. If cancellation is disabled, these unnecessary rpcs will waste
>    system resources.
>    2. One of the rpc throws and the Stream pipeline needs to propagate
>    the exception. Again, if the other rpcs cannot be cancelled, we'll have
>    many zombie rpcs.
>
> Zombie rpcs may or may not be a deal breaker, depending on the specific
> use case. But for a JDK library, losing cancellation would have a negative
> impact on usability.
>
> My 2c,
>
>
> On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi Ben,
>
> Thanks for raising these questions?getting feedback is crucial in the
> Preview stage of features.
>
> I wrote a reply to the Reddit thread so I'll just summarize here:
>
> It is important to note that *mapConcurrent()* is not a part of the
> Structured Concurrency JEPs, so it is not designed to join SC scopes.
>
> I'm currently experimenting with ignoring-but-restoring interrupts on the
> "calling thread" for *mapConcurrent()*, as well as capping
> work-in-progress to *maxConcurrency* (not only capping the concurrency
> but also the amount of completed-but-yet-to-be-pushed work). Both of these
> adjustments should increase predictability of behavior in the face of
> blocking operations with variable delays.
>
> Another adjustment I'm looking at right now is to harden/improve the
> cleanup to wait for concurrent tasks to acknowledge cancellation, so that
> once the finisher is done executing the VTs are known to have terminated.
>
> As for not preserving the encounter order, that would be a completely
> different thing, and I'd encourage you to experiment with that if that
> functionality would be interesting for your use-case(s).
>
> Again, thanks for your feedback!
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Friday, 3 January 2025 17:53
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* mapConcurrent() with InterruptedException
>
> Hi Java Experts,
>
> I sent this email incorrectly to loom-dev@ and was told on Reddit that
> core-libs-dev is the right list.
>
> The question is about the behavior of mapConcurrent() when the thread is
> interrupted.
>
> Currently mapConcurrent()'s finisher phase will re-interrupt the thread,
> then stop at whatever element that has already been processed and return.
>
> This strikes me as a surprising behavior, because for example if I'm
> running:
>
>    Stream.of(1, 2, 3)
>         .gather(mapConcurrent(i -> i * 2))
>         .toList()
>
> and the thread is being interrupted, the result could be any of [2], [2,
> 4] or [2, 4, 6].
>
> Since thread interruption is cooperative, there is no guarantee that the
> thread being interrupted will just abort. It's quite possible that it'll
> keep going and then will use for example [2] as the result of doubling the
> list of [1, 2, 3], which is imho incorrect.
>
> In the Reddit
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread,
> someone argued that interruption rarely happens so it's more of a
> theoretical issue. But interruption can easily happen in Structured
> Concurrency or in mapConcurrent() itself if any subtask has failed in order
> to cancel/interrupt the other ongoing tasks.
>
> There had been discussion about alternative strategies:
>
>    1. Don't respond to interruption and just keep running to completion.
>    2. Re-interrupt thread and wrap the InterruptedException in a standard
>    unchecked exception (StructuredConcurrencyInterruptedException?).
>
>
> I have concerns with option 1 because it disables cancellation propagation
> when mapConcurrent() itself is used in a subtask of a parent
> mapConcurrent() or in a StructuredConcurrencyScope.
>
> Both equivalent Future-composition async code, or C++'s fiber trees
> support cancellation propagation and imho it's a critical feature or else
> it's possible that a zombie thread is still sending RPCs long after the
> main thread has exited (failed, or falled back to some default action).
>
> My arguments for option 2:
>
>    1. InterruptedException is more error prone than traditional checked
>    exceptions for *users* to catch and handle. They can forget to
>    re-interrupt the thread. It's so confusing that even seasoned programmers
>    may not know they are *supposed to* re-interrupt the thread.
>    2. With Stream API using functional interfaces like Supplier,
>    Function, the option of just tacking on "throws IE" isn't available to many
>    users.
>    3. With Virtual Threads, it will be more acceptable, or even become
>    common to do blocking calls from a stream operation (including but
>    exclusive to mapConcurrent()). So the chance users are forced to deal with
>    IE will become substantially higher.
>    4. Other APIs such as the Structured Concurrency API have already
>    started wrapping system checked exceptions like ExecutionException,
>    TimeoutException in unchecked exceptions ( join()
>    <https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for
>    example).
>    5. Imho, exceptions that we'd rather users not catch and handle but
>    instead should mostly just propagate up as is, should be unchecked.
>
> There is also a side discussion
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about
> whether mapConcurrent() is better off preserving input order or push to
> downstream as soon as an element is computed. I'd love to discuss that
> topic too but maybe it's better to start a separate thread?
>
> Thank you and cheers!
>
> Ben Yu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250206/bc58c46d/attachment-0001.htm>

From coleenp at openjdk.org  Thu Feb  6 16:14:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 16:14:19 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v5]
In-Reply-To: <ZCPqZJZMge18qWYr8forvtyJ4nljCII84NOtQFfl7Q0=.3473465c-ff5c-41ad-a046-f579c89c05ea@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <AKYfWWvD5swMFVmt2c0zHTMd7d1q8b2kjcONoZP3Lp4=.56ce146a-a9e9-4d01-9fcb-8fb76b4b90d1@github.com>
 <ZCPqZJZMge18qWYr8forvtyJ4nljCII84NOtQFfl7Q0=.3473465c-ff5c-41ad-a046-f579c89c05ea@github.com>
Message-ID: <FP-h1OoTCxJvDoH0YhF5OPwDuL4t6t8z1VfHS0IA53A=.789039ad-7dc6-43d3-9507-585aaa819361@github.com>

On Thu, 6 Feb 2025 14:33:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Remove @Stable annotation for final field.
>
> test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java line 213:
> 
>> 211:             assertTrue(false);
>> 212:         } catch (NoSuchFieldException expected) { }
>> 213:     }
> 
> The test is about accessibility, it's checking for IllegalAccessException and InaccessibleObjectException. So not the right place to test that a field is hidden from core reflection. Can you look at test/jdk/internal/reflect/Reflection/Filtering.java as that is probably the right place to list the protectionDomain field.

Thank you Alan for letting me know the right place for this test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1945012057

From coleenp at openjdk.org  Thu Feb  6 16:18:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 16:18:53 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v6]
In-Reply-To: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
Message-ID: <0rJBsK2HU4bErJ4GKSt_XDEHgj2sfVPWBZ4rWzuV7uc=.6ae8ce99-a316-4f66-8ecd-c20db9937527@github.com>

> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.

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

  Move test for protectionDomain filtering.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23396/files
  - new: https://git.openjdk.org/jdk/pull/23396/files/6bb7fe6e..3fd90cd1

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

  Stats: 13 lines in 2 files changed: 1 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23396/head:pull/23396

PR: https://git.openjdk.org/jdk/pull/23396

From liach at openjdk.org  Thu Feb  6 16:20:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Feb 2025 16:20:21 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v5]
In-Reply-To: <4aAX8rSEcvkeYteaJUXHfVEzBbNGwGlhDLIz548dFcs=.616fa7dd-d5bf-42d5-aca0-0bea0b5591d0@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
 <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
 <yjBy9m5yM18_XOZjEN8dn5osnTUPviOliyM_qNHoKgQ=.f9c43bc8-4bee-46bb-b466-7d471bfcd582@github.com>
 <8Wx3xbbOnPXS5n1RuNaesqHbhKV3iLwrCVF0s6uWOrA=.cb20728e-e13c-4667-822b-3ba424cbc12f@github.com>
 <yuiSOJZCDOCs2H5MHBg5FZnJYjy4XxsEnRy87qL8DFg=.1d5fac0f-8695-4e26-ac3f-0d787421607f@github.com>
 <4aAX8rSEcvkeYteaJUXHfVEzBbNGwGlhDLIz548dFcs=.616fa7dd-d5bf-42d5-aca0-0bea0b5591d0@github.com>
Message-ID: <UIvrfGyV8aaiXHhTfrdrdhWX12Vx4kjonBNRFEwtTbw=.d008ebb0-d865-444e-b9c3-d198ff57bf7b@github.com>

On Thu, 6 Feb 2025 12:08:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> If Class had other fields smaller than `int`, would be consider making this something like `char` to save space (allowing all the sub-word fields to be compacted)?
>
> I thought of doing this since I made modifiers u2 in the Hotspot code just previously, but all the Java code refers to this as an int.  And I didn't see other fields to compact it with.  Maybe if access_flags are moved we could make them both char (not short since they're unsigned).  It feels weird to not have unsigned short to my C++ eyes.

>From a Java perspective, using `char` for the field is completely fine; this field is only accessed via `getModifiers` and not set by Java code, so the automatic widening conversion can handle it all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1945021458

From naoto at openjdk.org  Thu Feb  6 16:22:11 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Feb 2025 16:22:11 GMT
Subject: RFR: 8349006: File.getCanonicalPath should remove
 "(on UNIX platforms)" from its specification [v3]
In-Reply-To: <BffnDm8gaOLqDr54RlDfRkKv6dt2RZS8TgYVrN5rY7w=.add92c28-d788-4c52-ab04-566a08c5d2de@github.com>
References: <PTkxq0_JYomS7xoev4JIJfk2NoX-xsuCOyoATQ6G8AY=.cbcb3a8a-2d74-47d5-8ccf-8c383331d2ba@github.com>
 <BffnDm8gaOLqDr54RlDfRkKv6dt2RZS8TgYVrN5rY7w=.add92c28-d788-4c52-ab04-566a08c5d2de@github.com>
Message-ID: <xfFQG01rL-OAw44OP3vgsDRS8M1xAkjalgoTAwJ6lBA=.605fd645-ddec-4df6-91c7-70de7b3b3ed0@github.com>

On Thu, 30 Jan 2025 18:40:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> The change made for [JDK-8003887](https://bugs.openjdk.org/browse/JDK-8003887) updated `File.getCanonicalPath` to resolve symbolic links on Windows, but its specification was not modified to reflect this. Here it is proposed to correct that omission.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8349006: Fix copyright year gaffe

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23371#pullrequestreview-2599198978

From naoto at openjdk.org  Thu Feb  6 16:26:14 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Feb 2025 16:26:14 GMT
Subject: RFR: 8349092: File.getFreeSpace violates specification if quotas
 are in effect (win)
In-Reply-To: <wvwLKO8TOc3_ViFmZ3mDbkdQe9GssHzIRVMNLjE-_p4=.3f0e4bef-d426-4f14-a493-84434c950305@github.com>
References: <wvwLKO8TOc3_ViFmZ3mDbkdQe9GssHzIRVMNLjE-_p4=.3f0e4bef-d426-4f14-a493-84434c950305@github.com>
Message-ID: <_wYE6H_DBa4jlQ6leZQWeQ0xyA8EcDvEjmVGQ5E0waE=.5f56c64a-caf2-48ff-84e4-f5f91b92663c@github.com>

On Fri, 31 Jan 2025 00:19:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> On Windows, for `File.getFreeSpace` return the same value as returned by `File.getUsableSpace`.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23377#pullrequestreview-2599214692

From bpb at openjdk.org  Thu Feb  6 16:29:10 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Feb 2025 16:29:10 GMT
Subject: RFR: 8349006: File.getCanonicalPath should remove
 "(on UNIX platforms)" from its specification [v3]
In-Reply-To: <xfFQG01rL-OAw44OP3vgsDRS8M1xAkjalgoTAwJ6lBA=.605fd645-ddec-4df6-91c7-70de7b3b3ed0@github.com>
References: <PTkxq0_JYomS7xoev4JIJfk2NoX-xsuCOyoATQ6G8AY=.cbcb3a8a-2d74-47d5-8ccf-8c383331d2ba@github.com>
 <BffnDm8gaOLqDr54RlDfRkKv6dt2RZS8TgYVrN5rY7w=.add92c28-d788-4c52-ab04-566a08c5d2de@github.com>
 <xfFQG01rL-OAw44OP3vgsDRS8M1xAkjalgoTAwJ6lBA=.605fd645-ddec-4df6-91c7-70de7b3b3ed0@github.com>
Message-ID: <nDPCwhI9_B1Fl9W25p-nqSEBXiGBPzUHE9CJjX5QNQE=.b3341532-73e2-4d84-8317-a4bc55a01c1b@github.com>

On Thu, 6 Feb 2025 16:19:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8349006: Fix copyright year gaffe
>
> Marked as reviewed by naoto (Reviewer).

Thanks, @naotoj.

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

PR Comment: https://git.openjdk.org/jdk/pull/23371#issuecomment-2640329354

From bpb at openjdk.org  Thu Feb  6 16:30:10 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Feb 2025 16:30:10 GMT
Subject: RFR: 8349092: File.getFreeSpace violates specification if quotas
 are in effect (win)
In-Reply-To: <_wYE6H_DBa4jlQ6leZQWeQ0xyA8EcDvEjmVGQ5E0waE=.5f56c64a-caf2-48ff-84e4-f5f91b92663c@github.com>
References: <wvwLKO8TOc3_ViFmZ3mDbkdQe9GssHzIRVMNLjE-_p4=.3f0e4bef-d426-4f14-a493-84434c950305@github.com>
 <_wYE6H_DBa4jlQ6leZQWeQ0xyA8EcDvEjmVGQ5E0waE=.5f56c64a-caf2-48ff-84e4-f5f91b92663c@github.com>
Message-ID: <o4WhF539y5sgXI4DCc1KoE5fsrotBrXxoSV_i3ovyyE=.c0ecd420-607a-4fe0-a6e4-ec2475049abc@github.com>

On Thu, 6 Feb 2025 16:23:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> On Windows, for `File.getFreeSpace` return the same value as returned by `File.getUsableSpace`.
>
> LGTM

Thanks, @naotoj.

I should note that the test passed on Linux and macOS, and JCK CI tiers 1-3 passed on Windows.

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

PR Comment: https://git.openjdk.org/jdk/pull/23377#issuecomment-2640332567

From lancea at openjdk.org  Thu Feb  6 17:43:14 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 6 Feb 2025 17:43:14 GMT
Subject: RFR: 8344925: translet-name ignored when package-name is also set
In-Reply-To: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
References: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
Message-ID: <2prWLtrifKcUK3K21pilaoov4Np3-3xBqRMehDV23Jw=.632c5c67-e59f-4830-8a65-76c56f28836d@github.com>

On Tue, 4 Feb 2025 18:30:34 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an issue where the translet-name is incorrectly set when the package-name is also specified.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23446#pullrequestreview-2599444141

From sgehwolf at openjdk.org  Thu Feb  6 18:02:21 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 6 Feb 2025 18:02:21 GMT
Subject: RFR: 8344925: translet-name ignored when package-name is also set
In-Reply-To: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
References: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
Message-ID: <HU1KRNqZcTTBfe4JjKQMNIjjRaT97RpewdxCn8LD4HQ=.223b4351-4b20-49d4-a526-422db9a9d4a0@github.com>

On Tue, 4 Feb 2025 18:30:34 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an issue where the translet-name is incorrectly set when the package-name is also specified.

test/jaxp/javax/xml/jaxp/unittest/transform/PropertiesTest.java line 94:

> 92: 
> 93:         if (generateTranslet) {
> 94:             //Files.list(Path.of(path)).forEach(System.out::println);

Left over from testing the test? I'd suggest to remove this commented out code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23446#discussion_r1945187161

From asemenyuk at openjdk.org  Thu Feb  6 18:12:05 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Feb 2025 18:12:05 GMT
Subject: RFR: 8349564: Clean warnings found in jpackage tests when building
 them with -Xlint:all
Message-ID: <oFpKSze5bbMk9sUB55IQib3sPGVyq4Fyp4EbsH3_B_k=.ce30c7e6-3b6c-4e70-bf8b-d7ff6f654375@github.com>

Clean warnings found in jpackage tests when building them with `-Xlint:all` option in Eclipse IDE. 

They are:
 - redundant imports (solution: remove)
 - unused function/fields (solution: remove)
 - missing SuppressWarnings-s (solution: add what is missing)
 - redundant SuppressWarnings-s (solution: remove)
 - raw types used (solution: use wildcard or more specific types if appropriate)
 - generic varargs (solution: convert to single/double/list arguments)
 - an incomplete list of enum elements in switch statements (solution: add `default` branch)

To prevent regression, added `-Xlint:all -Werror` to the compiler command line of all jpackage tests

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

Commit messages:
 - Update copyright year
 - Add -Xlint:all and -Werror args to compiler command line of all jpackage tests
 - Bad merge fix
 - Merge branch 'master' into jlint-tests
 - Copyright year updated
 - Undo jlint clean up for the implementation
 - More jlint errors fixed
 - Merge branch 'master' into jlint-tests
 - "Cleanup" bugfix. Double facepalm
 - Merge branch 'master' into jlint-tests
 - ... and 3 more: https://git.openjdk.org/jdk/compare/eb847026...47217bb3

Changes: https://git.openjdk.org/jdk/pull/23455/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23455&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349564
  Stats: 346 lines in 82 files changed: 68 ins; 51 del; 227 mod
  Patch: https://git.openjdk.org/jdk/pull/23455.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23455/head:pull/23455

PR: https://git.openjdk.org/jdk/pull/23455

From bpb at openjdk.org  Thu Feb  6 19:13:18 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Feb 2025 19:13:18 GMT
Subject: Integrated: 8349006: File.getCanonicalPath should remove
 "(on UNIX platforms)" from its specification
In-Reply-To: <PTkxq0_JYomS7xoev4JIJfk2NoX-xsuCOyoATQ6G8AY=.cbcb3a8a-2d74-47d5-8ccf-8c383331d2ba@github.com>
References: <PTkxq0_JYomS7xoev4JIJfk2NoX-xsuCOyoATQ6G8AY=.cbcb3a8a-2d74-47d5-8ccf-8c383331d2ba@github.com>
Message-ID: <hJ8t425q9Bke3vwsIgicVO399ICAUrRdyAJ_zotBuRA=.5155fc69-49cb-4459-8029-75ca52a625f4@github.com>

On Thu, 30 Jan 2025 15:41:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The change made for [JDK-8003887](https://bugs.openjdk.org/browse/JDK-8003887) updated `File.getCanonicalPath` to resolve symbolic links on Windows, but its specification was not modified to reflect this. Here it is proposed to correct that omission.

This pull request has now been integrated.

Changeset: 0181030b
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0181030bdc300f1d8fe02c3e2e599c997a4ab876
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8349006: File.getCanonicalPath should remove "(on UNIX platforms)" from its specification

Reviewed-by: jlu, naoto

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

PR: https://git.openjdk.org/jdk/pull/23371

From bpb at openjdk.org  Thu Feb  6 19:14:19 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Feb 2025 19:14:19 GMT
Subject: Integrated: 8349092: File.getFreeSpace violates specification if
 quotas are in effect (win)
In-Reply-To: <wvwLKO8TOc3_ViFmZ3mDbkdQe9GssHzIRVMNLjE-_p4=.3f0e4bef-d426-4f14-a493-84434c950305@github.com>
References: <wvwLKO8TOc3_ViFmZ3mDbkdQe9GssHzIRVMNLjE-_p4=.3f0e4bef-d426-4f14-a493-84434c950305@github.com>
Message-ID: <tQtMfZRj8Fq0NmzQd5dXn6qunk5yiwqDLx0cS7yL4f0=.63af9618-9aa8-44ec-95b0-00fcc841f175@github.com>

On Fri, 31 Jan 2025 00:19:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> On Windows, for `File.getFreeSpace` return the same value as returned by `File.getUsableSpace`.

This pull request has now been integrated.

Changeset: 1a74ee64
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a74ee64eb835c3395fe763c42fd36e2a720f441
Stats:     16 lines in 2 files changed: 13 ins; 0 del; 3 mod

8349092: File.getFreeSpace violates specification if quotas are in effect (win)

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/23377

From naoto at openjdk.org  Thu Feb  6 19:16:13 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Feb 2025 19:16:13 GMT
Subject: RFR: 8344925: translet-name ignored when package-name is also set
In-Reply-To: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
References: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
Message-ID: <sJIWVdX4VDnMdXltNsQHdU8-lECHXjzaAfk5Ph5CTxo=.bc2b018e-fed1-4c7c-b239-354c9f8adf58@github.com>

On Tue, 4 Feb 2025 18:30:34 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an issue where the translet-name is incorrectly set when the package-name is also specified.

Marked as reviewed by naoto (Reviewer).

test/jaxp/javax/xml/jaxp/libs/jaxp/library/JUnitTestUtil.java line 33:

> 31:     public static final String CLS_DIR = System.getProperty("test.classes");
> 32:     public static final String SRC_DIR = System.getProperty("test.src");
> 33:     public static final boolean isWindows = System.getProperty("os.name").contains("Windows");

It is good as it stands, but Platform.isWindows() can be used here

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

PR Review: https://git.openjdk.org/jdk/pull/23446#pullrequestreview-2599499922
PR Review Comment: https://git.openjdk.org/jdk/pull/23446#discussion_r1945195866

From qamai at openjdk.org  Thu Feb  6 19:21:53 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 6 Feb 2025 19:21:53 GMT
Subject: RFR: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment [v5]
In-Reply-To: <sj7WfOT2Mc3mZa4jt5PI8z_tQtM2FNUT-RZ3F67hY2w=.60995a4e-6cb4-4d3b-9ecf-ce31cad1c33e@github.com>
References: <sj7WfOT2Mc3mZa4jt5PI8z_tQtM2FNUT-RZ3F67hY2w=.60995a4e-6cb4-4d3b-9ecf-ce31cad1c33e@github.com>
Message-ID: <t4oSVEAvE-2wUd3cM5DUoVtdPJ7-w_lQDSWoyLE_M68=.54ce6a3a-0281-4dc8-abf3-c61ee43233a7@github.com>

> Hi,
> 
> This patch improves the performance of a typical `Arena::allocate` in several ways:
> 
> - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge of the instance with the one obtained from the call in the uncommon path, increasing the chance the object being scalar replaced.
> - Split the allocation of over-aligned memory to a slow-path method.
> - Align the memory to 8 bytes, allowing faster zeroing.
> - Use a dedicated method to zero the just-allocated native memory, reduce code size and make it more straightforward.
> - Make `VM.pageAlignDirectMemory` a `Boolean` instead of a `boolean` so that `false` value can be constant folded.
> 
> Please take a look and leave your reviews, thanks a lot.

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

 - revert changes to CallocArena
 - Merge branch 'master' into segmentallocate
 - copyright
 - Merge branch 'master' into segmentallocate
 - wrong init
 - move segment instance creation to SegmentFactories
 - address review
 - improve the implementation of SegmentFactories::allocateSegment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22610/files
  - new: https://git.openjdk.org/jdk/pull/22610/files/d3cba466..f2330067

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

  Stats: 34672 lines in 1350 files changed: 16246 ins; 10070 del; 8356 mod
  Patch: https://git.openjdk.org/jdk/pull/22610.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22610/head:pull/22610

PR: https://git.openjdk.org/jdk/pull/22610

From qamai at openjdk.org  Thu Feb  6 19:21:53 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 6 Feb 2025 19:21:53 GMT
Subject: RFR: 8345687: Improve the implementation of
 SegmentFactories::allocateSegment [v3]
In-Reply-To: <CZjbOYY2xR9dD0elNlcQpBB1HleE5vGQh3y1cLlpBhE=.39e1b958-2aa4-4b2f-a053-d31d93c25871@github.com>
References: <sj7WfOT2Mc3mZa4jt5PI8z_tQtM2FNUT-RZ3F67hY2w=.60995a4e-6cb4-4d3b-9ecf-ce31cad1c33e@github.com>
 <5bAs8hhqvy-c776n0_9Xqw6n8quA-c_a59ii-nWFhuE=.2eae9a1b-b46a-4626-9ac5-3ee35a34b82c@github.com>
 <YduWHDK_lawPwbwOIfzhLbJr6Mkv1xDe11qrNOe1gcM=.55fa23e5-7f7f-4171-a90f-10d12af1c914@github.com>
 <4T4xAZGj1lmd8-KBdRCsBF5oltxC0mQzseUIJGTKaCE=.f71ab6fc-a247-45af-9000-9d1288bdf5d4@github.com>
 <_wjpvTZLmQbjFr0fWIJnB8hyZo0PDFnfnmTDeh7ujXo=.64334ac1-d6bd-45f3-a1c3-a4da05053768@github.com>
 <t92orma4IJsSWsrUMBkkuQtP5e0X7pZ1F1E6NMC1O3U=.6ab41c4e-5462-41bf-b072-fab3aa6bb103@github.com>
 <CZjbOYY2xR9dD0elNlcQpBB1HleE5vGQh3y1cLlpBhE=.39e1b958-2aa4-4b2f-a053-d31d93c25871@github.com>
Message-ID: <C2yunneeNjB3o3oOzb1vu5FxWU4vhqbkewu8ZvsjItY=.3cbc2d37-4ffc-4611-8ef7-20b205ee13fe@github.com>

On Wed, 5 Feb 2025 10:18:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Only the return value of `CALLOC` is converted to `MemorySegment` in an equivalent way, I believe passing a `MemorySegment` to a downcall involves acquiring the corresponding segment? As a result, `FREE` is made to accept the raw address, and `CALLOC` is changed in the same manner for consistency.
>
> Yes, passing segments to a downcall will acquire -- but if the segment is a wrapper around a long (a zero-length memory segment), its scope is the global scope, and acquire is a no-op. Stepping back what worries me with the changes in this benchmark is that we're replacing idiomatic FFM code with very low-level code which seems less representative of code people would write. Maybe if we need a dedicated benchmark to ensure there's no escaping in the innards of the API impl, we should write one specifically for that?

Got it, I have reverted the change here. `CLayouts::freeMemory` does not capture anything so I think it should not allocate?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22610#discussion_r1945291260

From asemenyuk at openjdk.org  Thu Feb  6 19:36:27 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Feb 2025 19:36:27 GMT
Subject: RFR: 8349564: Clean warnings found in jpackage tests when building
 them with -Xlint:all [v2]
In-Reply-To: <oFpKSze5bbMk9sUB55IQib3sPGVyq4Fyp4EbsH3_B_k=.ce30c7e6-3b6c-4e70-bf8b-d7ff6f654375@github.com>
References: <oFpKSze5bbMk9sUB55IQib3sPGVyq4Fyp4EbsH3_B_k=.ce30c7e6-3b6c-4e70-bf8b-d7ff6f654375@github.com>
Message-ID: <_wvMS4MJ9UkUZZpZcO3E8eKKIG_i7CRdIAPZ0qRS6jc=.cdd289e5-ee16-40bb-b996-9078c2ccd3f1@github.com>

> Clean warnings found in jpackage tests when building them with `-Xlint:all` option in Eclipse IDE. 
> 
> They are:
>  - redundant imports (solution: remove)
>  - unused function/fields (solution: remove)
>  - missing SuppressWarnings-s (solution: add what is missing)
>  - redundant SuppressWarnings-s (solution: remove)
>  - raw types used (solution: use wildcard or more specific types if appropriate)
>  - generic varargs (solution: convert to single/double/list arguments)
>  - an incomplete list of enum elements in switch statements (solution: add `default` branch)
> 
> To prevent regression, added `-Xlint:all -Werror` to the compiler command line of all jpackage tests

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

  More cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23455/files
  - new: https://git.openjdk.org/jdk/pull/23455/files/47217bb3..f60c3c59

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

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

PR: https://git.openjdk.org/jdk/pull/23455

From naoto at openjdk.org  Thu Feb  6 19:51:21 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Feb 2025 19:51:21 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables
Message-ID: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>

This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed.

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/23498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23498&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349254
  Stats: 137 lines in 3 files changed: 68 ins; 45 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/23498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23498/head:pull/23498

PR: https://git.openjdk.org/jdk/pull/23498

From jiangli at openjdk.org  Thu Feb  6 20:18:22 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Feb 2025 20:18:22 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK
Message-ID: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>

This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.

There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.

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

Commit messages:
 - - Don't explicitly link with libjvm.so for libExplicitAttach. That helps to avoid adding libjvm.so as a dependency for libExplicitAttach.so.

Changes: https://git.openjdk.org/jdk/pull/23500/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23500&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349284
  Stats: 32 lines in 2 files changed: 30 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23500.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23500/head:pull/23500

PR: https://git.openjdk.org/jdk/pull/23500

From joehw at openjdk.org  Thu Feb  6 20:19:53 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 6 Feb 2025 20:19:53 GMT
Subject: RFR: 8344925: translet-name ignored when package-name is also set
 [v2]
In-Reply-To: <sJIWVdX4VDnMdXltNsQHdU8-lECHXjzaAfk5Ph5CTxo=.bc2b018e-fed1-4c7c-b239-354c9f8adf58@github.com>
References: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
 <sJIWVdX4VDnMdXltNsQHdU8-lECHXjzaAfk5Ph5CTxo=.bc2b018e-fed1-4c7c-b239-354c9f8adf58@github.com>
Message-ID: <gF6UotYFYmkrD-oeS5svf8CSCPFd3ZALhUmwsh6MtzU=.e9ceb070-0eb2-46e0-80fe-777ba690aaae@github.com>

On Thu, 6 Feb 2025 18:04:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update test
>
> test/jaxp/javax/xml/jaxp/libs/jaxp/library/JUnitTestUtil.java line 33:
> 
>> 31:     public static final String CLS_DIR = System.getProperty("test.classes");
>> 32:     public static final String SRC_DIR = System.getProperty("test.src");
>> 33:     public static final boolean isWindows = System.getProperty("os.name").contains("Windows");
> 
> It is good as it stands, but Platform.isWindows() can be used here

Updated using the test lib. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23446#discussion_r1945367084

From joehw at openjdk.org  Thu Feb  6 20:19:53 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 6 Feb 2025 20:19:53 GMT
Subject: RFR: 8344925: translet-name ignored when package-name is also set
 [v2]
In-Reply-To: <HU1KRNqZcTTBfe4JjKQMNIjjRaT97RpewdxCn8LD4HQ=.223b4351-4b20-49d4-a526-422db9a9d4a0@github.com>
References: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
 <HU1KRNqZcTTBfe4JjKQMNIjjRaT97RpewdxCn8LD4HQ=.223b4351-4b20-49d4-a526-422db9a9d4a0@github.com>
Message-ID: <MZaSE5KXFs8-ZqQoR4qtfiN9DcXkTGqITZ813ftJZrk=.1b72aebe-0815-4583-8e20-7bc853cd6d7c@github.com>

On Thu, 6 Feb 2025 17:58:08 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update test
>
> test/jaxp/javax/xml/jaxp/unittest/transform/PropertiesTest.java line 94:
> 
>> 92: 
>> 93:         if (generateTranslet) {
>> 94:             //Files.list(Path.of(path)).forEach(System.out::println);
> 
> Left over from testing the test? I'd suggest to remove this commented out code.

Removed. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23446#discussion_r1945366583

From joehw at openjdk.org  Thu Feb  6 20:19:53 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 6 Feb 2025 20:19:53 GMT
Subject: RFR: 8344925: translet-name ignored when package-name is also set
 [v2]
In-Reply-To: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
References: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
Message-ID: <AQ3YipYyuYQj0idWX5wUA1qgevO6f7mWMlfuJB7B92w=.9a2ba149-9e5a-4d58-bb14-62148bb48268@github.com>

> Fix an issue where the translet-name is incorrectly set when the package-name is also specified.

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

  update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23446/files
  - new: https://git.openjdk.org/jdk/pull/23446/files/df9b015a..a31ac5e1

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

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

PR: https://git.openjdk.org/jdk/pull/23446

From lancea at openjdk.org  Thu Feb  6 20:49:25 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 6 Feb 2025 20:49:25 GMT
Subject: RFR: 8344925: translet-name ignored when package-name is also set
 [v2]
In-Reply-To: <AQ3YipYyuYQj0idWX5wUA1qgevO6f7mWMlfuJB7B92w=.9a2ba149-9e5a-4d58-bb14-62148bb48268@github.com>
References: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
 <AQ3YipYyuYQj0idWX5wUA1qgevO6f7mWMlfuJB7B92w=.9a2ba149-9e5a-4d58-bb14-62148bb48268@github.com>
Message-ID: <x-Fv4hvFgW_soVyK0BUMd4jE5j62CSaAgOUYwT4Yc5w=.6b1c763c-a9d0-4118-b01f-6e88cc586dc4@github.com>

On Thu, 6 Feb 2025 20:19:53 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fix an issue where the translet-name is incorrectly set when the package-name is also specified.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update test

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23446#pullrequestreview-2599888747

From vlivanov at openjdk.org  Thu Feb  6 21:15:12 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 6 Feb 2025 21:15:12 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <fIDzS3_DxYMZA78UX_HiBqnAPvUcE2qhBfw30T2hrv4=.d65d867b-2a38-49b7-ba1b-8284ae19e7d2@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>
 <0ZM_vg_dAmbdbeoIeZ8ylBUDj_4_jxM-aE6IKoH6ykM=.69c7554f-5e2b-40b9-8d1a-abe147548dbb@github.com>
 <0efX7bcHNl5p1RoF3VnqZIabdavsGosuMI14cZPDzbQ=.2bde6bbf-a59b-4f5b-9c68-7a8a258b2ee5@github.com>
 <7KdNVSXLx0N027uyQgtUuN82VpXTlyPpPOnBv3sqYRs=.6b549b56-36f9-4ab3-8469-4779d93dd1e7@github.com>
 <fIDzS3_DxYMZA78UX_HiBqnAPvUcE2qhBfw30T2hrv4=.d65d867b-2a38-49b7-ba1b-8284ae19e7d2@github.com>
Message-ID: <UYowvIDtIq6dD29gTSkg0hhi4JsrmETGcFNPuGrE_6Y=.bd96c4b1-3882-414a-ab6b-30abac2e665e@github.com>

On Thu, 6 Feb 2025 13:08:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Does `static final` help here?
>
> Yes.  Yes it does.

Cases when a class mirror is a compile-time constant are already well-optimized. Non constant cases are the ones where missing optimization opportunities arise. 

In this particular case, C2 doesn't benefit from the observation that `Clazz[]` is a leaf type at runtime (no subclasses). Hence, a value loaded from a field typed as `Clazz[]` has exactly the same type and `clazzArray.getClass()` can be constant folded to `Clazz[].class`.  Rather than a common case, it feels more like a corner case. So, worth addressing as a follow-up enhancement.

Another scenario is a meet of 2 primitive array types (ends up as `bottom[]` in C2 type system), but I believe it hasn't been optimized before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1945451909

From vlivanov at openjdk.org  Thu Feb  6 21:21:18 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 6 Feb 2025 21:21:18 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v5]
In-Reply-To: <Rnq14bXvkpbsJQdX-PF9uNr86akoq0ujgHPrFBLfIqY=.0278cab5-71ed-4a80-a751-e38248928e2e@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <Rnq14bXvkpbsJQdX-PF9uNr86akoq0ujgHPrFBLfIqY=.0278cab5-71ed-4a80-a751-e38248928e2e@github.com>
Message-ID: <YvJXs2OX-TBzUmJg0UJjwiVexzE85_cm_CQyX5FZZeo=.9bbcaeaf-06e0-4ea8-8a04-40b06a9cfc3f@github.com>

On Thu, 6 Feb 2025 14:31:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make compute_modifiers return u2.

Looks good. (Except a left-over `???` in a comment.)

I very much like this cleanup. Migrating from Klass to Class simplifies compiler logic since there's no need to care about primitives at runtime anymore.

Speaking of missing optimization opportunities (demonstrated by one microbenchmark), it looks like a corner case and can be addressed later.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2599983789

From asemenyuk at openjdk.org  Thu Feb  6 21:39:50 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Feb 2025 21:39:50 GMT
Subject: RFR: 8150442: Enforce Supported Platforms in Packager for MSI bundles
Message-ID: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>

Enable MSI installers to block installation if the version of Windows is too old.

jpackage will read major and minor OS versions from PE headers of the main launcher and `java.dll` in the app image. The combined version is the minimal Windows version these executables can run. Thus, it will be a lower bound for the Windows version the installer supports. 

The value of the combined version is passed as `JpExecutableOSVersion` WiX variable to a new `os-condition.wxf` WiX fragment. The fragment compares the value of `JpExecutableOSVersion` WiX variable with the value of `VersionNT` MSI property. If the value of the latter is less the installation is blocked.

The fragment can be overridden in the resource directory. This makes this feature fully customizable.

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

Commit messages:
 - Bugfix and corresponding unit test
 - Copyright year updated
 - Clean trailing whitespaces
 - Make it work when both the main launcher and java.dll are missing
 - Update doc and add "os-condition.wxf" to the resources
 - Remove debug output
 - Remove accidentally added file
 - Merge branch 'master' into JDK-8150442
 - Merge branch 'master' into JDK-8150442
 - Add ExecutableOSVersionTest test
 - ... and 2 more: https://git.openjdk.org/jdk/compare/64bd8d25...c208cfc5

Changes: https://git.openjdk.org/jdk/pull/23472/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23472&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8150442
  Stats: 407 lines in 14 files changed: 396 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23472/head:pull/23472

PR: https://git.openjdk.org/jdk/pull/23472

From iris at openjdk.org  Thu Feb  6 22:13:12 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 6 Feb 2025 22:13:12 GMT
Subject: RFR: 8344925: translet-name ignored when package-name is also set
 [v2]
In-Reply-To: <AQ3YipYyuYQj0idWX5wUA1qgevO6f7mWMlfuJB7B92w=.9a2ba149-9e5a-4d58-bb14-62148bb48268@github.com>
References: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
 <AQ3YipYyuYQj0idWX5wUA1qgevO6f7mWMlfuJB7B92w=.9a2ba149-9e5a-4d58-bb14-62148bb48268@github.com>
Message-ID: <zK5GhjJcO9y1fIOUYL1JcUU82ejPoHdNcCTkaDMhWEk=.a1dd22c3-aeb9-467b-bde6-94cbe6478cf8@github.com>

On Thu, 6 Feb 2025 20:19:53 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fix an issue where the translet-name is incorrectly set when the package-name is also specified.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update test

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23446#pullrequestreview-2600114265

From almatvee at openjdk.org  Thu Feb  6 22:29:14 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 6 Feb 2025 22:29:14 GMT
Subject: RFR: 8150442: Enforce Supported Platforms in Packager for MSI
 bundles
In-Reply-To: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
References: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
Message-ID: <ti2AiMIUTroSYIx5IYfcgMJcSx7vdwPY-FFsyjuTfRM=.842f1b33-6de9-4d07-9d83-011017c85da7@github.com>

On Wed, 5 Feb 2025 20:11:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Enable MSI installers to block installation if the version of Windows is too old.
> 
> jpackage will read major and minor OS versions from PE headers of the main launcher and `java.dll` in the app image. The combined version is the minimal Windows version these executables can run. Thus, it will be a lower bound for the Windows version the installer supports. 
> 
> The value of the combined version is passed as `JpExecutableOSVersion` WiX variable to a new `os-condition.wxf` WiX fragment. The fragment compares the value of `JpExecutableOSVersion` WiX variable with the value of `VersionNT` MSI property. If the value of the latter is less the installation is blocked.
> 
> The fragment can be overridden in the resource directory. This makes this feature fully customizable.

Looks good. Do you know what versions in PE headers of the main launcher and java.dll we have in JDK 25? Do you know how versions in PE header are being set, is it being updated between JDK releases?

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

PR Comment: https://git.openjdk.org/jdk/pull/23472#issuecomment-2641261618

From martin at openjdk.org  Thu Feb  6 22:33:10 2025
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 6 Feb 2025 22:33:10 GMT
Subject: RFR: 8349543: LinkedBlockingDeque does not immediately throw
 InterrruptedException in put/take
In-Reply-To: <Da_VhZrKMVCSNPN6BSYHrYLsU3MnehmJZcI0ZJUzaJ8=.eb25a512-e279-47f4-ae14-11c965f204cd@github.com>
References: <Da_VhZrKMVCSNPN6BSYHrYLsU3MnehmJZcI0ZJUzaJ8=.eb25a512-e279-47f4-ae14-11c965f204cd@github.com>
Message-ID: <YPphe1Vlhc2Dg8Xf9-Gm2uiTYkdb5XD3FdjUeWIGcew=.827e35e1-5aa1-4a75-887e-17c98ceb5a20@github.com>

On Wed, 5 Feb 2025 15:36:15 GMT, kabutz <duke at openjdk.org> wrote:

> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.

I will give this review a bit of my 1% openjdk time

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

PR Review: https://git.openjdk.org/jdk/pull/23464#pullrequestreview-2600177884

From almatvee at openjdk.org  Thu Feb  6 22:55:11 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 6 Feb 2025 22:55:11 GMT
Subject: RFR: 8349564: Clean warnings found in jpackage tests when building
 them with -Xlint:all [v2]
In-Reply-To: <_wvMS4MJ9UkUZZpZcO3E8eKKIG_i7CRdIAPZ0qRS6jc=.cdd289e5-ee16-40bb-b996-9078c2ccd3f1@github.com>
References: <oFpKSze5bbMk9sUB55IQib3sPGVyq4Fyp4EbsH3_B_k=.ce30c7e6-3b6c-4e70-bf8b-d7ff6f654375@github.com>
 <_wvMS4MJ9UkUZZpZcO3E8eKKIG_i7CRdIAPZ0qRS6jc=.cdd289e5-ee16-40bb-b996-9078c2ccd3f1@github.com>
Message-ID: <F1uoTAODBKxyrfihUbw-9XCCwLIErnDwany4wXxqjdY=.c2e7f48a-b88d-407d-ba43-bb876d46a20f@github.com>

On Thu, 6 Feb 2025 19:36:27 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Clean warnings found in jpackage tests when building them with `-Xlint:all` option in Eclipse IDE. 
>> 
>> They are:
>>  - redundant imports (solution: remove)
>>  - unused function/fields (solution: remove)
>>  - missing SuppressWarnings-s (solution: add what is missing)
>>  - redundant SuppressWarnings-s (solution: remove)
>>  - raw types used (solution: use wildcard or more specific types if appropriate)
>>  - generic varargs (solution: convert to single/double/list arguments)
>>  - an incomplete list of enum elements in switch statements (solution: add `default` branch)
>> 
>> To prevent regression, added `-Xlint:all -Werror` to the compiler command line of all jpackage tests
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More cleanup

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TestBuilder.java line 299:

> 297:     }
> 298: 
> 299:     // Wraps Method.invike() into ThrowingRunnable.run()

`invike` -> `invoke`.

test/jdk/tools/jpackage/share/JavaOptionsTest.java line 38:

> 36:  * @summary jpackage create image with --java-options test
> 37:  * @library /test/jdk/tools/jpackage/helpers
> 38:  * @build jdk.jpackage.test.*

Helper classes will be build without `-Xlint:all -Werror`, right? If yes do we need to add `-Xlint:all -Werror` as well when building helper classes?

test/jdk/tools/jpackage/share/JavaOptionsTest.java line 39:

> 37:  * @library /test/jdk/tools/jpackage/helpers
> 38:  * @build jdk.jpackage.test.*
> 39:  * @compile -Xlint:all -Werror JavaOptionsTest.java

Can we add `-Xlint:all -Werror` in generic way instead of repeating each time?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23455#discussion_r1945570982
PR Review Comment: https://git.openjdk.org/jdk/pull/23455#discussion_r1945583133
PR Review Comment: https://git.openjdk.org/jdk/pull/23455#discussion_r1945582226

From asemenyuk at openjdk.org  Thu Feb  6 23:12:48 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Feb 2025 23:12:48 GMT
Subject: RFR: 8349564: Clean warnings found in jpackage tests when building
 them with -Xlint:all [v3]
In-Reply-To: <oFpKSze5bbMk9sUB55IQib3sPGVyq4Fyp4EbsH3_B_k=.ce30c7e6-3b6c-4e70-bf8b-d7ff6f654375@github.com>
References: <oFpKSze5bbMk9sUB55IQib3sPGVyq4Fyp4EbsH3_B_k=.ce30c7e6-3b6c-4e70-bf8b-d7ff6f654375@github.com>
Message-ID: <9_lTyilsx5gtMm8kzamnVlpF1DvRTB-VmvVGTp-pwk4=.8a11e80b-fa5f-4bf7-bbb9-8ad1a4815aff@github.com>

> Clean warnings found in jpackage tests when building them with `-Xlint:all` option in Eclipse IDE. 
> 
> They are:
>  - redundant imports (solution: remove)
>  - unused function/fields (solution: remove)
>  - missing SuppressWarnings-s (solution: add what is missing)
>  - redundant SuppressWarnings-s (solution: remove)
>  - raw types used (solution: use wildcard or more specific types if appropriate)
>  - generic varargs (solution: convert to single/double/list arguments)
>  - an incomplete list of enum elements in switch statements (solution: add `default` branch)
> 
> To prevent regression, added `-Xlint:all -Werror` to the compiler command line of all jpackage tests

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

  Typo fixed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23455/files
  - new: https://git.openjdk.org/jdk/pull/23455/files/f60c3c59..1354a8b7

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

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

PR: https://git.openjdk.org/jdk/pull/23455

From asemenyuk at openjdk.org  Thu Feb  6 23:12:48 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Feb 2025 23:12:48 GMT
Subject: RFR: 8349564: Clean warnings found in jpackage tests when building
 them with -Xlint:all [v2]
In-Reply-To: <F1uoTAODBKxyrfihUbw-9XCCwLIErnDwany4wXxqjdY=.c2e7f48a-b88d-407d-ba43-bb876d46a20f@github.com>
References: <oFpKSze5bbMk9sUB55IQib3sPGVyq4Fyp4EbsH3_B_k=.ce30c7e6-3b6c-4e70-bf8b-d7ff6f654375@github.com>
 <_wvMS4MJ9UkUZZpZcO3E8eKKIG_i7CRdIAPZ0qRS6jc=.cdd289e5-ee16-40bb-b996-9078c2ccd3f1@github.com>
 <F1uoTAODBKxyrfihUbw-9XCCwLIErnDwany4wXxqjdY=.c2e7f48a-b88d-407d-ba43-bb876d46a20f@github.com>
Message-ID: <X44or-4gvMuvAALm2LjuepOeUBH4pStAImB5lIYDzR8=.b02c2c2c-1059-4a81-9d02-1e8b90938dc7@github.com>

On Thu, 6 Feb 2025 22:36:51 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More cleanup
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TestBuilder.java line 299:
> 
>> 297:     }
>> 298: 
>> 299:     // Wraps Method.invike() into ThrowingRunnable.run()
> 
> `invike` -> `invoke`.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23455#discussion_r1945597870

From asemenyuk at openjdk.org  Thu Feb  6 23:19:25 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Feb 2025 23:19:25 GMT
Subject: RFR: 8349564: Clean warnings found in jpackage tests when building
 them with -Xlint:all [v2]
In-Reply-To: <F1uoTAODBKxyrfihUbw-9XCCwLIErnDwany4wXxqjdY=.c2e7f48a-b88d-407d-ba43-bb876d46a20f@github.com>
References: <oFpKSze5bbMk9sUB55IQib3sPGVyq4Fyp4EbsH3_B_k=.ce30c7e6-3b6c-4e70-bf8b-d7ff6f654375@github.com>
 <_wvMS4MJ9UkUZZpZcO3E8eKKIG_i7CRdIAPZ0qRS6jc=.cdd289e5-ee16-40bb-b996-9078c2ccd3f1@github.com>
 <F1uoTAODBKxyrfihUbw-9XCCwLIErnDwany4wXxqjdY=.c2e7f48a-b88d-407d-ba43-bb876d46a20f@github.com>
Message-ID: <dX4XPRYzEbQfp6i7MMiLEkjje7WDFleEHWMt1UbTLLs=.86f8e550-b153-4c4b-abdd-4528f7843645@github.com>

On Thu, 6 Feb 2025 22:50:23 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> do we need to add -Xlint:all -Werror as well when building helper classes?

Good question. They are implicitly built by jtreg when requested through `@build jdk.jpackage.test.*` tag. I don't know how it constructs javac command line. @sormuras can you comment?

> test/jdk/tools/jpackage/share/JavaOptionsTest.java line 39:
> 
>> 37:  * @library /test/jdk/tools/jpackage/helpers
>> 38:  * @build jdk.jpackage.test.*
>> 39:  * @compile -Xlint:all -Werror JavaOptionsTest.java
> 
> Can we add `-Xlint:all -Werror` in generic way instead of repeating each time?

I don't think so.
@sormuras does jtreg allow to keep javac args for a group of tests in one place?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23455#discussion_r1945603281
PR Review Comment: https://git.openjdk.org/jdk/pull/23455#discussion_r1945601807

From coleenp at openjdk.org  Thu Feb  6 23:26:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 23:26:31 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v6]
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <FQVTF7A94az6n1bHbNae0CuaicfYRTcEh8qUzM7077s=.796fa77d-b455-4d96-b8ae-f6e1453c589a@github.com>

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:

 - Remove ??? in the code.
 - Hide Class.modifiers field.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22652/files
  - new: https://git.openjdk.org/jdk/pull/22652/files/146e2551..304a17ee

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

  Stats: 6 lines in 3 files changed: 1 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22652.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22652/head:pull/22652

PR: https://git.openjdk.org/jdk/pull/22652

From coleenp at openjdk.org  Thu Feb  6 23:26:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 23:26:31 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v5]
In-Reply-To: <Rnq14bXvkpbsJQdX-PF9uNr86akoq0ujgHPrFBLfIqY=.0278cab5-71ed-4a80-a751-e38248928e2e@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <Rnq14bXvkpbsJQdX-PF9uNr86akoq0ujgHPrFBLfIqY=.0278cab5-71ed-4a80-a751-e38248928e2e@github.com>
Message-ID: <IpxDRodyniGksNWI6F0ool2cmMfdnxV-lTXSLWFjYxg=.b23c920e-0d65-46e5-a4ce-697dbc638c3e@github.com>

On Thu, 6 Feb 2025 14:31:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make compute_modifiers return u2.

Thank you Vladimir for encouraging me to continue this change.  I removed the ??? and hid the modifiers field for reflection as suggested in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2641339406

From almatvee at openjdk.org  Thu Feb  6 23:35:40 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 6 Feb 2025 23:35:40 GMT
Subject: RFR: 8349509: [macos] Clean up macOS dead code in jpackage
Message-ID: <BDlttZM2kOvZJFNYxcYe43NfGZjq3YXpQ9-zW3AfOVc=.bb3eb6e7-62fb-4eab-aab3-069aca0cc5c0@github.com>

- Removed unused `INSTALLER_SUFFIX` bundler param.
- Removed unreachable if branch in `MacAppImageBuilder`.

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

Commit messages:
 - 8349509: [macos] Clean up macOS dead code in jpackage

Changes: https://git.openjdk.org/jdk/pull/23504/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23504&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349509
  Stats: 27 lines in 3 files changed: 1 ins; 20 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23504/head:pull/23504

PR: https://git.openjdk.org/jdk/pull/23504

From asemenyuk at openjdk.org  Thu Feb  6 23:49:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 6 Feb 2025 23:49:09 GMT
Subject: RFR: 8349509: [macos] Clean up macOS dead code in jpackage
In-Reply-To: <BDlttZM2kOvZJFNYxcYe43NfGZjq3YXpQ9-zW3AfOVc=.bb3eb6e7-62fb-4eab-aab3-069aca0cc5c0@github.com>
References: <BDlttZM2kOvZJFNYxcYe43NfGZjq3YXpQ9-zW3AfOVc=.bb3eb6e7-62fb-4eab-aab3-069aca0cc5c0@github.com>
Message-ID: <68WuII0OLo3Np7KMHL2U2Ldsi9ZBRNKIuWoSTYBdOCI=.eb7c027e-1bd6-4528-b2b3-4405d514593c@github.com>

On Thu, 6 Feb 2025 23:19:16 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Removed unused `INSTALLER_SUFFIX` bundler param.
> - Removed unreachable if branch in `MacAppImageBuilder`.

Marked as reviewed by asemenyuk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23504#pullrequestreview-2600269969

From bpb at openjdk.org  Fri Feb  7 00:13:47 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Feb 2025 00:13:47 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v4]
In-Reply-To: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
Message-ID: <wJ6bqoDR3iZLLO28hRTnXeXqjrp9w0QED83sFc3ryJw=.357a15f8-e4c8-412b-bc4f-eb7eaac29644@github.com>

> Update the specification of `java.io.File.exists()` to match its behavior, which seems correct in the context of how the empty abstract pathname is documented elsewhere in the class.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge
 - 8024695: Add test of length()
 - 8024695: Change implementation to work for empty path
 - 8024695: new File("").exists() returns false whereas it is the current working directory

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

Changes: https://git.openjdk.org/jdk/pull/22821/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22821&range=03
  Stats: 238 lines in 4 files changed: 193 ins; 1 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/22821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22821/head:pull/22821

PR: https://git.openjdk.org/jdk/pull/22821

From joehw at openjdk.org  Fri Feb  7 02:29:27 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 7 Feb 2025 02:29:27 GMT
Subject: Integrated: 8344925: translet-name ignored when package-name is also
 set
In-Reply-To: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
References: <lQmh7X_7Krc84vd6CgFFqn_ngWI_61kU7lXMDyQt9HI=.5107cbe1-ef84-4adb-bb5a-bb138ddc9964@github.com>
Message-ID: <ekMrSu7986Sz3d5xnuu26qMNZYrx0UxOQIX5DF3OxEs=.ffdd4ac0-efe1-4479-9079-6fae84342f1e@github.com>

On Tue, 4 Feb 2025 18:30:34 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an issue where the translet-name is incorrectly set when the package-name is also specified.

This pull request has now been integrated.

Changeset: 3989a199
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3989a199578fc1d91988cfdbb95f11dd6d4c7b81
Stats:     173 lines in 4 files changed: 165 ins; 4 del; 4 mod

8344925: translet-name ignored when package-name is also set

Reviewed-by: lancea, iris, naoto

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

PR: https://git.openjdk.org/jdk/pull/23446

From asemenyuk at openjdk.org  Fri Feb  7 03:52:11 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 7 Feb 2025 03:52:11 GMT
Subject: RFR: 8150442: Enforce Supported Platforms in Packager for MSI
 bundles
In-Reply-To: <ti2AiMIUTroSYIx5IYfcgMJcSx7vdwPY-FFsyjuTfRM=.842f1b33-6de9-4d07-9d83-011017c85da7@github.com>
References: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
 <ti2AiMIUTroSYIx5IYfcgMJcSx7vdwPY-FFsyjuTfRM=.842f1b33-6de9-4d07-9d83-011017c85da7@github.com>
Message-ID: <RwSn8CN7qx7bnZlaN1jO1fL5-pwcfB0jStoRKlCMEvM=.0778d2c2-85d7-4ba0-b5af-94fe575f237e@github.com>

On Thu, 6 Feb 2025 22:26:37 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Do you know what versions in PE headers of the main launcher and java.dll we have in JDK 25?

The major version is 6, and the minor version is 0. [List of Windows versions](https://learn.microsoft.com/en-us/windows/win32/sysinfo/operating-system-version)

> Do you know how versions in PE header are being set,

Linker sets them. See [linker option](https://learn.microsoft.com/en-us/cpp/build/reference/version-version-information?view=msvc-170).

> is it being updated between JDK releases?

I don't think so. Version is picked from the [manifest file](https://github.com/openjdk/jdk/blob/3989a199578fc1d91988cfdbb95f11dd6d4c7b81/src/java.base/windows/native/launcher/java.manifest) for launchers:

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
      <application>
        
        <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
        
        <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
        
        <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
        
        <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
        
        <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
      </application>
    </compatibility>


[The same manifest file in jdk11](https://github.com/openjdk/jdk11u/blob/master/src/java.base/windows/native/launcher/java.manifest) has the same contents.

Seems like the linker picks the lowest compatible version from the manifest and puts it in the PE header.

I don't know how major/minor OS versions are configured for dll-s but they are consistent with the launchers.

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

PR Comment: https://git.openjdk.org/jdk/pull/23472#issuecomment-2641882872

From sgehwolf at openjdk.org  Fri Feb  7 09:54:14 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 7 Feb 2025 09:54:14 GMT
Subject: RFR: 8344925: translet-name ignored,
 when package-name is also set via TransformerFactory.setAttribute
In-Reply-To: <kfTrynEd2-z8GfOCuvUOiY1VAOd2yO-qrGhGLCWLHmo=.dd17a46e-055c-4206-b129-39ad143ac474@github.com>
References: <kfTrynEd2-z8GfOCuvUOiY1VAOd2yO-qrGhGLCWLHmo=.dd17a46e-055c-4206-b129-39ad143ac474@github.com>
Message-ID: <-_5D1yCAXicKKaFFsrowh0Cit-KOUdajY53Y1TPVekY=.66d28787-48a9-466a-81c1-c177f08358c4@github.com>

On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng <duke at openjdk.org> wrote:

> ?String)
> 
> This bug seems from the improper handling of package and class name initialization in `XSLTC` since there is a default value of  `_packageName` with `die.verwandlung`. This fix is just adjusting to call `setPackageName` before `setClassName`.
> 
> I've done the tire1 and tire2 tests. The tire1 tests passed and tire2 reports
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  
>>> jtreg:test/hotspot/jtreg:tier2                      745   744     1     0 <<
>>> jtreg:test/jdk:tier2                               4142  4137     2     3 <<
>    jtreg:test/langtools:tier2                           12    12     0     0  
>    jtreg:test/jaxp:tier2                               514   514     0     0  
>    jtreg:test/docs:tier2                                 1     1     0     0  
> ==============================
> TEST FAILURE
> 
> 
> The failed tests are
> 
> JT Harness : Tests that failed
> runtime/Thread/ThreadCountLimit.java#id0: Stress test that reaches the process limit for thread count, or time limit.
> 
> JT Harness : Tests that failed
> java/net/InetAddress/CheckJNI.java: java -Xcheck:jni failing in net code on Solaris / [Datagram]Socket.getLocalAddress() failure
> java/net/Socket/LinkLocal.java: Connecting to a link-local IPv6 address should not causes a SocketException to be thrown.
> 
> JT Harness : Tests that had errors
> java/net/URL/EarlyOrDelayedParsing.java: URL built-in protocol handlers should parse the URL early to avoid constructing URLs for which openConnection would later throw an exception, when possible.
> java/net/ipv6tests/UdpTest.java: IPv6 support for Windows XP and 2003 server.
> java/nio/channels/DatagramChannel/SendReceiveMaxSize.java: Check that it is possible to send and receive datagrams of maximum size on macOS.

A change similar to the proposal here has been integrated with https://github.com/openjdk/jdk/pull/23446 I'd suggest to close this one. It looks like there was some miscommunication happening. In this case the person proposing the PR isn't OpenJDK author, so couldn't assign the bug to himself. We'll work with the team to catch cases like this in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/22425#issuecomment-2642453124

From viktor.klang at oracle.com  Fri Feb  7 10:16:09 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Fri, 7 Feb 2025 10:16:09 +0000
Subject: [External] : Re: mapConcurrent() with InterruptedException
In-Reply-To: <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
References: <CAKD1RYv0NNDVZJBGXUD93UJqaZacBth4YmimRNu7MxrnTapBHg@mail.gmail.com>
 <MW4PR10MB5774265B8728DA0641C48DBAFF152@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYut_G7TRSTr0hPVuxWAvJQ+25JyPBWB7PEtntamWq-E_A@mail.gmail.com>
 <MW4PR10MB5774AB9B6544E949383187F3FFEC2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvyRxcWv65v4+8KcRHys=jkbpfKZ3eK3ijTGKXR1UxNnA@mail.gmail.com>
 <MW4PR10MB5774986199F9EDF854A6D390FFEE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtE-xwb9tBhjPvObeG9_03nXh1aRA10sO7ibEGkQavntw@mail.gmail.com>
 <MW4PR10MB5774099E6747A4B9335555C7FFF72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtAUfyUHOdmSeZ2Azny=RJU63FQozY2NxpYu-4xQYCRkA@mail.gmail.com>
 <MW4PR10MB5774B089653C902899FEBEAFFFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB5774BB2B60EE5A1F4B1A7306FFF62@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvxZ0gpHJXW0ctuHwEGwfStfjmLvwV1CgSWrr8438rWPA@mail.gmail.com>
Message-ID: <MW4PR10MB5774EF4D4316B5BE46B29A0EFFF12@MW4PR10MB5774.namprd10.prod.outlook.com>

>Sorry, did the PR stop using Semaphore?

No, not that PR. See: https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e

The problem with interruption under parallel evaluation is that there is no general support for propagation of interruption in CountedCompleters. Adding support for such in (at least) GathererOp needs further study before contemplating making any changes to mapConcurrent()'s interruption policy.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Thursday, 6 February 2025 17:04
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Sorry, did the PR stop using Semaphore?

I had naively thought that mapConcurrent() will keep a buffer of Future of all currently-running concurrent tasks (it can be a ConcurrentMap<TaskKey, Future> if we don't have to ensure FIFO).

Upon interruption, the main thread can call .cancel(true) on all pending Futures; optionally join with the VTs (if we need to block until all VTs exit); then propagate exception.

Upon completion, each task just removes itself from the ConcurrentMap.

Just in case it adds anything.



On Thu, Feb 6, 2025 at 6:47?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
After some more investigation it seems tractable to propagate interruption of the caller in sequential mode, but parallel mode will require much bigger considerations.

I made a comment to that effect on the JBS issue: https://bugs.openjdk.org/browse/JDK-8349462?focusedId=14750017&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14750017


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Sent: Thursday, 6 February 2025 11:51
To: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

I think alignment in behavior between parallel Stream and mapConcurrent in terms of how interruptions are handled is a possible path forward.

I decided to close the PR for now as I realized my parallel Stream example had misled me regarding its exception throwing, so I'll need to go back and refine the solution.

It still seems solvable though.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 5 February 2025 19:20
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Oh good call!

I forgot to check what parallel streams do upon interruption (didn't think they do any blocking calls, but at least the main thread must block).

On Wed, Feb 5, 2025 at 8:18?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Jige,

I opened an issue to track the concern, and I have proposed a change which seems to align well with how parallel streams behave under caller thread interruption.

I've opened the following PR for review:
https://github.com/openjdk/jdk/pull/23467<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>

If you are able to make a local OpenJDK build with that solution you could check if it addresses your use-cases (or not).
[https://opengraph.githubassets.com/00e04f8a63bde12217df087df7ef8edee563adf7e925d07c75bdeae092180094/openjdk/jdk/pull/23467]<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
8349462: Gatherers.mapConcurrent could support async interrupts by viktorklang-ora ? Pull Request #23467 ? openjdk/jdk<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23467__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89E_mLvMu$>
This change is likely going to need some extra verbiage in the spec for mapConcurrent, and thus a CSR. This behavior aligns mapConcurrent with how parallel streams work in conjunction with interrup...
github.com<https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!M4nB0WxHU_1jcbZoNGy3DD81Oefr7BuObJ-7FHb_mw51HqMBI0BjFy97H6GnjZaX402UQZK89DBkMefT$>


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 5 February 2025 16:24
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

I understand the problem.

The main reason I asked is because I want to understand how the core Java team thinks of throwing an unchecked exception.

As explained above, I consider losing cancellability a big deal, a deal breaker even. And I thought throwing unchecked is more acceptable. Because the most common reason the mapConcurrent() VT can be interrupted is due to cancellation from a parent mapConcurrent(), or a parent Structured Concurrency scope. The cancellation could be either from an organic exception, or from the downstream not needing more elements, like maybe due to findFirst() already getting an element.

In both cases, since the concurrent operation is already cancelled (result ignored), what exception pops up to the top level isn't that big of a deal (perhaps only a log record will be seen?)

But if the core Java team considers it a bad idea, I would love to learn and adjust.

On Tue, Feb 4, 2025 at 4:41?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi,

The problem is that mapConcurrent cannot throw InterruptedException because that is a checked exception, so we cannot clear the interrupted flag and throw that exception.

So the updated semantics is to not cut the stream short but instead run to completion, restoring the interruption flag.

There exists a couple of alternatives to this approach which I am contemplating, but they need to be further explored before I consider moving forward with any of them.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 27 January 2025 17:00
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: mapConcurrent() with InterruptedException

Thanks Viktor!

It looks like the current fix ignores interruption.

I want to make sure my concern of it defeating cancellation is heard and understood.

The scenarios I worry about is for a mapConcurrent() that fans out to another method call, which internally calls mapConcurrent() as implementation detail.

An example:


List<RefundResponse> refundHelper(transaction) {
  transaction.creditCardAccounts.stream()
    .gather(mapConcurrent(acct -> service.refund(acct))
    .toList();
}

transactions.stream()
    .gather(mapConcurrent(transaction -> refundHelper(transaction));

It seems undesirable that in such a case all the service.refund() calls become non cancellable, because the only way the outer mapConcurrent() cancels the refundHelper() calls is through Thread.interrupt() the virtual threads that call refundHelper(), which would then be disabled by the inner mapConcurrent().

Does this example make sense to you? I can further explain if anything isn't clear.

But I want to make sure the decision to disable interruption is deliberate judgement call that such nested mapConcurrent() is unlikely,or not important.

Cheers,



On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi!

Please see: https://github.com/openjdk/jdk/pull/23100<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23100__;!!ACWV5N9M2RV99hQ!IzQs0G26M7ZGPwJ3YJpCcS0gxi6BjqoBux2T5u0cHud_zb_mHLfiIrASSZiP0ynNgnaAuwuOh__WinK8$>

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 26 January 2025 23:03
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: mapConcurrent() with InterruptedException

Checking in on what you've found out, Viktor.

From where we left off, I understand that you were looking at alternatives instead of silent truncation?

Have you reached any conclusion?

We touched on disallowing interruption during mapConcurrent(). I still have concerns with disabling cancellation, because it basically undoes this API note from the javadoc<https://cr.openjdk.org/~alanb/sc-20240503/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function)>:


API Note:

In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements.
In reality, people will use mapConcurrent() to fan out rpcs. Sometimes these rpcs are just a single blocking call; yet sometimes they may themselves be a Structured Concurrency scope, with 2 or 3 rpcs that constitute a single logical operation. Under two conditions, cancellation is imho important semantic:

  1.  The downstream code uses filter().findFirst(), and when it sees an element, it will return and no longer needs the other pending rpcs to complete. If cancellation is disabled, these unnecessary rpcs will waste system resources.
  2.  One of the rpc throws and the Stream pipeline needs to propagate the exception. Again, if the other rpcs cannot be cancelled, we'll have many zombie rpcs.

Zombie rpcs may or may not be a deal breaker, depending on the specific use case. But for a JDK library, losing cancellation would have a negative impact on usability.

My 2c,


On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi Ben,

Thanks for raising these questions?getting feedback is crucial in the Preview stage of features.

I wrote a reply to the Reddit thread so I'll just summarize here:

It is important to note that mapConcurrent() is not a part of the Structured Concurrency JEPs, so it is not designed to join SC scopes.

I'm currently experimenting with ignoring-but-restoring interrupts on the "calling thread" for mapConcurrent(), as well as capping work-in-progress to maxConcurrency (not only capping the concurrency but also the amount of completed-but-yet-to-be-pushed work). Both of these adjustments should increase predictability of behavior in the face of blocking operations with variable delays.

Another adjustment I'm looking at right now is to harden/improve the cleanup to wait for concurrent tasks to acknowledge cancellation, so that once the finisher is done executing the VTs are known to have terminated.

As for not preserving the encounter order, that would be a completely different thing, and I'd encourage you to experiment with that if that functionality would be interesting for your use-case(s).

Again, thanks for your feedback!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Friday, 3 January 2025 17:53
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: mapConcurrent() with InterruptedException

Hi Java Experts,

I sent this email incorrectly to loom-dev@ and was told on Reddit that core-libs-dev is the right list.

The question is about the behavior of mapConcurrent() when the thread is interrupted.

Currently mapConcurrent()'s finisher phase will re-interrupt the thread, then stop at whatever element that has already been processed and return.

This strikes me as a surprising behavior, because for example if I'm running:

   Stream.of(1, 2, 3)
        .gather(mapConcurrent(i -> i * 2))
        .toList()

and the thread is being interrupted, the result could be any of [2], [2, 4] or [2, 4, 6].

Since thread interruption is cooperative, there is no guarantee that the thread being interrupted will just abort. It's quite possible that it'll keep going and then will use for example [2] as the result of doubling the list of [1, 2, 3], which is imho incorrect.

In the Reddit<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/observations_of_gatherersmapconcurrent/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8M4PjPb7L$> thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks.

There had been discussion about alternative strategies:

  1.  Don't respond to interruption and just keep running to completion.
  2.  Re-interrupt thread and wrap the InterruptedException in a standard unchecked exception (StructuredConcurrencyInterruptedException?).

I have concerns with option 1 because it disables cancellation propagation when mapConcurrent() itself is used in a subtask of a parent mapConcurrent() or in a StructuredConcurrencyScope.

Both equivalent Future-composition async code, or C++'s fiber trees support cancellation propagation and imho it's a critical feature or else it's possible that a zombie thread is still sending RPCs long after the main thread has exited (failed, or falled back to some default action).

My arguments for option 2:

  1.  InterruptedException is more error prone than traditional checked exceptions for users to catch and handle. They can forget to re-interrupt the thread. It's so confusing that even seasoned programmers may not know they are supposed to re-interrupt the thread.
  2.  With Stream API using functional interfaces like Supplier, Function, the option of just tacking on "throws IE" isn't available to many users.
  3.  With Virtual Threads, it will be more acceptable, or even become common to do blocking calls from a stream operation (including but exclusive to mapConcurrent()). So the chance users are forced to deal with IE will become substantially higher.
  4.  Other APIs such as the Structured Concurrency API have already started wrapping system checked exceptions like ExecutionException, TimeoutException in unchecked exceptions ( join()<https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html*join()__;Iw!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MxGG4HzA$> for example).
  5.  Imho, exceptions that we'd rather users not catch and handle but instead should mostly just propagate up as is, should be unchecked.

There is also a side discussion<https://urldefense.com/v3/__https://www.reddit.com/r/java/comments/1hr8xyu/comment/m4z4f8c/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button__;!!ACWV5N9M2RV99hQ!L1LHRE2pnYPg43nM0J0dCoV4agscV_rybIV9jY97xn9XJi9d7VoPma4jhx4J4GBeoeQmVud8MyZYl02k$> about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread?

Thank you and cheers!

Ben Yu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250207/86e8be29/attachment-0001.htm>

From alanb at openjdk.org  Fri Feb  7 10:41:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Feb 2025 10:41:00 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK
In-Reply-To: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
Message-ID: <5uzw7F8io2kdoROQLcPw9Q3lJe5SKxyysAag22QD-4Y=.4d026330-4326-49e9-a50e-1dfe66d2a5a2@github.com>

On Thu, 6 Feb 2025 20:14:36 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
> 
> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.

Can you look at adding native init method instead? This could be called from the System.loadLibraray and avoid introduce a side effect of startThreads initialising GetCreatedJavaVMs.

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

PR Comment: https://git.openjdk.org/jdk/pull/23500#issuecomment-2642552698

From galder at openjdk.org  Fri Feb  7 12:31:11 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 7 Feb 2025 12:31:11 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
Message-ID: <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>

On Fri, 17 Jan 2025 17:53:24 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

@eastig is helping with the results on aarch64, so I will verify the numbers in same way done below for x86_64 once he provides me with the results.

Here is a summary of the benchmarking results I'm seeing on x86_64 (I will push an update that just merges the latest master shortly).

First I will go through the results of `MinMaxVector`. This benchmark computes throughput by default so the higher the number the better.

# MinMaxVector AVX-512

Following are results with AVX-512 instructions:

Benchmark                       (probability)  (range)  (seed)  (size)   Mode  Cnt   Baseline     Patch   Units
MinMaxVector.longClippingRange            N/A       90       0    1000  thrpt    4    834.127  3688.961  ops/ms
MinMaxVector.longClippingRange            N/A      100       0    1000  thrpt    4   1147.010  3687.721  ops/ms
MinMaxVector.longLoopMax                   50      N/A     N/A    2048  thrpt    4   1126.718  1072.812  ops/ms
MinMaxVector.longLoopMax                   80      N/A     N/A    2048  thrpt    4   1070.921  1070.538  ops/ms
MinMaxVector.longLoopMax                  100      N/A     N/A    2048  thrpt    4    510.483  1073.081  ops/ms
MinMaxVector.longLoopMin                   50      N/A     N/A    2048  thrpt    4    935.658  1016.910  ops/ms
MinMaxVector.longLoopMin                   80      N/A     N/A    2048  thrpt    4   1007.410   933.774  ops/ms
MinMaxVector.longLoopMin                  100      N/A     N/A    2048  thrpt    4    536.582  1017.337  ops/ms
MinMaxVector.longReductionMax              50      N/A     N/A    2048  thrpt    4    967.288   966.945  ops/ms
MinMaxVector.longReductionMax              80      N/A     N/A    2048  thrpt    4    967.327   967.382  ops/ms
MinMaxVector.longReductionMax             100      N/A     N/A    2048  thrpt    4    849.689   967.327  ops/ms
MinMaxVector.longReductionMin              50      N/A     N/A    2048  thrpt    4    966.323   967.275  ops/ms
MinMaxVector.longReductionMin              80      N/A     N/A    2048  thrpt    4    967.340   967.228  ops/ms
MinMaxVector.longReductionMin             100      N/A     N/A    2048  thrpt    4    880.921   967.233  ops/ms


### `longReduction[Min|Max]` performance improves slightly when probability is 100

Without the patch the code uses compare instructions:


   7.83%  ???? ????  ?           0x00007f4f700fb305:   imulq		$0xb, 0x20(%r14, %r8, 8), %rdi
          ???? ????  ?                                                                     ;*lmul {reexecute=0 rethrow=0 return_oop=0}
          ???? ????  ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 24 (line 255)
          ???? ????  ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)
   5.64%  ???? ????  ?           0x00007f4f700fb30b:   cmpq		%rdi, %rdx
          ?????????  ?           0x00007f4f700fb30e:   jge		0x7f4f700fb32c      ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ?????????  ?                                                                     ; - java.lang.Math::max at 11 (line 2037)
          ?????????  ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 30 (line 256)
          ?????????  ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)
  12.82%  ?????????? ?           0x00007f4f700fb310:   imulq		$0xb, 0x28(%r14, %r8, 8), %rbp
          ?????????? ?                                                                     ;*lmul {reexecute=0 rethrow=0 return_oop=0}
          ?????????? ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 24 (line 255)
          ?????????? ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)
   7.46%  ?????????? ?           0x00007f4f700fb316:   cmpq		%rbp, %rdi
          ?????????? ?           0x00007f4f700fb319:   jl		0x7f4f700fb2e0      ;*iflt {reexecute=0 rethrow=0 return_oop=0}
          ????? ???? ?                                                                     ; - java.lang.Math::max at 3 (line 2037)
          ????? ???? ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 30 (line 256)
          ????? ???? ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)


And with the patch these become vectorized:


          ?    ?? ?????  0x00007f56280fad10:   vpmullq		0xf0(%rdx, %rsi, 8), %ymm10, %ymm4
   8.35%  ?    ?? ?????  0x00007f56280fad1b:   vpmullq		0xd0(%rdx, %rsi, 8), %ymm10, %ymm5
   4.27%  ?    ?? ?????  0x00007f56280fad26:   vpmullq		0x10(%rdx, %rsi, 8), %ymm10, %ymm6
          ?    ?? ?????                                                            ;   {no_reloc}
   4.22%  ?    ?? ?????  0x00007f56280fad31:   vpmullq		0x30(%rdx, %rsi, 8), %ymm10, %ymm7
   4.00%  ?    ?? ?????  0x00007f56280fad3c:   vpmullq		0xb0(%rdx, %rsi, 8), %ymm10, %ymm8
   4.13%  ?    ?? ?????  0x00007f56280fad47:   vpmullq		0x50(%rdx, %rsi, 8), %ymm10, %ymm11
   4.10%  ?    ?? ?????  0x00007f56280fad52:   vpmullq		0x70(%rdx, %rsi, 8), %ymm10, %ymm12
   4.13%  ?    ?? ?????  0x00007f56280fad5d:   vpmullq		0x90(%rdx, %rsi, 8), %ymm10, %ymm13
   4.03%  ?    ?? ?????  0x00007f56280fad68:   vpmaxsq		%ymm6, %ymm3, %ymm3
          ?    ?? ?????  0x00007f56280fad6e:   vpmaxsq		%ymm7, %ymm3, %ymm3
   4.72%  ?    ?? ?????  0x00007f56280fad74:   vpmaxsq		%ymm11, %ymm3, %ymm3
          ?    ?? ?????  0x00007f56280fad7a:   vpmaxsq		%ymm12, %ymm3, %ymm3
   8.40%  ?    ?? ?????  0x00007f56280fad80:   vpmaxsq		%ymm13, %ymm3, %ymm3
  23.11%  ?    ?? ?????  0x00007f56280fad86:   vpmaxsq		%ymm8, %ymm3, %ymm3
   2.15%  ?    ?? ?????  0x00007f56280fad8c:   vpmaxsq		%ymm5, %ymm3, %ymm3
   8.79%  ?    ?? ?????  0x00007f56280fad92:   vpmaxsq		%ymm4, %ymm3, %ymm3 ;*invokestatic max {reexecute=0 rethrow=0 return_oop=0}
          ?    ?? ?????                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 30 (line 256)
          ?    ?? ?????                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)


### `longLoop[Min|Max]` performance improves considerably when probability is 100

Without the patch the code uses compare + move instructions:


   4.53%  ????  ??  ? ?           0x00007f96b40faf33:   movq		0x18(%rax, %rsi, 8), %r13;*laload {reexecute=0 rethrow=0 return_oop=0}
          ????  ??  ? ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longLoopMax at 20 (line 236)
          ????  ??  ? ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub at 19 (line 124)
   2.69%  ????  ??  ? ?           0x00007f96b40faf38:   cmpq		%r11, %r13
          ????? ??  ? ?           0x00007f96b40faf3b:   jl		0x7f96b40faf67      ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ????? ??  ? ?                                                                     ; - java.lang.Math::max at 11 (line 2037)
          ????? ??  ? ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longLoopMax at 27 (line 236)
          ????? ??  ? ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub at 19 (line 124)
   8.75%  ????? ??? ? ?           0x00007f96b40faf3d:   movq		%r13, 0x18(%rbp, %rsi, 8);*lastore {reexecute=0 rethrow=0 return_oop=0}
          ????? ??? ? ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longLoopMax at 30 (line 236)
          ????? ??? ? ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub at 19 (line 124)


And with the patch those become vectorized:


   3.55%  ?  ??  0x00007f13c80fa18a:   vmovdqu		0xf0(%rbx, %r10, 8), %ymm5
          ?  ??  0x00007f13c80fa194:   vmovdqu		0xf0(%rdi, %r10, 8), %ymm6
   2.35%  ?  ??  0x00007f13c80fa19e:   vpmaxsq		%ymm6, %ymm5, %ymm5
   5.03%  ?  ??  0x00007f13c80fa1a4:   vmovdqu		%ymm5, 0xf0(%rax, %r10, 8)
          ?  ??                                                            ;*lastore {reexecute=0 rethrow=0 return_oop=0}
          ?  ??                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longLoopMax at 30 (line 236)
          ?  ??                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub at 19 (line 124)


It's interesting to observe that at probabilites of 50/80% the baseline performs better than at 100%. The reason for that is because at 50/80% the baseline already vectorizes. So, why isn't the baseline vectorizing at 100% probability?


VLoop::check_preconditions
      Loop: N1256/N463  limit_check counted [int,int),+4 (3161 iters)  main rc  has_sfpt strip_mined
 1256  CountedLoop  === 1256 598 463  [[ 1256 1257 1271 1272 ]] inner stride: 4 main of N1256 strip mined !orig=[1126],[599],[590],[307] !jvms: MinMaxVector::longLoopMax @ bci:10 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
VLoop::check_preconditions: fails because of control flow.
  cl_exit 594  594  CountedLoopEnd  === 415 593  [[ 1275 463 ]] [lt] P=0.999684, C=707717.000000 !orig=[462] !jvms: MinMaxVector::longLoopMax @ bci:7 (line 235) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
  cl_exit->in(0) 415  415  Region  === 415 411 412  [[ 415 594 416 451 ]]  !orig=[423] !jvms: Math::max @ bci:11 (line 2037) MinMaxVector::longLoopMax @ bci:27 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
  lpt->_head 1256 1256  CountedLoop  === 1256 598 463  [[ 1256 1257 1271 1272 ]] inner stride: 4 main of N1256 strip mined !orig=[1126],[599],[590],[307] !jvms: MinMaxVector::longLoopMax @ bci:10 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
      Loop: N1256/N463  limit_check counted [int,int),+4 (3161 iters)  main rc  has_sfpt strip_mined
VLoop::check_preconditions: failed: control flow in loop not allowed


At 100% probability baseline fails to vectorize because it observes a control flow. This control flow is not the one you see in min/max implementations, but this is one added by HotSpot as a result of the JIT profiling. It observes that one branch is always taken so it optimizes for that, and adds a branch for the uncommon case where the branch is not taken.

### `longClippingRange` performance improves considerably

Without the patch the code uses compare + move instructions:


   3.39%  ?? ?      ?? ?            0x00007febb40fb175:   cmpq		%rbp, %rcx
          ?? ??     ?? ?            0x00007febb40fb178:   jge		0x7febb40fb17d      ;*iflt {reexecute=0 rethrow=0 return_oop=0}
          ?? ??     ?? ?                                                                      ; - java.lang.Math::max at 3 (line 2037)
          ?? ??     ?? ?                                                                      ; - org.openjdk.bench.java.lang.MinMaxVector::longClippingRange at 25 (line 220)
          ?? ??     ?? ?                                                                      ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)
   2.69%  ?? ??     ?? ?            0x00007febb40fb17a:   movq		%rbp, %rcx          ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ?? ??     ?? ?                                                                      ; - java.lang.Math::max at 11 (line 2037)
          ?? ??     ?? ?                                                                      ; - org.openjdk.bench.java.lang.MinMaxVector::longClippingRange at 25 (line 220)
          ?? ??     ?? ?                                                                      ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)
   4.35%  ?? ??     ?? ?            0x00007febb40fb17d:   nop
   2.93%  ?? ?      ?? ?            0x00007febb40fb180:   cmpq		%r8, %rcx
          ?? ? ?    ?? ?            0x00007febb40fb183:   jle		0x7febb40fb188      ;*ifgt {reexecute=0 rethrow=0 return_oop=0}
          ?? ? ?    ?? ?                                                                      ; - java.lang.Math::min at 3 (line 2132)
          ?? ? ?    ?? ?                                                                      ; - org.openjdk.bench.java.lang.MinMaxVector::longClippingRange at 32 (line 220)
          ?? ? ?    ?? ?                                                                      ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)
   3.51%  ?? ? ?    ?? ?            0x00007febb40fb185:   movq		%r8, %rcx           ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ?? ? ?    ?? ?                                                                      ; - java.lang.Math::min at 11 (line 2132)
          ?? ? ?    ?? ?                                                                      ; - org.openjdk.bench.java.lang.MinMaxVector::longClippingRange at 32 (line 220)
          ?? ? ?    ?? ?                                                                      ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)
   4.26%  ?? ? ?    ?? ?            0x00007febb40fb188:   movq		%rcx, 0x10(%rsi, %r9, 8);*lastore {reexecute=0 rethrow=0 return_oop=0}
          ?? ?      ?? ?                                                                      ; - org.openjdk.bench.java.lang.MinMaxVector::longClippingRange at 35 (line 220)
          ?? ?      ?? ?                                                                      ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)


With the patch these become vectorized:


   0.20%  ???        ?   0x00007f10180fd15c:   vmovdqu		0x10(%r11, %rcx, 8), %ymm6
          ???        ?   0x00007f10180fd163:   vpmaxsq		%ymm6, %ymm7, %ymm6
          ???        ?   0x00007f10180fd169:   vpminsq		%ymm8, %ymm6, %ymm6
          ???        ?   0x00007f10180fd16f:   vmovdqu		%ymm6, 0x10(%r8, %rcx, 8);*lastore {reexecute=0 rethrow=0 return_oop=0}
          ???        ?                                                             ; - org.openjdk.bench.java.lang.MinMaxVector::longClippingRange at 35 (line 220)
          ???        ?                                                             ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)


# `MinMaxVector` AVX2

Following are results on the same machine as above but forcing AVX2 to be used instead of AVX-512:

Benchmark                       (probability)  (range)  (seed)  (size)   Mode  Cnt  Baseline     Patch   Units
MinMaxVector.longClippingRange            N/A       90       0    1000  thrpt    4   832.132  1813.609  ops/ms
MinMaxVector.longClippingRange            N/A      100       0    1000  thrpt    4   832.546  1814.477  ops/ms
MinMaxVector.longLoopMax                   50      N/A     N/A    2048  thrpt    4   938.372   939.313  ops/ms
MinMaxVector.longLoopMax                   80      N/A     N/A    2048  thrpt    4   934.964   945.124  ops/ms
MinMaxVector.longLoopMax                  100      N/A     N/A    2048  thrpt    4   512.076   937.287  ops/ms
MinMaxVector.longLoopMin                   50      N/A     N/A    2048  thrpt    4   999.455   689.750  ops/ms
MinMaxVector.longLoopMin                   80      N/A     N/A    2048  thrpt    4  1000.352   876.326  ops/ms
MinMaxVector.longLoopMin                  100      N/A     N/A    2048  thrpt    4   536.359   999.475  ops/ms
MinMaxVector.longReductionMax              50      N/A     N/A    2048  thrpt    4   409.413   409.363  ops/ms
MinMaxVector.longReductionMax              80      N/A     N/A    2048  thrpt    4   409.374   409.141  ops/ms
MinMaxVector.longReductionMax             100      N/A     N/A    2048  thrpt    4   883.614   409.318  ops/ms
MinMaxVector.longReductionMin              50      N/A     N/A    2048  thrpt    4   404.723   404.705  ops/ms
MinMaxVector.longReductionMin              80      N/A     N/A    2048  thrpt    4   404.755   404.748  ops/ms
MinMaxVector.longReductionMin             100      N/A     N/A    2048  thrpt    4   848.784   404.669  ops/ms


### `longClippingRange` performance improves considerably

Baseline uses compare + move instructions as shown above. But the patched version improves in spite of not being able to use AVX-512 instructions such as `vpmaxsq`. The performance improvements come from using other vectorized compare + vectorized move instructions:


          ?    ?   ????  0x00007f9aa40f94ac:   vpcmpgtq		%ymm6, %ymm7, %ymm12
   3.79%  ?    ?   ????  0x00007f9aa40f94b1:   vblendvpd		%ymm12, %ymm7, %ymm6, %ymm12
   3.72%  ?    ?   ????  0x00007f9aa40f94b7:   vpcmpgtq		%ymm8, %ymm12, %ymm10
          ?    ?   ????  0x00007f9aa40f94bc:   vblendvpd		%ymm10, %ymm8, %ymm12, %ymm10
   3.78%  ?    ?   ????  0x00007f9aa40f94c2:   vmovdqu		%ymm10, 0xf0(%r8, %rcx, 8)
          ?    ?   ????                                                            ;*lastore {reexecute=0 rethrow=0 return_oop=0}
          ?    ?   ????                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longClippingRange at 35 (line 220)
          ?    ?   ????                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)


### `longReduction[Min|Max]` performance drops considerably when probability is 100

Baseline uses compare + move instruction to implement this:


          ???? ????  ?                                                                     ;*lmul {reexecute=0 rethrow=0 return_oop=0}
          ???? ????  ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 24 (line 255)
          ???? ????  ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)
   6.30%  ???? ????  ?           0x00007fd5580f678b:   cmpq		%rdi, %rdx
          ?????????  ?           0x00007fd5580f678e:   jge		0x7fd5580f67ac      ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ?????????  ?                                                                     ; - java.lang.Math::max at 11 (line 2037)
          ?????????  ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 30 (line 256)
          ?????????  ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)
  12.88%  ?????????? ?           0x00007fd5580f6790:   imulq		$0xb, 0x28(%r14, %r8, 8), %rbp
          ?????????? ?                                                                     ;*lmul {reexecute=0 rethrow=0 return_oop=0}
          ?????????? ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 24 (line 255)
          ?????????? ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)
   7.55%  ?????????? ?           0x00007fd5580f6796:   cmpq		%rbp, %rdi
          ?????????? ?           0x00007fd5580f6799:   jl		0x7fd5580f6760      ;*iflt {reexecute=0 rethrow=0 return_oop=0}
          ????? ???? ?                                                                     ; - java.lang.Math::max at 3 (line 2037)
          ????? ???? ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 30 (line 256)
          ????? ???? ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)


With the patch the code uses conditional moves instead:


   0.05%  ??  0x00007fc4700f5253:   imulq		$0xb, 0x28(%r14, %r11, 8), %rdx
  10.62%  ??  0x00007fc4700f5259:   imulq		$0xb, 0x20(%r14, %r11, 8), %rax
   0.63%  ??  0x00007fc4700f525f:   imulq		$0xb, 0x10(%r14, %r11, 8), %r8
          ??                                                            ;*lmul {reexecute=0 rethrow=0 return_oop=0}
          ??                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 24 (line 255)
          ??                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)
  10.34%  ??  0x00007fc4700f5265:   cmpq		%r8, %r13
   2.37%  ??  0x00007fc4700f5268:   cmovlq		%r8, %r13           ;*invokestatic max {reexecute=0 rethrow=0 return_oop=0}
          ??                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 30 (line 256)
          ??                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)
   1.15%  ??  0x00007fc4700f526c:   imulq		$0xb, 0x18(%r14, %r11, 8), %r8
          ??                                                            ;*lmul {reexecute=0 rethrow=0 return_oop=0}
          ??                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 24 (line 255)
          ??                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)
   9.28%  ??  0x00007fc4700f5272:   cmpq		%r8, %r13
   3.82%  ??  0x00007fc4700f5275:   cmovlq		%r8, %r13
  21.61%  ??  0x00007fc4700f5279:   cmpq		%rax, %r13
  11.55%  ??  0x00007fc4700f527c:   cmovlq		%rax, %r13
   4.48%  ??  0x00007fc4700f5280:   cmpq		%rdx, %r13
  11.76%  ??  0x00007fc4700f5283:   cmovlq		%rdx, %r13          ;*invokestatic max {reexecute=0 rethrow=0 return_oop=0}
          ??                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMax at 30 (line 256)
          ??                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub at 19 (line 124)


When one of the branches is taken always or almost always, the branched code of baseline can be optimized with branch prediction. However, the conditional move instructions force the CPU to compute both sides of the branch, so it performs worse in this scenario.

Why vectorized instructions are not used in this scenario? Vector instructions for min/max are not available with AVX2 and the trace vectorization signals it:


PackSet::print: 3 packs
 Pack: 0
    0:  1119  LoadL  === 1105 343 1120  [[ 1117 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8; #long (does not depend only on test, unknown control) !orig=997,663,[457] !jvms: MinMaxVector::longReductionMax @ bci:23 (line 255) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
    1:  1112  LoadL  === 1105 343 1113  [[ 1111 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8; #long (does not depend only on test, unknown control) !orig=663,[457] !jvms: MinMaxVector::longReductionMax @ bci:23 (line 255) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
    2:   997  LoadL  === 1105 343 998  [[ 996 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8; #long (does not depend only on test, unknown control) !orig=663,[457] !jvms: MinMaxVector::longReductionMax @ bci:23 (line 255) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
    3:   663  LoadL  === 1105 343 455  [[ 458 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8; #long (does not depend only on test, unknown control) !orig=[457] !jvms: MinMaxVector::longReductionMax @ bci:23 (line 255) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
 Pack: 1
    0:  1117  MulL  === _ 1119 162  [[ 1116 ]]  !orig=996,458 !jvms: MinMaxVector::longReductionMax @ bci:24 (line 255) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
    1:  1111  MulL  === _ 1112 162  [[ 1110 ]]  !orig=458 !jvms: MinMaxVector::longReductionMax @ bci:24 (line 255) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
    2:   996  MulL  === _ 997 162  [[ 995 ]]  !orig=458 !jvms: MinMaxVector::longReductionMax @ bci:24 (line 255) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
    3:   458  MulL  === _ 663 162  [[ 459 ]]  !jvms: MinMaxVector::longReductionMax @ bci:24 (line 255) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
 Pack: 2
    0:  1116  MaxL  === _ 1128 1117  [[ 1110 ]]  !orig=995,459,1012 !jvms: MinMaxVector::longReductionMax @ bci:30 (line 256) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
    1:  1110  MaxL  === _ 1116 1111  [[ 995 ]]  !orig=459,1012 !jvms: MinMaxVector::longReductionMax @ bci:30 (line 256) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
    2:   995  MaxL  === _ 1110 996  [[ 459 ]]  !orig=459,1012 !jvms: MinMaxVector::longReductionMax @ bci:30 (line 256) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
    3:   459  MaxL  === _ 995 458  [[ 1128 923 570 ]]  !orig=1012 !jvms: MinMaxVector::longReductionMax @ bci:30 (line 256) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)

WARNING: Removed pack: not implemented at any smaller size:
    0:  1116  MaxL  === _ 1128 1117  [[ 1110 ]]  !orig=995,459,1012 !jvms: MinMaxVector::longReductionMax @ bci:30 (line 256) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
    1:  1110  MaxL  === _ 1116 1111  [[ 995 ]]  !orig=459,1012 !jvms: MinMaxVector::longReductionMax @ bci:30 (line 256) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
    2:   995  MaxL  === _ 1110 996  [[ 459 ]]  !orig=459,1012 !jvms: MinMaxVector::longReductionMax @ bci:30 (line 256) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)
    3:   459  MaxL  === _ 995 458  [[ 1128 923 570 ]]  !orig=1012 !jvms: MinMaxVector::longReductionMax @ bci:30 (line 256) MinMaxVector_longReductionMax_jmhTest::longReductionMax_thrpt_jmhStub @ bci:19 (line 124)

After SuperWord::split_packs_only_implemented_with_smaller_size


One interesting question option to explore here would be if MaxL/MinL could be implemented in terms of vectorized compare instructions, as shown above in the `longClippingRange` scenario. Thoughts @rwestrel @eme64?

# `VectorReduction2.WithSuperword` on AVX-512 machine

As requested by Emanuel I've also run this benchmark. Note that the results here are time per op, so the lower the number the better:


Benchmark                                         (SIZE)  (seed)  Mode  Cnt  Baseline     Patch  Units
VectorReduction2.WithSuperword.longMaxBig           2048       0  avgt    3  3970.527  1918.821  ns/op
VectorReduction2.WithSuperword.longMaxDotProduct    2048       0  avgt    3  1369.634  1055.762  ns/op
VectorReduction2.WithSuperword.longMaxSimple        2048       0  avgt    3   722.314  2172.064  ns/op
VectorReduction2.WithSuperword.longMinBig           2048       0  avgt    3  3996.694  1918.398  ns/op
VectorReduction2.WithSuperword.longMinDotProduct    2048       0  avgt    3  1363.687  1056.375  ns/op
VectorReduction2.WithSuperword.longMinSimple        2048       0  avgt    3   718.150  2179.478  ns/op


`long[Min|Max]Big` and `long[Min|Max]DotProduct` benchmarks show considerable improvements,
but something odd is happening in `long[Min|Max]Simple`.

### `long[Min|Max]Simple` performance drops considerably

Baseline uses compare + moves instructions:


   8.05%  ??      ???       ?    0x00007f9d580f569b:   movq		0x18(%r13, %r11, 8), %r8;*laload {reexecute=0 rethrow=0 return_oop=0}
          ??      ???       ?                                                              ; - org.openjdk.bench.vm.compiler.VectorReduction2::longMaxSimple at 22 (line 1054)
          ??      ???       ?                                                              ; - org.openjdk.bench.vm.compiler.jmh_generated.VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub at 17 (line 190)
   0.23%  ??      ???       ?    0x00007f9d580f56a0:   cmpq		%r8, %rsi
          ???     ???       ?    0x00007f9d580f56a3:   jl		0x7f9d580f5713      ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ???     ???       ?                                                              ; - java.lang.Math::max at 11 (line 2037)
          ???     ???       ?                                                              ; - org.openjdk.bench.vm.compiler.VectorReduction2::longMaxSimple at 28 (line 1055)
          ???     ???       ?                                                              ; - org.openjdk.bench.vm.compiler.jmh_generated.VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub at 17 (line 190)


Patched version uses conditional moves instead of vectorized instructions:


   2.76%  ??    0x00007fcd180f695c:   movq		0x18(%r14, %r11, 8), %rdi;*laload {reexecute=0 rethrow=0 return_oop=0}
          ??                                                              ; - org.openjdk.bench.vm.compiler.VectorReduction2::longMaxSimple at 22 (line 1054)
          ??                                                              ; - org.openjdk.bench.vm.compiler.jmh_generated.VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub at 17 (line 190)
          ??    0x00007fcd180f6961:   cmpq		%rdi, %r13
   3.11%  ??    0x00007fcd180f6964:   cmovlq		%rdi, %r13          ;*invokestatic max {reexecute=0 rethrow=0 return_oop=0}
          ??                                                              ; - org.openjdk.bench.vm.compiler.VectorReduction2::longMaxSimple at 28 (line 1055)
          ??                                                              ; - org.openjdk.bench.vm.compiler.jmh_generated.VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub at 17 (line 190)


Why are vectorized instructions not kicking in with patch? Because superword doesn't think it's profitable to vectorize this:


PackSet::print: 2 packs
 Pack: 0
    0:  733  LoadL  === 721 184 734  [[ 732 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8; #long (does not depend only on test, unknown control) !orig=669,500,[319] !jvms: VectorReduction2::longMaxSimple @ bci:22 (line 1054) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
    1:  728  LoadL  === 721 184 729  [[ 727 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8; #long (does not depend only on test, unknown control) !orig=500,[319] !jvms: VectorReduction2::longMaxSimple @ bci:22 (line 1054) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
    2:  669  LoadL  === 721 184 670  [[ 668 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8; #long (does not depend only on test, unknown control) !orig=500,[319] !jvms: VectorReduction2::longMaxSimple @ bci:22 (line 1054) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
    3:  500  LoadL  === 721 184 317  [[ 320 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8; #long (does not depend only on test, unknown control) !orig=[319] !jvms: VectorReduction2::longMaxSimple @ bci:22 (line 1054) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
 Pack: 1
    0:  732  MaxL  === _ 743 733  [[ 727 ]]  !orig=668,320,685 !jvms: VectorReduction2::longMaxSimple @ bci:28 (line 1055) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
    1:  727  MaxL  === _ 732 728  [[ 668 ]]  !orig=320,685 !jvms: VectorReduction2::longMaxSimple @ bci:28 (line 1055) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
    2:  668  MaxL  === _ 727 669  [[ 320 ]]  !orig=320,685 !jvms: VectorReduction2::longMaxSimple @ bci:28 (line 1055) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
    3:  320  MaxL  === _ 668 500  [[ 743 593 456 ]]  !orig=685 !jvms: VectorReduction2::longMaxSimple @ bci:28 (line 1055) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)

WARNING: Removed pack: not profitable:
    0:  732  MaxL  === _ 743 733  [[ 727 ]]  !orig=668,320,685 !jvms: VectorReduction2::longMaxSimple @ bci:28 (line 1055) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
    1:  727  MaxL  === _ 732 728  [[ 668 ]]  !orig=320,685 !jvms: VectorReduction2::longMaxSimple @ bci:28 (line 1055) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
    2:  668  MaxL  === _ 727 669  [[ 320 ]]  !orig=320,685 !jvms: VectorReduction2::longMaxSimple @ bci:28 (line 1055) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
    3:  320  MaxL  === _ 668 500  [[ 743 593 456 ]]  !orig=685 !jvms: VectorReduction2::longMaxSimple @ bci:28 (line 1055) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)

WARNING: Removed pack: not profitable:
    0:  733  LoadL  === 721 184 734  [[ 732 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8; #long (does not depend only on test, unknown control) !orig=669,500,[319] !jvms: VectorReduction2::longMaxSimple @ bci:22 (line 1054) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
    1:  728  LoadL  === 721 184 729  [[ 727 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8; #long (does not depend only on test, unknown control) !orig=500,[319] !jvms: VectorReduction2::longMaxSimple @ bci:22 (line 1054) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
    2:  669  LoadL  === 721 184 670  [[ 668 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8; #long (does not depend only on test, unknown control) !orig=500,[319] !jvms: VectorReduction2::longMaxSimple @ bci:22 (line 1054) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)
    3:  500  LoadL  === 721 184 317  [[ 320 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=8; #long (does not depend only on test, unknown control) !orig=[319] !jvms: VectorReduction2::longMaxSimple @ bci:22 (line 1054) VectorReduction2_WithSuperword_longMaxSimple_jmhTest::longMaxSimple_avgt_jmhStub @ bci:17 (line 190)

After Superword::filter_packs_for_profitable

PackSet::print: 0 packs

SuperWord::transform_loop failed: SuperWord::SLP_extract did not vectorize


How can you make it vectorize? By doing something with the value in the array before passing it to min/max. That is what `MinMaxVector.longReduction[Min|Max]` and `VectorReduction2.long[Min|Max]DotProduct` methods do.

# `VectorReduction2.NoSuperword` on AVX-512 machine


Benchmark                                       (SIZE)  (seed)  Mode  Cnt  Baseline     Patch  Units
VectorReduction2.NoSuperword.longMaxBig           2048       0  avgt    3  3964.403  2966.258  ns/op
VectorReduction2.NoSuperword.longMaxDotProduct    2048       0  avgt    3  1686.373  2462.876  ns/op
VectorReduction2.NoSuperword.longMaxSimple        2048       0  avgt    3   722.219  2171.859  ns/op
VectorReduction2.NoSuperword.longMinBig           2048       0  avgt    3  3994.685  2971.143  ns/op
VectorReduction2.NoSuperword.longMinDotProduct    2048       0  avgt    3  1366.291  2428.173  ns/op
VectorReduction2.NoSuperword.longMinSimple        2048       0  avgt    3   719.218  2179.546  ns/op


Performance improves or `long[Min|Max]Big`. `long[Min|Max]Simple` suffers similar issues as shown in previous section because when not vectorized, these benchmarks fallback on conditional moves. The drop in performance in `long[Min|Max]DotProduct` needs some explanation.

### `long[Min|Max]DotProduct` performance drops considerably

Baseline uses compare + move instructions here:


   5.67%  ??? ????  ?    0x00007f3fcc0fa71d:   movq		0x20(%r14, %r8, 8), %r9
   5.19%  ??? ????  ?    0x00007f3fcc0fa722:   imulq		0x20(%rax, %r8, 8), %r9;*lmul {reexecute=0 rethrow=0 return_oop=0}
          ??? ????  ?                                                              ; - org.openjdk.bench.vm.compiler.VectorReduction2::longMaxDotProduct at 30 (line 1125)
          ??? ????  ?                                                              ; - org.openjdk.bench.vm.compiler.jmh_generated.VectorReduction2_NoSuperword_longMaxDotProduct_jmhTest::longMaxDotProduct_avgt_jmhStub at 17 (line 190)
   8.46%  ??? ????  ?    0x00007f3fcc0fa728:   cmpq		%r9, %rsi
          ????????  ?    0x00007f3fcc0fa72b:   jl		0x7f3fcc0fa751      ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ????????  ?                                                              ; - java.lang.Math::max at 11 (line 2037)
          ????????  ?                                                              ; - org.openjdk.bench.vm.compiler.VectorReduction2::longMaxDotProduct at 36 (line 1126)
          ????????  ?                                                              ; - org.openjdk.bench.vm.compiler.jmh_generated.VectorReduction2_NoSuperword_longMaxDotProduct_jmhTest::longMaxDotProduct_avgt_jmhStub at 17 (line 190)


Patch transforms this into conditional moves:


  11.00%  ?  0x00007f66f40f70b2:   movq		0x18(%r13, %rcx, 8), %rax
          ?  0x00007f66f40f70b7:   imulq		0x18(%r9, %rcx, 8), %rax;*lmul {reexecute=0 rethrow=0 return_oop=0}
          ?                                                            ; - org.openjdk.bench.vm.compiler.VectorReduction2::longMaxDotProduct at 30 (line 1125)
          ?                                                            ; - org.openjdk.bench.vm.compiler.jmh_generated.VectorReduction2_NoSuperword_longMaxDotProduct_jmhTest::longMaxDotProduct_avgt_jmhStub at 17 (line 190)
          ?  0x00007f66f40f70bd:   cmpq		%rdx, %rax
  13.07%  ?  0x00007f66f40f70c0:   cmovlq		%rdx, %rax          ;*invokestatic max {reexecute=0 rethrow=0 return_oop=0}
          ?                                                            ; - org.openjdk.bench.vm.compiler.VectorReduction2::longMaxDotProduct at 36 (line 1126)
          ?                                                            ; - org.openjdk.bench.vm.compiler.jmh_generated.VectorReduction2_NoSuperword_longMaxDotProduct_jmhTest::longMaxDotProduct_avgt_jmhStub at 17 (line 190)


This is similar to what we have seen above. Lacking superword functionality, the fallback for MaxL/MinL implies using conditional moves. Although branch probabilities are not controlled here, we can observe that one of the branches is likely being taken ~100% of the time.

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2642788364

From coleenp at openjdk.org  Fri Feb  7 12:34:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 7 Feb 2025 12:34:40 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

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

  Fix jvmci test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22652/files
  - new: https://git.openjdk.org/jdk/pull/22652/files/304a17ee..37a8cf81

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

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

PR: https://git.openjdk.org/jdk/pull/22652

From galder at openjdk.org  Fri Feb  7 12:39:24 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 7 Feb 2025 12:39:24 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

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

 - Merge branch 'master' into topic.intrinsify-max-min-long
 - Fix typo
 - Renaming methods and variables and add docu on algorithms
 - Fix copyright years
 - Make sure it runs with cpus with either avx512 or asimd
 - Test can only run with 256 bit registers or bigger
   
   * Remove platform dependant check
   and use platform independent configuration instead.
 - Fix license header
 - Tests should also run on aarch64 asimd=true envs
 - Added comment around the assertions
 - Adjust min/max identity IR test expectations after changes
 - ... and 34 more: https://git.openjdk.org/jdk/compare/f56622ff...a190ae68

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/724a346a..a190ae68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=10-11

  Stats: 206462 lines in 5108 files changed: 101636 ins; 84099 del; 20727 mod
  Patch: https://git.openjdk.org/jdk/pull/20098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098

PR: https://git.openjdk.org/jdk/pull/20098

From clanger at openjdk.org  Fri Feb  7 13:17:33 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 7 Feb 2025 13:17:33 GMT
Subject: RFR: 8349648: Test tools/jpackage/share/JLinkOptionsTest.java fails
 with --enable-linkable-runtime set after JDK-8346434
Message-ID: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>

The change for JDK-8346434 added a new test case to tools/jpackage/share/JLinkOptionsTest.java which does not respect the constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be part of the target image.
This can be circumvented by limiting the modules.

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

Commit messages:
 - JDK-8349648

Changes: https://git.openjdk.org/jdk/pull/23514/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23514&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349648
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23514.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23514/head:pull/23514

PR: https://git.openjdk.org/jdk/pull/23514

From pminborg at openjdk.org  Fri Feb  7 13:19:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 7 Feb 2025 13:19:14 GMT
Subject: RFR: JDK-8348030 : Extend Math.min and Math.max to support
 multiple parameters [v2]
In-Reply-To: <sLi_7d1SZLsElDMHMx7R2s7KIFF8wUyZsXB3BCjiMdA=.324aeb77-2ca4-49bd-a336-80ff56c47776@github.com>
References: <vm1XCdlH9sOO4m4xx2T4Ir2Vx5Z7i2-2DA_7lAtJut8=.c81461cb-364a-4188-9027-8eb7aeaa0ca2@github.com>
 <nUsydSIjImuVTSAzRj1_0s9YMz0E3IGQmJ8G59FFgvI=.12edb0c6-e1ee-4a6e-9363-d4b0f2fa0204@github.com>
 <sLi_7d1SZLsElDMHMx7R2s7KIFF8wUyZsXB3BCjiMdA=.324aeb77-2ca4-49bd-a336-80ff56c47776@github.com>
Message-ID: <dY58hAQoB1QnYksE-7S_z8zB5QWc_byznAFIENnqbiE=.12594ff3-36da-41e6-9d5b-1d28fe3b4290@github.com>

On Mon, 20 Jan 2025 12:51:47 GMT, Aviad Zer <duke at openjdk.org> wrote:

>> Aviad Zer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Math.java by adding extended max function
>
>> Before dealing with a CSR, I suggest you socialize your idea/PR in the [core-libs-dev at openjdk.org](mailto:core-libs-dev at openjdk.org) mailing list. You could reference this PR in the initial mail.
> 
> Thanks for help, I'll do that

Thanks for socializing your idea @aviad1486 ! 

I think we should *not* integrate this PR and there are many reasons for that including, but not limited to:

 * There are easy ways to provide this kind of functionality outside the JDK.
 * We are not sure there is a need for this in the community.
 * Adding these overloads means we commit to supporting them in perpetuity.
 * There are works ongoing to intensify `Math::min` and `Math::max`. This means we'd have to do the same here.
 * There are replacements for many similar constructs (e.g. using a reduction of streams).
 * The reviewing capacity is limited and currently, we are focusing on major additions to the Java platforms (e.g. Valhalla).
 * It is not clear which other methods in `Math` (and `MathExact`) should be expanded in a similar way.
 * It is not clear what performance, escape analysis, and inline factors this would impact.

Languages such as Haskel support "infix" operators meaning you could write something like `a 'min' b 'min' c`. If such a feature would be available in Java in the distant future, then the use of the proposed methods would be reduced but we would still have to maintain them forever.

So, I strongly suggest that we should close this PR without integrating it. Thanks again @aviad1486 for your effort.

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

PR Comment: https://git.openjdk.org/jdk/pull/23138#issuecomment-2642878666

From jpai at openjdk.org  Fri Feb  7 13:20:11 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Feb 2025 13:20:11 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables
In-Reply-To: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
Message-ID: <rpmeuVno-fO-BTBVHPtN_NWSshW5HskgyIOLsxlEiF4=.60898745-8833-4542-8d3c-1a795a208b1f@github.com>

On Thu, 6 Feb 2025 19:46:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed.

src/java.base/share/native/libjli/args.c line 479:

> 477:     jboolean ret = JNI_FALSE;
> 478: 
> 479:     if (firstAppArgIndex != 0 && // If not 'java', return

Hello Naoto, this is a pre-existing thing, but since we are changing this part of the code, I think the checks for `firstAppArgIndex` and `relaunch` can be moved before the call to `getenv()` (and now before `winGetEnv()` too) since the syscall to `getenv()` wasn't anyway changing the state of `firstAppArgIndex` or `relaunch`. I think doing those checks before the call to fetch the env value will simplify the conditional check here a bit, in terms of readability.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1946511351

From jpai at openjdk.org  Fri Feb  7 13:43:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Feb 2025 13:43:10 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables
In-Reply-To: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
Message-ID: <LDGLVVlMYcO1OFb_iVawEXJ7wR9UBKyjm_z6QY70C3U=.9de25135-e4a6-4013-b77a-f4a0738f8521@github.com>

On Thu, 6 Feb 2025 19:46:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed.

src/java.base/share/native/libjli/args.c line 472:

> 470: JLI_AddArgsFromEnvVar(JLI_List args, const char *var_name) {
> 471: #ifdef _WIN32
> 472:     char *env = winGetEnv(var_name);

I see that we are limiting this call to use `_wgetenv()` (the wide-character version of `getenv()`) only to `_WIN32`. Is there any harm in using `_wgetenv()` even for `_WIN64`? Or is the `getenv()` implementation on `_WIN64` not susceptible to the issues noted in the JBS?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1946542097

From jpai at openjdk.org  Fri Feb  7 14:45:11 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Feb 2025 14:45:11 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables
In-Reply-To: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
Message-ID: <ZHcK546du7wd_m5LHjU9iOvBeqyQMSUxsJpV-yEIyvc=.f6b327c5-b48e-454e-af33-fb8d303fa967@github.com>

On Thu, 6 Feb 2025 19:46:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed.

In (the Windows specific) `src/java.base/windows/native/libjli/cmdtoargs.c` there's an additional call to lookup (a different) `_JAVA_OPTIONS` environment variable through `getenv()` just to log out that environment variable's value. Should we replace that call to `getenv()` with `winGetEnv()` too?

And on a more general note, should the calls to `getenv()` in the launcher's native code (for example, For example, the `getenv("CLASSPATH")`) be re-examined in context of this issue and have it replaced with this alternative?

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

PR Comment: https://git.openjdk.org/jdk/pull/23498#issuecomment-2643130961

From duke at openjdk.org  Fri Feb  7 14:46:11 2025
From: duke at openjdk.org (Aviad Zer)
Date: Fri, 7 Feb 2025 14:46:11 GMT
Subject: RFR: JDK-8348030 : Extend Math.min and Math.max to support
 multiple parameters [v2]
In-Reply-To: <nUsydSIjImuVTSAzRj1_0s9YMz0E3IGQmJ8G59FFgvI=.12edb0c6-e1ee-4a6e-9363-d4b0f2fa0204@github.com>
References: <vm1XCdlH9sOO4m4xx2T4Ir2Vx5Z7i2-2DA_7lAtJut8=.c81461cb-364a-4188-9027-8eb7aeaa0ca2@github.com>
 <nUsydSIjImuVTSAzRj1_0s9YMz0E3IGQmJ8G59FFgvI=.12edb0c6-e1ee-4a6e-9363-d4b0f2fa0204@github.com>
Message-ID: <YcdkxMh2jzQbSB6UQvykQvzNqWkQPE1nipTG3iQgpMY=.347d0998-91fb-4391-a208-d4a9ac4b22b5@github.com>

On Mon, 20 Jan 2025 11:43:13 GMT, Aviad Zer <duke at openjdk.org> wrote:

>> This change extends the Math.min function to support multiple parameters, improving its usability and code readability.
>> 
>> Previously, finding the minimum value among multiple variables required using nested Math.min calls or converting the variables into an array and iterating through it. This enhancement provides a more intuitive and straightforward approach to achieve the same result.
>> 
>> Benefits:
>> 
>> Simplifies code by eliminating the need for nested Math.min calls.
>> Enhances readability, especially when comparing multiple values.
>> Offers consistency with existing Math.min usage patterns.
>
> Aviad Zer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Math.java by adding extended max function

Can you please keep the PR? I'm still working on it

?????? ??? ??, 7 ????? 2025, 15:16, ??? Per-Ake Minborg ?<
***@***.***>:

> Thanks for socializing your idea @aviad1486 <https://github.com/aviad1486>
> !
>
> I think we should *not* integrate this PR and there are many reasons for
> that including, but not limited to:
>
>    - There are easy ways to provide this kind of functionality outside
>    the JDK.
>    - We are not sure there is a need for this in the community.
>    - Adding these overloads means we commit to supporting them in
>    perpetuity.
>    - There are works ongoing to intensify Math::min and Math::max. This
>    means we'd have to do the same here.
>    - There are replacements for many similar constructs (e.g. using a
>    reduction of streams).
>    - The reviewing capacity is limited and currently, we are focusing on
>    major additions to the Java platforms (e.g. Valhalla).
>    - It is not clear which other methods in Math (and MathExact) should
>    be expanded in a similar way.
>    - It is not clear what performance, escape analysis, and inline
>    factors this would impact.
>
> Languages such as Haskel support "infix" operators meaning you could write
> something like a 'min' b 'min' c. If such a feature would be available in
> Java in the distant future, then the use of the proposed methods would be
> reduced but we would still have to maintain them forever.
>
> So, I strongly suggest that we should close this PR without integrating
> it. Thanks again @aviad1486 <https://github.com/aviad1486> for your
> effort.
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/23138#issuecomment-2642878666>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/BEHBFNK742B4HJSYSAB4YQL2OSW2ZAVCNFSM6AAAAABVHL4VJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBSHA3TQNRWGY>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/23138#issuecomment-2643132031

From asemenyuk at openjdk.org  Fri Feb  7 14:50:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 7 Feb 2025 14:50:09 GMT
Subject: RFR: 8349648: Test tools/jpackage/share/JLinkOptionsTest.java
 fails with --enable-linkable-runtime set after JDK-8346434
In-Reply-To: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
References: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
Message-ID: <YnT5hz7p_bm5eH0DbOS-qZPmwnT21VOhfe1v6o5uM2M=.c2b05385-2a9e-4518-9c37-88e6396178d1@github.com>

On Fri, 7 Feb 2025 13:13:24 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The change for JDK-8346434 added a new test case to tools/jpackage/share/JLinkOptionsTest.java which does not respect the constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be part of the target image.
> This can be circumvented by limiting the modules.

Marked as reviewed by asemenyuk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23514#pullrequestreview-2601938477

From jpai at openjdk.org  Fri Feb  7 15:10:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Feb 2025 15:10:13 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v6]
In-Reply-To: <MEaVh56gQqp2517Z7lF9JHRj45sEbNSfqq1vt-brOYU=.145a5b62-0e0a-437f-a21f-87ad700e860f@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
 <MEaVh56gQqp2517Z7lF9JHRj45sEbNSfqq1vt-brOYU=.145a5b62-0e0a-437f-a21f-87ad700e860f@github.com>
Message-ID: <GP1A8uvU2bpTUwuPHIdEJUtcnMSkMrBhivhB6bppTnU=.19a898fa-7057-4ee5-be2e-01b4841e710e@github.com>

On Tue, 4 Feb 2025 14:26:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
>> 
>> 
>> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
>> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
>> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
>> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
>> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
>> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
>> 
>> 
>> **Other highlights:**
>> 
>> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
>> - `test.lib.Asserts::assertFileContentsEqual` is added
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing `assertFileContentsEqual` replacement to `FixedThreadPoolTest`

The updated changes look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23401#pullrequestreview-2601992489

From pminborg at openjdk.org  Fri Feb  7 15:30:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 7 Feb 2025 15:30:39 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno
Message-ID: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>

Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.

Hence, this PR proposes to add a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.

It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.

Here are some benchmarks that ran on a platform thread and virtual threads respectively:


Benchmark                                                  Mode  Cnt   Score   Error  Units
CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.193 ? 0.268  ns/op
CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.268 ? 0.080  ns/op
CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  42.076 ? 1.003  ns/op
CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.801 ? 0.138  ns/op
CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.265 ? 0.087  ns/op
CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.285 ? 0.155  ns/op

CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.033 ? 0.423  ns/op
CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   3.676 ? 0.104  ns/op  // <- Happy path using an internal pool

CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.023 ? 0.736  ns/op
CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  22.013 ? 0.648  ns/op  // <- Allocating memory upon each invocation

CaptureStateUtilBench.tlAllocationFail                     avgt   30  22.050 ? 0.233  ns/op
CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   3.756 ? 0.056  ns/op  // <- Using the pool explicitly from Java code


Adapted system call:


        return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool


Explicit allocation:


        try (var arena = Arena.ofConfined()) {
            return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
        }


Thread Local allocation:


        try (var arena = POOLS.take()) {
            return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
        }


The adapted system call exhibits a ~6x performance improvement over the existing "explicit allocation" scheme for the happy path on platform threads. Because there needs to be sharing across threads for virtual-tread-capable carrier threads, these are a bit slower ("only" ~2.5x faster).

Tested and passed tiers 1-3.

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

Commit messages:
 - Bump copyright year
 - Add benchmarks
 - Add method handle adapter for system calls

Changes: https://git.openjdk.org/jdk/pull/23517/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23517&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347408
  Stats: 1381 lines in 11 files changed: 1370 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23517/head:pull/23517

PR: https://git.openjdk.org/jdk/pull/23517

From kcr at openjdk.org  Fri Feb  7 15:34:34 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Feb 2025 15:34:34 GMT
Subject: [jdk24] RFR: 8347302: Mark test tools/jimage/JImageToolTest.java
 as flagless
In-Reply-To: <7dooar8_-8E_DBbaSltN1pexdsG3IeltgxU6wS0Q9P0=.c376b363-9d5d-4d87-969e-3999b02fc0c8@github.com>
References: <7dooar8_-8E_DBbaSltN1pexdsG3IeltgxU6wS0Q9P0=.c376b363-9d5d-4d87-969e-3999b02fc0c8@github.com>
Message-ID: <1gdr3GBUCdqspBEkg6OeIoSgeMOGiaqGAdbWem1ZHJo=.c488f11e-d529-44ea-8cbc-e07362df3413@github.com>

On Mon, 13 Jan 2025 02:59:52 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e7e8f60c](https://github.com/openjdk/jdk/commit/e7e8f60c9bedd5622525cc4339300b438eedc9fd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24.
> 
> Test test/jdk/tools/jimage/JImageToolTest.java ignore vm flags and should be marked as flagless. Test-fix only, no risk.
> 
> Thanks!

As we are now in the [Release Candidate phase of JDK 24](https://openjdk.org/projects/jdk/24/), this fix is no longer suitable for JDK 24. See [JEP 3](https://openjdk.org/jeps/3) for more information.

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

PR Comment: https://git.openjdk.org/jdk/pull/23058#issuecomment-2643256756

From kcr at openjdk.org  Fri Feb  7 15:34:34 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Feb 2025 15:34:34 GMT
Subject: [jdk24] Withdrawn: 8347302: Mark test tools/jimage/JImageToolTest.java
 as flagless
In-Reply-To: <7dooar8_-8E_DBbaSltN1pexdsG3IeltgxU6wS0Q9P0=.c376b363-9d5d-4d87-969e-3999b02fc0c8@github.com>
References: <7dooar8_-8E_DBbaSltN1pexdsG3IeltgxU6wS0Q9P0=.c376b363-9d5d-4d87-969e-3999b02fc0c8@github.com>
Message-ID: <3YRWZ4SJF_x7HFjaHVpOSzf8Sl1AUL4y-qhGopRDTz8=.380e55a7-e982-4424-8889-99117e9da017@github.com>

On Mon, 13 Jan 2025 02:59:52 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e7e8f60c](https://github.com/openjdk/jdk/commit/e7e8f60c9bedd5622525cc4339300b438eedc9fd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24.
> 
> Test test/jdk/tools/jimage/JImageToolTest.java ignore vm flags and should be marked as flagless. Test-fix only, no risk.
> 
> Thanks!

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/23058

From archie.cobbs at gmail.com  Fri Feb  7 15:42:48 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 7 Feb 2025 09:42:48 -0600
Subject: RFR: 8315585: Optimization for decimal to string [v4]
In-Reply-To: <OuPjhqT8MhzedE6GjsbHHh2WgmRIyGdgmtgYQ2yta6I=.b2d4ee54-4b4c-4ed0-95e7-4bab92666d50@github.com>
References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
 <JENdZLiCWbHnkdjyhqKGyjZxHcq2byLXXj1YRwi_X18=.a94901e5-cc33-4aa8-8f89-16a4fdb9c361@github.com>
 <OuPjhqT8MhzedE6GjsbHHh2WgmRIyGdgmtgYQ2yta6I=.b2d4ee54-4b4c-4ed0-95e7-4bab92666d50@github.com>
Message-ID: <CANSoFxtJre6tcYNmSzWYaKyZw81rcQHfcJQV_TA36wu09HPzwg@mail.gmail.com>

On Tue, Feb 4, 2025 at 5:26?PM Shaojin Wen <swen at openjdk.org> wrote:

> I think you are talking about the problem of PR #23420, which is caused by
> the use of thread-unsafe StringBuilder in multi-threaded scenarios. This
> problem is very obscure and I didn't consider it before. I have started to
> solve this problem and have submitted PR #23427. After it is completed, I
> will continue to submit PR to redo PR #19626 in a thread-safe way.
>

Yes - apologies if it sounded like I was trying to single you out. The
optimizations you've been doing are looking great. It's just that this
example is a good data point in the larger discussion about what the
general policy should be, etc.


> The above problem does not affect toString, because it only occurs when
> StringBuilder is used in a multi-threaded scenario.
>

Good point, but frankly, an irrelevant one. The key issue here is that if
plain, ordinary, non-native-invoking Java bytecode can corrupt memory
and/or crash the JVM, then that's a Big Problem??. It doesn't matter how
contrived the code that makes it happen is.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250207/67028683/attachment.htm>

From sgehwolf at openjdk.org  Fri Feb  7 16:51:12 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 7 Feb 2025 16:51:12 GMT
Subject: RFR: 8349648: Test tools/jpackage/share/JLinkOptionsTest.java
 fails with --enable-linkable-runtime set after JDK-8346434
In-Reply-To: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
References: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
Message-ID: <h8CnqRPapIeSl5dP_GYMdlkkJGn1Vbld2dhG0kS-Z20=.0759ff70-57f5-46fb-ae34-2f86eca67023@github.com>

On Fri, 7 Feb 2025 13:13:24 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The change for JDK-8346434 added a new test case to tools/jpackage/share/JLinkOptionsTest.java which does not respect the constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be part of the target image.
> This can be circumvented by limiting the modules.

test/jdk/tools/jpackage/share/JLinkOptionsTest.java line 145:

> 143:     public void testNoBindServicesByDefault() {
> 144:         final var defaultModules = getModulesInRuntime("--limit-modules java.smartcardio,jdk.crypto.cryptoki,java.desktop");
> 145:         final var modulesWithBindServices = getModulesInRuntime("--bind-services --limit-modules java.smartcardio,jdk.crypto.cryptoki,java.desktop");

Pre-existing: It would be good to document which additional modules in the set get dragged in by `--bind-services`. That would allow future readers of that test to figure out why a test starts to fail (e.g. by a future change removing a provided service in a module).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23514#discussion_r1946847340

From sgehwolf at openjdk.org  Fri Feb  7 17:11:15 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 7 Feb 2025 17:11:15 GMT
Subject: RFR: 8349648: Test tools/jpackage/share/JLinkOptionsTest.java
 fails with --enable-linkable-runtime set after JDK-8346434
In-Reply-To: <h8CnqRPapIeSl5dP_GYMdlkkJGn1Vbld2dhG0kS-Z20=.0759ff70-57f5-46fb-ae34-2f86eca67023@github.com>
References: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
 <h8CnqRPapIeSl5dP_GYMdlkkJGn1Vbld2dhG0kS-Z20=.0759ff70-57f5-46fb-ae34-2f86eca67023@github.com>
Message-ID: <WGIslGt3gPmQn1wfkL4CswaKfBvSDnrxBhvwtKF06Js=.18597f47-d3ce-4bed-ba23-c4ccb035a4cf@github.com>

On Fri, 7 Feb 2025 16:48:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The change for JDK-8346434 added a new test case to tools/jpackage/share/JLinkOptionsTest.java which does not respect the constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be part of the target image.
>> This can be circumvented by limiting the modules.
>
> test/jdk/tools/jpackage/share/JLinkOptionsTest.java line 145:
> 
>> 143:     public void testNoBindServicesByDefault() {
>> 144:         final var defaultModules = getModulesInRuntime("--limit-modules java.smartcardio,jdk.crypto.cryptoki,java.desktop");
>> 145:         final var modulesWithBindServices = getModulesInRuntime("--bind-services --limit-modules java.smartcardio,jdk.crypto.cryptoki,java.desktop");
> 
> Pre-existing: It would be good to document which additional modules in the set get dragged in by `--bind-services`. That would allow future readers of that test to figure out why a test starts to fail (e.g. by a future change removing a provided service in a module).

As far as my testing is concerned it's only `jdk.crypto.cryptoki` which is different with `--bind-services` (as it provides a security provider as a service and doesn't export API).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23514#discussion_r1946877904

From jlu at openjdk.org  Fri Feb  7 17:11:24 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Feb 2025 17:11:24 GMT
Subject: Integrated: 8349493: Replace sun.util.locale.ParseStatus usage with
 java.text.ParsePosition
In-Reply-To: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
References: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
Message-ID: <vukQXZryDb8I1yahT2wd47a5S4pP_LhobnCyu59p4Pw=.47cd88a3-9732-4e94-9ae7-d29eccfe6370@github.com>

On Wed, 5 Feb 2025 21:25:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes  _sun.util.locale.ParseStatus_ which is a Locale helper class used for parsing language tags.
> 
> Such usages should be replaced by _java.text.ParsePosition_ which has almost 1 to 1 behavior. Note that this cleanup changes the exception message in `Locale.caseFoldLanguageTag(String)` to no longer be prepended by `"Ill formed tag: "`. As such, a CSR is filed to address the compatibility aspect.

This pull request has now been integrated.

Changeset: fb847bb2
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb847bb2afc9e9e164430078c5c403ec6583d50e
Stats:     137 lines in 3 files changed: 12 ins; 78 del; 47 mod

8349493: Replace sun.util.locale.ParseStatus usage with java.text.ParsePosition

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/23474

From asemenyuk at openjdk.org  Fri Feb  7 17:46:17 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 7 Feb 2025 17:46:17 GMT
Subject: RFR: 8349648: Test tools/jpackage/share/JLinkOptionsTest.java
 fails with --enable-linkable-runtime set after JDK-8346434
In-Reply-To: <WGIslGt3gPmQn1wfkL4CswaKfBvSDnrxBhvwtKF06Js=.18597f47-d3ce-4bed-ba23-c4ccb035a4cf@github.com>
References: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
 <h8CnqRPapIeSl5dP_GYMdlkkJGn1Vbld2dhG0kS-Z20=.0759ff70-57f5-46fb-ae34-2f86eca67023@github.com>
 <WGIslGt3gPmQn1wfkL4CswaKfBvSDnrxBhvwtKF06Js=.18597f47-d3ce-4bed-ba23-c4ccb035a4cf@github.com>
Message-ID: <n-amuJVmNcDNz42toirFgpD9dR6W_rnfGRMx8R5b7TU=.d73757b7-152c-4287-a3d9-b030ea23881a@github.com>

On Fri, 7 Feb 2025 17:08:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/jdk/tools/jpackage/share/JLinkOptionsTest.java line 145:
>> 
>>> 143:     public void testNoBindServicesByDefault() {
>>> 144:         final var defaultModules = getModulesInRuntime("--limit-modules java.smartcardio,jdk.crypto.cryptoki,java.desktop");
>>> 145:         final var modulesWithBindServices = getModulesInRuntime("--bind-services --limit-modules java.smartcardio,jdk.crypto.cryptoki,java.desktop");
>> 
>> Pre-existing: It would be good to document which additional modules in the set get dragged in by `--bind-services`. That would allow future readers of that test to figure out why a test starts to fail (e.g. by a future change removing a provided service in a module).
>
> As far as my testing is concerned it's only `jdk.crypto.cryptoki` which is different with `--bind-services` (as it provides a security provider as a service and doesn't export API).

This is the diff of modules between "jpackage without --bind-services" and "jpackage with --bind-services" before this PR:

[20:27:10.849] TRACE: assertNotEquals(, jdk.charsets,jdk.crypto.cryptoki,jdk.crypto.mscapi,jdk.editpad,jdk.jdeps,jdk.jlink,jdk.jpackage,jdk.jstatd,jdk.localedata,jdk.naming.dns,jdk.naming.rmi): Check '--bind-services' option adds modules

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23514#discussion_r1946924600

From sviswanathan at openjdk.org  Fri Feb  7 17:53:16 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 7 Feb 2025 17:53:16 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v5]
In-Reply-To: <iM9vtfQfDcasU0MRo3s7tqumBaSXt9Iupiaj_e_Haps=.b0642339-ecba-41f3-84be-7a71e65f2798@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <iM9vtfQfDcasU0MRo3s7tqumBaSXt9Iupiaj_e_Haps=.b0642339-ecba-41f3-84be-7a71e65f2798@github.com>
Message-ID: <Ko77AneV_bi8aYXkLbNYokRNPTbmbvca_mUFsAZv_tQ=.f3bef7d0-7f50-44b5-a6a1-04ba2eaed43a@github.com>

On Mon, 3 Feb 2025 21:43:56 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>> 
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
>> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
>> 
>> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
>> 
>> 
>> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
>> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
>> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
>> 
>> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
>> 
>> ---
>> 
>> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 2393:

> 2391:   stmxcsr(mxcsr_save);
> 2392:   movl(tmp, mxcsr_save);
> 2393:   // Mask out any pending exceptions (only check control and mask bits)

This comment should go on the else path and could be changed to "Mask out status bits (only check control and mask bits)"

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 2396:

> 2394:   if (EnableX86ECoreOpts) {
> 2395:     // On Ecore, status bits are set by default (for performance)
> 2396:     orl(tmp, 0x003f);  // On Ecore, exception bits are set by default

Duplication in comment.  Comment could be modified to reflect something like "The mxcsr_std has status bits set for performance on ECore"

src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 183:

> 181:     jint MxCsr = INITIAL_MXCSR; // set to 0x1f80` in winnt.h
> 182:     if (EnableX86ECoreOpts) {
> 183:       // On ECore, restore with signaling flags enabled

Change comment to // On ECore restore with status bits enabled.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22673#discussion_r1946911130
PR Review Comment: https://git.openjdk.org/jdk/pull/22673#discussion_r1946915061
PR Review Comment: https://git.openjdk.org/jdk/pull/22673#discussion_r1946934759

From duke at openjdk.org  Fri Feb  7 18:14:12 2025
From: duke at openjdk.org (duke)
Date: Fri, 7 Feb 2025 18:14:12 GMT
Subject: RFR: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
 [v6]
In-Reply-To: <MEaVh56gQqp2517Z7lF9JHRj45sEbNSfqq1vt-brOYU=.145a5b62-0e0a-437f-a21f-87ad700e860f@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
 <MEaVh56gQqp2517Z7lF9JHRj45sEbNSfqq1vt-brOYU=.145a5b62-0e0a-437f-a21f-87ad700e860f@github.com>
Message-ID: <W99kQ14gQU55djGYV6Ec1GkZ5q019trd8QBtYJNLB1o=.88172217-c2a9-4f17-8038-d29ff6f476c8@github.com>

On Tue, 4 Feb 2025 14:26:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
>> 
>> 
>> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
>> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
>> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
>> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
>> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
>> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
>> 
>> 
>> **Other highlights:**
>> 
>> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
>> - `test.lib.Asserts::assertFileContentsEqual` is added
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing `assertFileContentsEqual` replacement to `FixedThreadPoolTest`

@vy 
Your change (at version 5e9b30f431676c714cf81b85846f16c58c0dcdf6) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23401#issuecomment-2643664263

From naoto at openjdk.org  Fri Feb  7 18:32:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Feb 2025 18:32:26 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables [v2]
In-Reply-To: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
Message-ID: <qhINoIIT466GCrjA3xHQnJZ6AhkvifGcWYva0qgFLFA=.9eecd1c7-66bc-4d64-b6e9-24bb0797eb3b@github.com>

> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed.

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

  Reflects review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23498/files
  - new: https://git.openjdk.org/jdk/pull/23498/files/48aa31a7..5a00388e

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

  Stats: 12 lines in 1 file changed: 9 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23498/head:pull/23498

PR: https://git.openjdk.org/jdk/pull/23498

From naoto at openjdk.org  Fri Feb  7 18:42:20 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Feb 2025 18:42:20 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables [v2]
In-Reply-To: <LDGLVVlMYcO1OFb_iVawEXJ7wR9UBKyjm_z6QY70C3U=.9de25135-e4a6-4013-b77a-f4a0738f8521@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
 <LDGLVVlMYcO1OFb_iVawEXJ7wR9UBKyjm_z6QY70C3U=.9de25135-e4a6-4013-b77a-f4a0738f8521@github.com>
Message-ID: <-JPSYAwiOS_4E9GMZTKv--ju4PFGGoX_oH5Laxk4uMc=.b7439475-673a-4aed-a7b6-44fa4c3116dc@github.com>

On Fri, 7 Feb 2025 13:41:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review
>
> src/java.base/share/native/libjli/args.c line 472:
> 
>> 470: JLI_AddArgsFromEnvVar(JLI_List args, const char *var_name) {
>> 471: #ifdef _WIN32
>> 472:     char *env = winGetEnv(var_name);
> 
> I see that we are limiting this call to use `_wgetenv()` (the wide-character version of `getenv()`) only to `_WIN32`. Is there any harm in using `_wgetenv()` even for `_WIN64`? Or is the `getenv()` implementation on `_WIN64` not susceptible to the issues noted in the JBS?

The macro name is confusing, but `_WIN32` means Win32 API set and does not specify the target platform. This link (https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170) reads


_WIN32 Defined as 1 when the compilation target is 32-bit ARM, 64-bit ARM, x86, or x64. Otherwise, undefined.


So I believen `_WIN32` is correct here.

> src/java.base/share/native/libjli/args.c line 479:
> 
>> 477:     jboolean ret = JNI_FALSE;
>> 478: 
>> 479:     if (firstAppArgIndex != 0 && // If not 'java', return
> 
> Hello Naoto, this is a pre-existing thing, but since we are changing this part of the code, I think the checks for `firstAppArgIndex` and `relaunch` can be moved before the call to `getenv()` (and now before `winGetEnv()` too) since the syscall to `getenv()` wasn't anyway changing the state of `firstAppArgIndex` or `relaunch`. I think doing those checks before the call to fetch the env value will simplify the conditional check here a bit, in terms of readability.

Thanks Jai. That is a good point. Moved those checks before winGetEnv().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1946998326
PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1946998307

From naoto at openjdk.org  Fri Feb  7 18:45:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Feb 2025 18:45:10 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables
In-Reply-To: <ZHcK546du7wd_m5LHjU9iOvBeqyQMSUxsJpV-yEIyvc=.f6b327c5-b48e-454e-af33-fb8d303fa967@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
 <ZHcK546du7wd_m5LHjU9iOvBeqyQMSUxsJpV-yEIyvc=.f6b327c5-b48e-454e-af33-fb8d303fa967@github.com>
Message-ID: <6PQSLmZ9okO97NEKmvoiQBIO3y2Bq1mr1KeZOYIhHKU=.e0bb3458-2e39-45b8-9b13-1b9fee749b5a@github.com>

On Fri, 7 Feb 2025 14:42:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> In (the Windows specific) `src/java.base/windows/native/libjli/cmdtoargs.c` there's an additional call to lookup (a different) `_JAVA_OPTIONS` environment variable through `getenv()` just to log out that environment variable's value. Should we replace that call to `getenv()` with `winGetEnv()` too?

It is a debug code and simply log out the environment variables (as you pointed out), I think it is OK to leave it as it is.

> And on a more general note, should the calls to `getenv()` in the launcher's native code (for example, For example, the `getenv("CLASSPATH")`) be re-examined in context of this issue and have it replaced with this alternative?

I skimmed through all the `getenv()`s in the launcher, and I don't see other occurrences require this special handling. They all simply fails (as expected). I believe ones that are used for command line arguments are relevant in this case.

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

PR Comment: https://git.openjdk.org/jdk/pull/23498#issuecomment-2643714733

From coleenp at openjdk.org  Fri Feb  7 19:16:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 7 Feb 2025 19:16:13 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
Message-ID: <lE8Fzktp5eGkcXgqGo9BX2XZ-7nP2_63aoED1jxBbtk=.8dcfa9e0-c8a8-4922-937e-fdb22ee84c95@github.com>

On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jvmci test.

I added some code to hide the Class.modifiers field and fixed the JVMCI test. Please re-review.

Also @iwanowww I think the intrinsic for isInterface can be removed and just be Java code like:


public boolean isInterface()  {
  return getModifiers().isInterface();
}

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2643799984

From jlu at openjdk.org  Fri Feb  7 19:21:14 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Feb 2025 19:21:14 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables [v2]
In-Reply-To: <qhINoIIT466GCrjA3xHQnJZ6AhkvifGcWYva0qgFLFA=.9eecd1c7-66bc-4d64-b6e9-24bb0797eb3b@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
 <qhINoIIT466GCrjA3xHQnJZ6AhkvifGcWYva0qgFLFA=.9eecd1c7-66bc-4d64-b6e9-24bb0797eb3b@github.com>
Message-ID: <63AfV3MGoeAb4h6lPx5cRlFU-ECOwwnTcPFBczmDHb8=.89f6d5b3-28ca-402d-ae51-1aca7977468d@github.com>

On Fri, 7 Feb 2025 18:32:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review

Logic to get the UTF-16 string env value, and map back to a code page string looks good to me. All conversions are done with the `WC_NO_BEST_FIT_CHARS` flag, so indeed there should be no best-fit mappings done. All the failure checks on the return values of `MultiByteToWideChar` and `WideCharToMultiByte` look appropriate as well.

I left a few comments.

src/java.base/share/native/libjli/args.c line 603:

> 601: /*
> 602:  * getenv() without best-fit mapping
> 603:  */

I think a quick comment that says something along the lines of 


env variable name: code page -> UTF-16 
variable value : UTF-16 -> code page


would be helpful to overview what is happening here.

src/java.base/share/native/libjli/args.c line 611:

> 609:         LPWSTR wcVarName = JLI_MemAlloc(wcCount * sizeof(wchar_t));
> 610:         if (MultiByteToWideChar(CP_ACP, 0, var_name, -1, wcVarName, wcCount) != 0) {
> 611:             LPWSTR wcEnvVar = _wgetenv(wcVarName);

Since we are in Windows specific code, would it make sense to call `GetEnvironmentVariableW` over `_wgetenv`? It won't be as concise since we will have to follow the 2-call style of determining the size, then filling the buffer; but I presume it avoids some overhead, since it's directly apart of the Win32 API? I am also guessing it's the convention for Windows native code, although I'm not fully sure.

test/jdk/tools/launcher/DisableBestFitMappingTest.java line 32:

> 30:  * @requires (os.family == "windows")
> 31:  * @library /test/lib
> 32:  * @run junit DisableBestFitMappingTest

I think it might be best to re-write this test as a non Junit test. Through IntelliJ it's hard to run this test, I presume because of the combination of it being a Junit test and having a `main` method? If I run the 'launcher' suite of tests, this test does not seem to be included.

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

PR Review: https://git.openjdk.org/jdk/pull/23498#pullrequestreview-2602530119
PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947013548
PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1946999296
PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947024510

From liach at openjdk.org  Fri Feb  7 19:44:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Feb 2025 19:44:20 GMT
Subject: RFR: 8349624: Validation for slot missing in CodeBuilder local
 variable instructions
Message-ID: <fI6Ex768gvhUYXMDTqPDAHL0uGHxxVwYhwQRqKtYTCg=.64b662b0-7724-42f6-82e7-08dadb62e674@github.com>

In CodeBuilder, validation for a slot was missing due to concurrent patches, and the original patch did not add effective tests for CodeBuilder because of the complex exceptional behaviors. Now the bug is fixed with renames to prevent future risky usages, and the tests have been enhanced to ensure at least the failure-case behavior (while the non-failure case is harder to check due to exceptional behaviors)

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

Commit messages:
 - 8349624: Validation for slot missing in CodeBuilder local variable instructions

Changes: https://git.openjdk.org/jdk/pull/23522/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23522&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349624
  Stats: 61 lines in 2 files changed: 38 ins; 1 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/23522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23522/head:pull/23522

PR: https://git.openjdk.org/jdk/pull/23522

From vlivanov at openjdk.org  Fri Feb  7 19:47:12 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 7 Feb 2025 19:47:12 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
Message-ID: <RwOpQ-TzMSazfLgxqUZ5fJcdzBmOHvhfgnelely73SQ=.0dbfb18a-98d1-4342-b897-1d99900fb3ec@github.com>

On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jvmci test.

Marked as reviewed by vlivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2602686659

From vlivanov at openjdk.org  Fri Feb  7 20:01:27 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 7 Feb 2025 20:01:27 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <lE8Fzktp5eGkcXgqGo9BX2XZ-7nP2_63aoED1jxBbtk=.8dcfa9e0-c8a8-4922-937e-fdb22ee84c95@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
 <lE8Fzktp5eGkcXgqGo9BX2XZ-7nP2_63aoED1jxBbtk=.8dcfa9e0-c8a8-4922-937e-fdb22ee84c95@github.com>
Message-ID: <Hai1knECYXvemIZZ5utF6G7XsGtjf7VH4wySvU6WT4s=.40d63bbb-4a91-4983-9921-82d963f8ead8@github.com>

On Fri, 7 Feb 2025 19:13:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I think the intrinsic for isInterface can be removed

Good point. Moreover, it seems most of intrinsics on Class queries can be replaced with a flag bit check on the mirror. (Do we have 16 unused bits in Class::modifiers after this change?)

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2643997479

From almatvee at openjdk.org  Fri Feb  7 20:01:30 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 7 Feb 2025 20:01:30 GMT
Subject: Integrated: 8349509: [macos] Clean up macOS dead code in jpackage
In-Reply-To: <BDlttZM2kOvZJFNYxcYe43NfGZjq3YXpQ9-zW3AfOVc=.bb3eb6e7-62fb-4eab-aab3-069aca0cc5c0@github.com>
References: <BDlttZM2kOvZJFNYxcYe43NfGZjq3YXpQ9-zW3AfOVc=.bb3eb6e7-62fb-4eab-aab3-069aca0cc5c0@github.com>
Message-ID: <jSt9xmXCoaW3JUJt_8gWd054-anYZFgmsdSgHRadmSo=.799af936-92bf-43b5-8d40-0c2e76d72054@github.com>

On Thu, 6 Feb 2025 23:19:16 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Removed unused `INSTALLER_SUFFIX` bundler param.
> - Removed unreachable if branch in `MacAppImageBuilder`.

This pull request has now been integrated.

Changeset: f0ea38b3
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0ea38b3874ac627766768cbcd13f4be68c53797
Stats:     27 lines in 3 files changed: 1 ins; 20 del; 6 mod

8349509: [macos] Clean up macOS dead code in jpackage

Reviewed-by: asemenyuk

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

PR: https://git.openjdk.org/jdk/pull/23504

From naoto at openjdk.org  Fri Feb  7 20:05:49 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Feb 2025 20:05:49 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables [v3]
In-Reply-To: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
Message-ID: <EK6n63VyKwdmaAgLsAmV9IEjv0NV8HGNXVnyna7S-K4=.87fe6c89-cb86-4f94-ab55-f11827b3f56e@github.com>

> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed.

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

 - Reflects review
 - Merge branch 'master' into JDK-8349254-disable-best-fit-env-vars
 - Reflects review
 - initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23498/files
  - new: https://git.openjdk.org/jdk/pull/23498/files/5a00388e..bf89fd40

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

  Stats: 6954 lines in 202 files changed: 2578 ins; 2754 del; 1622 mod
  Patch: https://git.openjdk.org/jdk/pull/23498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23498/head:pull/23498

PR: https://git.openjdk.org/jdk/pull/23498

From joehw at openjdk.org  Fri Feb  7 20:08:32 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 7 Feb 2025 20:08:32 GMT
Subject: RFR: 8327378: XMLStreamReader throws EOFException instead of
 XMLStreamException
Message-ID: <RKo-msZoGZlYlQH95ToSGKdrOS6P8hsVUqHDfADpleU=.4545375d-c694-463c-864d-00e92d194ffc@github.com>

Fix an error handling where the XMLStreamReader impl throws EOFException instead of XMLStreamException as defined.

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

Commit messages:
 - 8327378: XMLStreamReader throws EOFException instead of XMLStreamException

Changes: https://git.openjdk.org/jdk/pull/23524/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23524&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327378
  Stats: 68 lines in 3 files changed: 62 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23524/head:pull/23524

PR: https://git.openjdk.org/jdk/pull/23524

From jiangli at openjdk.org  Fri Feb  7 20:10:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 7 Feb 2025 20:10:02 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v2]
In-Reply-To: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
Message-ID: <2i2FPE7phj9T1M0tOJpzD8SQGr3G-l2Ij6GGPgy1JoE=.efedd3f1-88ef-4f94-a3fb-47e1d7bb91bf@github.com>

> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
> 
> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.

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

  Move JNI_GetCreatedJavaVMs lookup into JNI_OnLoad, to address AlanBateman's suggestion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23500/files
  - new: https://git.openjdk.org/jdk/pull/23500/files/b68f76b2..4ee170d2

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

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

PR: https://git.openjdk.org/jdk/pull/23500

From jiangli at openjdk.org  Fri Feb  7 20:13:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 7 Feb 2025 20:13:09 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK
In-Reply-To: <5uzw7F8io2kdoROQLcPw9Q3lJe5SKxyysAag22QD-4Y=.4d026330-4326-49e9-a50e-1dfe66d2a5a2@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <5uzw7F8io2kdoROQLcPw9Q3lJe5SKxyysAag22QD-4Y=.4d026330-4326-49e9-a50e-1dfe66d2a5a2@github.com>
Message-ID: <QoEI4kUeWxoE5yM9EfbcJeeZlzV-giwgoxb_Qhwi0OM=.9c427c9a-11f0-4e5f-9cc5-19187f320dc7@github.com>

On Fri, 7 Feb 2025 10:38:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you look at adding native init method instead? This could be called from the System.loadLibraray and avoid introduce a side effect of startThreads initialising GetCreatedJavaVMs.

Done, thanks. Moved `JNI_GetCreatedJavaVMs` lookup into JNI_OnLoad.

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

PR Comment: https://git.openjdk.org/jdk/pull/23500#issuecomment-2644030507

From naoto at openjdk.org  Fri Feb  7 20:15:13 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Feb 2025 20:15:13 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables [v2]
In-Reply-To: <63AfV3MGoeAb4h6lPx5cRlFU-ECOwwnTcPFBczmDHb8=.89f6d5b3-28ca-402d-ae51-1aca7977468d@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
 <qhINoIIT466GCrjA3xHQnJZ6AhkvifGcWYva0qgFLFA=.9eecd1c7-66bc-4d64-b6e9-24bb0797eb3b@github.com>
 <63AfV3MGoeAb4h6lPx5cRlFU-ECOwwnTcPFBczmDHb8=.89f6d5b3-28ca-402d-ae51-1aca7977468d@github.com>
Message-ID: <9fpcX6C4eIIGwasgSoHKiYUZ9UiIhcpA2bdEkLP6R08=.fe27ac83-c9d0-435e-a0e6-ae2e4ca17173@github.com>

On Fri, 7 Feb 2025 18:53:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review
>
> src/java.base/share/native/libjli/args.c line 603:
> 
>> 601: /*
>> 602:  * getenv() without best-fit mapping
>> 603:  */
> 
> I think a quick comment that says something along the lines of 
> 
> 
> env variable name: code page -> UTF-16 
> variable value : UTF-16 -> code page
> 
> 
> would be helpful to overview what is happening here.

Thanks. I modified the comment.

> src/java.base/share/native/libjli/args.c line 611:
> 
>> 609:         LPWSTR wcVarName = JLI_MemAlloc(wcCount * sizeof(wchar_t));
>> 610:         if (MultiByteToWideChar(CP_ACP, 0, var_name, -1, wcVarName, wcCount) != 0) {
>> 611:             LPWSTR wcEnvVar = _wgetenv(wcVarName);
> 
> Since we are in Windows specific code, would it make sense to call `GetEnvironmentVariableW` over `_wgetenv`? It won't be as concise since we will have to follow the 2-call style of determining the size, then filling the buffer; but I presume it avoids some overhead, since it's directly apart of the Win32 API?

I think the overhead is negligible. If we use the Get... function, we will need to allocate/deallocate the intermediate buffer, which will make the code complex.

> test/jdk/tools/launcher/DisableBestFitMappingTest.java line 32:
> 
>> 30:  * @requires (os.family == "windows")
>> 31:  * @library /test/lib
>> 32:  * @run junit DisableBestFitMappingTest
> 
> I think it might be best to re-write this test as a non Junit test. Through IntelliJ it's hard to run this test, I presume because of the combination of it being a Junit test and having a `main` method? If I run the 'launcher' suite of tests, this test does not seem to be included.

I am not sure of this. Isn't it the issue in jtreg plugin? At least `make test TEST=...` will succeed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947128400
PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947128384
PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947128439

From bpb at openjdk.org  Fri Feb  7 20:17:47 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 7 Feb 2025 20:17:47 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v5]
In-Reply-To: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
Message-ID: <tvHVVZMbkAoFY__zewbMsAmDTpO7P-dfxHYo_7GRYxA=.20d64325-8276-4bef-acf9-08c62022c088@github.com>

> Update the specification of `java.io.File.exists()` to match its behavior, which seems correct in the context of how the empty abstract pathname is documented elsewhere in the class.

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

  8024695: Fix merge error; improve get*Space tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22821/files
  - new: https://git.openjdk.org/jdk/pull/22821/files/01fd1990..2cde95cb

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

  Stats: 21 lines in 2 files changed: 14 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22821/head:pull/22821

PR: https://git.openjdk.org/jdk/pull/22821

From almatvee at openjdk.org  Fri Feb  7 20:30:12 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 7 Feb 2025 20:30:12 GMT
Subject: RFR: 8150442: Enforce Supported Platforms in Packager for MSI
 bundles
In-Reply-To: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
References: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
Message-ID: <dOA5Dbr7VPIMRRDqEiars7t1tPxiJfsnt83_wFfAUDs=.a31ae6d5-d6ce-496d-8a88-27ce2967bbc7@github.com>

On Wed, 5 Feb 2025 20:11:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Enable MSI installers to block installation if the version of Windows is too old.
> 
> jpackage will read major and minor OS versions from PE headers of the main launcher and `java.dll` in the app image. The combined version is the minimal Windows version these executables can run. Thus, it will be a lower bound for the Windows version the installer supports. 
> 
> The value of the combined version is passed as `JpExecutableOSVersion` WiX variable to a new `os-condition.wxf` WiX fragment. The fragment compares the value of `JpExecutableOSVersion` WiX variable with the value of `VersionNT` MSI property. If the value of the latter is less the installation is blocked.
> 
> The fragment can be overridden in the resource directory. This makes this feature fully customizable.

I am not sure if we should limit installer upto Windows Vista. Should we limit installation to `Certified System Configurations` based on https://www.oracle.com/java/technologies/javase-subscription/documentation.html#sysconfig instead? User can override it if needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23472#issuecomment-2644062202

From iris at openjdk.org  Fri Feb  7 20:32:11 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 7 Feb 2025 20:32:11 GMT
Subject: RFR: 8327378: XMLStreamReader throws EOFException instead of
 XMLStreamException
In-Reply-To: <RKo-msZoGZlYlQH95ToSGKdrOS6P8hsVUqHDfADpleU=.4545375d-c694-463c-864d-00e92d194ffc@github.com>
References: <RKo-msZoGZlYlQH95ToSGKdrOS6P8hsVUqHDfADpleU=.4545375d-c694-463c-864d-00e92d194ffc@github.com>
Message-ID: <8r2kDjFkeFPR9ds9FoZMj35gnqwhtstzEHUavHE7dPk=.9b091c22-d410-4fd0-9595-7c2a781242d5@github.com>

On Fri, 7 Feb 2025 20:03:21 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an error handling where the XMLStreamReader impl throws EOFException instead of XMLStreamException as defined.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23524#pullrequestreview-2602766876

From lancea at openjdk.org  Fri Feb  7 20:39:12 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 7 Feb 2025 20:39:12 GMT
Subject: RFR: 8327378: XMLStreamReader throws EOFException instead of
 XMLStreamException
In-Reply-To: <RKo-msZoGZlYlQH95ToSGKdrOS6P8hsVUqHDfADpleU=.4545375d-c694-463c-864d-00e92d194ffc@github.com>
References: <RKo-msZoGZlYlQH95ToSGKdrOS6P8hsVUqHDfADpleU=.4545375d-c694-463c-864d-00e92d194ffc@github.com>
Message-ID: <kVihBHYoqfm8MU5AeV_hWIxKNHo3LSUuoI4rF3b_2r8=.f756dd82-257f-4f49-b9e4-ca69cfdeb165@github.com>

On Fri, 7 Feb 2025 20:03:21 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an error handling where the XMLStreamReader impl throws EOFException instead of XMLStreamException as defined.

Looks OK Joe

I might suggest an RN to give a heads up on the change of Exception to match he spec

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23524#pullrequestreview-2602777128

From asemenyuk at openjdk.org  Fri Feb  7 21:08:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 7 Feb 2025 21:08:09 GMT
Subject: RFR: 8150442: Enforce Supported Platforms in Packager for MSI
 bundles
In-Reply-To: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
References: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
Message-ID: <YUTIPQD6SvM1Sr3eF5kpcYPjtzJ9UYLL-SnSffsULPk=.0be8e449-45f1-435c-b505-496e885bcdb8@github.com>

On Wed, 5 Feb 2025 20:11:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Enable MSI installers to block installation if the version of Windows is too old.
> 
> jpackage will read major and minor OS versions from PE headers of the main launcher and `java.dll` in the app image. The combined version is the minimal Windows version these executables can run. Thus, it will be a lower bound for the Windows version the installer supports. 
> 
> The value of the combined version is passed as `JpExecutableOSVersion` WiX variable to a new `os-condition.wxf` WiX fragment. The fragment compares the value of `JpExecutableOSVersion` WiX variable with the value of `VersionNT` MSI property. If the value of the latter is less the installation is blocked.
> 
> The fragment can be overridden in the resource directory. This makes this feature fully customizable.

Should we limit installation to Certified System Configurations?

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

PR Comment: https://git.openjdk.org/jdk/pull/23472#issuecomment-2644127722

From coleenp at openjdk.org  Fri Feb  7 21:14:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 7 Feb 2025 21:14:13 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <Hai1knECYXvemIZZ5utF6G7XsGtjf7VH4wySvU6WT4s=.40d63bbb-4a91-4983-9921-82d963f8ead8@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
 <lE8Fzktp5eGkcXgqGo9BX2XZ-7nP2_63aoED1jxBbtk=.8dcfa9e0-c8a8-4922-937e-fdb22ee84c95@github.com>
 <Hai1knECYXvemIZZ5utF6G7XsGtjf7VH4wySvU6WT4s=.40d63bbb-4a91-4983-9921-82d963f8ead8@github.com>
Message-ID: <RXGNb9N_QtHpY_ACo3Tqlezykzg36nHJSHO0Ep7jVEQ=.0ee2e5c1-006e-436d-815a-9086bd002dc5@github.com>

On Fri, 7 Feb 2025 19:58:12 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Good point. Moreover, it seems most of intrinsics on Class queries can be replaced with a flag bit check on the mirror. (Do we have 16 unused bits in Class::modifiers after this change?)

Yes, I think so.  isArray and isPrimitive definitely.  We could first change the modifiers field to "char" because that's its size and then have two booleans for each of these.

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2644136904

From naoto at openjdk.org  Fri Feb  7 21:15:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Feb 2025 21:15:10 GMT
Subject: RFR: 8327378: XMLStreamReader throws EOFException instead of
 XMLStreamException
In-Reply-To: <RKo-msZoGZlYlQH95ToSGKdrOS6P8hsVUqHDfADpleU=.4545375d-c694-463c-864d-00e92d194ffc@github.com>
References: <RKo-msZoGZlYlQH95ToSGKdrOS6P8hsVUqHDfADpleU=.4545375d-c694-463c-864d-00e92d194ffc@github.com>
Message-ID: <dGJpyGbr5H5rug_YPjSNX0Xo6cZ8uaLH4igs__iSzAE=.401f2c61-6769-4f91-a2e7-f879e4d153d4@github.com>

On Fri, 7 Feb 2025 20:03:21 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an error handling where the XMLStreamReader impl throws EOFException instead of XMLStreamException as defined.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23524#pullrequestreview-2602856181

From duke at openjdk.org  Fri Feb  7 21:23:16 2025
From: duke at openjdk.org (duke)
Date: Fri, 7 Feb 2025 21:23:16 GMT
Subject: Withdrawn: 8340380: Improve source launcher's shebang script detection
In-Reply-To: <pPn4yrTw5nsM__oUzo4K9XtXiu0TFpkQmEi7fG1OOCQ=.b18d5a33-d569-4633-bb27-121973ee1ea3@github.com>
References: <pPn4yrTw5nsM__oUzo4K9XtXiu0TFpkQmEi7fG1OOCQ=.b18d5a33-d569-4633-bb27-121973ee1ea3@github.com>
Message-ID: <88MAHc5J-IrtYwWP8zztq3jG5MZLga_XwqCqSghMUZ0=.0e0e671f-b24b-4269-9adc-37ed3bfe5a19@github.com>

On Tue, 5 Nov 2024 16:16:13 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change that improves the launcher mode detection by reading the initial two characters from the started file for being a shebang script. It addresses the reported confusing error messages and also supports more shebang line variations. Including those line variations that omit the `--source` arguments like shown in the underlying issue description of JDK-8340380.
> 
> Tests of tier 1..3: _in progress_

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/21910

From liach at openjdk.org  Fri Feb  7 21:37:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Feb 2025 21:37:12 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
Message-ID: <rOsaO-sBYnrdqrPazYWGUx95QxEJ6vkbqO-C47E-P5Q=.fdda2cd0-df90-4a6a-8c2c-4fb577a72de3@github.com>

On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jvmci test.

Making `isArray` and `isPrimitive` Java-based is going to be helpful for the interpreter performance of these methods in early bootstrap. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2644171713

From almatvee at openjdk.org  Fri Feb  7 22:03:09 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 7 Feb 2025 22:03:09 GMT
Subject: RFR: 8150442: Enforce Supported Platforms in Packager for MSI
 bundles
In-Reply-To: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
References: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
Message-ID: <K-T4rGLVnlDCtBu6WkWUzMhBmy-fSZJCJS14JScjiGM=.497009b5-8bfc-409c-83d9-39128597b0e2@github.com>

On Wed, 5 Feb 2025 20:11:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Enable MSI installers to block installation if the version of Windows is too old.
> 
> jpackage will read major and minor OS versions from PE headers of the main launcher and `java.dll` in the app image. The combined version is the minimal Windows version these executables can run. Thus, it will be a lower bound for the Windows version the installer supports. 
> 
> The value of the combined version is passed as `JpExecutableOSVersion` WiX variable to a new `os-condition.wxf` WiX fragment. The fragment compares the value of `JpExecutableOSVersion` WiX variable with the value of `VersionNT` MSI property. If the value of the latter is less the installation is blocked.
> 
> The fragment can be overridden in the resource directory. This makes this feature fully customizable.

Marked as reviewed by almatvee (Reviewer).

Looks good.

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

PR Review: https://git.openjdk.org/jdk/pull/23472#pullrequestreview-2602939110
PR Comment: https://git.openjdk.org/jdk/pull/23472#issuecomment-2644206600

From jlu at openjdk.org  Fri Feb  7 22:49:11 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Feb 2025 22:49:11 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables [v3]
In-Reply-To: <EK6n63VyKwdmaAgLsAmV9IEjv0NV8HGNXVnyna7S-K4=.87fe6c89-cb86-4f94-ab55-f11827b3f56e@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
 <EK6n63VyKwdmaAgLsAmV9IEjv0NV8HGNXVnyna7S-K4=.87fe6c89-cb86-4f94-ab55-f11827b3f56e@github.com>
Message-ID: <qXyf8CL8bzRnkuZqe3xPWuDxlclLxL6hD_jvLJAoGb0=.0f35fb6a-faf3-4d92-b434-8061fcb09123@github.com>

On Fri, 7 Feb 2025 20:05:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Reflects review
>  - Merge branch 'master' into JDK-8349254-disable-best-fit-env-vars
>  - Reflects review
>  - initial commit

Looks good to me; reviewed CSR as well.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23498#pullrequestreview-2603007217

From jlu at openjdk.org  Fri Feb  7 22:49:12 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Feb 2025 22:49:12 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables [v2]
In-Reply-To: <9fpcX6C4eIIGwasgSoHKiYUZ9UiIhcpA2bdEkLP6R08=.fe27ac83-c9d0-435e-a0e6-ae2e4ca17173@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
 <qhINoIIT466GCrjA3xHQnJZ6AhkvifGcWYva0qgFLFA=.9eecd1c7-66bc-4d64-b6e9-24bb0797eb3b@github.com>
 <63AfV3MGoeAb4h6lPx5cRlFU-ECOwwnTcPFBczmDHb8=.89f6d5b3-28ca-402d-ae51-1aca7977468d@github.com>
 <9fpcX6C4eIIGwasgSoHKiYUZ9UiIhcpA2bdEkLP6R08=.fe27ac83-c9d0-435e-a0e6-ae2e4ca17173@github.com>
Message-ID: <dqKZ-E2TpUuzsFn8zKYKC-p_bHt3n2v1fkR5hvUxcRw=.60b5903b-99ab-44ec-bf3b-02e267ca3f2e@github.com>

On Fri, 7 Feb 2025 20:11:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/native/libjli/args.c line 611:
>> 
>>> 609:         LPWSTR wcVarName = JLI_MemAlloc(wcCount * sizeof(wchar_t));
>>> 610:         if (MultiByteToWideChar(CP_ACP, 0, var_name, -1, wcVarName, wcCount) != 0) {
>>> 611:             LPWSTR wcEnvVar = _wgetenv(wcVarName);
>> 
>> Since we are in Windows specific code, would it make sense to call `GetEnvironmentVariableW` over `_wgetenv`? It won't be as concise since we will have to follow the 2-call style of determining the size, then filling the buffer; but I presume it avoids some overhead, since it's directly apart of the Win32 API?
>
> I think the overhead is negligible. If we use the Get... function, we will need to allocate/deallocate the intermediate buffer, which will make the code complex.

OK, seems good to use `_wgetenv` then.

>> test/jdk/tools/launcher/DisableBestFitMappingTest.java line 32:
>> 
>>> 30:  * @requires (os.family == "windows")
>>> 31:  * @library /test/lib
>>> 32:  * @run junit DisableBestFitMappingTest
>> 
>> I think it might be best to re-write this test as a non Junit test. Through IntelliJ it's hard to run this test, I presume because of the combination of it being a Junit test and having a `main` method? If I run the 'launcher' suite of tests, this test does not seem to be included.
>
> I am not sure of this. Isn't it the issue in jtreg plugin? At least `make test TEST=...` will succeed.

Oops, I thought the test would mark as "skipped" or something like that, but yes its a Windows only test, hence why it does not show up, duh.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947288085
PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947288095

From jiangli at openjdk.org  Fri Feb  7 23:55:43 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 7 Feb 2025 23:55:43 GMT
Subject: RFR: 8349620: Add VMProps for static JDK
Message-ID: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>

Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.

This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 

`@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.

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

Commit messages:
 - - Add 'jdk.static' in VMProps. It can be used to skip tests not for running on static JDK.

Changes: https://git.openjdk.org/jdk/pull/23528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349620
  Stats: 19 lines in 6 files changed: 16 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23528/head:pull/23528

PR: https://git.openjdk.org/jdk/pull/23528

From paul.sandoz at oracle.com  Sat Feb  8 00:13:13 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sat, 8 Feb 2025 00:13:13 +0000
Subject: RFR: 8315585: Optimization for decimal to string [v4]
In-Reply-To: <CANSoFxtJre6tcYNmSzWYaKyZw81rcQHfcJQV_TA36wu09HPzwg@mail.gmail.com>
References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com>
 <JENdZLiCWbHnkdjyhqKGyjZxHcq2byLXXj1YRwi_X18=.a94901e5-cc33-4aa8-8f89-16a4fdb9c361@github.com>
 <OuPjhqT8MhzedE6GjsbHHh2WgmRIyGdgmtgYQ2yta6I=.b2d4ee54-4b4c-4ed0-95e7-4bab92666d50@github.com>
 <CANSoFxtJre6tcYNmSzWYaKyZw81rcQHfcJQV_TA36wu09HPzwg@mail.gmail.com>
Message-ID: <C49FEF91-8677-4657-AD85-1D927D056A2A@oracle.com>

I would like to amplify this point ? undermining Java?s integrity is a big deal. Every time we use unsafe mechanisms within the JDK we risk doing that. The more complex such code is the harder it is reason about whether overall it is safe [*]. We need to balance reasoning about code, quality, and maintenance of against narrowly measured performance benefits that increase the risk of some integrity violation.

Paul.

[*] And even if it is not so complex, others may not be aware of the subtleties when refactoring. Unsafe allocation that does not zero memory is particular worrisome in this regard.

> On Feb 7, 2025, at 7:42?AM, Archie Cobbs <archie.cobbs at gmail.com> wrote:
> Good point, but frankly, an irrelevant one. The key issue here is that if plain, ordinary, non-native-invoking Java bytecode can corrupt memory and/or crash the JVM, then that's a Big Problem??. It doesn't matter how contrived the code that makes it happen is.
> 
> -Archie
> 
> --
> Archie L. Cobbs


From duke at openjdk.org  Sat Feb  8 01:22:21 2025
From: duke at openjdk.org (Zheng Feng)
Date: Sat, 8 Feb 2025 01:22:21 GMT
Subject: RFR: 8344925: translet-name ignored,
 when package-name is also set via TransformerFactory.setAttribute
In-Reply-To: <kfTrynEd2-z8GfOCuvUOiY1VAOd2yO-qrGhGLCWLHmo=.dd17a46e-055c-4206-b129-39ad143ac474@github.com>
References: <kfTrynEd2-z8GfOCuvUOiY1VAOd2yO-qrGhGLCWLHmo=.dd17a46e-055c-4206-b129-39ad143ac474@github.com>
Message-ID: <z3_6uire3rV2Tq9GTTB9tbB2emATD7dLR12VB1JW9qQ=.ec01a751-9197-40c6-a71a-1d9a78dae23e@github.com>

On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng <duke at openjdk.org> wrote:

> ?String)
> 
> This bug seems from the improper handling of package and class name initialization in `XSLTC` since there is a default value of  `_packageName` with `die.verwandlung`. This fix is just adjusting to call `setPackageName` before `setClassName`.
> 
> I've done the tire1 and tire2 tests. The tire1 tests passed and tire2 reports
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  
>>> jtreg:test/hotspot/jtreg:tier2                      745   744     1     0 <<
>>> jtreg:test/jdk:tier2                               4142  4137     2     3 <<
>    jtreg:test/langtools:tier2                           12    12     0     0  
>    jtreg:test/jaxp:tier2                               514   514     0     0  
>    jtreg:test/docs:tier2                                 1     1     0     0  
> ==============================
> TEST FAILURE
> 
> 
> The failed tests are
> 
> JT Harness : Tests that failed
> runtime/Thread/ThreadCountLimit.java#id0: Stress test that reaches the process limit for thread count, or time limit.
> 
> JT Harness : Tests that failed
> java/net/InetAddress/CheckJNI.java: java -Xcheck:jni failing in net code on Solaris / [Datagram]Socket.getLocalAddress() failure
> java/net/Socket/LinkLocal.java: Connecting to a link-local IPv6 address should not causes a SocketException to be thrown.
> 
> JT Harness : Tests that had errors
> java/net/URL/EarlyOrDelayedParsing.java: URL built-in protocol handlers should parse the URL early to avoid constructing URLs for which openConnection would later throw an exception, when possible.
> java/net/ipv6tests/UdpTest.java: IPv6 support for Windows XP and 2003 server.
> java/nio/channels/DatagramChannel/SendReceiveMaxSize.java: Check that it is possible to send and receive datagrams of maximum size on macOS.

Thanks all of you and this is my first time to contribute to the openjdk project. I did not know the procedure and should have asked such things on the ML first. Is there any document refer to the first time contribution?

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

PR Comment: https://git.openjdk.org/jdk/pull/22425#issuecomment-2644405171

From duke at openjdk.org  Sat Feb  8 01:22:22 2025
From: duke at openjdk.org (Zheng Feng)
Date: Sat, 8 Feb 2025 01:22:22 GMT
Subject: Withdrawn: 8344925: translet-name ignored,
 when package-name is also set via TransformerFactory.setAttribute
In-Reply-To: <kfTrynEd2-z8GfOCuvUOiY1VAOd2yO-qrGhGLCWLHmo=.dd17a46e-055c-4206-b129-39ad143ac474@github.com>
References: <kfTrynEd2-z8GfOCuvUOiY1VAOd2yO-qrGhGLCWLHmo=.dd17a46e-055c-4206-b129-39ad143ac474@github.com>
Message-ID: <2MvI9ZDaa4WEeOlRTGcBPXc_Q0QvJHPyFKXCcazFh8o=.28587de4-0bdb-4fc2-8a81-34ed9855d9e4@github.com>

On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng <duke at openjdk.org> wrote:

> ?String)
> 
> This bug seems from the improper handling of package and class name initialization in `XSLTC` since there is a default value of  `_packageName` with `die.verwandlung`. This fix is just adjusting to call `setPackageName` before `setClassName`.
> 
> I've done the tire1 and tire2 tests. The tire1 tests passed and tire2 reports
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  
>>> jtreg:test/hotspot/jtreg:tier2                      745   744     1     0 <<
>>> jtreg:test/jdk:tier2                               4142  4137     2     3 <<
>    jtreg:test/langtools:tier2                           12    12     0     0  
>    jtreg:test/jaxp:tier2                               514   514     0     0  
>    jtreg:test/docs:tier2                                 1     1     0     0  
> ==============================
> TEST FAILURE
> 
> 
> The failed tests are
> 
> JT Harness : Tests that failed
> runtime/Thread/ThreadCountLimit.java#id0: Stress test that reaches the process limit for thread count, or time limit.
> 
> JT Harness : Tests that failed
> java/net/InetAddress/CheckJNI.java: java -Xcheck:jni failing in net code on Solaris / [Datagram]Socket.getLocalAddress() failure
> java/net/Socket/LinkLocal.java: Connecting to a link-local IPv6 address should not causes a SocketException to be thrown.
> 
> JT Harness : Tests that had errors
> java/net/URL/EarlyOrDelayedParsing.java: URL built-in protocol handlers should parse the URL early to avoid constructing URLs for which openConnection would later throw an exception, when possible.
> java/net/ipv6tests/UdpTest.java: IPv6 support for Windows XP and 2003 server.
> java/nio/channels/DatagramChannel/SendReceiveMaxSize.java: Check that it is possible to send and receive datagrams of maximum size on macOS.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/22425

From joehw at openjdk.org  Sat Feb  8 02:50:17 2025
From: joehw at openjdk.org (Joe Wang)
Date: Sat, 8 Feb 2025 02:50:17 GMT
Subject: RFR: 8327378: XMLStreamReader throws EOFException instead of
 XMLStreamException
In-Reply-To: <RKo-msZoGZlYlQH95ToSGKdrOS6P8hsVUqHDfADpleU=.4545375d-c694-463c-864d-00e92d194ffc@github.com>
References: <RKo-msZoGZlYlQH95ToSGKdrOS6P8hsVUqHDfADpleU=.4545375d-c694-463c-864d-00e92d194ffc@github.com>
Message-ID: <zzFiKfJJxPIroTlIoGOVYy0xI11i0YtDjWdtA1Lg96c=.216559ed-9e46-4817-8ecc-b1cddff6197c@github.com>

On Fri, 7 Feb 2025 20:03:21 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an error handling where the XMLStreamReader impl throws EOFException instead of XMLStreamException as defined.

RN added.  Thanks all!

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

PR Comment: https://git.openjdk.org/jdk/pull/23524#issuecomment-2644447199

From joehw at openjdk.org  Sat Feb  8 02:50:18 2025
From: joehw at openjdk.org (Joe Wang)
Date: Sat, 8 Feb 2025 02:50:18 GMT
Subject: Integrated: 8327378: XMLStreamReader throws EOFException instead of
 XMLStreamException
In-Reply-To: <RKo-msZoGZlYlQH95ToSGKdrOS6P8hsVUqHDfADpleU=.4545375d-c694-463c-864d-00e92d194ffc@github.com>
References: <RKo-msZoGZlYlQH95ToSGKdrOS6P8hsVUqHDfADpleU=.4545375d-c694-463c-864d-00e92d194ffc@github.com>
Message-ID: <83900abrIlg6EdyLTeIZWiVgStywqoEFLpozvpeFDG4=.f41f0d09-bcfd-450d-8ab7-5ecb4eb8c541@github.com>

On Fri, 7 Feb 2025 20:03:21 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an error handling where the XMLStreamReader impl throws EOFException instead of XMLStreamException as defined.

This pull request has now been integrated.

Changeset: 5395ffa0
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5395ffa006d06fb2b6a087885a9d7118048e6696
Stats:     68 lines in 3 files changed: 62 ins; 1 del; 5 mod

8327378: XMLStreamReader throws EOFException instead of XMLStreamException

Reviewed-by: iris, lancea, naoto

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

PR: https://git.openjdk.org/jdk/pull/23524

From joehw at openjdk.org  Sat Feb  8 04:27:16 2025
From: joehw at openjdk.org (Joe Wang)
Date: Sat, 8 Feb 2025 04:27:16 GMT
Subject: RFR: 8344925: translet-name ignored,
 when package-name is also set via TransformerFactory.setAttribute
In-Reply-To: <kfTrynEd2-z8GfOCuvUOiY1VAOd2yO-qrGhGLCWLHmo=.dd17a46e-055c-4206-b129-39ad143ac474@github.com>
References: <kfTrynEd2-z8GfOCuvUOiY1VAOd2yO-qrGhGLCWLHmo=.dd17a46e-055c-4206-b129-39ad143ac474@github.com>
Message-ID: <FckC88fvn_ALiiaXEvnnGCCiKcI5CY6r6KB_ZfMCYnQ=.c167a85f-82fd-450f-9a87-bfe325f43042@github.com>

On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng <duke at openjdk.org> wrote:

> ?String)
> 
> This bug seems from the improper handling of package and class name initialization in `XSLTC` since there is a default value of  `_packageName` with `die.verwandlung`. This fix is just adjusting to call `setPackageName` before `setClassName`.
> 
> I've done the tire1 and tire2 tests. The tire1 tests passed and tire2 reports
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  
>>> jtreg:test/hotspot/jtreg:tier2                      745   744     1     0 <<
>>> jtreg:test/jdk:tier2                               4142  4137     2     3 <<
>    jtreg:test/langtools:tier2                           12    12     0     0  
>    jtreg:test/jaxp:tier2                               514   514     0     0  
>    jtreg:test/docs:tier2                                 1     1     0     0  
> ==============================
> TEST FAILURE
> 
> 
> The failed tests are
> 
> JT Harness : Tests that failed
> runtime/Thread/ThreadCountLimit.java#id0: Stress test that reaches the process limit for thread count, or time limit.
> 
> JT Harness : Tests that failed
> java/net/InetAddress/CheckJNI.java: java -Xcheck:jni failing in net code on Solaris / [Datagram]Socket.getLocalAddress() failure
> java/net/Socket/LinkLocal.java: Connecting to a link-local IPv6 address should not causes a SocketException to be thrown.
> 
> JT Harness : Tests that had errors
> java/net/URL/EarlyOrDelayedParsing.java: URL built-in protocol handlers should parse the URL early to avoid constructing URLs for which openConnection would later throw an exception, when possible.
> java/net/ipv6tests/UdpTest.java: IPv6 support for Windows XP and 2003 server.
> java/nio/channels/DatagramChannel/SendReceiveMaxSize.java: Check that it is possible to send and receive datagrams of maximum size on macOS.

Check out the OpenJDK Developers? Guide: https://openjdk.org/guide/

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

PR Comment: https://git.openjdk.org/jdk/pull/22425#issuecomment-2644492737

From jpai at openjdk.org  Sat Feb  8 07:18:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 8 Feb 2025 07:18:17 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables [v3]
In-Reply-To: <-JPSYAwiOS_4E9GMZTKv--ju4PFGGoX_oH5Laxk4uMc=.b7439475-673a-4aed-a7b6-44fa4c3116dc@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
 <LDGLVVlMYcO1OFb_iVawEXJ7wR9UBKyjm_z6QY70C3U=.9de25135-e4a6-4013-b77a-f4a0738f8521@github.com>
 <-JPSYAwiOS_4E9GMZTKv--ju4PFGGoX_oH5Laxk4uMc=.b7439475-673a-4aed-a7b6-44fa4c3116dc@github.com>
Message-ID: <RwDJOPW8rpnPi4PrFDPfX7r66rhhxEyC_L30BNyZsLY=.7a37d23f-3ce5-4b78-be1e-fa941e819f32@github.com>

On Fri, 7 Feb 2025 18:39:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/native/libjli/args.c line 472:
>> 
>>> 470: JLI_AddArgsFromEnvVar(JLI_List args, const char *var_name) {
>>> 471: #ifdef _WIN32
>>> 472:     char *env = winGetEnv(var_name);
>> 
>> I see that we are limiting this call to use `_wgetenv()` (the wide-character version of `getenv()`) only to `_WIN32`. Is there any harm in using `_wgetenv()` even for `_WIN64`? Or is the `getenv()` implementation on `_WIN64` not susceptible to the issues noted in the JBS?
>
> The macro name is confusing, but `_WIN32` means Win32 API set and does not specify the target platform. This link (https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170) reads
> 
> 
> _WIN32 Defined as 1 when the compilation target is 32-bit ARM, 64-bit ARM, x86, or x64. Otherwise, undefined.
> 
> 
> So I believe `_WIN32` is correct here.

Thank you for that detail Naoto. I didn't realize `_WIN32` was a Windows standard macro - I was under the impression that it is defined by the JDK's build files and (like you noticed) even misunderstood it to be something else.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23498#discussion_r1947500611

From jpai at openjdk.org  Sat Feb  8 07:18:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 8 Feb 2025 07:18:17 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables [v3]
In-Reply-To: <EK6n63VyKwdmaAgLsAmV9IEjv0NV8HGNXVnyna7S-K4=.87fe6c89-cb86-4f94-ab55-f11827b3f56e@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
 <EK6n63VyKwdmaAgLsAmV9IEjv0NV8HGNXVnyna7S-K4=.87fe6c89-cb86-4f94-ab55-f11827b3f56e@github.com>
Message-ID: <wZpflTovMnvszYiBfpFFCXiCkuXm4bs3A3Ox-mthRHo=.44147ee2-179b-4c50-b6b8-b02cd4c82069@github.com>

On Fri, 7 Feb 2025 20:05:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Reflects review
>  - Merge branch 'master' into JDK-8349254-disable-best-fit-env-vars
>  - Reflects review
>  - initial commit

The updated changes look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23498#pullrequestreview-2603334817

From alanb at openjdk.org  Sat Feb  8 09:32:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 8 Feb 2025 09:32:10 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v2]
In-Reply-To: <2i2FPE7phj9T1M0tOJpzD8SQGr3G-l2Ij6GGPgy1JoE=.efedd3f1-88ef-4f94-a3fb-47e1d7bb91bf@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <2i2FPE7phj9T1M0tOJpzD8SQGr3G-l2Ij6GGPgy1JoE=.efedd3f1-88ef-4f94-a3fb-47e1d7bb91bf@github.com>
Message-ID: <DvvA7piLSCsjhlUXRfHCpA5tQMfj5lifvJmcCpaiqvc=.402f8dd1-8b1b-4fd1-90a3-10e6f38debe2@github.com>

On Fri, 7 Feb 2025 20:10:02 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
>> 
>> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move JNI_GetCreatedJavaVMs lookup into JNI_OnLoad, to address AlanBateman's suggestion.

test/jdk/java/lang/Thread/jni/AttachCurrentThread/libExplicitAttach.c line 57:

> 55:         return JNI_ERR;
> 56:     }
> 57:     return JNI_VERSION_1_8;

Is the JavaVM param passed to JNI_OnLoad usable in static builds? If so then this just needs to be saved, no need to use GetCreatedJavaVMs, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23500#discussion_r1947551019

From duke at openjdk.org  Sat Feb  8 17:06:16 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 8 Feb 2025 17:06:16 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v31]
In-Reply-To: <wmzwqSiFdhqcr8MsGA9FjLjix25b2xbUR6EMldc2k9c=.8f74f6ad-c453-459b-a6ed-8091e1a8794e@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <wmzwqSiFdhqcr8MsGA9FjLjix25b2xbUR6EMldc2k9c=.8f74f6ad-c453-459b-a6ed-8091e1a8794e@github.com>
Message-ID: <8Y0EFs5UwqZRwejFi6NKzHNFpC1zughyKu9soR2TyfE=.6439e74e-3776-4a2f-8b2e-2f6a8bea5dc5@github.com>

On Wed, 4 Dec 2024 14:56:02 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
>> 
>> The main steps of the algorithm are as follows:
>> first argument reduce the value to an integer using the following relations:
>> 
>> x = y * 10 ^ exp
>> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
>> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
>> 
>> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
>> 
>> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   An optimization

This comment is to avoid closing this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2645846004

From alanb at openjdk.org  Sat Feb  8 19:44:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 8 Feb 2025 19:44:12 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
Message-ID: <YJ99YDxAF7V-8aQ9vkVzWyGuNciUbP6D0yTaPs7jqgY=.edf8667d-605e-4ae9-87c0-bd6376daf30f@github.com>

On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jvmci test.

No more comments from me.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2604014387

From duke at openjdk.org  Sun Feb  9 01:34:27 2025
From: duke at openjdk.org (duke)
Date: Sun, 9 Feb 2025 01:34:27 GMT
Subject: Withdrawn: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
Message-ID: <5eu5ddMQC1dKl9tRJH11Y-uOMrUutke0t4xWR7rwVxc=.53126589-5b82-4aa7-aaf2-a25df13dc2f3@github.com>

On Thu, 7 Nov 2024 21:38:28 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
> 
> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
> 
> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/21964

From jwaters at openjdk.org  Sun Feb  9 13:10:19 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 9 Feb 2025 13:10:19 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
Message-ID: <Qq762lW7bsLbDvZ0w_V6aUDBiDtSeffMRngVGsw4teY=.900b8f62-c67c-4d62-8814-3a4ab24042c2@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unused
>  - Neater warning silencer in proc_md.h
>  - Revert _WIN32 workaround in log_messages.c
>  - Copyright in VersionInfo.cpp
>  - Remove neutralLangId in VersionInfo.cpp
>  - Remove global memHandle, would've liked to keep it as a comment :(
>  - Merge branch 'master' into unused
>  - 8342682

Don't close it

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2646295839

From markus at headcrashing.eu  Sun Feb  9 18:34:38 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sun, 9 Feb 2025 19:34:38 +0100
Subject: Request for Comments: Adding bulk-read method
 "CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)"
In-Reply-To: <004501db441e$18e46310$4aad2930$@eu>
References: <000001db2704$04318bf0$0c94a3d0$@eu>
 <004501db441e$18e46310$4aad2930$@eu>
Message-ID: <48bd29a1-4aa3-44e0-8beb-d8f28c9b4806@headcrashing.eu>

Thank you, everybody. As no more comments arrived in the past eight 
weeks, I assume that there is implicit agreement with my latest 
arguments (see below), so next I will provide a PR to continue 
discussion with real Java code at hand.

-Markus


Am 01.12.2024 um 19:23 schrieb Markus Karg:
>
> As Thanksgiving is over, and as work towards 24-RDP1 should mostly be 
> done, I think it is a good time to resume our now.
>
> To kick-off, below I am repeating my last response to Chen. Kindly 
> asking everybody to chime in, so we can find a feasible and beneficial 
> conclusion in this area.
>
> -Markus
>
> *Von:*Markus Karg [mailto:markus at headcrashing.eu]
> *Gesendet:* Sonntag, 27. Oktober 2024 09:44
> *An:* 'core-libs-dev'
> *Betreff:* Request for Comments: Adding bulk-read method 
> "CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int 
> dstBegin)"
>
> >Hi Markus,
>
> >Should we drop the srcBigin/srcEnd parameters, as they can be replaced by a 
> subSequence(srcBegin, srcEnd) call?
>
> Chen, I do understand your idea and while originally I had the same in 
> mind (it really /is/ appealing!), I came up with a draft using the 
> *original* String.getChars()signature instead, due to the following 
> drawbacks:
>
>   * There might exist (possibly lotsof) CharSequence.getChars(int,
>     int, char[], int)implementations already, as this problem (and the
>     idea how to solve it) is anything but new. At least such
>     implementations are String, StringBuilderand StringBuffer. If we
>     come up with a different signature, then *none* of these already
>     existing performance boosters will get used by
>     Reader.of(CharSequence)automatically - at least until they come up
>     with alias methods. Effectively this leads to (possibly lots) of
>     alias methods. At least it leads to alias methods in String,
>     StringBuilder, StringBufferand CharBuffer. In contrast, when
>     keeping the signature copied from String.getChars, chances are
>     good that (possibly lots of) implementations will /instantly/ be
>     supported by Reader.of(CharSequence)without alias methods. At
>     least, String, StringBuilderand StringBufferwill be.
>   * Since decades people are now very used to
>     StringBuilder.getChars(int, int, char[], int), so (possibly a lot
>     of) people might simply /expect/ us to come up with that lengthy
>     signature. These people might be rather confused (if not to say
>     frustrated) when we now force them to write an intermediate
>     subSequence(int, int)for something that was "such simple" before.
>   * Custom implementations of CharSequence.subSequencecould come up
>     with the (performance-wise "bad") idea of creating *copies*
>     instead of views. At least it seems like AbstractStringBuilderis
>     doing that, so chances are "good" that custom libs will do that,
>     too. For example, because they need it for safety. Or possibly,
>     because they have a technical reason that /enforces/ a copy. That
>     would (possibly massively, depending on the actual class) spoil
>     the idea of performance-boosting this RFC is all about.
>
> -Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250209/e3c814c2/attachment.htm>

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
Message-ID: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>

This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.

In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.

To ensure quality...
* ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
* ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

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

Commit messages:
 - Merge master
 - Copyright (C) 2025
 - @Override
 - Draft: CharSequence.getChars

Changes: https://git.openjdk.org/jdk/pull/21730/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343110
  Stats: 79 lines in 5 files changed: 64 ins; 9 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21730/head:pull/21730

PR: https://git.openjdk.org/jdk/pull/21730

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <dsUpWwgPLBSQk7wReV_AgqdtcHH1K4OPRGTKvjss7Ec=.29bf8d87-bbd7-4902-91fa-0123923a80a5@github.com>

On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

FYI @liach @bokken @eirbjo @robtimus @parttimenerd

Kindly asking anybody's contribution to the ongoing discussion on the core-devs mailing list. Thanks you.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2439635920
PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2558392238

From liach at openjdk.org  Sun Feb  9 18:41:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <mnYTzE2ZFnmuNbOub0FURZ07ib19OLHB4WwHyBCR41s=.5a4d68d7-c777-41f4-987b-5121b408665d@github.com>

On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

Sorry for belated mail response, but I think we should design the API to not take source start/end. I think JIT can escape analysis the new String in practice.

Hi Markus, I recommend to continue the discussion on the mailing list instead of on GitHub. Note that GitHub pull requests are only forwarded to the mailing list when it's ready for review, and this proposal is way too early. (And the CSR is too early, too: we should agree on an API surface, such as exception contracts, first)

Sorry that no one has responded to you yet, but many engineers are busy with other areas, such as pushing the JEPs (as you see, we have a huge number of candidate/submitted JEPs right now, and JDK 24 RDP1 is just 6 weeks away). They are monitoring your core-libs thread, stay assured!

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2439641840
PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2439740522

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <mnYTzE2ZFnmuNbOub0FURZ07ib19OLHB4WwHyBCR41s=.5a4d68d7-c777-41f4-987b-5121b408665d@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <mnYTzE2ZFnmuNbOub0FURZ07ib19OLHB4WwHyBCR41s=.5a4d68d7-c777-41f4-987b-5121b408665d@github.com>
Message-ID: <91jI-SwtJz_LQk4SnzNF5xKeTPQoOOEp4HmYcEHmgqI=.028c8bdd-a630-427a-b544-3d90553d8080@github.com>

On Sat, 26 Oct 2024 16:26:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> Sorry for belated mail response, but I think we should design the API to not take source start/end. I think JIT can escape analysis the new String in practice.

Chen, thank you for chiming in! There is nothing to be sorry, I was just posting *drafts* so far! ? 

Regarding your actual question, I do understand your idea and while originally I had the same in mind (it really *is* appealing!), I came up with a draft using the original `String.getChars()` signature instead, due to the following drawbacks:
* There might exist (possibly lotsof) `CharSequence.getChars(int, int, char[], int)` implementations already, as this problem (and the idea how to solve it) is anything but new. At least such implementations are `String`, `StringBuilder` and `StringBuffer`. If we come up with a different signature, then **none** of these already existing performance boosters will get used by `Reader.of(CharSequence)` automatically - at least until they come up with alias methods. Effectively this leads to (possibly lots) of alias methods. At least it leads to alias methods in `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`. In contrast, when keeping the signature copied from `String.getChars`, chances are good that (possibly lots of) implementations will *instantly* be supported by `Reader.of(CharSequence)` without alias methods. At least, `String`, `StringBuilder` and `StringBuffer` will be.
* Since decades people are now very used to `StringBuilder.getChars(int, int, char[], int)`, so (possibly a lot of) people might simply *expect* us to come up with that lengthy signature. These people might be rather confused (if not to say frustrated) when we now force them to write an intermediate `subSequence(int, int)` for something that was "such simple" before.
* Custom implementations of `CharSequence.subSequence` could come up with the (performance-wise "bad") idea of creating **copies** instead of views. At least it seems like `AbstractStringBuilder` is doing that, so chances are "good" that custom libs will do that, too. For example, because they need it for safety. Or possibly, because they have a technical reason that *enforces* a copy. That would (possibly massively, depending on the actual class) spoil the idea of performance-boosting this PR is actually all about.

> Hi Markus, I recommend to continue the discussion on the mailing list instead of on GitHub. Note that GitHub pull requests are only forwarded to the mailing list when it's ready for review, and this proposal is way too early. (And the CSR is too early, too: we should agree on an API surface, such as exception contracts, first)
> 
> Sorry that no one has responded to you yet, but many engineers are busy with other areas, such as pushing the JEPs (as you see, we have a huge number of candidate/submitted JEPs right now, and JDK 24 RDP1 is just 6 weeks away). They are monitoring your core-libs thread, stay assured!

@liach Agreed with all you say, but actually: I **did not expect** any response - in particular on a weekend!

I do not know why apparently people started to *review* the **draft** documents. I just filed it for no other purpose than *taking note of its existence*. ?  I thought it is pretty clear to everybody that draft means **"do not review"**. At least this is how I used draft documents in the past 30 years. ?

So it seems there was a misunderstanding here regarding my **drafts**. My intention ever was and still is to first finish the discussion *about alternatives (A)...(E)* **on the core-lib mailing list** *first*. My PR and CSR **drafts** are *intentionally* in draft state, which means, they are **not open for review** yet (there is **no** `rfr` label) and solely serve as my public storage for ideas-in-progress in lieu of out-of-band media. The detail discussion you started regarding *details of the PR* was a bit too early IMHO (and surprised me, and actually your duplicate question in the PR confused me), as it is not even decided that we actually go with proposal A, so why discussing *details* of exactly *that* already (my conclusion was, you like to prepare it for the case it becomes the finalist of the mailing list discussion)? Maybe I misunderstood your intent, and you actually wanted to propose alternative (F), then sorry for me not seeing that in the first place.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2439658000
PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2439748858

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Rob Spoor)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <hECkKj_ZjbRmBfhGGdWftHnBlcnVYkdm2bjonSJvsbE=.5d5c8608-d717-45e5-8363-4e20f682042a@github.com>

On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

src/java.base/share/classes/java/lang/CharSequence.java line 338:

> 336:      * @since 24
> 337:      */
> 338:     public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {

Shouldn't the `getChars` methods of `String`, `AbstractStringBuilder`, `StringBuilder` and `StringBuffer` be marked with `@Override`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r1817880004

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <hECkKj_ZjbRmBfhGGdWftHnBlcnVYkdm2bjonSJvsbE=.5d5c8608-d717-45e5-8363-4e20f682042a@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <hECkKj_ZjbRmBfhGGdWftHnBlcnVYkdm2bjonSJvsbE=.5d5c8608-d717-45e5-8363-4e20f682042a@github.com>
Message-ID: <YBp_jIj8IpXOBPfVNeMciZnSXfy04XDnlsM5xgfPP3Q=.26bf5351-35a7-4c16-a55d-2387224db0d9@github.com>

On Sat, 26 Oct 2024 16:19:32 GMT, Rob Spoor <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> src/java.base/share/classes/java/lang/CharSequence.java line 338:
> 
>> 336:      * @since 24
>> 337:      */
>> 338:     public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {
> 
> Shouldn't the `getChars` methods of `String`, `AbstractStringBuilder`, `StringBuilder` and `StringBuffer` be marked with `@Override`?

While technically not being necessary, it is definitively a good idea. I will add it to the draft once we actually agreed that we really want to go with this particular signature (see the discussion with Chen).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r1817891741

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <YBp_jIj8IpXOBPfVNeMciZnSXfy04XDnlsM5xgfPP3Q=.26bf5351-35a7-4c16-a55d-2387224db0d9@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <hECkKj_ZjbRmBfhGGdWftHnBlcnVYkdm2bjonSJvsbE=.5d5c8608-d717-45e5-8363-4e20f682042a@github.com>
 <YBp_jIj8IpXOBPfVNeMciZnSXfy04XDnlsM5xgfPP3Q=.26bf5351-35a7-4c16-a55d-2387224db0d9@github.com>
Message-ID: <E-2bpWjAIQJc6GyH4FfeOB7Tw9c2dKVgEqQbBl1W7ks=.30fdade5-6ab8-4a32-8fe8-df74f2b56612@github.com>

On Sat, 26 Oct 2024 17:09:29 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/CharSequence.java line 338:
>> 
>>> 336:      * @since 24
>>> 337:      */
>>> 338:     public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {
>> 
>> Shouldn't the `getChars` methods of `String`, `AbstractStringBuilder`, `StringBuilder` and `StringBuffer` be marked with `@Override`?
>
> While technically not being necessary, it is definitively a good idea. I will add it to the draft once we actually agreed that we really want to go with this particular signature (see the discussion with Chen).

Fixed in `String` and `AbstractStringBuilder`. There is no `StringBuilder.getChars`. `StringBuffer.getChars` already has `@Override`, just as `CharBuffer.getChars`. Thanks for the tip! ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r1947929157

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Rob Spoor)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <E-2bpWjAIQJc6GyH4FfeOB7Tw9c2dKVgEqQbBl1W7ks=.30fdade5-6ab8-4a32-8fe8-df74f2b56612@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <hECkKj_ZjbRmBfhGGdWftHnBlcnVYkdm2bjonSJvsbE=.5d5c8608-d717-45e5-8363-4e20f682042a@github.com>
 <YBp_jIj8IpXOBPfVNeMciZnSXfy04XDnlsM5xgfPP3Q=.26bf5351-35a7-4c16-a55d-2387224db0d9@github.com>
 <E-2bpWjAIQJc6GyH4FfeOB7Tw9c2dKVgEqQbBl1W7ks=.30fdade5-6ab8-4a32-8fe8-df74f2b56612@github.com>
Message-ID: <leEZ0wNXF8qF0lEpNFyk3CoFhf2mJ6M3DKIoPLIc1zI=.43246c40-504b-4281-ae0d-57744d446383@github.com>

On Sat, 8 Feb 2025 18:56:00 GMT, Markus KARG <duke at openjdk.org> wrote:

>> While technically not being necessary, it is definitively a good idea. I will add it to the draft once we actually agreed that we really want to go with this particular signature (see the discussion with Chen).
>
> Fixed in `String` and `AbstractStringBuilder`. There is no `StringBuilder.getChars`. `StringBuffer.getChars` already has `@Override`, just as `CharBuffer.getChars`. Thanks for the tip! ?

You're welcome :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r1948073040

From markus at headcrashing.eu  Sun Feb  9 18:49:38 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sun, 9 Feb 2025 19:49:38 +0100
Subject: Request for Comments: Adding bulk-read method
 "CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)"
In-Reply-To: <48bd29a1-4aa3-44e0-8beb-d8f28c9b4806@headcrashing.eu>
References: <000001db2704$04318bf0$0c94a3d0$@eu>
 <004501db441e$18e46310$4aad2930$@eu>
 <48bd29a1-4aa3-44e0-8beb-d8f28c9b4806@headcrashing.eu>
Message-ID: <ea9d6d2c-b1de-4671-bb25-8e1f65b4b0f7@headcrashing.eu>

As recently announced, kindly inviting everybody to contribute / review 
/ comment on https://github.com/openjdk/jdk/pull/21730. Thank you!

-Markus Karg


Am 09.02.2025 um 19:34 schrieb Markus KARG:
>
> Thank you, everybody. As no more comments arrived in the past eight 
> weeks, I assume that there is implicit agreement with my latest 
> arguments (see below), so next I will provide a PR to continue 
> discussion with real Java code at hand.
>
> -Markus
>
>
> Am 01.12.2024 um 19:23 schrieb Markus Karg:
>>
>> As Thanksgiving is over, and as work towards 24-RDP1 should mostly be 
>> done, I think it is a good time to resume our now.
>>
>> To kick-off, below I am repeating my last response to Chen. Kindly 
>> asking everybody to chime in, so we can find a feasible and 
>> beneficial conclusion in this area.
>>
>> -Markus
>>
>> *Von:*Markus Karg [mailto:markus at headcrashing.eu]
>> *Gesendet:* Sonntag, 27. Oktober 2024 09:44
>> *An:* 'core-libs-dev'
>> *Betreff:* Request for Comments: Adding bulk-read method 
>> "CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int 
>> dstBegin)"
>>
>> >Hi Markus,
>>
>> >Should we drop the srcBigin/srcEnd parameters, as they can be replaced by a 
>> subSequence(srcBegin, srcEnd) call?
>>
>> Chen, I do understand your idea and while originally I had the same 
>> in mind (it really /is/ appealing!), I came up with a draft using the 
>> *original* String.getChars()signature instead, due to the following 
>> drawbacks:
>>
>>   * There might exist (possibly lotsof) CharSequence.getChars(int,
>>     int, char[], int)implementations already, as this problem (and
>>     the idea how to solve it) is anything but new. At least such
>>     implementations are String, StringBuilderand StringBuffer. If we
>>     come up with a different signature, then *none* of these already
>>     existing performance boosters will get used by
>>     Reader.of(CharSequence)automatically - at least until they come
>>     up with alias methods. Effectively this leads to (possibly lots)
>>     of alias methods. At least it leads to alias methods in String,
>>     StringBuilder, StringBufferand CharBuffer. In contrast, when
>>     keeping the signature copied from String.getChars, chances are
>>     good that (possibly lots of) implementations will /instantly/ be
>>     supported by Reader.of(CharSequence)without alias methods. At
>>     least, String, StringBuilderand StringBufferwill be.
>>   * Since decades people are now very used to
>>     StringBuilder.getChars(int, int, char[], int), so (possibly a lot
>>     of) people might simply /expect/ us to come up with that lengthy
>>     signature. These people might be rather confused (if not to say
>>     frustrated) when we now force them to write an intermediate
>>     subSequence(int, int)for something that was "such simple" before.
>>   * Custom implementations of CharSequence.subSequencecould come up
>>     with the (performance-wise "bad") idea of creating *copies*
>>     instead of views. At least it seems like AbstractStringBuilderis
>>     doing that, so chances are "good" that custom libs will do that,
>>     too. For example, because they need it for safety. Or possibly,
>>     because they have a technical reason that /enforces/ a copy. That
>>     would (possibly massively, depending on the actual class) spoil
>>     the idea of performance-boosting this RFC is all about.
>>
>> -Markus
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250209/fb35ef55/attachment-0001.htm>

From alan.bateman at oracle.com  Sun Feb  9 19:27:56 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sun, 9 Feb 2025 19:27:56 +0000
Subject: Request for Enhancement: java.io.Writer.of(Appendable) as an
 efficient alternative to java.io.StringWriter
In-Reply-To: <538b0443-bd36-4286-9a5f-cc6c7d161e37@headcrashing.eu>
References: <3d41a187-87f5-4a99-80c7-ba0593d4dbc1@headcrashing.eu>
 <CABe8uE2F=bROKVyNTccD7-o7R_8E1cjCKFncMvmtMrXybk3JrA@mail.gmail.com>
 <df49e253-1cea-4d4b-be10-5b5831092219@headcrashing.eu>
 <CABe8uE0Err3uUtkDqMxeVArp0LHKzeSr5k03zFG7VwswwdWZ3A@mail.gmail.com>
 <6ed5af05-6cc8-46ae-8ef4-4dbbc7f410e8@headcrashing.eu>
 <538b0443-bd36-4286-9a5f-cc6c7d161e37@headcrashing.eu>
Message-ID: <54518836-3ec8-4253-8c6f-0f3670541c9f@oracle.com>

On 26/01/2025 16:37, Markus KARG wrote:
>
> As there have not been any more comments so far in the past weeks, I 
> assume there is common agreement with my current proposal.
>
I don't think you can assume this. There are many large projects and 
other significant efforts in progress so it's more likely that the 
maintainers just haven't had any cycles to work through the implications.

-Alan

From markus at headcrashing.eu  Sun Feb  9 21:34:43 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Sun, 9 Feb 2025 22:34:43 +0100
Subject: Request for Enhancement: java.io.Writer.of(Appendable) as an
 efficient alternative to java.io.StringWriter
In-Reply-To: <54518836-3ec8-4253-8c6f-0f3670541c9f@oracle.com>
References: <3d41a187-87f5-4a99-80c7-ba0593d4dbc1@headcrashing.eu>
 <CABe8uE2F=bROKVyNTccD7-o7R_8E1cjCKFncMvmtMrXybk3JrA@mail.gmail.com>
 <df49e253-1cea-4d4b-be10-5b5831092219@headcrashing.eu>
 <CABe8uE0Err3uUtkDqMxeVArp0LHKzeSr5k03zFG7VwswwdWZ3A@mail.gmail.com>
 <6ed5af05-6cc8-46ae-8ef4-4dbbc7f410e8@headcrashing.eu>
 <538b0443-bd36-4286-9a5f-cc6c7d161e37@headcrashing.eu>
 <54518836-3ec8-4253-8c6f-0f3670541c9f@oracle.com>
Message-ID: <ca7582b9-be52-42bd-bb42-71058aec6558@headcrashing.eu>

Alan,

those big projects are really much appreciated by the community. 
Nevertheless there must not be a mutual exclusive situation, as other 
contributors are working on other things which are also appreciated by 
the same community.

So how to proceed? Stop all my work for many more months? Looking at the 
number and status of all those large projects I doubt that this 
situation will change drastically before end of 2025.

We need to find a way that allows external contributors like me to 
proceed, though.

If we haven't enough reviewers / commiters for both, we simply need to 
nominate more.

-Markus


Am 09.02.2025 um 20:27 schrieb Alan Bateman:
> On 26/01/2025 16:37, Markus KARG wrote:
>>
>> As there have not been any more comments so far in the past weeks, I 
>> assume there is common agreement with my current proposal.
>>
> I don't think you can assume this. There are many large projects and 
> other significant efforts in progress so it's more likely that the 
> maintainers just haven't had any cycles to work through the implications.
>
> -Alan

From liangchenblue at gmail.com  Mon Feb 10 00:51:07 2025
From: liangchenblue at gmail.com (Chen Liang)
Date: Sun, 9 Feb 2025 18:51:07 -0600
Subject: Request for Enhancement: java.io.Writer.of(Appendable) as an
 efficient alternative to java.io.StringWriter
In-Reply-To: <ca7582b9-be52-42bd-bb42-71058aec6558@headcrashing.eu>
References: <3d41a187-87f5-4a99-80c7-ba0593d4dbc1@headcrashing.eu>
 <CABe8uE2F=bROKVyNTccD7-o7R_8E1cjCKFncMvmtMrXybk3JrA@mail.gmail.com>
 <df49e253-1cea-4d4b-be10-5b5831092219@headcrashing.eu>
 <CABe8uE0Err3uUtkDqMxeVArp0LHKzeSr5k03zFG7VwswwdWZ3A@mail.gmail.com>
 <6ed5af05-6cc8-46ae-8ef4-4dbbc7f410e8@headcrashing.eu>
 <538b0443-bd36-4286-9a5f-cc6c7d161e37@headcrashing.eu>
 <54518836-3ec8-4253-8c6f-0f3670541c9f@oracle.com>
 <ca7582b9-be52-42bd-bb42-71058aec6558@headcrashing.eu>
Message-ID: <CABe8uE22KZi9egWUCdg_UmKh-75yhSC8+yv9v5vt1NOPnh=zVQ@mail.gmail.com>

Hi Mark,
After thinking about the Appendable-Closeable-Flushable trio versus Writer,
I believe that one problem with Writer.of is that it goes against interface
segregation principle represented by the trifecta, and accidentally leaking
the Closeable or Flushable functionality is still dubious to me. This
appears simple, but it may cause unintended consequences, such as if
Appendable b implements Closeable too, its closing behavior is not proxied
and users may find this inconsistency weird. And as for interface
segregation principle, it means APIs should request Appendable instead of
Writer if they only need writing abilities with no lifecycle; using Writer
as the type implies potential dependency on closing/flushing behavior,
which can sometimes be dangerous.

> So how to proceed? Stop all my work for many more months?

Unfortunately, Mark, many ideas turn out not to be good ideas. I don't know
how many months have Alan's works on security manager, finalizers, or
serializations have stopped, but sometimes things have troubles, and due to
various considerations such as "not sending a false signal" or
compatibility, we often cannot take action (see https://openjdk.org/jeps/154
)

Regards,
Chen

On Sun, Feb 9, 2025 at 3:35?PM Markus KARG <markus at headcrashing.eu> wrote:

> Alan,
>
> those big projects are really much appreciated by the community.
> Nevertheless there must not be a mutual exclusive situation, as other
> contributors are working on other things which are also appreciated by
> the same community.
>
> So how to proceed? Stop all my work for many more months? Looking at the
> number and status of all those large projects I doubt that this
> situation will change drastically before end of 2025.
>
> We need to find a way that allows external contributors like me to
> proceed, though.
>
> If we haven't enough reviewers / commiters for both, we simply need to
> nominate more.
>
> -Markus
>
>
> Am 09.02.2025 um 20:27 schrieb Alan Bateman:
> > On 26/01/2025 16:37, Markus KARG wrote:
> >>
> >> As there have not been any more comments so far in the past weeks, I
> >> assume there is common agreement with my current proposal.
> >>
> > I don't think you can assume this. There are many large projects and
> > other significant efforts in progress so it's more likely that the
> > maintainers just haven't had any cycles to work through the implications.
> >
> > -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250209/d375e436/attachment-0001.htm>

From liangchenblue at gmail.com  Mon Feb 10 01:02:25 2025
From: liangchenblue at gmail.com (Chen Liang)
Date: Sun, 9 Feb 2025 19:02:25 -0600
Subject: Request for Comments: Adding bulk-read method
 "CharSequence.getChars(int
 srcBegin, int srcEnd, char[] dst, int dstBegin)"
In-Reply-To: <ea9d6d2c-b1de-4671-bb25-8e1f65b4b0f7@headcrashing.eu>
References: <000001db2704$04318bf0$0c94a3d0$@eu>
 <004501db441e$18e46310$4aad2930$@eu>
 <48bd29a1-4aa3-44e0-8beb-d8f28c9b4806@headcrashing.eu>
 <ea9d6d2c-b1de-4671-bb25-8e1f65b4b0f7@headcrashing.eu>
Message-ID: <CABe8uE0V55oBOGtrBBQTci8W73WCj6-aQgmiRHNAnjnx09yXjQ@mail.gmail.com>

This API seems tricky again... I don't wish to see patterns like:

cs.getChars(begin, end, dest, 0);
if (charSequence.getClass().getModule() != Object.class.getModule()) {
    dest = dest.clone();
}

to ensure the safety of the copy.

Also in this pattern, the dest array is often a shared cache array; sharing
such a cache array to arbitrary charsequence implementations is almost
always inherently unsafe, and this makes destBegin argument pointless as
such a call pollutes the whole dest array.

Regards,
Chen Liang

On Sun, Feb 9, 2025 at 12:50?PM Markus KARG <markus at headcrashing.eu> wrote:

> As recently announced, kindly inviting everybody to contribute / review /
> comment on https://github.com/openjdk/jdk/pull/21730. Thank you!
>
> -Markus Karg
>
>
> Am 09.02.2025 um 19:34 schrieb Markus KARG:
>
> Thank you, everybody. As no more comments arrived in the past eight weeks,
> I assume that there is implicit agreement with my latest arguments (see
> below), so next I will provide a PR to continue discussion with real Java
> code at hand.
>
> -Markus
>
>
> Am 01.12.2024 um 19:23 schrieb Markus Karg:
>
> As Thanksgiving is over, and as work towards 24-RDP1 should mostly be
> done, I think it is a good time to resume our now.
>
>
>
> To kick-off, below I am repeating my last response to Chen. Kindly asking
> everybody to chime in, so we can find a feasible and beneficial conclusion
> in this area.
>
>
>
> -Markus
>
>
>
>
>
> *Von:* Markus Karg [mailto:markus at headcrashing.eu <markus at headcrashing.eu>]
>
> *Gesendet:* Sonntag, 27. Oktober 2024 09:44
> *An:* 'core-libs-dev'
> *Betreff:* Request for Comments: Adding bulk-read method
> "CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)"
>
>
>
> >Hi Markus,
>
> >Should we drop the srcBigin/srcEnd parameters, as they can be replaced by
> a subSequence(srcBegin, srcEnd) call?
>
> Chen, I do understand your idea and while originally I had the same in
> mind (it really *is* appealing!), I came up with a draft using the
> *original* String.getChars() signature instead, due to the following
> drawbacks:
>
>    - There might exist (possibly lotsof) CharSequence.getChars(int, int,
>    char[], int) implementations already, as this problem (and the idea
>    how to solve it) is anything but new. At least such implementations are
>    String, StringBuilder and StringBuffer. If we come up with a different
>    signature, then *none* of these already existing performance boosters
>    will get used by Reader.of(CharSequence) automatically - at least
>    until they come up with alias methods. Effectively this leads to (possibly
>    lots) of alias methods. At least it leads to alias methods in String,
>    StringBuilder, StringBuffer and CharBuffer. In contrast, when keeping
>    the signature copied from String.getChars, chances are good that
>    (possibly lots of) implementations will *instantly* be supported by
>    Reader.of(CharSequence) without alias methods. At least, String,
>    StringBuilder and StringBuffer will be.
>    - Since decades people are now very used to StringBuilder.getChars(int,
>    int, char[], int), so (possibly a lot of) people might simply *expect*
>    us to come up with that lengthy signature. These people might be rather
>    confused (if not to say frustrated) when we now force them to write an
>    intermediate subSequence(int, int) for something that was "such
>    simple" before.
>    - Custom implementations of CharSequence.subSequence could come up
>    with the (performance-wise "bad") idea of creating *copies* instead of
>    views. At least it seems like AbstractStringBuilder is doing that, so
>    chances are "good" that custom libs will do that, too. For example, because
>    they need it for safety. Or possibly, because they have a technical reason
>    that *enforces* a copy. That would (possibly massively, depending on
>    the actual class) spoil the idea of performance-boosting this RFC is all
>    about.
>
> -Markus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250209/8dea295d/attachment.htm>

From duke at openjdk.org  Mon Feb 10 01:44:24 2025
From: duke at openjdk.org (Nicole Xu)
Date: Mon, 10 Feb 2025 01:44:24 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <ljxrhzoRck0LUkRbHYC_0hfPXiW_L1vuw0K7B8lKUKY=.fea555f9-651a-47a1-8c98-b33470d85a8b@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <ljxrhzoRck0LUkRbHYC_0hfPXiW_L1vuw0K7B8lKUKY=.fea555f9-651a-47a1-8c98-b33470d85a8b@github.com>
Message-ID: <2wciGZERU8bFZReIK9wzaQEFGMBwbbMWfneJGWjTPKg=.afc9ea1d-860b-46b6-a243-a107330041a5@github.com>

On Tue, 4 Feb 2025 18:55:25 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86 and AArch64 with the following error:
>> 
>> 
>> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
>> 
>> 
>> The variable `long256_arr_idx` is misused when indexing  'LongVector l2, l3, l4, l5' in function `maskedLogicOperationsLongKernel()`. 'long256_arr_idx' increases by 4 every time the benchmark runs and ensures the incremented value remains within the bounds of the array. However, for `LongVector.SPECIES_512`, it loads 8 numbers from the array each time the benchmark runs, resulting in an out-of-range indexing issue.
>> 
>> Hence, we revised the index variables from `long256_arr_idx` to `long512_arr_idx`, which has a stride of 8, to ensure that the loaded vector is inside of the array boundary for all vector species. This is also consistent with other kernel functions.
>> 
>> Additionally, some defined but unused variables have been removed.
>
> Oh, the OCA-verify is still stuck. I'm sorry about that ? 
> I pinged my manager @TobiHartmann , he will reach out to see what's the issue.

Thanks @eme64. The OCA finally passed! ?

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

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2646741800

From duke at openjdk.org  Mon Feb 10 01:48:24 2025
From: duke at openjdk.org (Nicole Xu)
Date: Mon, 10 Feb 2025 01:48:24 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
Message-ID: <d73Sr2-j9wtDlVxTzZmlw4eM9OIp2wnm3MkQsP8uQGg=.7bfe93a6-6fee-43f4-9305-008203262ef3@github.com>

On Wed, 8 Jan 2025 09:04:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86 and AArch64 with the following error:
> 
> 
> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
> 
> 
> The variable `long256_arr_idx` is misused when indexing  'LongVector l2, l3, l4, l5' in function `maskedLogicOperationsLongKernel()`. 'long256_arr_idx' increases by 4 every time the benchmark runs and ensures the incremented value remains within the bounds of the array. However, for `LongVector.SPECIES_512`, it loads 8 numbers from the array each time the benchmark runs, resulting in an out-of-range indexing issue.
> 
> Hence, we revised the index variables from `long256_arr_idx` to `long512_arr_idx`, which has a stride of 8, to ensure that the loaded vector is inside of the array boundary for all vector species. This is also consistent with other kernel functions.
> 
> Additionally, some defined but unused variables have been removed.

Hi @jatin-bhateja Would you help to review the patch and verify the changes? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2646745390

From davidalayachew at gmail.com  Mon Feb 10 03:16:07 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 9 Feb 2025 22:16:07 -0500
Subject: Request for Comments: Adding bulk-read method
 "CharSequence.getChars(int
 srcBegin, int srcEnd, char[] dst, int dstBegin)"
In-Reply-To: <48bd29a1-4aa3-44e0-8beb-d8f28c9b4806@headcrashing.eu>
References: <000001db2704$04318bf0$0c94a3d0$@eu>
 <004501db441e$18e46310$4aad2930$@eu>
 <48bd29a1-4aa3-44e0-8beb-d8f28c9b4806@headcrashing.eu>
Message-ID: <CAA9v-_O=DwUD8OLpbVDEUtWjRvzCZng0K0BhQcB1nc4qhyxdXA@mail.gmail.com>

Hello Markus,

I am ignorant about the larger topic, so I will only respond to the
following point.

> Thank you, everybody. As no more comments arrived in the past eight
weeks, I assume that there is implicit agreement with my latest arguments
(see below), so next I will provide a PR to continue discussion with real
Java code at hand.

No.

In general, it's considered a faux pas to try and make a PR before getting
the thumb's up from at least a few people via the mailing lists. If people
have concerns about the design, the intent is to continue hashing it out on
the mailing lists until they have been addressed. Making a PR before those
issues are resolved is considered premature.

And if there is a general sense of no-response, you can knock the door a
few times, but after that, no-response should be interpreted as rejection
if the above points aren't dealt with.

On Sun, Feb 9, 2025, 1:35?PM Markus KARG <markus at headcrashing.eu> wrote:

> Thank you, everybody. As no more comments arrived in the past eight weeks,
> I assume that there is implicit agreement with my latest arguments (see
> below), so next I will provide a PR to continue discussion with real Java
> code at hand.
>
> -Markus
>
>
> Am 01.12.2024 um 19:23 schrieb Markus Karg:
>
> As Thanksgiving is over, and as work towards 24-RDP1 should mostly be
> done, I think it is a good time to resume our now.
>
>
>
> To kick-off, below I am repeating my last response to Chen. Kindly asking
> everybody to chime in, so we can find a feasible and beneficial conclusion
> in this area.
>
>
>
> -Markus
>
>
>
>
>
> *Von:* Markus Karg [mailto:markus at headcrashing.eu <markus at headcrashing.eu>]
>
> *Gesendet:* Sonntag, 27. Oktober 2024 09:44
> *An:* 'core-libs-dev'
> *Betreff:* Request for Comments: Adding bulk-read method
> "CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)"
>
>
>
> >Hi Markus,
>
> >Should we drop the srcBigin/srcEnd parameters, as they can be replaced by
> a subSequence(srcBegin, srcEnd) call?
>
> Chen, I do understand your idea and while originally I had the same in
> mind (it really *is* appealing!), I came up with a draft using the
> *original* String.getChars() signature instead, due to the following
> drawbacks:
>
>    - There might exist (possibly lotsof) CharSequence.getChars(int, int,
>    char[], int) implementations already, as this problem (and the idea
>    how to solve it) is anything but new. At least such implementations are
>    String, StringBuilder and StringBuffer. If we come up with a different
>    signature, then *none* of these already existing performance boosters
>    will get used by Reader.of(CharSequence) automatically - at least
>    until they come up with alias methods. Effectively this leads to (possibly
>    lots) of alias methods. At least it leads to alias methods in String,
>    StringBuilder, StringBuffer and CharBuffer. In contrast, when keeping
>    the signature copied from String.getChars, chances are good that
>    (possibly lots of) implementations will *instantly* be supported by
>    Reader.of(CharSequence) without alias methods. At least, String,
>    StringBuilder and StringBuffer will be.
>    - Since decades people are now very used to StringBuilder.getChars(int,
>    int, char[], int), so (possibly a lot of) people might simply *expect*
>    us to come up with that lengthy signature. These people might be rather
>    confused (if not to say frustrated) when we now force them to write an
>    intermediate subSequence(int, int) for something that was "such
>    simple" before.
>    - Custom implementations of CharSequence.subSequence could come up
>    with the (performance-wise "bad") idea of creating *copies* instead of
>    views. At least it seems like AbstractStringBuilder is doing that, so
>    chances are "good" that custom libs will do that, too. For example, because
>    they need it for safety. Or possibly, because they have a technical reason
>    that *enforces* a copy. That would (possibly massively, depending on
>    the actual class) spoil the idea of performance-boosting this RFC is all
>    about.
>
> -Markus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250209/79db5475/attachment-0001.htm>

From davidalayachew at gmail.com  Mon Feb 10 03:28:12 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 9 Feb 2025 22:28:12 -0500
Subject: Request for Enhancement: java.io.Writer.of(Appendable) as an
 efficient alternative to java.io.StringWriter
In-Reply-To: <ca7582b9-be52-42bd-bb42-71058aec6558@headcrashing.eu>
References: <3d41a187-87f5-4a99-80c7-ba0593d4dbc1@headcrashing.eu>
 <CABe8uE2F=bROKVyNTccD7-o7R_8E1cjCKFncMvmtMrXybk3JrA@mail.gmail.com>
 <df49e253-1cea-4d4b-be10-5b5831092219@headcrashing.eu>
 <CABe8uE0Err3uUtkDqMxeVArp0LHKzeSr5k03zFG7VwswwdWZ3A@mail.gmail.com>
 <6ed5af05-6cc8-46ae-8ef4-4dbbc7f410e8@headcrashing.eu>
 <538b0443-bd36-4286-9a5f-cc6c7d161e37@headcrashing.eu>
 <54518836-3ec8-4253-8c6f-0f3670541c9f@oracle.com>
 <ca7582b9-be52-42bd-bb42-71058aec6558@headcrashing.eu>
Message-ID: <CAA9v-_PCtW6zRuN73NXJpbFNT-sK3MCESTtU5AoMeO+jEOPX7w@mail.gmail.com>

Hello Markus,

I already posted a response, but since you added more detail, I will adress
that detail too.

> So how to proceed? Stop all my work for many more months?

Address the criticisms (which you did), and knock on the door once or twice
if you get no responses.

But if after all of that, you get lukewarm or no response, then yes, you
should interpret that as a rejection of your idea. You need to get at least
a few people to thumb's up your idea before making a PR, else it is a faux
pas.

One of the goals of these mailing lists is to propose ideas and garner
community approval. I can tell you from 1st and 2nd hand experience that
there are literally >100 developers with over a decade of experience who
read *every single message* that goes through this mailing list. It may not
be immediate, but the above statement becomes true after <3-4 weeks for
each message.

All of that is to say, if your idea did not get picked up by that point,
then that answers your question.

> We need to find a way that allows external contributors like me to
proceed, though.

This mailing list is the way, via the method described above.

> If we haven't enough reviewers / commiters for both, we simply need to
nominate more.

There are more than enough of both. This thread not getting attention is
not for a lack of reviewers or commiters.

On Sun, Feb 9, 2025, 4:35?PM Markus KARG <markus at headcrashing.eu> wrote:

> Alan,
>
> those big projects are really much appreciated by the community.
> Nevertheless there must not be a mutual exclusive situation, as other
> contributors are working on other things which are also appreciated by
> the same community.
>
> So how to proceed? Stop all my work for many more months? Looking at the
> number and status of all those large projects I doubt that this
> situation will change drastically before end of 2025.
>
> We need to find a way that allows external contributors like me to
> proceed, though.
>
> If we haven't enough reviewers / commiters for both, we simply need to
> nominate more.
>
> -Markus
>
>
> Am 09.02.2025 um 20:27 schrieb Alan Bateman:
> > On 26/01/2025 16:37, Markus KARG wrote:
> >>
> >> As there have not been any more comments so far in the past weeks, I
> >> assume there is common agreement with my current proposal.
> >>
> > I don't think you can assume this. There are many large projects and
> > other significant efforts in progress so it's more likely that the
> > maintainers just haven't had any cycles to work through the implications.
> >
> > -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250209/7b95a5de/attachment.htm>

From jiangli at openjdk.org  Mon Feb 10 03:53:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 03:53:09 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v2]
In-Reply-To: <DvvA7piLSCsjhlUXRfHCpA5tQMfj5lifvJmcCpaiqvc=.402f8dd1-8b1b-4fd1-90a3-10e6f38debe2@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <2i2FPE7phj9T1M0tOJpzD8SQGr3G-l2Ij6GGPgy1JoE=.efedd3f1-88ef-4f94-a3fb-47e1d7bb91bf@github.com>
 <DvvA7piLSCsjhlUXRfHCpA5tQMfj5lifvJmcCpaiqvc=.402f8dd1-8b1b-4fd1-90a3-10e6f38debe2@github.com>
Message-ID: <0eVzIjugTG80YcdBQ46poOhNtkPHHpmV4QhvQU0znZc=.7a325e78-11ed-42ae-bee6-7f94968c01c3@github.com>

On Sat, 8 Feb 2025 09:29:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Is the JavaVM param passed to JNI_OnLoad usable in static builds? If so then this just needs to be saved, no need to use GetCreatedJavaVMs, right?

Yes, on static JDK, `JNI_OnLoad`'s `JavaVM *` argument behaves the same as on regular JDK. It points to the current VM. IIUC, `libExplicitAttach.c` does not appear to explicitly test `JNI_GetCreatedJavaVMs`, but only calls it to retrieve the VM. Removing the `JNI_GetCreatedJavaVMs` call can result a cleaner fix. Thanks for pointing that out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23500#discussion_r1948363497

From jiangli at openjdk.org  Mon Feb 10 03:56:42 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 03:56:42 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v3]
In-Reply-To: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
Message-ID: <C9OCiz0yBcm7d-Q8sXlTfeB1GDnJ7Q0CEVb0NbNfNiw=.e5f126a7-35c5-488d-bec4-72b9be53ebee@github.com>

> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
> 
> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.

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

  - Stash `JavaVM *` argument from `JNI_OnLoad`. Remove `JNI_GetCreatedJavaVMs`. Thanks AlanBateman for noticing that.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23500/files
  - new: https://git.openjdk.org/jdk/pull/23500/files/4ee170d2..1da4da96

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

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

PR: https://git.openjdk.org/jdk/pull/23500

From jbhateja at openjdk.org  Mon Feb 10 05:33:25 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 10 Feb 2025 05:33:25 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v17]
In-Reply-To: <sgcWAEvXaWi40uFqPPJq-e6n3YsHb7agKBUrMBdqJSc=.48c41eab-6641-45b7-9765-400622894f4b@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <sgcWAEvXaWi40uFqPPJq-e6n3YsHb7agKBUrMBdqJSc=.48c41eab-6641-45b7-9765-400622894f4b@github.com>
Message-ID: <LgeejggXLAJq4_9FPPMg5w2HFVYid76BGKErA1D2u_0=.9a64cd0b-0cff-4aa1-a2f3-6c380d00de4e@github.com>

On Tue, 4 Feb 2025 10:05:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing typos

Hi @PaulSandoz , Kindly let us know if this is good for integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2646957788

From alanb at openjdk.org  Mon Feb 10 07:28:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Feb 2025 07:28:10 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK
In-Reply-To: <QoEI4kUeWxoE5yM9EfbcJeeZlzV-giwgoxb_Qhwi0OM=.9c427c9a-11f0-4e5f-9cc5-19187f320dc7@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <5uzw7F8io2kdoROQLcPw9Q3lJe5SKxyysAag22QD-4Y=.4d026330-4326-49e9-a50e-1dfe66d2a5a2@github.com>
 <QoEI4kUeWxoE5yM9EfbcJeeZlzV-giwgoxb_Qhwi0OM=.9c427c9a-11f0-4e5f-9cc5-19187f320dc7@github.com>
Message-ID: <OYwib11w03AEAzDGZikCoKJ9iU2dtWEEYs75Un_XaYQ=.1c3a64be-2102-4567-990c-027357100933@github.com>

On Fri, 7 Feb 2025 20:10:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Done, thanks. Moved `JNI_GetCreatedJavaVMs` lookup into JNI_OnLoad.

Good, this is much better.

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

PR Comment: https://git.openjdk.org/jdk/pull/23500#issuecomment-2647141990

From alanb at openjdk.org  Mon Feb 10 07:28:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Feb 2025 07:28:09 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v4]
In-Reply-To: <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
Message-ID: <pFzTAAZwyjTRz-CsWzU2OcjPckrdszkyPfd0pB0yUv0=.f5eb8fdc-09fb-4b11-a4df-c20c222ba69f@github.com>

On Mon, 10 Feb 2025 04:00:44 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
>> 
>> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused variables.

Can you bump the copyright header date on libExplicitAttach.c before you integrate.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23500#pullrequestreview-2604875066

From alanb at openjdk.org  Mon Feb 10 08:24:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Feb 2025 08:24:10 GMT
Subject: RFR: 8349620: Add VMProps for static JDK
In-Reply-To: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
Message-ID: <JIm6MX4f6S8SxGx-IlJGov7rvsFZqLLQACrIZozjl5k=.0c185caf-30a2-4b1a-95bf-b526bc0012ec@github.com>

On Fri, 7 Feb 2025 23:51:41 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
> 
> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
> 
> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.

I think this looks okay, I'm just wondering is one property is enough to cover all the configurations.

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

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2647241299

From alanb at openjdk.org  Mon Feb 10 08:42:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Feb 2025 08:42:11 GMT
Subject: RFR: 8349543: LinkedBlockingDeque does not immediately throw
 InterrruptedException in put/take
In-Reply-To: <Da_VhZrKMVCSNPN6BSYHrYLsU3MnehmJZcI0ZJUzaJ8=.eb25a512-e279-47f4-ae14-11c965f204cd@github.com>
References: <Da_VhZrKMVCSNPN6BSYHrYLsU3MnehmJZcI0ZJUzaJ8=.eb25a512-e279-47f4-ae14-11c965f204cd@github.com>
Message-ID: <PbUTTLzO-VvAVic__PDQQWudxzjEPhTOl8yBq_TQ3p4=.92fc7515-d31d-4c71-84e7-1fcd458e576e@github.com>

On Wed, 5 Feb 2025 15:36:15 GMT, kabutz <duke at openjdk.org> wrote:

> The LinkedBlockingDeque does not behave consistently with other concurrency components. If we call putFirst(), putLast(), takeFirst(), or takeLast() with a thread that is interrupted, it does not immediately throw an InterruptedException, the way that ArrayBlockingQueue and LInkedBlockingQueue does, because instead of lockInterruptibly(), we call lock(). It will only throw an InterruptedException if the queue is full (on put) or empty (on take). Since interruptions are frequently used as a shutdown mechanism, this might prevent code from ever shutting down.

I think this is okay. Anything calling these methods already has to deal with InterruptedException. I see that the implementation offerFirst/offerLast/pollFirst/pollLast is using lockInterruptibly so if usage extends to these methods then there is already the possibility of the exception when calling them with the interrupt status set.

Given the behavior change then a CSR + release notes would be good but I think it's overall.

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

PR Comment: https://git.openjdk.org/jdk/pull/23464#issuecomment-2647283704

From pminborg at openjdk.org  Mon Feb 10 08:53:49 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Feb 2025 08:53:49 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v2]
In-Reply-To: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
References: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
Message-ID: <kHJrhD8Ci36hLzZxxeYphoDjLYjjPq_OYCFomWwx0pU=.6b721f61-171a-4993-8f18-c4958182c407@github.com>

> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes to add a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively:
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.193 ? 0.268  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.268 ? 0.080  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  42.076 ? 1.003  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.801 ? 0.138  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.265 ? 0.087  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.285 ? 0.155  ns/op
> 
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.033 ? 0.423  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   3.676 ? 0.104  ns/op  // <- Happy path using an internal pool
> 
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.023 ? 0.736  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  22.013 ? 0.648  ns/op  // <- Allocating memory upon each invocation
> 
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  22.050 ? 0.233  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   3.756 ? 0.056  ns/op  // <- Using the pool explicitly from Java code
> 
> 
> Adapted system call:
> 
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> 
> 
> Explicit allocation:
> 
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> 
> 
> Thread Local allocation:
> 
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> 
> 
> The adapted system call exhibits a ~6x performanc...

Per Minborg has updated the pull request incrementally with four additional commits since the last revision:

 - Clean up
 - Fix test issue and polish comments
 - Use lazy initialization
 - Improve comments and formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23517/files
  - new: https://git.openjdk.org/jdk/pull/23517/files/4acac9e9..1c2b437e

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

  Stats: 188 lines in 2 files changed: 83 ins; 21 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/23517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23517/head:pull/23517

PR: https://git.openjdk.org/jdk/pull/23517

From pminborg at openjdk.org  Mon Feb 10 09:20:17 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Feb 2025 09:20:17 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v31]
In-Reply-To: <wmzwqSiFdhqcr8MsGA9FjLjix25b2xbUR6EMldc2k9c=.8f74f6ad-c453-459b-a6ed-8091e1a8794e@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <wmzwqSiFdhqcr8MsGA9FjLjix25b2xbUR6EMldc2k9c=.8f74f6ad-c453-459b-a6ed-8091e1a8794e@github.com>
Message-ID: <rr-1SsRzTqZ5SD8XrbZtUKPrROkuLgs-XZx0RwVV7aA=.08d658b2-f59c-4185-bc5e-6d631ba20052@github.com>

On Wed, 4 Dec 2024 14:56:02 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
>> 
>> The main steps of the algorithm are as follows:
>> first argument reduce the value to an integer using the following relations:
>> 
>> x = y * 10 ^ exp
>> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
>> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
>> 
>> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
>> 
>> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   An optimization

This PR seems to be targeting performance, yet no benchmarks are provided comparing the current vs. proposed branch with respect to performance. We need to understand the upside of the proposed changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2647388730

From galder at openjdk.org  Mon Feb 10 09:29:20 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 10 Feb 2025 09:29:20 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
Message-ID: <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>

On Fri, 7 Feb 2025 12:27:42 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> At 100% probability baseline fails to vectorize because it observes a control flow. This control flow is not the one you see in min/max implementations, but this is one added by HotSpot as a result of the JIT profiling. It observes that one branch is always taken so it optimizes for that, and adds a branch for the uncommon case where the branch is not taken.

I've dug further into this to try to understand how the baseline hotspot code works, and the explanation above is not entirely correct. Let's look at the IR differences between say 100% vs 80% branch situations.

At branch 80% you see:

 1115  CountedLoop  === 1115 598 463  [[ 1101 1115 1116 1118 451 594 ]] inner stride: 2 main of N1115 strip mined !orig=[599],[590],[307] !jvms: MinMaxVector::longLoopMax @ bci:10 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)

  692  LoadL  === 1083 1101 393  [[ 747 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9; #long (does not depend only on test, unknown control) !orig=[395] !jvms: MinMaxVector::longLoopMax @ bci:26 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
  651  LoadL  === 1095 1101 355  [[ 747 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9; #long (does not depend only on test, unknown control) !orig=[357] !jvms: MinMaxVector::longLoopMax @ bci:20 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
  747  MaxL  === _ 651 692  [[ 451 ]]  !orig=[608],[416] !jvms: Math::max @ bci:11 (line 2037) MinMaxVector::longLoopMax @ bci:27 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)

  451  StoreL  === 1115 1101 449 747  [[ 1116 454 911 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9;  Memory: @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=9; !orig=1124 !jvms: MinMaxVector::longLoopMax @ bci:30 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)

  594  CountedLoopEnd  === 1115 593  [[ 1123 463 ]] [lt] P=0.999731, C=780799.000000 !orig=[462] !jvms: MinMaxVector::longLoopMax @ bci:7 (line 235) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)


You see the counted loop with the LoadL for array loads and MaxL consuming those. The StoreL is for array assignment (I think).

At branch 100% you see:


  650  LoadL  === 1105 1119 355  [[ 416 408 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9; #long (does not depend only on test, unknown control) !orig=[357] !jvms: MinMaxVector::longLoopMax @ bci:20 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
  691  LoadL  === 1093 1119 393  [[ 416 408 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9; #long (does not depend only on test, unknown control) !orig=[395] !jvms: MinMaxVector::longLoopMax @ bci:26 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
  408  CmpL  === _ 650 691  [[ 409 ]]  !jvms: Math::max @ bci:3 (line 2037) MinMaxVector::longLoopMax @ bci:27 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
  409  Bool  === _ 408  [[ 410 ]] [lt] !jvms: Math::max @ bci:3 (line 2037) MinMaxVector::longLoopMax @ bci:27 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
  410  If  === 1132 409  [[ 411 412 ]] P=0.019892, C=79127.000000 !jvms: Math::max @ bci:3 (line 2037) MinMaxVector::longLoopMax @ bci:27 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
  411  IfTrue  === 410  [[ 415 ]] #1 !jvms: Math::max @ bci:3 (line 2037) MinMaxVector::longLoopMax @ bci:27 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
  412  IfFalse  === 410  [[ 415 ]] #0 !jvms: Math::max @ bci:3 (line 2037) MinMaxVector::longLoopMax @ bci:27 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
  415  Region  === 415 411 412  [[ 415 594 416 451 ]]  !orig=[423] !jvms: Math::max @ bci:11 (line 2037) MinMaxVector::longLoopMax @ bci:27 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)

  594  CountedLoopEnd  === 415 593  [[ 1139 463 ]] [lt] P=0.999683, C=706030.000000 !orig=[462] !jvms: MinMaxVector::longLoopMax @ bci:7 (line 235) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)


You see a region within the counted loop with the if/else which belongs to the actual `Math.max` implementation, with the corresponding CmpL and the LoadL nodes for retrieving the longs from the arrays.

What causes the difference? It's this section in `PhaseIdealLoop::conditional_move`:

```c++
  // Check for highly predictable branch.  No point in CMOV'ing if
  // we are going to predict accurately all the time.
  if (C->use_cmove() && (cmp_op == Op_CmpF || cmp_op == Op_CmpD)) {
    //keep going
  } else if (iff->_prob < infrequent_prob ||
      iff->_prob > (1.0f - infrequent_prob))
    return nullptr;


At branch 100 `iff->_prob > (1.0f - infrequent_prob)` becomes true and no CMoveL is created so hotspot seems to stick to the original bytecode implementation of `Math.max`. At branch 80 that comparison is below and CMoveL is created, which eventually gets converted into a MaxL node and vectorization kicks in. The numbers are interesting. `infrequent_prob` appears to be a fixed number `0.181818187` and `1.0f` minus that is `0.818181812`. So, at branch 100 `iff->_prob` is `0.906792104` therefore higher than `0.818181812`, and at branch 80 `0.718619287`. I would have expected those `iff->_prob` to be closer to the branch % targets I set, but ignoring that, seems like ~90% would be the cut off.

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2647410266

From shade at openjdk.org  Mon Feb 10 09:31:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Feb 2025 09:31:28 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v11]
In-Reply-To: <Qg6LRxXXXTeW4eITWQ_06w1nfpQBrf7irmF_WLsx9Kg=.07000623-4c26-4440-9a27-3c2e804ec14c@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <RQNxtymZk4gFgkve802B8cFKJEPReJwOoclLxHe43PA=.2fb4a5ed-0ef6-4914-b046-3cfab73ef8a0@github.com>
 <L-No84e66ZZFpxf_d3c2ePydWwzVN4-zSf3jY7Jj5GM=.d9dca630-dbe8-456a-8a2e-937bd49e09c8@github.com>
 <9e-kLX5DVX9v0teMvEFIrp6QaKM5g66WCaR8-pOwF2E=.a2be9c9f-804f-4228-9032-535dbcb5ff50@github.com>
 <Qg6LRxXXXTeW4eITWQ_06w1nfpQBrf7irmF_WLsx9Kg=.07000623-4c26-4440-9a27-3c2e804ec14c@github.com>
Message-ID: <8Ci27Bl509_2RKPjvYfv2QOdZ7UzP9dNOoTZQIpcrgc=.01e9fbb8-a292-4ad8-97eb-fd9e6e65ffff@github.com>

On Thu, 30 Jan 2025 16:25:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @kimbarrett Do you have a change coming to allow waitForPendingReferences be used by WB? I assume this will at least add a comment to the method (or whatever it changes to) to make it clear that it's for testing.
>
> @AlanBateman I've not done any work on JDK-8305186.  There has also been discussion about making
> that function non-private or even public (though with concerns about specification difficulty) for use in
> places like this.
> 
> @shipilev I'm working on a reply, but it might be long-ish.  That outpacing issue for some tests is why this
> code wasn't switched away from jdk.internal.ref.Cleaner a long time ago.  I'm still looking at it, but I currently
> don't think the canary provides a reliable solution to that.

I would like to integrate this PR. How are you doing, @kimbarrett? Have you found any major holes in it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1948705265

From dholmes at openjdk.org  Mon Feb 10 10:12:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Feb 2025 10:12:11 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]
In-Reply-To: <nX9vDm85JyvkMKXgWyk_hQbg8Sh0hEaUKfK4uNpKmDE=.34340f7f-2484-42fb-91cf-d47147c33195@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <syxVRD9ASKql288dZ8hdYJjliScymiDGldc7fSoEAiU=.d4084758-4fb0-496f-a7bb-ad0093129f11@github.com>
 <rnBxm-eKFKaOGdMay4i94tiSB28d_9s6SOrfGAnrTZk=.875ea4cd-2d71-4139-997c-ef1f1a0fd59d@github.com>
 <as8AhJFiM7kItFtO_ryI9gtRMyedA3SBBPMU53jA32A=.f1630384-852e-4273-83ff-52783e8a4699@github.com>
 <6TuFE5mx8jXm2donAE_cM3I5UXCaB1eKrpCyp7qk0wM=.1c585567-cf27-4d3e-bca9-4aa7a556942c@github.com>
 <nX9vDm85JyvkMKXgWyk_hQbg8Sh0hEaUKfK4uNpKmDE=.34340f7f-2484-42fb-91cf-d47147c33195@github.com>
Message-ID: <Rvmk6-e-vvVzFy-9cNmU7mPmK_u0_QnfFmWqNIs_dpM=.cb8e6a4e-e1b2-42a7-8b3a-3be797e700c5@github.com>

On Thu, 6 Feb 2025 12:12:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I am still missing what can actually set a PD here, sorry. ??
>
> Because the field is final, it has to be initialized in the constructor in Java code.  My initial patch for modifiers chose to initialize to zero but that's not quite correct.  The constructor cannot be called nor can it be made accessible with setAccessible().   So the constructor for java.lang.Class is essentially the Hotspot code JavaClasses::create_mirror().  This is where the PD is assigned.

Okay so this pattern of assigning the final fields in the constructor that is never called is just for appeasing the javac compiler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1948769808

From cstein at openjdk.org  Mon Feb 10 10:16:16 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 10 Feb 2025 10:16:16 GMT
Subject: RFR: 8150442: Enforce Supported Platforms in Packager for MSI
 bundles
In-Reply-To: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
References: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
Message-ID: <SdNcT1gYDwcYT-fVq0X1T4rdNGRs6R20AbS2Pqdv39s=.f11d2e03-7d17-4e6e-a879-2387afed5298@github.com>

On Wed, 5 Feb 2025 20:11:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Enable MSI installers to block installation if the version of Windows is too old.
> 
> jpackage will read major and minor OS versions from PE headers of the main launcher and `java.dll` in the app image. The combined version is the minimal Windows version these executables can run. Thus, it will be a lower bound for the Windows version the installer supports. 
> 
> The value of the combined version is passed as `JpExecutableOSVersion` WiX variable to a new `os-condition.wxf` WiX fragment. The fragment compares the value of `JpExecutableOSVersion` WiX variable with the value of `VersionNT` MSI property. If the value of the latter is less the installation is blocked.
> 
> The fragment can be overridden in the resource directory. This makes this feature fully customizable.

Integration with `jtreg` and JUnit looks good.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23472#pullrequestreview-2605292288

From yzheng at openjdk.org  Mon Feb 10 10:17:15 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 10 Feb 2025 10:17:15 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
Message-ID: <s10zFU38xW679o1IZQLM-ABYTxKHhGnVzX1sg0rVoiY=.7fe943fc-f4c0-4cd5-ab69-fb6dbfa6fde6@github.com>

On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jvmci test.

JVMCI change looks good to me

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

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2605295926

From dholmes at openjdk.org  Mon Feb 10 10:25:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Feb 2025 10:25:11 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v4]
In-Reply-To: <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
Message-ID: <ue30YRpX05j5Vck8GnhKUh1k_7wcnBFb-b6c9yRZDQo=.1287477c-818e-4fb1-b932-d5afdf0e481a@github.com>

On Mon, 10 Feb 2025 04:00:44 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
>> 
>> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused variables.

This seems a nice simplification to me too.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23500#pullrequestreview-2605315239

From pminborg at openjdk.org  Mon Feb 10 12:09:09 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Feb 2025 12:09:09 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v3]
In-Reply-To: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
References: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
Message-ID: <iQ6dV_DHPRQO8-WYar8gxYQ19n_cJL5VgJrUNdFeHm4=.2ddebba4-8c40-4c7a-a268-eb4dc79e829b@github.com>

> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes to add a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively:
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.193 ? 0.268  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.268 ? 0.080  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  42.076 ? 1.003  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.801 ? 0.138  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.265 ? 0.087  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.285 ? 0.155  ns/op
> 
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.033 ? 0.423  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   3.676 ? 0.104  ns/op  // <- Happy path using an internal pool
> 
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.023 ? 0.736  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  22.013 ? 0.648  ns/op  // <- Allocating memory upon each invocation
> 
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  22.050 ? 0.233  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   3.756 ? 0.056  ns/op  // <- Using the pool explicitly from Java code
> 
> 
> Adapted system call:
> 
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> 
> 
> Explicit allocation:
> 
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> 
> 
> Thread Local allocation:
> 
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> 
> 
> The adapted system call exhibits a ~6x performanc...

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

  Add stress test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23517/files
  - new: https://git.openjdk.org/jdk/pull/23517/files/1c2b437e..0e65ea5b

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

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

PR: https://git.openjdk.org/jdk/pull/23517

From vyazici at openjdk.org  Mon Feb 10 12:15:15 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 10 Feb 2025 12:15:15 GMT
Subject: Integrated: 8343074:
 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated
In-Reply-To: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
References: <SaExsbfzfVag7TcaZ6EehWBZyn6uudChgiN6snxh9nM=.6bcbee93-5493-45d6-a2b9-8d63e6416560@github.com>
Message-ID: <M77_bIz8YUrdPveEXOHgWUvweDTlEBibuA4qnohm0nU=.759e8496-dda0-41fb-b301-fbb0d1704995@github.com>

On Fri, 31 Jan 2025 19:42:55 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git:
> 
> 
> $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt
> $ sort -n /tmp/trackedFileSizes.txt | tail -n 4
> 2730088	test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt
> 2798680	src/java.base/share/data/unicodedata/NormalizationTest.txt
> 3574947	test/jdk/java/foreign/libTestDowncallStack.c
> 7128495	test/jdk/java/foreign/libTestUpcallStack.c
> 
> 
> **Other highlights:**
> 
> - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts`
> - `test.lib.Asserts::assertFileContentsEqual` is added

This pull request has now been integrated.

Changeset: 55898922
Author:    Volkan Yazici <vyazici at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/55898922628a7fb1aef3ff6727a612baac3f6b1a
Stats:     681 lines in 15 files changed: 235 ins; 281 del; 165 mod

8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated

Reviewed-by: dfuchs, jpai

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

PR: https://git.openjdk.org/jdk/pull/23401

From coleenp at openjdk.org  Mon Feb 10 12:47:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Feb 2025 12:47:31 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
Message-ID: <DmXMLnORTe6gOVepuVwqdgQDFU-2XSaO70XqWd1mhfU=.3cb505ca-fe8f-4e4b-940a-93713cb3f637@github.com>

On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jvmci test.

Thank you for the reviews Yudi, Alan, Chen, Vladimir and Dean, and the help and comments with the various pieces of this.

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2647880184

From coleenp at openjdk.org  Mon Feb 10 12:47:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Feb 2025 12:47:32 GMT
Subject: Integrated: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <-VYQTxGucpCCQZccdw6wMnDavFDAt75MDHY8mGxEMiw=.042099b8-41dc-4b0d-8bdd-a874f004a0f6@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

This pull request has now been integrated.

Changeset: c9cadbd2
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9cadbd23fb13933b8968f283d27842cd35f8d6f
Stats:     217 lines in 31 files changed: 71 ins; 127 del; 19 mod

8346567: Make Class.getModifiers() non-native

Reviewed-by: alanb, vlivanov, yzheng, dlong

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

PR: https://git.openjdk.org/jdk/pull/22652

From coleenp at openjdk.org  Mon Feb 10 13:23:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Feb 2025 13:23:49 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v7]
In-Reply-To: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
Message-ID: <gYu9Dt5fOYOETzUd4lXF-rUVu7jHsAS7okf_R7qUxHM=.996c13f8-d671-4713-839b-7d31c5444bfc@github.com>

> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into protection-domain
 - Move test for protectionDomain filtering.
 - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Remove @Stable annotation for final field.
 - Fix test that knows which fields are hidden from reflection in jvmci.
 - Hide Class.protectionDomain for reflection and add a test case.
 - Merge branch 'master' into protection-domain
 - Fix two tests.
 - Fix the test.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c9cadbd2...2208302c

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

Changes: https://git.openjdk.org/jdk/pull/23396/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23396&range=06
  Stats: 65 lines in 13 files changed: 15 ins; 34 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/23396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23396/head:pull/23396

PR: https://git.openjdk.org/jdk/pull/23396

From coleenp at openjdk.org  Mon Feb 10 13:31:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Feb 2025 13:31:12 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]
In-Reply-To: <Rvmk6-e-vvVzFy-9cNmU7mPmK_u0_QnfFmWqNIs_dpM=.cb8e6a4e-e1b2-42a7-8b3a-3be797e700c5@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <syxVRD9ASKql288dZ8hdYJjliScymiDGldc7fSoEAiU=.d4084758-4fb0-496f-a7bb-ad0093129f11@github.com>
 <rnBxm-eKFKaOGdMay4i94tiSB28d_9s6SOrfGAnrTZk=.875ea4cd-2d71-4139-997c-ef1f1a0fd59d@github.com>
 <as8AhJFiM7kItFtO_ryI9gtRMyedA3SBBPMU53jA32A=.f1630384-852e-4273-83ff-52783e8a4699@github.com>
 <6TuFE5mx8jXm2donAE_cM3I5UXCaB1eKrpCyp7qk0wM=.1c585567-cf27-4d3e-bca9-4aa7a556942c@github.com>
 <nX9vDm85JyvkMKXgWyk_hQbg8Sh0hEaUKfK4uNpKmDE=.34340f7f-2484-42fb-91cf-d47147c33195@github.com>
 <Rvmk6-e-vvVzFy-9cNmU7mPmK_u0_QnfFmWqNIs_dpM=.cb8e6a4e-e1b2-42a7-8b3a-3be797e700c5@github.com>
Message-ID: <-UEqYFgj9UYs8PyS9GLD2b1kU11bvMKi5vFmEbXcb-I=.14ab7e47-61dc-4c21-b2e6-8829e938b8c4@github.com>

On Mon, 10 Feb 2025 10:09:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Because the field is final, it has to be initialized in the constructor in Java code.  My initial patch for modifiers chose to initialize to zero but that's not quite correct.  The constructor cannot be called nor can it be made accessible with setAccessible().   So the constructor for java.lang.Class is essentially the Hotspot code JavaClasses::create_mirror().  This is where the PD is assigned.
>
> Okay so this pattern of assigning the final fields in the constructor that is never called is just for appeasing the javac compiler.

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1948979011

From coleenp at openjdk.org  Mon Feb 10 13:31:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Feb 2025 13:31:13 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v7]
In-Reply-To: <AJfrwbufV-R4ZyyH3aGupcDPvgjSsWwH5kE3za4o8y0=.4a05c30f-9b26-4aee-8ff1-563f778f6ec9@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <SOWXVHkeYjR8PkoJydN2M9rD5R6_yB464izVGrjBcEo=.c3cbd9b0-0a45-4fdb-bc71-ce348f73af86@github.com>
 <MvwTuFPKF_B6HWF6_L5yI06NvxTfLDKWoRufYKEU_8w=.a313ab4e-1ff8-4a03-a768-f43e8c38f993@github.com>
 <CxQeGbgbFQvte2g8TyIzgI6laS-EbiVpLiYBuPEG4fk=.d24c8dc3-7742-4dee-b13e-353c6a2d8a2d@github.com>
 <HjRm9YSBznG8WiaMkb6CwaCD1uZWzCYjHIHpQvLYMLI=.04c0edb6-196e-402a-a864-91deb4d69bd3@github.com>
 <LFWlDa9-UElLC3ANqbToOlHoaZBdDkitpzeAAQ1h61g=.944a60c7-f7d1-47ab-94af-d69d4cdc82fa@github.com>
 <AJfrwbufV-R4ZyyH3aGupcDPvgjSsWwH5kE3za4o8y0=.4a05c30f-9b26-4aee-8ff1-563f778f6ec9@github.com>
Message-ID: <KhJZzpVmxBoaY55VAZBK6668e5XaTJa3-l3T9XBFl8c=.32c64fb7-f87a-4e66-947e-2b6fa2c08efd@github.com>

On Tue, 4 Feb 2025 16:56:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Aside from JVMTI (CFLH for example), is there anything left in the VM that needs this? The last param to JVM_DefineClassWithSource has the location from the code source if available.
>
> The VM doesn't need this but it carries it around because it's a parameter to JVM_DefineClass and DefineClassWithSource (second to last parameter).  CFLH and CDS from what I can tell have it for the same purpose - ultimately to assign it into the mirror.
> There are some remaining code in the compilers (ci).  Not sure if they are needed without studying it more.

The remaining code in ci isn't necessary.  I filed and fixed another issue for that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1945033858

From vklang at openjdk.org  Mon Feb 10 13:32:14 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 10 Feb 2025 13:32:14 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <Amjp6MjM2sbIgfQA2_b2LLiX0LnU937qnuap_YFQk3g=.62530e00-3fb0-48c5-8c78-8732625731f9@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <Amjp6MjM2sbIgfQA2_b2LLiX0LnU937qnuap_YFQk3g=.62530e00-3fb0-48c5-8c78-8732625731f9@github.com>
Message-ID: <VAiPUvNDKG5MYvQPfQOKFfJN0yrM0MWRrza0TOZxCuE=.c8eabf09-90dd-4f62-8026-8fae205bb422@github.com>

On Sat, 18 Jan 2025 11:35:28 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
>> 
>> Modification:
>> Add detail error messages.
>> 
>> Result:
>> Helpful messages.
>
> I have another PR, I will wait before oca is completed.

Hi @He-Pin,

Thanks for your patience here?I've been in catch-up mode.

I didn't know there was already a PR for this issue when I created my PR for the issue, so in order to pick a PR to move forward with, would you prefer that I review your PR or would you rather move forward with the other PR?

Either works for me!

Cheers,
?

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

PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2647994356

From pminborg at openjdk.org  Mon Feb 10 14:27:28 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 10 Feb 2025 14:27:28 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v4]
In-Reply-To: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
References: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
Message-ID: <CucJcSwpBewVwNSDBO8_a-kABLbrSFDfW8HJouIpMmY=.29d12ce2-f64e-43dd-997d-36210538794f@github.com>

> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes to add a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively:
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.193 ? 0.268  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.268 ? 0.080  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  42.076 ? 1.003  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.801 ? 0.138  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.265 ? 0.087  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.285 ? 0.155  ns/op
> 
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.033 ? 0.423  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   3.676 ? 0.104  ns/op  // <- Happy path using an internal pool
> 
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.023 ? 0.736  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  22.013 ? 0.648  ns/op  // <- Allocating memory upon each invocation
> 
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  22.050 ? 0.233  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   3.756 ? 0.056  ns/op  // <- Using the pool explicitly from Java code
> 
> 
> Adapted system call:
> 
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> 
> 
> Explicit allocation:
> 
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> 
> 
> Thread Local allocation:
> 
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> 
> 
> The adapted system call exhibits a ~6x performanc...

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

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23517/files
  - new: https://git.openjdk.org/jdk/pull/23517/files/0e65ea5b..2fb7af12

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

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

PR: https://git.openjdk.org/jdk/pull/23517

From bpb at openjdk.org  Mon Feb 10 16:39:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Feb 2025 16:39:17 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v5]
In-Reply-To: <tvHVVZMbkAoFY__zewbMsAmDTpO7P-dfxHYo_7GRYxA=.20d64325-8276-4bef-acf9-08c62022c088@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <tvHVVZMbkAoFY__zewbMsAmDTpO7P-dfxHYo_7GRYxA=.20d64325-8276-4bef-acf9-08c62022c088@github.com>
Message-ID: <c8XE6UFnfeSmfjAz1-7Us2vT7ACYoAohCinVG6c8W0w=.5a2a6d7b-d09b-4af4-b8fe-2a4ad243939a@github.com>

On Fri, 7 Feb 2025 20:17:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Update the specification of `java.io.File.exists()` to match its behavior, which seems correct in the context of how the empty abstract pathname is documented elsewhere in the class.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8024695: Fix merge error; improve get*Space tests

The latest commit 2cde95c  passes all tests in JDK tiers 1-3 on Linux and Windows.

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

PR Comment: https://git.openjdk.org/jdk/pull/22821#issuecomment-2648613136

From dnsimon at openjdk.org  Mon Feb 10 17:11:17 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 10 Feb 2025 17:11:17 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long [v7]
In-Reply-To: <r8bHdCoTfOU3KTo-4IrVjn1NzsA2u5Mv6z-W8-1aCjA=.e96c4083-ea4d-468c-94e5-074673e64e4f@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
 <r8bHdCoTfOU3KTo-4IrVjn1NzsA2u5Mv6z-W8-1aCjA=.e96c4083-ea4d-468c-94e5-074673e64e4f@github.com>
Message-ID: <V_TF_5sPAiBfEQsCVihqAa5Q0yz2HsjLD8XTEC-aIsU=.57277f3f-78e8-48b9-9a27-0b0d4793e123@github.com>

On Thu, 30 Jan 2025 00:37:16 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
>> 
>> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

I'm curious why `arrayOopDesc::base_offset_in_bytes` was not included in this change - does it not face the same overflow problem?

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

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2648702248

From bpb at openjdk.org  Mon Feb 10 17:18:21 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Feb 2025 17:18:21 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v11]
In-Reply-To: <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com>
Message-ID: <_zxZyGe0-1D_LWJyhrJqYu3e_RLBHJ0si_SRuptCkSE=.435a91e7-277b-4187-b804-692aba507dd2@github.com>

On Thu, 5 Dec 2024 18:44:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge
>  - Merge
>  - Merge
>  - 8337143: Minor makefile tweak
>  - 8337143: Clean up to address reviewer comments
>  - Merge
>  - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
>  - Merge
>  - 8337143: Removed dependency of libjava on headers in libnio/ch
>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/bedb68ab...2cb82267

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2648719746

From jiangli at openjdk.org  Mon Feb 10 17:41:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 17:41:55 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v5]
In-Reply-To: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
Message-ID: <Udgh_pdW_QiadxbkityPgjOi01uMx1ZxX_MhhvnfBnw=.cd43bd7e-ce20-444b-8ea2-441fd7e6bef3@github.com>

> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
> 
> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.

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

  Update copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23500/files
  - new: https://git.openjdk.org/jdk/pull/23500/files/317d2315..98d1dea8

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

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

PR: https://git.openjdk.org/jdk/pull/23500

From jiangli at openjdk.org  Mon Feb 10 17:41:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 17:41:55 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v4]
In-Reply-To: <pFzTAAZwyjTRz-CsWzU2OcjPckrdszkyPfd0pB0yUv0=.f5eb8fdc-09fb-4b11-a4df-c20c222ba69f@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
 <pFzTAAZwyjTRz-CsWzU2OcjPckrdszkyPfd0pB0yUv0=.f5eb8fdc-09fb-4b11-a4df-c20c222ba69f@github.com>
Message-ID: <MdSURK8QBOFrG-TglUh6uReGpe_ES4teDQnV_zMvvvI=.cc4d452c-c7eb-42a0-ac1c-470134c7bbe3@github.com>

On Mon, 10 Feb 2025 07:26:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you bump the copyright header date on libExplicitAttach.c before you integrate.

Done.

@AlanBateman @dholmes-ora Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23500#issuecomment-2648775523

From jiangli at openjdk.org  Mon Feb 10 17:41:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 17:41:55 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v4]
In-Reply-To: <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <wbkHA6G2b49PKnZqR79o5VEQwGR3xQkNGg0xorGU21o=.cc8d6848-510e-4298-ab43-737dc2bab365@github.com>
Message-ID: <L7nT3jgGYzuXEC7ay01DDOcAZbIMXBV81BCURMf96Yk=.cdc5f721-a69d-44aa-9ff0-a137bfefe404@github.com>

On Mon, 10 Feb 2025 04:00:44 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
>> 
>> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused variables.

Looks like the copyright header update required the PR to be reviewed again before integration. Could you review again? Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/23500#issuecomment-2648779004

From duke at openjdk.org  Mon Feb 10 18:34:17 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 10 Feb 2025 18:34:17 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v31]
In-Reply-To: <rr-1SsRzTqZ5SD8XrbZtUKPrROkuLgs-XZx0RwVV7aA=.08d658b2-f59c-4185-bc5e-6d631ba20052@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <wmzwqSiFdhqcr8MsGA9FjLjix25b2xbUR6EMldc2k9c=.8f74f6ad-c453-459b-a6ed-8091e1a8794e@github.com>
 <rr-1SsRzTqZ5SD8XrbZtUKPrROkuLgs-XZx0RwVV7aA=.08d658b2-f59c-4185-bc5e-6d631ba20052@github.com>
Message-ID: <Rf6-v509lmjQmzOWTH42UlRYaGobts4l9_87X-H-MjQ=.f7d28ae4-b168-4724-89a2-0b5ec892da1b@github.com>

On Mon, 10 Feb 2025 09:17:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   An optimization
>
> This PR seems to be targeting performance, yet no benchmarks are provided comparing the current vs. proposed branch with respect to performance. We need to understand the upside of the proposed changes.

@minborg The essential part of the sqrt algorithms is the actual computing of root's digits. In the PR implementation, this task is performed by calling `BigInteger.sqrt()`, while in the current implementation is done by Newton's iteration loop. The existing benchmarks I've done for `BigInteger.sqrt()` already proved that the current code of `BigInteger.sqrt()`, which implements Zimmermann's sqrt algorithm, is way much faster (`O(n^k)`, if the running time for multiply is `O(n^k)`) than the older implementation of `BigInteger.sqrt()` (`O(n^k log n)`), which also used Newton's method. Since the arithmetic operations are more time-consuming for `BigDecimal`s rather than `BigInteger`s, then it's easy to see that, for the same digit precision, Newton's method is much slower when done with `BigDecimal`s, so this should show that the PR implementation is way much faster than the current implementation of `BigDecimal.sqrt()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2648901484

From liach at openjdk.org  Mon Feb 10 18:57:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Feb 2025 18:57:18 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long [v7]
In-Reply-To: <r8bHdCoTfOU3KTo-4IrVjn1NzsA2u5Mv6z-W8-1aCjA=.e96c4083-ea4d-468c-94e5-074673e64e4f@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
 <r8bHdCoTfOU3KTo-4IrVjn1NzsA2u5Mv6z-W8-1aCjA=.e96c4083-ea4d-468c-94e5-074673e64e4f@github.com>
Message-ID: <kfUhFN7xxZOXdWo3NvcNUKEiGvqIVn-b1gH8mZq2EUw=.618f84eb-b3cd-4def-a642-b5597a05c8ee@github.com>

On Thu, 30 Jan 2025 00:37:16 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
>> 
>> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

Re dougxc: This migration is specific to the Java language. I am not so sure about the C++ counterparts, especially that C++ has unsigned types that can complicate things. Another motivation of the Java change is that unsafe is widely used in the Java codebase so upgrading the type can potentially make future usages safer. For example, this already revealed a misuse of the array base offset in the benchmarks in #23393.

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

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2648951653

From alanb at openjdk.org  Mon Feb 10 19:04:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Feb 2025 19:04:11 GMT
Subject: RFR: 8349284: Make libExplicitAttach work on static JDK [v5]
In-Reply-To: <Udgh_pdW_QiadxbkityPgjOi01uMx1ZxX_MhhvnfBnw=.cd43bd7e-ce20-444b-8ea2-441fd7e6bef3@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
 <Udgh_pdW_QiadxbkityPgjOi01uMx1ZxX_MhhvnfBnw=.cd43bd7e-ce20-444b-8ea2-441fd7e6bef3@github.com>
Message-ID: <T2VCnKv5za7quw54eCsGWOJSBuGieRiWsK7NSO3nVvY=.449f656c-5b0e-47a5-a980-1c1065a0b111@github.com>

On Mon, 10 Feb 2025 17:41:55 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
>> 
>> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23500#pullrequestreview-2606882163

From jiangli at openjdk.org  Mon Feb 10 20:22:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Feb 2025 20:22:15 GMT
Subject: Integrated: 8349284: Make libExplicitAttach work on static JDK
In-Reply-To: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
References: <BWts2SFiRxQqr-M79kr7yD5rSQnNDk76_P0kRGjc-V8=.da704720-128d-4d13-a84a-ad4e811937cd@github.com>
Message-ID: <WLkAvyKZ3ca5vBWdBccxB5lYNpGPLXFqFRPhfG5JWsY=.0e437e6b-f62d-485e-b914-c92349b21f1e@github.com>

On Thu, 6 Feb 2025 20:14:36 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It removes libjvm.so as a recorded dependency for libExplicitAttach.so by not explicitly link libExplicitAttach.so with libjvm.so at build time. To do that, it also changes libExplicitAttach.c to dynamically lookup the JNI_GetCreatedJavaVMs symbol then invokes the function using the obtained address. The change makes the test to work on both regular 'jdk' image and the 'static-jdk' image.
> 
> There are discussions in https://github.com/openjdk/jdk/pull/23431 comment thread among @dholmes-ora, @AlanBateman and myself. Based on my understanding, we are converging on the approach to fix just these few tests, and both @dholmes-ora and @AlanBateman are okay with that. So I'm sending out this PR for libExplicitAttach's fix as well.

This pull request has now been integrated.

Changeset: 527489c0
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/527489c06d827f5d08a8053bedcd26db4608c9f0
Stats:     18 lines in 2 files changed: 7 ins; 10 del; 1 mod

8349284: Make libExplicitAttach work on static JDK

Reviewed-by: alanb, dholmes

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

PR: https://git.openjdk.org/jdk/pull/23500

From psandoz at openjdk.org  Mon Feb 10 21:26:25 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 10 Feb 2025 21:26:25 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v17]
In-Reply-To: <sgcWAEvXaWi40uFqPPJq-e6n3YsHb7agKBUrMBdqJSc=.48c41eab-6641-45b7-9765-400622894f4b@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <sgcWAEvXaWi40uFqPPJq-e6n3YsHb7agKBUrMBdqJSc=.48c41eab-6641-45b7-9765-400622894f4b@github.com>
Message-ID: <fYcbuTZ6Uicn6x1uTnhBZxYwgzim_TwldI_9MSLBbmw=.74d51608-d631-4a8a-8e72-a5d623ffef25@github.com>

On Tue, 4 Feb 2025 10:05:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing typos

An impressive and substantial change. I focused on the Java code, there are some small tweaks, presented in comments, we can make to the intrinsics to improve the expression of code, and it has no impact on the intrinsic implementation.

src/java.base/share/classes/jdk/internal/vm/vector/Float16Math.java line 32:

> 30:  * The class {@code Float16Math} constains intrinsic entry points corresponding
> 31:  * to scalar numeric operations defined in Float16 class.
> 32:  * @since   25

You can remove this line, since this is an internal class.

src/java.base/share/classes/jdk/internal/vm/vector/Float16Math.java line 38:

> 36:     }
> 37: 
> 38:     public interface Float16UnaryMathOp {

You can just use `UnaryOperator<T>`, no need for a new type, here are the updated methods you can apply to this class.

    @FunctionalInterface
    public interface TernaryOperator<T> {
        T apply(T a, T b, T c);
    }

    @IntrinsicCandidate
    public static <T> T sqrt(Class<T> box_class, T oa, UnaryOperator<T> defaultImpl) {
        assert isNonCapturingLambda(defaultImpl) : defaultImpl;
        return defaultImpl.apply(oa);
    }

    @IntrinsicCandidate
    public static <T> T fma(Class<T> box_class, T oa, T ob, T oc, TernaryOperator<T> defaultImpl) {
        assert isNonCapturingLambda(defaultImpl) : defaultImpl;
        return defaultImpl.apply(oa, ob, oc);
    }

    static boolean isNonCapturingLambda(Object o) {
        return o.getClass().getDeclaredFields().length == 0;
    }


And in `src/hotspot/share/classfile/vmIntrinsics.hpp`:

  /* Float16Math API intrinsification support */                                                                         \
  /* Float16 signatures */                                                                                               \
  do_signature(float16_unary_math_op_sig, "(Ljava/lang/Class;"                                                           \
                                           "Ljava/lang/Object;"                                                          \
                                           "Ljava/util/function/UnaryOperator;)"                                         \
                                           "Ljava/lang/Object;")                                                         \
  do_signature(float16_ternary_math_op_sig, "(Ljava/lang/Class;"                                                         \
                                             "Ljava/lang/Object;"                                                        \
                                             "Ljava/lang/Object;"                                                        \
                                             "Ljava/lang/Object;"                                                        \
                                             "Ljdk/internal/vm/vector/Float16Math$TernaryOperator;)"                     \
                                             "Ljava/lang/Object;")                                                       \
  do_intrinsic(_sqrt_float16, jdk_internal_vm_vector_Float16Math, sqrt_name, float16_unary_math_op_sig, F_S)             \
  do_intrinsic(_fma_float16, jdk_internal_vm_vector_Float16Math, fma_name, float16_ternary_math_op_sig, F_S)             \

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1202:

> 1200:      */
> 1201:     public static Float16 sqrt(Float16 radicand) {
> 1202:         return (Float16) Float16Math.sqrt(Float16.class, radicand,

With changes to the intrinsics (as presented in another comment) you no longer need explicit casts and the code is precisely the same as before except embedded in a lambda body:

    public static Float16 sqrt(Float16 radicand) {
        return Float16Math.sqrt(Float16.class, radicand,
            (_radicand) -> {
                // Rounding path of sqrt(Float16 -> double) -> Float16 is fine
                // for preserving the correct final value. The conversion
                // Float16 -> double preserves the exact numerical value. The
                // conversion of double -> Float16 also benefits from the
                // 2p+2 property of IEEE 754 arithmetic.
               return valueOf(Math.sqrt(_radicand.doubleValue()));
            }
        );
    }


Similarly for `fma`:

         return Float16Math.fma(Float16.class, a, b, c,
                (_a, _b, _c) -> {
                    // product is numerically exact in float before the cast to
                    // double; not necessary to widen to double before the
                    // multiply.
                    double product = (double)(_a.floatValue() * _b.floatValue());
                    return valueOf(product + _c.doubleValue());
                });

test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java line 44:

> 42: import static jdk.incubator.vector.Float16.*;
> 43: 
> 44: public class ScalarFloat16OperationsTest {

Now that we have IR tests do you still think this test is necessary or should we have more IR test instead? @eme64 thoughts? We could follow up in another PR if need be.

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

PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2607094727
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1949842011
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1949871647
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1949847574
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1949858554

From dnsimon at openjdk.org  Mon Feb 10 21:41:18 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 10 Feb 2025 21:41:18 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long [v7]
In-Reply-To: <kfUhFN7xxZOXdWo3NvcNUKEiGvqIVn-b1gH8mZq2EUw=.618f84eb-b3cd-4def-a642-b5597a05c8ee@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
 <r8bHdCoTfOU3KTo-4IrVjn1NzsA2u5Mv6z-W8-1aCjA=.e96c4083-ea4d-468c-94e5-074673e64e4f@github.com>
 <kfUhFN7xxZOXdWo3NvcNUKEiGvqIVn-b1gH8mZq2EUw=.618f84eb-b3cd-4def-a642-b5597a05c8ee@github.com>
Message-ID: <K0-Dr4AyjT5tN9vhyd6zdblus9QdwHLtrw2srbWEqvs=.bdb9fe88-70c4-4ab8-979f-fae4fec7f7e0@github.com>

On Mon, 10 Feb 2025 18:54:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright
>
> Re dougxc: This migration is specific to the Java language. I am not so sure about the C++ counterparts, especially that C++ has unsigned types that can complicate things. Another motivation of the Java change is that unsafe is widely used in the Java codebase so upgrading the type can potentially make future usages safer. For example, this already revealed a misuse of the array base offset in the benchmarks in #23393.

Thanks for the clarification @liach . This means we only need to focus on the Java code in https://bugs.openjdk.org/browse/JDK-8349743 (cc @mur47x111).

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

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2649300214

From jiangli at openjdk.org  Tue Feb 11 01:03:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Feb 2025 01:03:09 GMT
Subject: RFR: 8349620: Add VMProps for static JDK
In-Reply-To: <JIm6MX4f6S8SxGx-IlJGov7rvsFZqLLQACrIZozjl5k=.0c185caf-30a2-4b1a-95bf-b526bc0012ec@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <JIm6MX4f6S8SxGx-IlJGov7rvsFZqLLQACrIZozjl5k=.0c185caf-30a2-4b1a-95bf-b526bc0012ec@github.com>
Message-ID: <WfKTOm-OVBf1gdY9_GWomHdOoaNfoX-7RYltSRW2GQY=.f5611ddf-aee1-4124-b054-bed11ba77d88@github.com>

On Mon, 10 Feb 2025 08:21:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
>> 
>> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
>> 
>> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.
>
> I think this looks okay, I'm just wondering is one property is enough to cover all the configurations.

Thanks, @AlanBateman.

> I'm just wondering is one property is enough to cover all the configurations.

+1

It's not easy to predict all different cases for now. How about adding/refining when we find any new cases? I'm also wondering if we would want to merge the `isStatic` into `isHermetic` check in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2649588820

From liach at openjdk.org  Tue Feb 11 02:31:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Feb 2025 02:31:53 GMT
Subject: RFR: 8342206: Convenience method to check if a constant pool entry
 matches nominal descriptors
Message-ID: <W3im0ithPIye8qZ3-YwRYX3JpYKH69dqeQ96MKRButo=.54bb8b43-a2a1-4a4a-a8e0-b37f109f0a35@github.com>

The ClassFile API promotes usage of constant nominal descriptors over literal strings. However, for `class` file parsing, currently the efficient way to check if a constant pool entry matches a desired descriptor is via unrolling them back to strings. However, string unrolling is ugly, and often times confusing, such as internal names versus field descriptors.

As a result, I propose to provide new methods that compare constant pool entries with the potential symbolic descriptors they represent. This is no less efficient as checking raw string equality, avoids exceptional failure behaviors of conversion to symbolic descriptors, and avoids potential programmer errors stemming from raw string handling. See the CSR for a full story.

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

Commit messages:
 - 8342206: Convenience method to check if a constant pool entry matches nominal descriptors

Changes: https://git.openjdk.org/jdk/pull/23548/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23548&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342206
  Stats: 413 lines in 9 files changed: 396 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23548.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23548/head:pull/23548

PR: https://git.openjdk.org/jdk/pull/23548

From syan at openjdk.org  Tue Feb 11 02:49:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 02:49:49 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
Message-ID: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>

H all,

This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.

I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.

1. java/lang/management/ThreadMXBean/VirtualThreads.java#default

VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.

2. java/lang/Thread/virtual/stress/PinALot.java

PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".

3. java/lang/Thread/virtual/SynchronizedNative.java

Call System.loadLibrary("SynchronizedNative") at line 85.

4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java


- Why we need the '/native' keywork?

I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.

Change has been verified locally, test-fix, no risk.

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

Commit messages:
 - 8349689: Several virtual thread tests missing /native keyword

Changes: https://git.openjdk.org/jdk/pull/23550/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23550&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349689
  Stats: 48 lines in 10 files changed: 0 ins; 0 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/23550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23550/head:pull/23550

PR: https://git.openjdk.org/jdk/pull/23550

From xgong at openjdk.org  Tue Feb 11 03:02:14 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 11 Feb 2025 03:02:14 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
Message-ID: <Ydh64uR5WQcX8IvpXzTWIhFbEfqlSlElKf4G9Dv-0ls=.eb8ad9df-6b6a-47f4-a851-eee69cf826e0@github.com>

On Wed, 8 Jan 2025 09:04:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86 and AArch64 with the following error:
> 
> 
> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
> 
> 
> The variable `long256_arr_idx` is misused when indexing  'LongVector l2, l3, l4, l5' in function `maskedLogicOperationsLongKernel()`. 'long256_arr_idx' increases by 4 every time the benchmark runs and ensures the incremented value remains within the bounds of the array. However, for `LongVector.SPECIES_512`, it loads 8 numbers from the array each time the benchmark runs, resulting in an out-of-range indexing issue.
> 
> Hence, we revised the index variables from `long256_arr_idx` to `long512_arr_idx`, which has a stride of 8, to ensure that the loaded vector is inside of the array boundary for all vector species. This is also consistent with other kernel functions.
> 
> Additionally, some defined but unused variables have been removed.

Looks good to me. Thanks for the fixing!

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

Marked as reviewed by xgong (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22963#pullrequestreview-2607593816

From liach at openjdk.org  Tue Feb 11 03:05:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Feb 2025 03:05:53 GMT
Subject: RFR: 8347472: Correct Attribute traversal and writing for Code
 attributes
Message-ID: <ZDFEms2WIiyQI1Mgw_qiHlnTwQUdDs_ohvdjzkMWb3w=.e4472f43-9020-4636-aa27-e4631da984bd@github.com>

Make UnknownAttribute and CustomAttribute delivered in code traversal, and make sure stack maps update the label references after a code transform when it is reused. Other code-bound attributes are not updated as they cannot be supplied to a CodeBuilder.

Tested the 2 cases in the new AttributesInCodeTest fails on earlier JDKs.

Testing: JDK tier 1-3 ongoing

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

Commit messages:
 - Fix exhaustive switch
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/code-traversal
 - 8347472: Correct Attribute traversal and writing for Code attributes

Changes: https://git.openjdk.org/jdk/pull/23521/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23521&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347472
  Stats: 218 lines in 10 files changed: 198 ins; 6 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/23521.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23521/head:pull/23521

PR: https://git.openjdk.org/jdk/pull/23521

From jwtang at openjdk.org  Tue Feb 11 03:08:53 2025
From: jwtang at openjdk.org (Jiawei Tang)
Date: Tue, 11 Feb 2025 03:08:53 GMT
Subject: RFR: 8349763: Expose more ForkJoinPool parameters for virtual thread
 scheduler to reduce startup jitter and improve stability
Message-ID: <YeyueE6v3n473qGjXlegW9ISOE-DSqoC7VbNH1TaDTg=.d8d2ba47-d8a2-4460-a77d-822b432c5b60@github.com>

Since the parameters `-Djdk.virtualThreadScheduler.parallelism=N` , `-Djdk.virtualThreadScheduler.maxPoolSize=M`, `-Djdk.virtualThreadScheduler.minimumRunnable=Y` have already been made available, it would be worth considering opening up additional ForkJoinPool-related parameters: `-Djdk.virtualThreadScheduler.corePoolSize=X`, `-Djdk.virtualThreadScheduler.keepAliveTime=Z` and `-Djdk.virtualThreadScheduler.timeUnit`.

In particular, configuring corePoolSize can help reduce jitter caused by thread ramp-up during application startup, while keepAliveTime and timeUnit ensures more threads are available within the time expected by users. Opening these parameters would be highly meaningful for optimizing virtual thread scheduling.

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

Commit messages:
 - 8349763: Expose more ForkJoinPool parameters for virtual thread scheduler to reduce startup jitter and improve stability

Changes: https://git.openjdk.org/jdk/pull/23549/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23549&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349763
  Stats: 27 lines in 1 file changed: 25 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23549.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23549/head:pull/23549

PR: https://git.openjdk.org/jdk/pull/23549

From duke at openjdk.org  Tue Feb 11 03:57:12 2025
From: duke at openjdk.org (He-Pin (kerr))
Date: Tue, 11 Feb 2025 03:57:12 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
Message-ID: <AnrjLD7rJwg1dT8fNc5XMs8rqhSlLxIPNPk27zZtN7k=.34540e60-36c4-4c98-9a11-668fff434160@github.com>

On Sat, 11 Jan 2025 07:10:53 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

> Motivation:
> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
> 
> Modification:
> Add detail error messages.
> 
> Result:
> Helpful messages.

It would be much nicer if you take this one:), we are on JDK 21 and want to have this in the next LTS.

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

PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2649747805

From jbhateja at openjdk.org  Tue Feb 11 06:32:56 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 11 Feb 2025 06:32:56 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v18]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <GTm_Er6CT-A4aFdVeWEMCXyJKWWrW56VLe9On4W02fk=.6bb331e3-3a26-4f5e-befb-42e955e4d994@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

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

  Review comments resolutions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/82a42213..111c8084

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=16-17

  Stats: 38 lines in 3 files changed: 2 ins; 11 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From jbhateja at openjdk.org  Tue Feb 11 06:32:56 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 11 Feb 2025 06:32:56 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v17]
In-Reply-To: <fYcbuTZ6Uicn6x1uTnhBZxYwgzim_TwldI_9MSLBbmw=.74d51608-d631-4a8a-8e72-a5d623ffef25@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <sgcWAEvXaWi40uFqPPJq-e6n3YsHb7agKBUrMBdqJSc=.48c41eab-6641-45b7-9765-400622894f4b@github.com>
 <fYcbuTZ6Uicn6x1uTnhBZxYwgzim_TwldI_9MSLBbmw=.74d51608-d631-4a8a-8e72-a5d623ffef25@github.com>
Message-ID: <lbTe_GWhxZ_joIIxX3Bpr6BTzk8xm1rbn-s3fKEShl0=.09c2feaa-b3a1-412c-ac19-c5cbffa9c297@github.com>

On Mon, 10 Feb 2025 20:43:19 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing typos
>
> test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java line 44:
> 
>> 42: import static jdk.incubator.vector.Float16.*;
>> 43: 
>> 44: public class ScalarFloat16OperationsTest {
> 
> Now that we have IR tests do you still think this test is necessary or should we have more IR test instead? @eme64 thoughts? We could follow up in another PR if need be.

Hi Paul, DataProviders used in this Functional validation test exercises each newly added Float16 operation over entire value range, while our IR tests are more directed towards valdating the newly added IR transforms and constant folding scenarios. We have a follow-up PR for auto-vectorizing Float16 operation which can be used to beefup any validation gap.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1950290083

From alanb at openjdk.org  Tue Feb 11 06:46:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 06:46:09 GMT
Subject: RFR: 8349763: Expose more ForkJoinPool parameters for virtual
 thread scheduler to reduce startup jitter and improve stability
In-Reply-To: <YeyueE6v3n473qGjXlegW9ISOE-DSqoC7VbNH1TaDTg=.d8d2ba47-d8a2-4460-a77d-822b432c5b60@github.com>
References: <YeyueE6v3n473qGjXlegW9ISOE-DSqoC7VbNH1TaDTg=.d8d2ba47-d8a2-4460-a77d-822b432c5b60@github.com>
Message-ID: <ZsXGgUBXtRJ6ztBkA6ww_-KjOvpOwoYhkdCjsdh9W0M=.98f7b87a-53fc-448a-bb9f-e742ed22168f@github.com>

On Tue, 11 Feb 2025 02:36:14 GMT, Jiawei Tang <jwtang at openjdk.org> wrote:

> Since the parameters `-Djdk.virtualThreadScheduler.parallelism=N` , `-Djdk.virtualThreadScheduler.maxPoolSize=M`, `-Djdk.virtualThreadScheduler.minimumRunnable=Y` have already been made available, it would be worth considering opening up additional ForkJoinPool-related parameters: `-Djdk.virtualThreadScheduler.corePoolSize=X`, `-Djdk.virtualThreadScheduler.keepAliveTime=Z` and `-Djdk.virtualThreadScheduler.timeUnit`.
> 
> In particular, configuring corePoolSize can help reduce jitter caused by thread ramp-up during application startup, while keepAliveTime and timeUnit ensures more threads are available within the time expected by users. Opening these parameters would be highly meaningful for optimizing virtual thread scheduling.

Can you bring the issue to loom-dev to discuss? It might be that some additional configuration knobs may be useful to expose but I think important to explain + discuss the issues first.

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

PR Comment: https://git.openjdk.org/jdk/pull/23549#issuecomment-2649951733

From alanb at openjdk.org  Tue Feb 11 07:29:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 07:29:09 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <Of1AGZzrUCxm87JHwlMt8-OXoqXw3OEV8qQta4dRxdw=.024f2266-368f-4bc5-9fa9-60929822bd31@github.com>

On Tue, 11 Feb 2025 02:45:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 30:

> 28:  * @modules java.base/java.lang:+open java.management
> 29:  * @library /test/lib
> 30:  * @run junit/othervm/native VirtualThreads

Can you add `--enable-native-access=ALL-UNNAMED` to this test while you are editing this line? It makes it more obvious that it invokes native code and also removes the warning at runtime.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950353219

From jwtang at openjdk.org  Tue Feb 11 07:30:12 2025
From: jwtang at openjdk.org (Jiawei Tang)
Date: Tue, 11 Feb 2025 07:30:12 GMT
Subject: RFR: 8349763: Expose more ForkJoinPool parameters to configure
 virtual thread scheduler
In-Reply-To: <ZsXGgUBXtRJ6ztBkA6ww_-KjOvpOwoYhkdCjsdh9W0M=.98f7b87a-53fc-448a-bb9f-e742ed22168f@github.com>
References: <YeyueE6v3n473qGjXlegW9ISOE-DSqoC7VbNH1TaDTg=.d8d2ba47-d8a2-4460-a77d-822b432c5b60@github.com>
 <ZsXGgUBXtRJ6ztBkA6ww_-KjOvpOwoYhkdCjsdh9W0M=.98f7b87a-53fc-448a-bb9f-e742ed22168f@github.com>
Message-ID: <aEGyM8RoSDjZPi5WrjNtoLfoKxDbDMkhnBLsWxV6ktw=.9d7b2ef5-eae8-4c14-b13e-df3eaa2ad7f0@github.com>

On Tue, 11 Feb 2025 06:43:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you bring the issue to loom-dev to discuss? It might be that some additional configuration knobs may be useful to expose but I think important to explain + discuss the issues first.

I open a new pr in loom for discussion: https://github.com/openjdk/loom/pull/216

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

PR Comment: https://git.openjdk.org/jdk/pull/23549#issuecomment-2650012144

From alanb at openjdk.org  Tue Feb 11 07:33:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 07:33:11 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <SUVzURn2ddC0NfegZpTP92cCAtb49hr_ehCTgc1uF7c=.10f321b0-e348-46e7-b5b9-65dd9abee38c@github.com>

On Tue, 11 Feb 2025 02:45:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

Can you check if these two needs to be updated too?

test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java
test/jdk/java/lang/Thread/virtual/Starvation.java

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

PR Comment: https://git.openjdk.org/jdk/pull/23550#issuecomment-2650016781

From alanb at openjdk.org  Tue Feb 11 07:41:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 07:41:09 GMT
Subject: RFR: 8349763: Expose more ForkJoinPool parameters to configure
 virtual thread scheduler
In-Reply-To: <YeyueE6v3n473qGjXlegW9ISOE-DSqoC7VbNH1TaDTg=.d8d2ba47-d8a2-4460-a77d-822b432c5b60@github.com>
References: <YeyueE6v3n473qGjXlegW9ISOE-DSqoC7VbNH1TaDTg=.d8d2ba47-d8a2-4460-a77d-822b432c5b60@github.com>
Message-ID: <heM9u9zDOAj1WuxjCj7e8Ftk2QUU9SXg1x4Ycy55jK0=.3bc7b6dd-8da8-40c0-b049-4a46c7a17d06@github.com>

On Tue, 11 Feb 2025 02:36:14 GMT, Jiawei Tang <jwtang at openjdk.org> wrote:

> Since the parameters `-Djdk.virtualThreadScheduler.parallelism=N` , `-Djdk.virtualThreadScheduler.maxPoolSize=M`, `-Djdk.virtualThreadScheduler.minimumRunnable=Y` have already been made available, it would be worth considering opening up additional ForkJoinPool-related parameters: `-Djdk.virtualThreadScheduler.corePoolSize=X`, `-Djdk.virtualThreadScheduler.keepAliveTime=Z` and `-Djdk.virtualThreadScheduler.timeUnit`.
> 
> In particular, configuring corePoolSize can help reduce jitter caused by thread ramp-up during application startup, while keepAliveTime and timeUnit ensures more threads are available within the time expected by users. Opening these parameters would be highly meaningful for optimizing virtual thread scheduling.

I should have been clearer, I wasn't suggesting creating a PR against the loom repo. Instead I'm suggesting that you start a discussion on loom-dev with a summary of the issues that you are running into so they can be discussed and understood. It's too early to say if this is something that FJP should do better or whether additional configuration knobs need to be exposed. When we initially introduced this feature we decided to limit the number of configuration knobs to two system properties documented in an implNote of the Thread API.

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

PR Comment: https://git.openjdk.org/jdk/pull/23549#issuecomment-2650028840

From syan at openjdk.org  Tue Feb 11 07:43:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 07:43:47 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v2]
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <0bp5M6-iiZxngQJk5uRVX6h_-uMXYYG2zBOtqgQEQDo=.96dc6c54-59ae-42d3-8f8e-ed531e15c0a9@github.com>

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

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

  add --enable-native-access=ALL-UNNAMED for test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java#default

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23550/files
  - new: https://git.openjdk.org/jdk/pull/23550/files/03e76ed3..7c030997

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

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

PR: https://git.openjdk.org/jdk/pull/23550

From syan at openjdk.org  Tue Feb 11 07:43:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 07:43:47 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v2]
In-Reply-To: <Of1AGZzrUCxm87JHwlMt8-OXoqXw3OEV8qQta4dRxdw=.024f2266-368f-4bc5-9fa9-60929822bd31@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Of1AGZzrUCxm87JHwlMt8-OXoqXw3OEV8qQta4dRxdw=.024f2266-368f-4bc5-9fa9-60929822bd31@github.com>
Message-ID: <mkh92dxM39AIrZDtRErygNzyJhmTC9kpS_zV0kJW954=.269d6d2d-fcbd-400e-b2e2-7adadf66dd14@github.com>

On Tue, 11 Feb 2025 07:26:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add --enable-native-access=ALL-UNNAMED for test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java#default
>
> test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 30:
> 
>> 28:  * @modules java.base/java.lang:+open java.management
>> 29:  * @library /test/lib
>> 30:  * @run junit/othervm/native VirtualThreads
> 
> Can you add `--enable-native-access=ALL-UNNAMED` to this test while you are editing this line? It makes it more obvious that it invokes native code and also removes the warning at runtime.

Thanks. Argument `--enable-native-access=ALL-UNNAMED` has been added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950365978

From jwtang at openjdk.org  Tue Feb 11 07:46:11 2025
From: jwtang at openjdk.org (Jiawei Tang)
Date: Tue, 11 Feb 2025 07:46:11 GMT
Subject: RFR: 8349763: Expose more ForkJoinPool parameters to configure
 virtual thread scheduler
In-Reply-To: <YeyueE6v3n473qGjXlegW9ISOE-DSqoC7VbNH1TaDTg=.d8d2ba47-d8a2-4460-a77d-822b432c5b60@github.com>
References: <YeyueE6v3n473qGjXlegW9ISOE-DSqoC7VbNH1TaDTg=.d8d2ba47-d8a2-4460-a77d-822b432c5b60@github.com>
Message-ID: <3R8aiDMDf45li5iYPJySUjoMuGZBSWD5HQjMEzl03aE=.e6b9497a-2b07-4634-b8e6-4d42a79c6182@github.com>

On Tue, 11 Feb 2025 02:36:14 GMT, Jiawei Tang <jwtang at openjdk.org> wrote:

> Since the parameters `-Djdk.virtualThreadScheduler.parallelism=N` , `-Djdk.virtualThreadScheduler.maxPoolSize=M`, `-Djdk.virtualThreadScheduler.minimumRunnable=Y` have already been made available, it would be worth considering opening up additional ForkJoinPool-related parameters: `-Djdk.virtualThreadScheduler.corePoolSize=X`, `-Djdk.virtualThreadScheduler.keepAliveTime=Z` and `-Djdk.virtualThreadScheduler.timeUnit`.
> 
> In particular, configuring corePoolSize can help reduce jitter caused by thread ramp-up during application startup, while keepAliveTime and timeUnit ensures more threads are available within the time expected by users. Opening these parameters would be highly meaningful for optimizing virtual thread scheduling.

Thank you. I get it. I will provide some data for discussion.

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

PR Comment: https://git.openjdk.org/jdk/pull/23549#issuecomment-2650034999

From asotona at openjdk.org  Tue Feb 11 07:56:10 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 11 Feb 2025 07:56:10 GMT
Subject: RFR: 8349624: Validation for slot missing in CodeBuilder local
 variable instructions
In-Reply-To: <fI6Ex768gvhUYXMDTqPDAHL0uGHxxVwYhwQRqKtYTCg=.64b662b0-7724-42f6-82e7-08dadb62e674@github.com>
References: <fI6Ex768gvhUYXMDTqPDAHL0uGHxxVwYhwQRqKtYTCg=.64b662b0-7724-42f6-82e7-08dadb62e674@github.com>
Message-ID: <YAQ_ncTd3jU1DulrCYx4JXU_p-DA5qroJ8IUZYO59Fc=.401b5c1d-91ed-479f-a392-dd19c5ba8aa6@github.com>

On Fri, 7 Feb 2025 19:40:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> In CodeBuilder, validation for a slot was missing due to concurrent patches, and the original patch did not add effective tests for CodeBuilder because of the complex exceptional behaviors. Now the bug is fixed with renames to prevent future risky usages, and the tests have been enhanced to ensure at least the failure-case behavior (while the non-failure case is harder to check due to exceptional behaviors)
> 
> Testing: JDK tier 1-3

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23522#pullrequestreview-2607934748

From asotona at openjdk.org  Tue Feb 11 08:06:10 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 11 Feb 2025 08:06:10 GMT
Subject: RFR: 8342206: Convenience method to check if a constant pool entry
 matches nominal descriptors
In-Reply-To: <W3im0ithPIye8qZ3-YwRYX3JpYKH69dqeQ96MKRButo=.54bb8b43-a2a1-4a4a-a8e0-b37f109f0a35@github.com>
References: <W3im0ithPIye8qZ3-YwRYX3JpYKH69dqeQ96MKRButo=.54bb8b43-a2a1-4a4a-a8e0-b37f109f0a35@github.com>
Message-ID: <xe9YCwkkpS1rAXx0GtKEpMyY_cETHg-41PIQ74NJtQk=.0a12669c-8e26-4b34-83a3-a9513b697525@github.com>

On Tue, 11 Feb 2025 02:26:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> The ClassFile API promotes usage of constant nominal descriptors over literal strings. However, for `class` file parsing, currently the efficient way to check if a constant pool entry matches a desired descriptor is via unrolling them back to strings. However, string unrolling is ugly, and often times confusing, such as internal names versus field descriptors.
> 
> As a result, I propose to provide new methods that compare constant pool entries with the potential symbolic descriptors they represent. This is no less efficient as checking raw string equality, avoids exceptional failure behaviors of conversion to symbolic descriptors, and avoids potential programmer errors stemming from raw string handling. See the CSR for a full story.

src/java.base/share/classes/java/lang/classfile/constantpool/Utf8Entry.java line 95:

> 93:      * @since 25
> 94:      */
> 95:     boolean equalsSymbol(ClassDesc desc);

Ambiguity of class internal name vs. descriptor serialization might be confusing:

classEntry.equalsSymbol(classDesc) != classEntry.name().equalsSymbol(classDesc)

I think it should be more highlighted to avoid mistakes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23548#discussion_r1950390119

From alanb at openjdk.org  Tue Feb 11 08:13:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 08:13:09 GMT
Subject: RFR: 8349620: Add VMProps for static JDK
In-Reply-To: <JIm6MX4f6S8SxGx-IlJGov7rvsFZqLLQACrIZozjl5k=.0c185caf-30a2-4b1a-95bf-b526bc0012ec@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <JIm6MX4f6S8SxGx-IlJGov7rvsFZqLLQACrIZozjl5k=.0c185caf-30a2-4b1a-95bf-b526bc0012ec@github.com>
Message-ID: <DDkY02jwb9ew9lA0tBoGpL29CLfRf028eSiKdGVz8AY=.efbdfb9d-4c7e-492c-9628-88222f4b8bf8@github.com>

On Mon, 10 Feb 2025 08:21:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
>> 
>> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
>> 
>> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.
>
> I think this looks okay, I'm just wondering is one property is enough to cover all the configurations.

> Thanks, @AlanBateman.
> 
> > I'm just wondering is one property is enough to cover all the configurations.
> 
> +1
> 
> It's not easy to predict all different cases for now. How about adding/refining when we find any new cases? 

That's okay with me. I'm hoping Magnus will jump in when he gets a chance as he has experience with the "other" static build configurations.

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

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2650077629

From syan at openjdk.org  Tue Feb 11 08:38:48 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:38:48 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

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

  add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23550/files
  - new: https://git.openjdk.org/jdk/pull/23550/files/7c030997..413ee6b1

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

  Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23550/head:pull/23550

PR: https://git.openjdk.org/jdk/pull/23550

From pminborg at openjdk.org  Tue Feb 11 08:43:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 11 Feb 2025 08:43:13 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
Message-ID: <eX36fGOUut-v-udmXyq6XDLwM3BubayrBTBANBkF-dM=.b73c4771-7863-4ac6-9b02-181f11d025da@github.com>

On Sat, 11 Jan 2025 07:10:53 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

> Motivation:
> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
> 
> Modification:
> Add detail error messages.
> 
> Result:
> Helpful messages.

src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java line 122:

> 120:     @Override
> 121:     public Future<?> submit(Runnable task) {
> 122:         if (task == null) throw new NullPointerException("task can't be null");

Why not use `Objects.requireNonNull()` and break out the repeated code into a common method?

test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java line 758:

> 756:                                    new ArrayBlockingQueue<Runnable>(10));
> 757:             shouldThrow();
> 758:         } catch (IllegalArgumentException success) {

We could test the actual message here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r1950433862
PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r1950435392

From syan at openjdk.org  Tue Feb 11 08:47:11 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:47:11 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
In-Reply-To: <SUVzURn2ddC0NfegZpTP92cCAtb49hr_ehCTgc1uF7c=.10f321b0-e348-46e7-b5b9-65dd9abee38c@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <SUVzURn2ddC0NfegZpTP92cCAtb49hr_ehCTgc1uF7c=.10f321b0-e348-46e7-b5b9-65dd9abee38c@github.com>
Message-ID: <W3DxZL_gHfiu5vtMqDWnFGgWEU5LPV1odLtVXijdkJY=.d4252543-9bda-4e96-ab6b-2105c6547c03@github.com>

On Tue, 11 Feb 2025 07:30:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you check if these two needs to be updated too?
> 
> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java

These two tests also need `/native` keyword.

- Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java do not report test failed or error when missing load the native shared libary. So I add a check to make sure that the first virtual of this test run normally.

The original test output from jfr file shows below:


STARTED    ThreadPollOnYield::testThreadYieldPolls 'testThreadYieldPolls()'
Exception in thread "" java.lang.ExceptionInInitializerError
    at ThreadPollOnYield.lambda$testThreadYieldPolls$0(ThreadPollOnYield.java:59)
    at java.base/java.lang.VirtualThread.run(VirtualThread.java:466)
Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: Cannot open library: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib/libVThreadPinner.so
    at jdk.test.lib.thread.VThreadPinner.invoker(VThreadPinner.java:135)
    at jdk.test.lib.thread.VThreadPinner.<clinit>(VThreadPinner.java:50)
    ... 2 more
Caused by: java.lang.IllegalArgumentException: Cannot open library: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib/libVThreadPinner.so
    at java.base/java.lang.foreign.SymbolLookup.libraryLookup(SymbolLookup.java:350)
    at java.base/java.lang.foreign.SymbolLookup.libraryLookup(SymbolLookup.java:335)
    at jdk.test.lib.thread.VThreadPinner.invoker(VThreadPinner.java:130)
    ... 3 more
Exception in thread "" java.lang.NoClassDefFoundError: Could not initialize class jdk.test.lib.thread.VThreadPinner
    at ThreadPollOnYield.lambda$testThreadYieldPolls$2(ThreadPollOnYield.java:69)
    at java.base/java.lang.VirtualThread.run(VirtualThread.java:466)
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.RuntimeException: java.lang.IllegalArgumentException: Cannot open library: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib/libVThreadPinner.so [in thread "ForkJoinPool-1-worker-1"]
    at jdk.test.lib.thread.VThreadPinner.invoker(VThreadPinner.java:135)
    at jdk.test.lib.thread.VThreadPinner.<clinit>(VThreadPinner.java:50)
    at ThreadPollOnYield.lambda$testThreadYieldPolls$0(ThreadPollOnYield.java:59)
    ... 1 more
SUCCESSFUL ThreadPollOnYield::testThreadYieldPolls 'testThreadYieldPolls()'



- Test test/jdk/java/lang/Thread/virtual/Starvation.java execute over 120 seconds on my local environment. So I add `timeout=200` also.


elapsed time (seconds): 121.41

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

PR Comment: https://git.openjdk.org/jdk/pull/23550#issuecomment-2650141187

From alanb at openjdk.org  Tue Feb 11 08:47:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 08:47:13 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
Message-ID: <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>

On Tue, 11 Feb 2025 08:38:48 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java

test/jdk/java/lang/Thread/virtual/Starvation.java line 28:

> 26:  * @library /test/lib
> 27:  * @bug 8345294
> 28:  * @run main/othervm/timeout=200/native --enable-native-access=ALL-UNNAMED Starvation 100000

Did you mean to add /timeout=200 to this test?

test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 39:

> 37:  * @requires vm.continuations & vm.compMode != "Xcomp"
> 38:  * @library /test/lib
> 39:  * @run junit/othervm/native --enable-native-access=ALL-UNNAMED -Xcomp -XX:-TieredCompilation -XX:CompileCommand=inline,*::yield* -XX:CompileCommand=inline,*::*Yield ThreadPollOnYield

Would you mind splitting this line (jtreg is okay with that) as it's nearly 190 chars now so getting too long.

test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 69:

> 67:         if (flag != true) {
> 68:             throw new RuntimeException("flag = " + flag);
> 69:         }

What are these other changes about?

test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 30:

> 28:  * @modules java.base/java.lang:+open java.management
> 29:  * @library /test/lib
> 30:  * @run junit/othervm/native --enable-native-access=ALL-UNNAMED VirtualThreads

Can you check if the end copyright date needs to be updated on this one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950436579
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950439893
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950438562
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950440627

From syan at openjdk.org  Tue Feb 11 08:47:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:47:14 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
Message-ID: <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>

On Tue, 11 Feb 2025 08:41:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java
>
> test/jdk/java/lang/Thread/virtual/Starvation.java line 28:
> 
>> 26:  * @library /test/lib
>> 27:  * @bug 8345294
>> 28:  * @run main/othervm/timeout=200/native --enable-native-access=ALL-UNNAMED Starvation 100000
> 
> Did you mean to add /timeout=200 to this test?

Test test/jdk/java/lang/Thread/virtual/Starvation.java execute over 120 seconds on my local environment. So I add timeout=200 also.

> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 69:
> 
>> 67:         if (flag != true) {
>> 68:             throw new RuntimeException("flag = " + flag);
>> 69:         }
> 
> What are these other changes about?

Reason description as https://github.com/openjdk/jdk/pull/23550#issuecomment-2650141187.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950440123
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950439898

From syan at openjdk.org  Tue Feb 11 08:53:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:53:46 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v4]
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <XL5_3IfJOXgAxPLi6mkQbGahdqhlwyh99KdOUZVjyP0=.aefddd7b-fbd1-477a-ab42-f0280d42b745@github.com>

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

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

  update copyright year for test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java; Split @run line for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23550/files
  - new: https://git.openjdk.org/jdk/pull/23550/files/413ee6b1..07f34357

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

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

PR: https://git.openjdk.org/jdk/pull/23550

From syan at openjdk.org  Tue Feb 11 08:53:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:53:47 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
Message-ID: <PVDVRTf-xeGDKnWVzkghJizkZRxWPIIagWHXvnsUc3c=.fdac3bf4-436c-4f80-ba14-2fc27f38d8c2@github.com>

On Tue, 11 Feb 2025 08:44:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java
>
> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 39:
> 
>> 37:  * @requires vm.continuations & vm.compMode != "Xcomp"
>> 38:  * @library /test/lib
>> 39:  * @run junit/othervm/native --enable-native-access=ALL-UNNAMED -Xcomp -XX:-TieredCompilation -XX:CompileCommand=inline,*::yield* -XX:CompileCommand=inline,*::*Yield ThreadPollOnYield
> 
> Would you mind splitting this line (jtreg is okay with that) as it's nearly 190 chars now so getting too long.

Okey, this line has been split two lines.

> test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 30:
> 
>> 28:  * @modules java.base/java.lang:+open java.management
>> 29:  * @library /test/lib
>> 30:  * @run junit/othervm/native --enable-native-access=ALL-UNNAMED VirtualThreads
> 
> Can you check if the end copyright date needs to be updated on this one.

Sorry, the copyright date has been updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950447560
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950448055

From alanb at openjdk.org  Tue Feb 11 08:56:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 08:56:11 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
 <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>
Message-ID: <jNjxb0ICFVP8dva3FROLJGVqYY_gNiLiysF7Syq-Nz4=.51b9716c-f5ae-4092-9cef-cc209a2b6f62@github.com>

On Tue, 11 Feb 2025 08:44:15 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 69:
>> 
>>> 67:         if (flag != true) {
>>> 68:             throw new RuntimeException("flag = " + flag);
>>> 69:         }
>> 
>> What are these other changes about?
>
> Reason description as https://github.com/openjdk/jdk/pull/23550#issuecomment-2650141187.

Can you remove this change from the PR as it this is a separate discussion? My guess is that in your environment the Thread.yield is somehow taking more than 5 seconds, is that right? In that case, we can modify the test to use a latch to ensure that it loops at least once. Anyway, separate issue, we shouldn't include it in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950452441

From syan at openjdk.org  Tue Feb 11 09:03:24 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 09:03:24 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

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

  Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23550/files
  - new: https://git.openjdk.org/jdk/pull/23550/files/07f34357..912c1ab3

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

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

PR: https://git.openjdk.org/jdk/pull/23550

From syan at openjdk.org  Tue Feb 11 09:03:25 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 09:03:25 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <jNjxb0ICFVP8dva3FROLJGVqYY_gNiLiysF7Syq-Nz4=.51b9716c-f5ae-4092-9cef-cc209a2b6f62@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
 <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>
 <jNjxb0ICFVP8dva3FROLJGVqYY_gNiLiysF7Syq-Nz4=.51b9716c-f5ae-4092-9cef-cc209a2b6f62@github.com>
Message-ID: <gYHa8V4K2jhEtds5JwLG6s4zNb_awl-2nXn0KTq8Kvk=.a501a0bb-fb73-4d07-9666-c53a96004899@github.com>

On Tue, 11 Feb 2025 08:53:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Reason description as https://github.com/openjdk/jdk/pull/23550#issuecomment-2650141187.
>
> Can you remove this change from the PR as it this is a separate discussion? My guess is that in your environment the Thread.yield is somehow taking more than 5 seconds, is that right? In that case, we can modify the test to use a latch to ensure that it loops at least once. Anyway, separate issue, we shouldn't include it in this PR.

Okey, the additional check has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950462081

From syan at openjdk.org  Tue Feb 11 09:10:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 09:10:12 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <gYHa8V4K2jhEtds5JwLG6s4zNb_awl-2nXn0KTq8Kvk=.a501a0bb-fb73-4d07-9666-c53a96004899@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
 <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>
 <jNjxb0ICFVP8dva3FROLJGVqYY_gNiLiysF7Syq-Nz4=.51b9716c-f5ae-4092-9cef-cc209a2b6f62@github.com>
 <gYHa8V4K2jhEtds5JwLG6s4zNb_awl-2nXn0KTq8Kvk=.a501a0bb-fb73-4d07-9666-c53a96004899@github.com>
Message-ID: <jUNt_xes1UYoItHwJqUDnLoe_8ni56CMXGxvKmtRgcM=.432e03ea-b648-4647-9dfe-918a44c18ef9@github.com>

On Tue, 11 Feb 2025 09:00:46 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Can you remove this change from the PR as it this is a separate discussion? My guess is that in your environment the Thread.yield is somehow taking more than 5 seconds, is that right? In that case, we can modify the test to use a latch to ensure that it loops at least once. Anyway, separate issue, we shouldn't include it in this PR.
>
> Okey, the additional check has been removed.

I have created a separate [issue](https://bugs.openjdk.org/browse/JDK-8349787) to record that. I will investigate later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950471694

From alanb at openjdk.org  Tue Feb 11 09:24:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 09:24:10 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <-WVSOZWZXjlAhICbHjfuu-QEAlpqx_Pmyy4EIvfdwQk=.dcac8e8d-5662-4dda-87de-8931e86c3960@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

912c1ab3 looks okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23550#pullrequestreview-2608124096

From syan at openjdk.org  Tue Feb 11 09:30:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 09:30:14 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <UgO_pPmUbbGUSzuY8XmBTgScyYkptyf45DKrKgRuOcY=.4d243896-996c-481e-b9aa-6a1810c4aa11@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

> [912c1ab](https://github.com/openjdk/jdk/commit/912c1ab384ffb82e36e46cbf2236b42d4321bc27) looks okay.

@AlanBateman Thanks for the patience suggest and review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23550#issuecomment-2650245614

From clanger at openjdk.org  Tue Feb 11 10:17:48 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 11 Feb 2025 10:17:48 GMT
Subject: RFR: 8349648: Test tools/jpackage/share/JLinkOptionsTest.java
 fails with --enable-linkable-runtime set after JDK-8346434 [v2]
In-Reply-To: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
References: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
Message-ID: <RKzcjQBZoMagTwWIWJhFUH4nM6dY4KV_DftM7aEGqQ0=.87909bb9-7497-401f-ab23-bcf87a2cc601@github.com>

> The change for JDK-8346434 added a new test case to tools/jpackage/share/JLinkOptionsTest.java which does not respect the constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be part of the target image.
> This can be circumvented by limiting the modules.

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

  Add a comment to help understand the output

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23514/files
  - new: https://git.openjdk.org/jdk/pull/23514/files/e606244c..d13fa654

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

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

PR: https://git.openjdk.org/jdk/pull/23514

From clanger at openjdk.org  Tue Feb 11 10:17:48 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 11 Feb 2025 10:17:48 GMT
Subject: RFR: 8349648: Test tools/jpackage/share/JLinkOptionsTest.java
 fails with --enable-linkable-runtime set after JDK-8346434 [v2]
In-Reply-To: <n-amuJVmNcDNz42toirFgpD9dR6W_rnfGRMx8R5b7TU=.d73757b7-152c-4287-a3d9-b030ea23881a@github.com>
References: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
 <h8CnqRPapIeSl5dP_GYMdlkkJGn1Vbld2dhG0kS-Z20=.0759ff70-57f5-46fb-ae34-2f86eca67023@github.com>
 <WGIslGt3gPmQn1wfkL4CswaKfBvSDnrxBhvwtKF06Js=.18597f47-d3ce-4bed-ba23-c4ccb035a4cf@github.com>
 <n-amuJVmNcDNz42toirFgpD9dR6W_rnfGRMx8R5b7TU=.d73757b7-152c-4287-a3d9-b030ea23881a@github.com>
Message-ID: <IfXr2mciFZf9vbJ-2WbeC2CJBrrdywvbeeuslCGFRYI=.93829ca6-9c3f-40ae-9272-a5051afb4197@github.com>

On Fri, 7 Feb 2025 17:43:15 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> As far as my testing is concerned it's only `jdk.crypto.cryptoki` which is different with `--bind-services` (as it provides a security provider as a service and doesn't export API).
>
> This is the diff of modules between "jpackage without --bind-services" and "jpackage with --bind-services" before this PR:
> 
> [20:27:10.849] TRACE: assertNotEquals(, jdk.charsets,jdk.crypto.cryptoki,jdk.crypto.mscapi,jdk.editpad,jdk.jdeps,jdk.jlink,jdk.jpackage,jdk.jstatd,jdk.localedata,jdk.naming.dns,jdk.naming.rmi): Check '--bind-services' option adds modules

I added a comment about what is expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23514#discussion_r1950571483

From pminborg at openjdk.org  Tue Feb 11 15:24:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 11 Feb 2025 15:24:56 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v5]
In-Reply-To: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
References: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
Message-ID: <o1JXupsLBnK_WgEVFv_9d0yJB3fayBFP_8P-cPoGnG0=.21884fbb-d292-4c55-b30c-f9eb8ca7a083@github.com>

> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes to add a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively:
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.193 ? 0.268  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.268 ? 0.080  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  42.076 ? 1.003  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.801 ? 0.138  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.265 ? 0.087  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.285 ? 0.155  ns/op
> 
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.033 ? 0.423  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   3.676 ? 0.104  ns/op  // <- Happy path using an internal pool
> 
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.023 ? 0.736  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  22.013 ? 0.648  ns/op  // <- Allocating memory upon each invocation
> 
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  22.050 ? 0.233  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   3.756 ? 0.056  ns/op  // <- Using the pool explicitly from Java code
> 
> 
> Adapted system call:
> 
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> 
> 
> Explicit allocation:
> 
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> 
> 
> Thread Local allocation:
> 
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> 
> 
> The adapted system call exhibits a ~6x performanc...

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

 - Use an automatic arena
 - Merge branch 'master' into errno-util3
 - Add test
 - Add stress test
 - Clean up
 - Fix test issue and polish comments
 - Use lazy initialization
 - Improve comments and formatting
 - Bump copyright year
 - Add benchmarks
 - ... and 1 more: https://git.openjdk.org/jdk/compare/485ca76c...df2bcbdd

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23517/files
  - new: https://git.openjdk.org/jdk/pull/23517/files/2fb7af12..df2bcbdd

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

  Stats: 4058 lines in 154 files changed: 2158 ins; 1061 del; 839 mod
  Patch: https://git.openjdk.org/jdk/pull/23517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23517/head:pull/23517

PR: https://git.openjdk.org/jdk/pull/23517

From liach at openjdk.org  Tue Feb 11 16:24:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Feb 2025 16:24:15 GMT
Subject: RFR: 8349624: Validation for slot missing in CodeBuilder local
 variable instructions
In-Reply-To: <fI6Ex768gvhUYXMDTqPDAHL0uGHxxVwYhwQRqKtYTCg=.64b662b0-7724-42f6-82e7-08dadb62e674@github.com>
References: <fI6Ex768gvhUYXMDTqPDAHL0uGHxxVwYhwQRqKtYTCg=.64b662b0-7724-42f6-82e7-08dadb62e674@github.com>
Message-ID: <PViNHVBl1qHRY4-azbhXZ4z4qjJ5I-FO7bujyaYcOYo=.70dbe387-c1d2-4311-85ab-179448a9f1f3@github.com>

On Fri, 7 Feb 2025 19:40:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> In CodeBuilder, validation for a slot was missing due to concurrent patches, and the original patch did not add effective tests for CodeBuilder because of the complex exceptional behaviors. Now the bug is fixed with renames to prevent future risky usages, and the tests have been enhanced to ensure at least the failure-case behavior (while the non-failure case is harder to check due to exceptional behaviors)
> 
> Testing: JDK tier 1-3

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23522#issuecomment-2651318152

From liach at openjdk.org  Tue Feb 11 16:24:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Feb 2025 16:24:16 GMT
Subject: Integrated: 8349624: Validation for slot missing in CodeBuilder local
 variable instructions
In-Reply-To: <fI6Ex768gvhUYXMDTqPDAHL0uGHxxVwYhwQRqKtYTCg=.64b662b0-7724-42f6-82e7-08dadb62e674@github.com>
References: <fI6Ex768gvhUYXMDTqPDAHL0uGHxxVwYhwQRqKtYTCg=.64b662b0-7724-42f6-82e7-08dadb62e674@github.com>
Message-ID: <7aHBIgMSnwOjz_UL1o2ihCu0uzo_V8gCs_xVnZraIGc=.2b98a81f-8654-420d-890f-6728cf91f8a2@github.com>

On Fri, 7 Feb 2025 19:40:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> In CodeBuilder, validation for a slot was missing due to concurrent patches, and the original patch did not add effective tests for CodeBuilder because of the complex exceptional behaviors. Now the bug is fixed with renames to prevent future risky usages, and the tests have been enhanced to ensure at least the failure-case behavior (while the non-failure case is harder to check due to exceptional behaviors)
> 
> Testing: JDK tier 1-3

This pull request has now been integrated.

Changeset: 32dc41c9
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32dc41c9f782d0c8829e1ef29846d236b3cf0fe2
Stats:     61 lines in 2 files changed: 38 ins; 1 del; 22 mod

8349624: Validation for slot missing in CodeBuilder local variable instructions

Reviewed-by: asotona

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

PR: https://git.openjdk.org/jdk/pull/23522

From liach at openjdk.org  Tue Feb 11 16:39:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Feb 2025 16:39:10 GMT
Subject: RFR: 8342206: Convenience method to check if a constant pool entry
 matches nominal descriptors
In-Reply-To: <xe9YCwkkpS1rAXx0GtKEpMyY_cETHg-41PIQ74NJtQk=.0a12669c-8e26-4b34-83a3-a9513b697525@github.com>
References: <W3im0ithPIye8qZ3-YwRYX3JpYKH69dqeQ96MKRButo=.54bb8b43-a2a1-4a4a-a8e0-b37f109f0a35@github.com>
 <xe9YCwkkpS1rAXx0GtKEpMyY_cETHg-41PIQ74NJtQk=.0a12669c-8e26-4b34-83a3-a9513b697525@github.com>
Message-ID: <3hRPrfKDdclj2HM_H0ThsFHp3Q8SuIu8W6I2H_EkB1c=.f9ac31e2-6fec-49ff-ae47-7a6700db2aff@github.com>

On Tue, 11 Feb 2025 08:03:23 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> The ClassFile API promotes usage of constant nominal descriptors over literal strings. However, for `class` file parsing, currently the efficient way to check if a constant pool entry matches a desired descriptor is via unrolling them back to strings. However, string unrolling is ugly, and often times confusing, such as internal names versus field descriptors.
>> 
>> As a result, I propose to provide new methods that compare constant pool entries with the potential symbolic descriptors they represent. This is no less efficient as checking raw string equality, avoids exceptional failure behaviors of conversion to symbolic descriptors, and avoids potential programmer errors stemming from raw string handling. See the CSR for a full story.
>
> src/java.base/share/classes/java/lang/classfile/constantpool/Utf8Entry.java line 95:
> 
>> 93:      * @since 25
>> 94:      */
>> 95:     boolean equalsSymbol(ClassDesc desc);
> 
> Ambiguity of class internal name vs. descriptor serialization might be confusing:
> 
> classEntry.equalsSymbol(classDesc) != classEntry.name().equalsSymbol(classDesc)
> 
> I think it should be more highlighted to avoid mistakes.

I think the best way to avoid these confusions is, in addition to specifying in the docs, renaming the methods on `Utf8Entry` to include the word "descriptor", like `equalsDescriptorString`, but I fear this method name might be too long.

If the `equalsDescriptorString` on `Utf8Entry` is too inconvenient, a remedy may be to add `matches(String, ClassDesc)` or `matches(String, MethodTypeDesc)` to NameAndTypeEntry and/or MemberRefEntry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23548#discussion_r1951191457

From asotona at openjdk.org  Tue Feb 11 17:17:13 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 11 Feb 2025 17:17:13 GMT
Subject: RFR: 8342206: Convenience method to check if a constant pool entry
 matches nominal descriptors
In-Reply-To: <3hRPrfKDdclj2HM_H0ThsFHp3Q8SuIu8W6I2H_EkB1c=.f9ac31e2-6fec-49ff-ae47-7a6700db2aff@github.com>
References: <W3im0ithPIye8qZ3-YwRYX3JpYKH69dqeQ96MKRButo=.54bb8b43-a2a1-4a4a-a8e0-b37f109f0a35@github.com>
 <xe9YCwkkpS1rAXx0GtKEpMyY_cETHg-41PIQ74NJtQk=.0a12669c-8e26-4b34-83a3-a9513b697525@github.com>
 <3hRPrfKDdclj2HM_H0ThsFHp3Q8SuIu8W6I2H_EkB1c=.f9ac31e2-6fec-49ff-ae47-7a6700db2aff@github.com>
Message-ID: <Z5bhg4C5of3c1CtT-YrlKpZT7KcO8ZPHhDSSfnDgmqU=.589f2e24-845c-45df-af79-74e6797b3b71@github.com>

On Tue, 11 Feb 2025 16:36:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/classfile/constantpool/Utf8Entry.java line 95:
>> 
>>> 93:      * @since 25
>>> 94:      */
>>> 95:     boolean equalsSymbol(ClassDesc desc);
>> 
>> Ambiguity of class internal name vs. descriptor serialization might be confusing:
>> 
>> classEntry.equalsSymbol(classDesc) != classEntry.name().equalsSymbol(classDesc)
>> 
>> I think it should be more highlighted to avoid mistakes.
>
> I think the best way to avoid these confusions is, in addition to specifying in the docs, renaming the methods on `Utf8Entry` to include the word "descriptor", like `equalsDescriptorString`, but I fear this method name might be too long.
> 
> If the `equalsDescriptorString` on `Utf8Entry` is too inconvenient, a remedy may be to add `matches(String, ClassDesc)` or `matches(String, MethodTypeDesc)` to NameAndTypeEntry and/or MemberRefEntry.

I think it is clearly OK to add the non-ambiguous methods, however this one probably should be brought to the mailing list for discussion. We already did some spins related to the ClassDesc serialization ambiguity in the API and there was never clear output. One of the option might be to exclude the ambiguous methods from this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23548#discussion_r1951261649

From naoto at openjdk.org  Tue Feb 11 17:23:21 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 11 Feb 2025 17:23:21 GMT
Subject: Integrated: 8349254: Disable "best-fit" mapping on Windows environment
 variables
In-Reply-To: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
Message-ID: <cCNC1yOsOBrrY9b5zzCF4afdc64DydrXTn0NS4U__MI=.9853a98d-a345-42b9-b90a-506e492a2ae0@github.com>

On Thu, 6 Feb 2025 19:46:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed.

This pull request has now been integrated.

Changeset: 64281653
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/642816538fbaa5b74c6beb8a14d1738cdde28c10
Stats:     138 lines in 3 files changed: 74 ins; 43 del; 21 mod

8349254: Disable "best-fit" mapping on Windows environment variables

Reviewed-by: jlu, jpai

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

PR: https://git.openjdk.org/jdk/pull/23498

From naoto at openjdk.org  Tue Feb 11 17:23:20 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 11 Feb 2025 17:23:20 GMT
Subject: RFR: 8349254: Disable "best-fit" mapping on Windows environment
 variables [v3]
In-Reply-To: <EK6n63VyKwdmaAgLsAmV9IEjv0NV8HGNXVnyna7S-K4=.87fe6c89-cb86-4f94-ab55-f11827b3f56e@github.com>
References: <xOCAcmvxfSESU9yjoiMa1I_WaHLQJIbYiyG4KlA39kM=.7a0ea9e6-047a-42eb-914e-75528338a63e@github.com>
 <EK6n63VyKwdmaAgLsAmV9IEjv0NV8HGNXVnyna7S-K4=.87fe6c89-cb86-4f94-ab55-f11827b3f56e@github.com>
Message-ID: <X5vovgjf-TfZhp2tUwqG8Fh_1DXaeM0kNs6ZDn83QLU=.28031c74-d570-4e4f-9343-4df9c924edc1@github.com>

On Fri, 7 Feb 2025 20:05:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a follow-on fix to [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same processing is needed. Also, obsolete code for Windows 9x has been removed.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Reflects review
>  - Merge branch 'master' into JDK-8349254-disable-best-fit-env-vars
>  - Reflects review
>  - initial commit

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23498#issuecomment-2651520018

From jnimeh at openjdk.org  Tue Feb 11 17:57:25 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 11 Feb 2025 17:57:25 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms
Message-ID: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>

This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).

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

Commit messages:
 - 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms

Changes: https://git.openjdk.org/jdk/pull/23566/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349759
  Stats: 316 lines in 3 files changed: 269 ins; 13 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/23566.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23566/head:pull/23566

PR: https://git.openjdk.org/jdk/pull/23566

From liach at openjdk.org  Tue Feb 11 18:00:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Feb 2025 18:00:25 GMT
Subject: RFR: 8349716: IllegalAccessError when Proxy methods return object of a
 package-private type
Message-ID: <4f_LF0KVq5VErEt3iTND7-mgpfQv1OAloAnBQML6MJg=.da4c2f30-835d-489b-92b8-586830b66564@github.com>

The return value adaption of Proxy is problematic, that it may attempt to access package-private types inaccessible to its package in a `checkcast` instruction, which causes `IllegalAccessError` if the returned object is not `null`. This likely affects all Java versions since the publication of OpenJDK.

A practical effect of this is that if a repeatable annotation is package-private but the container is not, user code cannot access the `value` element in the container annotation.

All added tests except `PackagePrivateContainerTest::testGetRepeatable` fail on current mainline and pass with the ProxyGenerator patch.

Testing: Running tier 1-3

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

Commit messages:
 - 8349716: IllegalAccessError when Proxy methods return object of a package-private type

Changes: https://git.openjdk.org/jdk/pull/23567/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23567&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349716
  Stats: 140 lines in 3 files changed: 133 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23567/head:pull/23567

PR: https://git.openjdk.org/jdk/pull/23567

From asemenyuk at openjdk.org  Tue Feb 11 19:25:21 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 11 Feb 2025 19:25:21 GMT
Subject: Integrated: 8150442: Enforce Supported Platforms in Packager for MSI
 bundles
In-Reply-To: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
References: <NVa5rAp4waywmwR6hSjpRoNd5JCKFY1eHTOKnVMOZak=.b4a6be36-462b-4ff5-a44b-84822ccd8068@github.com>
Message-ID: <7Yq_VsI6vfwnWcbc4HMhJ--sfP3I8-WhNNFAJHG0n90=.271513ff-7013-4cf0-a4a8-900ecdeee4ec@github.com>

On Wed, 5 Feb 2025 20:11:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Enable MSI installers to block installation if the version of Windows is too old.
> 
> jpackage will read major and minor OS versions from PE headers of the main launcher and `java.dll` in the app image. The combined version is the minimal Windows version these executables can run. Thus, it will be a lower bound for the Windows version the installer supports. 
> 
> The value of the combined version is passed as `JpExecutableOSVersion` WiX variable to a new `os-condition.wxf` WiX fragment. The fragment compares the value of `JpExecutableOSVersion` WiX variable with the value of `VersionNT` MSI property. If the value of the latter is less the installation is blocked.
> 
> The fragment can be overridden in the resource directory. This makes this feature fully customizable.

This pull request has now been integrated.

Changeset: e7157d17
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7157d174c19a3562c4bf19760760cb1de13cb0e
Stats:     406 lines in 14 files changed: 396 ins; 2 del; 8 mod

8150442: Enforce Supported Platforms in Packager for MSI bundles

Reviewed-by: almatvee, cstein

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

PR: https://git.openjdk.org/jdk/pull/23472

From vpaprotski at openjdk.org  Tue Feb 11 21:47:31 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Tue, 11 Feb 2025 21:47:31 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v6]
In-Reply-To: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
Message-ID: <SSCxiJUNRkdEHOIJ2mbrBJ6Re8GzFwGBEtI4gqibvNA=.e9ba99b3-6c50-4a86-9de9-795f8045c9b3@github.com>

> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
> 
> This PR fixes two issues:
> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
> 
> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
> 
> 
> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
> 
> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
> 
> ---
> 
> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)

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

  comments from Sandhya

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22673/files
  - new: https://git.openjdk.org/jdk/pull/22673/files/2e372f29..b23764ab

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

  Stats: 5 lines in 2 files changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22673/head:pull/22673

PR: https://git.openjdk.org/jdk/pull/22673

From sviswanathan at openjdk.org  Tue Feb 11 23:46:13 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 11 Feb 2025 23:46:13 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v6]
In-Reply-To: <SSCxiJUNRkdEHOIJ2mbrBJ6Re8GzFwGBEtI4gqibvNA=.e9ba99b3-6c50-4a86-9de9-795f8045c9b3@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <SSCxiJUNRkdEHOIJ2mbrBJ6Re8GzFwGBEtI4gqibvNA=.e9ba99b3-6c50-4a86-9de9-795f8045c9b3@github.com>
Message-ID: <2dkEcQAbzdcH-cajmzsDbpdwdIGIzRY9PeqPG7xG2oE=.38f8d823-cd20-4c00-af84-29982d755b30@github.com>

On Tue, 11 Feb 2025 21:47:31 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>> 
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
>> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
>> 
>> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
>> 
>> 
>> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
>> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
>> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
>> 
>> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
>> 
>> ---
>> 
>> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments from Sandhya

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22673#pullrequestreview-2610374929

From duke at openjdk.org  Tue Feb 11 23:47:11 2025
From: duke at openjdk.org (Bernd)
Date: Tue, 11 Feb 2025 23:47:11 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms
In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
Message-ID: <02WAoRP3oFoYsFTUELth8tNifdLT_iWgCpmA3kxs3c4=.0230e7b3-6ca4-4ad5-8605-64948581814d@github.com>

On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).

Interesting! Is there no JEP Level Initiative for This? Did you do any Interop Testing, in fact are there already Root CAs offering such certificates? Does it apply Cross key typen? (ML-DSA issue signature on a ECDSA key or vice versa?)

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

PR Comment: https://git.openjdk.org/jdk/pull/23566#issuecomment-2652309271

From jnimeh at openjdk.org  Tue Feb 11 23:55:11 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 11 Feb 2025 23:55:11 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms
In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
Message-ID: <31MLKC3JzJF2jRoIH2llf7ZnO1GlZpnhapoZgdDdwBk=.d2a30349-c715-4db9-b5cf-2ff493801b00@github.com>

On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).

I see no reason why an ECDSA end-entity key wouldn't work when signed from an ML-DSA root.  To be clear, this just fixes these test classes I wrote a long time ago where the creation of signatures on certs and OCSP responses just wasn't done in a manner as algorithm-neutral as I intended it to be.  As far as I've seen since the inclusion of ML-DSA, CertPathValidator operations seem to work just fine.  I haven't gone looking to see who in the 3rd party world is doing ML-DSA certs...the goal of this PR was to make sure that we could simply build those cert chains for use with our tests, especially where we needed an OCSP server.

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

PR Comment: https://git.openjdk.org/jdk/pull/23566#issuecomment-2652318099

From liach at openjdk.org  Wed Feb 12 00:03:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Feb 2025 00:03:13 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v7]
In-Reply-To: <gYu9Dt5fOYOETzUd4lXF-rUVu7jHsAS7okf_R7qUxHM=.996c13f8-d671-4713-839b-7d31c5444bfc@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <gYu9Dt5fOYOETzUd4lXF-rUVu7jHsAS7okf_R7qUxHM=.996c13f8-d671-4713-839b-7d31c5444bfc@github.com>
Message-ID: <2lG9VhKEsE-D5TAEt0bwzEBbi8m4CeFHYXVaCa2ihz4=.8394ff99-d47a-4761-8e5b-f740daea92ea@github.com>

On Mon, 10 Feb 2025 13:23:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into protection-domain
>  - Move test for protectionDomain filtering.
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Remove @Stable annotation for final field.
>  - Fix test that knows which fields are hidden from reflection in jvmci.
>  - Hide Class.protectionDomain for reflection and add a test case.
>  - Merge branch 'master' into protection-domain
>  - Fix two tests.
>  - Fix the test.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c9cadbd2...2208302c

The updated java code looks good. Need other engineers to look at hotspot changes.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23396#pullrequestreview-2610411471

From lmesnik at openjdk.org  Wed Feb 12 00:30:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 12 Feb 2025 00:30:12 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <miP5yG1cxruk-95cFJS12OB98XAg0nSm_xkci79tbQ4=.921bf560-093f-4cb8-bcfd-eb24b0ff4049@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23550#pullrequestreview-2610467761

From syan at openjdk.org  Wed Feb 12 03:03:26 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 03:03:26 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <db73BhWt2Xgz_zGic_5SxAW-ho2D-yaSerK-v64lfNs=.30b138e6-20c2-4d5e-a738-cdb2c8ca551b@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

Thanks all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23550#issuecomment-2652545506

From syan at openjdk.org  Wed Feb 12 03:03:26 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 03:03:26 GMT
Subject: Integrated: 8349689: Several virtual thread tests missing /native
 keyword
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <XGK3Deje9V8dDObSEdwBq5uveDcwruowG_lPj9U8rvY=.c361a005-650c-4bab-ad71-a1f87159d360@github.com>

On Tue, 11 Feb 2025 02:45:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

This pull request has now been integrated.

Changeset: 88b4a906
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88b4a906d2c520ce6a7b21adc5e709067e520cdd
Stats:     55 lines in 12 files changed: 1 ins; 0 del; 54 mod

8349689: Several virtual thread tests missing /native keyword

Reviewed-by: alanb, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/23550

From syan at openjdk.org  Wed Feb 12 03:30:24 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 03:30:24 GMT
Subject: RFR: 8349787: Test ThreadPollOnYield.java#default passed unexpected
 without native library
Message-ID: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>

Hi all,

Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java run passed unexpected without native library or with the incorrect native library path. The test command with incorrect native library path shows below. We will seen this tests run passed unexpected before this PR, because the first virtual thread do not run normally without the dependent shared library libVThreadPinner.so, and there is no assert when the first virtual thread run abnormal.


mkdir -p empty-directory ; jtreg -v:fail,error -w tmp -nr -jdk:build/linux-x86_64-server-release/images/jdk -nativepath:empty-directory test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java#default


This PR add a latch variable will make sure the first virtual thread run once at least. After this PR run the same test command which with incorrect native library path, and we will seen this pass run timed out as expected.

Change has been verified locally, test-fix only, no risk.

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

Commit messages:
 - 8349787: Test ThreadPollOnYield.java passed unexpected without native library

Changes: https://git.openjdk.org/jdk/pull/23576/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23576&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349787
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23576.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23576/head:pull/23576

PR: https://git.openjdk.org/jdk/pull/23576

From dholmes at openjdk.org  Wed Feb 12 03:46:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 12 Feb 2025 03:46:16 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <sJ_UAcGbIL7_HNi9UjRplJKfjCcO2Q6NpYxVoLTbOgw=.04ab048c-254b-432e-b447-061a39b28c6a@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

test/jdk/java/lang/Thread/virtual/Starvation.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, 2025 Oracle and/or its affiliates. All rights reserved.

You missed the comma after 2025 here. This is now causing failures in our CI.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1951933716

From syan at openjdk.org  Wed Feb 12 04:38:19 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 04:38:19 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <sJ_UAcGbIL7_HNi9UjRplJKfjCcO2Q6NpYxVoLTbOgw=.04ab048c-254b-432e-b447-061a39b28c6a@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
 <sJ_UAcGbIL7_HNi9UjRplJKfjCcO2Q6NpYxVoLTbOgw=.04ab048c-254b-432e-b447-061a39b28c6a@github.com>
Message-ID: <iow9jDZFLb3hH5Im4vQFk-lnBX6c4HZl93SMpWM7GTg=.4e95a434-c0d2-4a48-9c5c-d29b319d6cd4@github.com>

On Wed, 12 Feb 2025 03:43:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java
>
> test/jdk/java/lang/Thread/virtual/Starvation.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, 2025 Oracle and/or its affiliates. All rights reserved.
> 
> You missed the comma after 2025 here. This is now causing failures in our CI.

Sorry, I create a new issue [JDK-8349876](https://bugs.openjdk.org/browse/JDK-8349876) for that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1951963891

From syan at openjdk.org  Wed Feb 12 06:12:13 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 06:12:13 GMT
Subject: Integrated: 8349874: Missing comma in copyright from JDK-8349689
In-Reply-To: <b2-gwYtyxRqHDxvCoL6GFqNv1F3IWyXysi3wJGPQkTo=.5baba208-e171-4816-a468-e509fef87207@github.com>
References: <b2-gwYtyxRqHDxvCoL6GFqNv1F3IWyXysi3wJGPQkTo=.5baba208-e171-4816-a468-e509fef87207@github.com>
Message-ID: <Tog5tnyWS0x_vGxvbiRnpuvgqwGJzQJ_zLVrq_NGMhc=.1f7522d3-2560-4e83-88d3-0a01514c6846@github.com>

On Wed, 12 Feb 2025 03:53:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Trivial fix for missing comma.
> 
> Thanks

Thanks David. Apologize for mine carelessness.

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

PR Comment: https://git.openjdk.org/jdk/pull/23577#issuecomment-2652752680

From dholmes at openjdk.org  Wed Feb 12 06:32:25 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 12 Feb 2025 06:32:25 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v7]
In-Reply-To: <gYu9Dt5fOYOETzUd4lXF-rUVu7jHsAS7okf_R7qUxHM=.996c13f8-d671-4713-839b-7d31c5444bfc@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <gYu9Dt5fOYOETzUd4lXF-rUVu7jHsAS7okf_R7qUxHM=.996c13f8-d671-4713-839b-7d31c5444bfc@github.com>
Message-ID: <GDGwKKzRDGhafRVl1osR_kHT9WS17aBWjWLIWBj1tXw=.8ef43ca8-9292-42ee-9817-85443318984b@github.com>

On Mon, 10 Feb 2025 13:23:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into protection-domain
>  - Move test for protectionDomain filtering.
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Remove @Stable annotation for final field.
>  - Fix test that knows which fields are hidden from reflection in jvmci.
>  - Hide Class.protectionDomain for reflection and add a test case.
>  - Merge branch 'master' into protection-domain
>  - Fix two tests.
>  - Fix the test.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c9cadbd2...2208302c

Hotspot changes are fine. This all looks good to me.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23396#pullrequestreview-2610940836

From alanb at openjdk.org  Wed Feb 12 07:18:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Feb 2025 07:18:12 GMT
Subject: RFR: 8349787: Test ThreadPollOnYield.java#default passed
 unexpected without native library
In-Reply-To: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
References: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
Message-ID: <TJ0MjFd1eZGBMUpkSnCTCABPHBqdPZ3x4QkvuC5XVkA=.078babb6-b06f-4877-b8fc-705043f89e76@github.com>

On Wed, 12 Feb 2025 03:24:07 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java run passed unexpected without native library or with the incorrect native library path. The test command with incorrect native library path shows below. We will seen this tests run passed unexpected before this PR, because the first virtual thread do not run normally without the dependent shared library libVThreadPinner.so, and there is no assert when the first virtual thread run abnormal.
> 
> 
> mkdir -p empty-directory ; jtreg -v:fail,error -w tmp -nr -jdk:build/linux-x86_64-server-release/images/jdk -nativepath:empty-directory test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java#default
> 
> 
> This PR add a latch variable will make sure the first virtual thread run once at least. After this PR run the same test command which with incorrect native library path, and we will seen this pass run timed out as expected.
> 
> Change has been verified locally, test-fix only, no risk.

test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 54:

> 52:     static void foo(AtomicBoolean done) {
> 53:         while (!done.get()) {
> 54:             latch.countDown();

While not correct, it looks very strange to do the count down in the loop. It would be a lot clearer to rename "latch" to "started" and do the countDown before the while.  Also no need for it to be public.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23576#discussion_r1952099166

From syan at openjdk.org  Wed Feb 12 07:35:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 07:35:50 GMT
Subject: RFR: 8349787: Test ThreadPollOnYield.java#default passed
 unexpected without native library [v2]
In-Reply-To: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
References: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
Message-ID: <6iY9xW3XQGugq9_qtgNupdnQyDJHv5PmpJJMwVrns0o=.9528527c-2498-4efc-bced-f725d13609dc@github.com>

> Hi all,
> 
> Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java run passed unexpected without native library or with the incorrect native library path. The test command with incorrect native library path shows below. We will seen this tests run passed unexpected before this PR, because the first virtual thread do not run normally without the dependent shared library libVThreadPinner.so, and there is no assert when the first virtual thread run abnormal.
> 
> 
> mkdir -p empty-directory ; jtreg -v:fail,error -w tmp -nr -jdk:build/linux-x86_64-server-release/images/jdk -nativepath:empty-directory test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java#default
> 
> 
> This PR add a latch variable will make sure the first virtual thread run once at least. After this PR run the same test command which with incorrect native library path, and we will seen this pass run timed out as expected.
> 
> Change has been verified locally, test-fix only, no risk.

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

 - Merge branch 'openjdk:master' into jbs8349787
 - 8349787: Test ThreadPollOnYield.java passed unexpected without native library

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23576/files
  - new: https://git.openjdk.org/jdk/pull/23576/files/2f3dd3b8..12f069c1

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

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

PR: https://git.openjdk.org/jdk/pull/23576

From alanb at openjdk.org  Wed Feb 12 07:36:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Feb 2025 07:36:13 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v7]
In-Reply-To: <gYu9Dt5fOYOETzUd4lXF-rUVu7jHsAS7okf_R7qUxHM=.996c13f8-d671-4713-839b-7d31c5444bfc@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <gYu9Dt5fOYOETzUd4lXF-rUVu7jHsAS7okf_R7qUxHM=.996c13f8-d671-4713-839b-7d31c5444bfc@github.com>
Message-ID: <IxQRZcQXMb_XZ3uuoOkE6bnoVCNADB4b-aLoL_nBKSY=.eb635676-4226-4053-b923-6f7415f25558@github.com>

On Mon, 10 Feb 2025 13:23:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into protection-domain
>  - Move test for protectionDomain filtering.
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Remove @Stable annotation for final field.
>  - Fix test that knows which fields are hidden from reflection in jvmci.
>  - Hide Class.protectionDomain for reflection and add a test case.
>  - Merge branch 'master' into protection-domain
>  - Fix two tests.
>  - Fix the test.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c9cadbd2...2208302c

This looks okay. There will be some follow-up cleanup needed in the libs code, e.g.JLA.protectionDomain(Class) can go away, something for future PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2652874791

From syan at openjdk.org  Wed Feb 12 07:43:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 07:43:50 GMT
Subject: RFR: 8349787:
 java/lang/Thread/virtual/ThreadPollOnYield.java#default passes unexpectedly
 without libVThreadPinner.so [v3]
In-Reply-To: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
References: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
Message-ID: <91SpmlF69kAm2IUjfMiCu3cKq7lWpns5cfw7MvtM3Yg=.2294f7ab-3045-4bec-8f44-096997f6bd10@github.com>

> Hi all,
> 
> Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java run passed unexpected without native library or with the incorrect native library path. The test command with incorrect native library path shows below. We will seen this tests run passed unexpected before this PR, because the first virtual thread do not run normally without the dependent shared library libVThreadPinner.so, and there is no assert when the first virtual thread run abnormal.
> 
> 
> mkdir -p empty-directory ; jtreg -v:fail,error -w tmp -nr -jdk:build/linux-x86_64-server-release/images/jdk -nativepath:empty-directory test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java#default
> 
> 
> This PR add a latch variable will make sure the first virtual thread run once at least. After this PR run the same test command which with incorrect native library path, and we will seen this pass run timed out as expected.
> 
> Change has been verified locally, test-fix only, no risk.

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

  Rename latch to started, and do the countDown before the while loop

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23576/files
  - new: https://git.openjdk.org/jdk/pull/23576/files/12f069c1..341eae9a

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

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

PR: https://git.openjdk.org/jdk/pull/23576

From syan at openjdk.org  Wed Feb 12 07:43:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 07:43:50 GMT
Subject: RFR: 8349787:
 java/lang/Thread/virtual/ThreadPollOnYield.java#default passes unexpectedly
 without libVThreadPinner.so [v3]
In-Reply-To: <TJ0MjFd1eZGBMUpkSnCTCABPHBqdPZ3x4QkvuC5XVkA=.078babb6-b06f-4877-b8fc-705043f89e76@github.com>
References: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
 <TJ0MjFd1eZGBMUpkSnCTCABPHBqdPZ3x4QkvuC5XVkA=.078babb6-b06f-4877-b8fc-705043f89e76@github.com>
Message-ID: <Oz4JEeZtK0Ez3YJihB-W7c4by0AHapChkDre84SDLAk=.8aad33dc-2275-4ff6-910f-6425a3038525@github.com>

On Wed, 12 Feb 2025 07:15:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename latch to started, and do the countDown before the while loop
>
> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 54:
> 
>> 52:     static void foo(AtomicBoolean done) {
>> 53:         while (!done.get()) {
>> 54:             latch.countDown();
> 
> While not incorrect, it looks very strange to do the count down in the loop. It would be a lot clearer to rename "latch" to "started" and do the countDown before the while.  Also no need for it to be public.

Thanks. Variable has been renamed to `started`, and do the countDown before the while loop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23576#discussion_r1952124848

From alanb at openjdk.org  Wed Feb 12 08:25:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Feb 2025 08:25:11 GMT
Subject: RFR: 8349787:
 java/lang/Thread/virtual/ThreadPollOnYield.java#default passes unexpectedly
 without libVThreadPinner.so [v3]
In-Reply-To: <91SpmlF69kAm2IUjfMiCu3cKq7lWpns5cfw7MvtM3Yg=.2294f7ab-3045-4bec-8f44-096997f6bd10@github.com>
References: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
 <91SpmlF69kAm2IUjfMiCu3cKq7lWpns5cfw7MvtM3Yg=.2294f7ab-3045-4bec-8f44-096997f6bd10@github.com>
Message-ID: <FJXLURIgJrGKf4lz-Vr7Pnq140PoDWTa5_Rg0-H-cik=.1c7409be-b43a-44a3-992c-f20b77b0fc9c@github.com>

On Wed, 12 Feb 2025 07:43:50 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java run passed unexpected without native library or with the incorrect native library path. The test command with incorrect native library path shows below. We will seen this tests run passed unexpected before this PR, because the first virtual thread do not run normally without the dependent shared library libVThreadPinner.so, and there is no assert when the first virtual thread run abnormal.
>> 
>> 
>> mkdir -p empty-directory ; jtreg -v:fail,error -w tmp -nr -jdk:build/linux-x86_64-server-release/images/jdk -nativepath:empty-directory test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java#default
>> 
>> 
>> This PR add a latch variable will make sure the first virtual thread run once at least. After this PR run the same test command which with incorrect native library path, and we will seen this pass run timed out as expected.
>> 
>> Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename latch to started, and do the countDown before the while loop

test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 51:

> 49: 
> 50: class ThreadPollOnYield {
> 51:     private static CountDownLatch started = new CountDownLatch(1);

Can you make this final?

test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 65:

> 63:             VThreadPinner.runPinned(() -> foo(done));
> 64:         });
> 65:         started.await();

I think this is okay. If the test is run directly with jtreg without libVThreadPinner.so then the virtual thread will throw and the main thread will wait indefinitely here, and the test will timeout.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23576#discussion_r1952180355
PR Review Comment: https://git.openjdk.org/jdk/pull/23576#discussion_r1952181937

From syan at openjdk.org  Wed Feb 12 08:31:48 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 08:31:48 GMT
Subject: RFR: 8349787:
 java/lang/Thread/virtual/ThreadPollOnYield.java#default passes unexpectedly
 without libVThreadPinner.so [v4]
In-Reply-To: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
References: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
Message-ID: <ljKyc7eN6gNLSPAkMmAFvC_GImSVMKiU5SMYeDeWMHo=.6cd62598-9129-4332-9023-af98c82ee4c9@github.com>

> Hi all,
> 
> Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java run passed unexpected without native library or with the incorrect native library path. The test command with incorrect native library path shows below. We will seen this tests run passed unexpected before this PR, because the first virtual thread do not run normally without the dependent shared library libVThreadPinner.so, and there is no assert when the first virtual thread run abnormal.
> 
> 
> mkdir -p empty-directory ; jtreg -v:fail,error -w tmp -nr -jdk:build/linux-x86_64-server-release/images/jdk -nativepath:empty-directory test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java#default
> 
> 
> This PR add a latch variable will make sure the first virtual thread run once at least. After this PR run the same test command which with incorrect native library path, and we will seen this pass run timed out as expected.
> 
> Change has been verified locally, test-fix only, no risk.

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

  Set started as final

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23576/files
  - new: https://git.openjdk.org/jdk/pull/23576/files/341eae9a..e958b348

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

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

PR: https://git.openjdk.org/jdk/pull/23576

From alanb at openjdk.org  Wed Feb 12 08:31:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Feb 2025 08:31:48 GMT
Subject: RFR: 8349787:
 java/lang/Thread/virtual/ThreadPollOnYield.java#default passes unexpectedly
 without libVThreadPinner.so [v4]
In-Reply-To: <ljKyc7eN6gNLSPAkMmAFvC_GImSVMKiU5SMYeDeWMHo=.6cd62598-9129-4332-9023-af98c82ee4c9@github.com>
References: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
 <ljKyc7eN6gNLSPAkMmAFvC_GImSVMKiU5SMYeDeWMHo=.6cd62598-9129-4332-9023-af98c82ee4c9@github.com>
Message-ID: <U0JDyN2g5CJMsWE_G84eBq4UCHdX-lj3LyfWL0FiGrI=.564238f8-df23-42dc-8d40-89718b4207dc@github.com>

On Wed, 12 Feb 2025 08:28:16 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java run passed unexpected without native library or with the incorrect native library path. The test command with incorrect native library path shows below. We will seen this tests run passed unexpected before this PR, because the first virtual thread do not run normally without the dependent shared library libVThreadPinner.so, and there is no assert when the first virtual thread run abnormal.
>> 
>> 
>> mkdir -p empty-directory ; jtreg -v:fail,error -w tmp -nr -jdk:build/linux-x86_64-server-release/images/jdk -nativepath:empty-directory test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java#default
>> 
>> 
>> This PR add a latch variable will make sure the first virtual thread run once at least. After this PR run the same test command which with incorrect native library path, and we will seen this pass run timed out as expected.
>> 
>> Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set started as final

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23576#pullrequestreview-2611154381

From syan at openjdk.org  Wed Feb 12 08:31:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 08:31:49 GMT
Subject: RFR: 8349787:
 java/lang/Thread/virtual/ThreadPollOnYield.java#default passes unexpectedly
 without libVThreadPinner.so [v3]
In-Reply-To: <FJXLURIgJrGKf4lz-Vr7Pnq140PoDWTa5_Rg0-H-cik=.1c7409be-b43a-44a3-992c-f20b77b0fc9c@github.com>
References: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
 <91SpmlF69kAm2IUjfMiCu3cKq7lWpns5cfw7MvtM3Yg=.2294f7ab-3045-4bec-8f44-096997f6bd10@github.com>
 <FJXLURIgJrGKf4lz-Vr7Pnq140PoDWTa5_Rg0-H-cik=.1c7409be-b43a-44a3-992c-f20b77b0fc9c@github.com>
Message-ID: <W1q4wkgljlyFp1SoO68v0wGnz9piukimZMBocOrXoHw=.7ab133e2-c74d-488c-975f-e956127101e7@github.com>

On Wed, 12 Feb 2025 08:21:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename latch to started, and do the countDown before the while loop
>
> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 51:
> 
>> 49: 
>> 50: class ThreadPollOnYield {
>> 51:     private static CountDownLatch started = new CountDownLatch(1);
> 
> Can you make this final?

Okey.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23576#discussion_r1952187449

From pminborg at openjdk.org  Wed Feb 12 08:46:31 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Feb 2025 08:46:31 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v6]
In-Reply-To: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
References: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
Message-ID: <D3zUzTl67AIhytSDaeVLUldKBjvXB82ph_zio8g925k=.dd5de015-dc55-4d48-9047-c926f68873b0@github.com>

> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes to add a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively:
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.193 ? 0.268  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.268 ? 0.080  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  42.076 ? 1.003  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.801 ? 0.138  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.265 ? 0.087  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.285 ? 0.155  ns/op
> 
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.033 ? 0.423  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   3.676 ? 0.104  ns/op  // <- Happy path using an internal pool
> 
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.023 ? 0.736  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  22.013 ? 0.648  ns/op  // <- Allocating memory upon each invocation
> 
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  22.050 ? 0.233  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   3.756 ? 0.056  ns/op  // <- Using the pool explicitly from Java code
> 
> 
> Adapted system call:
> 
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> 
> 
> Explicit allocation:
> 
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> 
> 
> Thread Local allocation:
> 
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> 
> 
> The adapted system call exhibits a ~6x performanc...

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

  Ensure reachability

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23517/files
  - new: https://git.openjdk.org/jdk/pull/23517/files/df2bcbdd..8b9b5087

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

  Stats: 23 lines in 1 file changed: 14 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23517/head:pull/23517

PR: https://git.openjdk.org/jdk/pull/23517

From jbhateja at openjdk.org  Wed Feb 12 09:13:17 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 12 Feb 2025 09:13:17 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v17]
In-Reply-To: <fYcbuTZ6Uicn6x1uTnhBZxYwgzim_TwldI_9MSLBbmw=.74d51608-d631-4a8a-8e72-a5d623ffef25@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <sgcWAEvXaWi40uFqPPJq-e6n3YsHb7agKBUrMBdqJSc=.48c41eab-6641-45b7-9765-400622894f4b@github.com>
 <fYcbuTZ6Uicn6x1uTnhBZxYwgzim_TwldI_9MSLBbmw=.74d51608-d631-4a8a-8e72-a5d623ffef25@github.com>
Message-ID: <1xQeG8IO8aJNUluyWTaz9cm2xmTKSNsZJMNhnicnm5s=.304de8b6-9bba-44db-9982-eddaf950a415@github.com>

On Mon, 10 Feb 2025 21:23:28 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing typos
>
> An impressive and substantial change. I focused on the Java code, there are some small tweaks, presented in comments, we can make to the intrinsics to improve the expression of code, and it has no impact on the intrinsic implementation.

Hi @PaulSandoz , Your comments have been addressed.

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

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2653071755

From fabian at buildbuddy.io  Wed Feb 12 10:09:45 2025
From: fabian at buildbuddy.io (Fabian Meumertzheim)
Date: Wed, 12 Feb 2025 11:09:45 +0100
Subject: JDK-8072840: Presizing for Stream Collectors
Message-ID: <CAHY-eHsUqc905OqqcYXsuVZjeM+A81OOV2K7CsJ1zg8uc4cPOQ@mail.gmail.com>

As an avid user of Guava's ImmutableCollections, I have been
interested in ways to close the efficiency gap between the built-in
`Stream#toList()` and third-party `Collector` implementations such as
`ImmutableList#toImmutableList()`. I've found the biggest problem to
be the lack of sizing information in `Collector`s, which led to me to
draft a solution to JDK-8072840:
https://github.com/openjdk/jdk/pull/23461

The benchmark shows pretty significant gains for sized streams that
mostly reshape data (e.g. slice records or turn a list into a map by
associating keys), which I've found to be a pretty common use case.

Before I formally send out the PR for review, I would like to gather
feedback on the design aspects of it (rather than the exact
implementation). I will thus leave it in draft mode for now, but
invite anyone to comment on it or on this thread.

Fabian

From sgehwolf at openjdk.org  Wed Feb 12 11:56:12 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Feb 2025 11:56:12 GMT
Subject: RFR: 8349648: Test tools/jpackage/share/JLinkOptionsTest.java
 fails with --enable-linkable-runtime set after JDK-8346434 [v2]
In-Reply-To: <RKzcjQBZoMagTwWIWJhFUH4nM6dY4KV_DftM7aEGqQ0=.87909bb9-7497-401f-ab23-bcf87a2cc601@github.com>
References: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
 <RKzcjQBZoMagTwWIWJhFUH4nM6dY4KV_DftM7aEGqQ0=.87909bb9-7497-401f-ab23-bcf87a2cc601@github.com>
Message-ID: <j_W7BA_94cmOXVt_SRgtixYhsG4KmNGFQUZc80voFp8=.fdd45f4e-b8ad-4dba-9737-a22e97a9b6bc@github.com>

On Tue, 11 Feb 2025 10:17:48 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The change for JDK-8346434 added a new test case to tools/jpackage/share/JLinkOptionsTest.java which does not respect the constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be part of the target image.
>> This can be circumvented by limiting the modules.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment to help understand the output

Marked as reviewed by sgehwolf (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23514#pullrequestreview-2611683179

From yzheng at openjdk.org  Wed Feb 12 12:08:21 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 12 Feb 2025 12:08:21 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v7]
In-Reply-To: <gYu9Dt5fOYOETzUd4lXF-rUVu7jHsAS7okf_R7qUxHM=.996c13f8-d671-4713-839b-7d31c5444bfc@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <gYu9Dt5fOYOETzUd4lXF-rUVu7jHsAS7okf_R7qUxHM=.996c13f8-d671-4713-839b-7d31c5444bfc@github.com>
Message-ID: <1OD68qMw2krDXRaD2SYsuqSYX5tnnRTaXHpGZfxjmz8=.aece15d8-56cc-41cb-9f75-67669a8e0bba@github.com>

On Mon, 10 Feb 2025 13:23:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into protection-domain
>  - Move test for protectionDomain filtering.
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Remove @Stable annotation for final field.
>  - Fix test that knows which fields are hidden from reflection in jvmci.
>  - Hide Class.protectionDomain for reflection and add a test case.
>  - Merge branch 'master' into protection-domain
>  - Fix two tests.
>  - Fix the test.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c9cadbd2...2208302c

LGTM

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

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23396#pullrequestreview-2611703401

From coleenp at openjdk.org  Wed Feb 12 12:08:21 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 12 Feb 2025 12:08:21 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v7]
In-Reply-To: <gYu9Dt5fOYOETzUd4lXF-rUVu7jHsAS7okf_R7qUxHM=.996c13f8-d671-4713-839b-7d31c5444bfc@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <gYu9Dt5fOYOETzUd4lXF-rUVu7jHsAS7okf_R7qUxHM=.996c13f8-d671-4713-839b-7d31c5444bfc@github.com>
Message-ID: <_uTUsNtEQuGM5gEJm51_U8_mPyBePpr3hIzfktY_6SA=.bf9b162d-fa01-4f6d-aaa1-fc54b1c8797c@github.com>

On Mon, 10 Feb 2025 13:23:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into protection-domain
>  - Move test for protectionDomain filtering.
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Remove @Stable annotation for final field.
>  - Fix test that knows which fields are hidden from reflection in jvmci.
>  - Hide Class.protectionDomain for reflection and add a test case.
>  - Merge branch 'master' into protection-domain
>  - Fix two tests.
>  - Fix the test.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c9cadbd2...2208302c

Thanks for reviewing Chen, David, Alan and Yudi.

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

PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2653516543

From coleenp at openjdk.org  Wed Feb 12 12:08:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 12 Feb 2025 12:08:22 GMT
Subject: Integrated: 8349145: Make Class.getProtectionDomain() non-native
In-Reply-To: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
Message-ID: <QVx6U6An95aeR5U86J1g0wbfn19IDggnmHaycmkeiDo=.bc81b5b3-ca17-419d-a9da-41dfb1759f59@github.com>

On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: ed17c55e
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed17c55ea34b3b6009dab11d64f21e0b7af3d701
Stats:     65 lines in 13 files changed: 15 ins; 34 del; 16 mod

8349145: Make Class.getProtectionDomain() non-native

Reviewed-by: liach, dholmes, yzheng

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

PR: https://git.openjdk.org/jdk/pull/23396

From sgehwolf at openjdk.org  Wed Feb 12 12:10:17 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Feb 2025 12:10:17 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v15]
In-Reply-To: <GOLkliNcZsHseg0QKDaS2qAfzst8-8o6v_Fki4Cmk00=.1b2a2161-018e-4cf1-8e3f-1ea7de174456@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <GOLkliNcZsHseg0QKDaS2qAfzst8-8o6v_Fki4Cmk00=.1b2a2161-018e-4cf1-8e3f-1ea7de174456@github.com>
Message-ID: <jJNunBu15HQY3T7PEkYbZo0o8_BuA_5okJ0y8zLCVN0=.1271d1da-3af5-4aea-a99d-62f49e040ef3@github.com>

On Fri, 10 Jan 2025 14:57:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
>> 
>> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
>> 
>> This patch addresses this issue by:
>> 
>> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
>> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
>> 
>> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
>> 
>> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
>> 
>> Thoughts?
>> 
>> Testing:
>> 
>> - [x] GHA
>> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
>> - [x] Some manual testing using systemd slices
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Fix missing imports
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Add exclusive access dirs directive for systemd tests
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/1f457977...c83c22eb

keep open bot. Still looking for a review.

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

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2653525390

From vklang at openjdk.org  Wed Feb 12 14:09:13 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 12 Feb 2025 14:09:13 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <eX36fGOUut-v-udmXyq6XDLwM3BubayrBTBANBkF-dM=.b73c4771-7863-4ac6-9b02-181f11d025da@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <eX36fGOUut-v-udmXyq6XDLwM3BubayrBTBANBkF-dM=.b73c4771-7863-4ac6-9b02-181f11d025da@github.com>
Message-ID: <wkuj6v5vSdqxaRKgFwtar3LgYhc_ji4KA-sT2uVu5Bg=.c7c19978-715d-41a9-8c1f-29860663edae@github.com>

On Tue, 11 Feb 2025 08:39:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
>> 
>> Modification:
>> Add detail error messages.
>> 
>> Result:
>> Helpful messages.
>
> src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java line 122:
> 
>> 120:     @Override
>> 121:     public Future<?> submit(Runnable task) {
>> 122:         if (task == null) throw new NullPointerException("task can't be null");
> 
> Why not use `Objects.requireNonNull()` and break out the repeated code into a common method?

I'd prefer `Objects.requireNonNull(task, "task");`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r1952715499

From jpai at openjdk.org  Wed Feb 12 14:14:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Feb 2025 14:14:45 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases
Message-ID: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>

Can I please get a review of this change in `jdk.tools.jlink.internal.plugins.ZipPlugin` which proposes to close the `Deflater` instance cleanly? This addresses https://bugs.openjdk.org/browse/JDK-8349907.

As noted in that issue, the `Deflater` instance wasn't being closed in the exception code path of this method. The commit in this PR merely changes the code to use a try-with-resources block on the `Deflater` instance.

No new tests have been introduced given the nature of the change. I've added a `noreg-hard` to the issue. Existing tier1, tier2 and tier3 tests continue to pass with this change without any related failures.

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

Commit messages:
 - 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not close the Deflater in exceptional cases

Changes: https://git.openjdk.org/jdk/pull/23588/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23588&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349907
  Stats: 24 lines in 1 file changed: 4 ins; 6 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/23588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23588/head:pull/23588

PR: https://git.openjdk.org/jdk/pull/23588

From vklang at openjdk.org  Wed Feb 12 14:19:18 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 12 Feb 2025 14:19:18 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message
In-Reply-To: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
Message-ID: <cElxtWF1_O0xCn0JPJnScwY0yLSNoPkJYI5X40yTGZo=.82e63e17-7688-4446-8084-7489d3101be8@github.com>

On Sat, 11 Jan 2025 07:10:53 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

> Motivation:
> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
> 
> Modification:
> Add detail error messages.
> 
> Result:
> Helpful messages.

src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java line 1264:

> 1262:             throw new IllegalArgumentException("maximumPoolSize must be positive, but got " + maximumPoolSize);
> 1263:         } else if (maximumPoolSize < corePoolSize) {
> 1264:             throw new IllegalArgumentException("maximumPoolSize must >= corePoolSize , " + "but got maximumPoolSize:" + maximumPoolSize + " corePoolSize :" + corePoolSize);

Too many different formulations of messages for me ("can't" vs "must be" vs "must >=")

I'd recommend using "must be" as in "must be non-negative", "must be positive", "must be greater-or-equal to"

test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java line 309:

> 307:                 shouldThrow();
> 308:             } catch (NullPointerException success) {
> 309:                 Assert.assertNotNull(success.getMessage());

Should assert the expected message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r1952735674
PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r1952737822

From psandoz at openjdk.org  Wed Feb 12 14:49:27 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 12 Feb 2025 14:49:27 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v18]
In-Reply-To: <GTm_Er6CT-A4aFdVeWEMCXyJKWWrW56VLe9On4W02fk=.6bb331e3-3a26-4f5e-befb-42e955e4d994@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <GTm_Er6CT-A4aFdVeWEMCXyJKWWrW56VLe9On4W02fk=.6bb331e3-3a26-4f5e-befb-42e955e4d994@github.com>
Message-ID: <lmzYNgi6uBiqH8YxnqZb-lcmFB6ZRHscR8s4M4u-ZEk=.4eb0803e-b74a-4109-91da-c49ea84fb4a2@github.com>

On Tue, 11 Feb 2025 06:32:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions

Looks good. I merged this PR with master, successfully (at the time) with no conflicts, and ran it through tier 1 to 3 testing and there were no failures.

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

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2612181239

From duke at openjdk.org  Wed Feb 12 15:25:52 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Feb 2025 15:25:52 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
Message-ID: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>

8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.

1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
2. Add explanatory comments to various affected methods.
3. Add a test to ensure deadlocks no longer occur.

Note that this change does not address issue in MemoryHandler (see JDK-8349208).

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

Commit messages:
 - Tweaking the comment in Handler.
 - Reverted comments in Formatter and re-worked the comment in Handler to be more direct.
 - Merge remote-tracking branch 'origin/JDK-8349206-1' into JDK-8349206-1
 - Making sure handlers are closed in tests and adding FileHandler test.
 - Making sure handlers are closed in tests and adding FileHandler test.
 - Re-adjust the comment about parent locking.
 - Adjust copyright back to just start + current years.
 - 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.

Changes: https://git.openjdk.org/jdk/pull/23491/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349206
  Stats: 238 lines in 5 files changed: 222 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/23491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491

PR: https://git.openjdk.org/jdk/pull/23491

From liach at openjdk.org  Wed Feb 12 15:25:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Feb 2025 15:25:52 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <Y97qAwzz2q1Y8ZWv-wJr420qaxwWFe-Hb6F6ykF21fk=.1b12da79-3a93-4e25-a1d7-f0cb1d2b07c6@github.com>

On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont <duke at openjdk.org> wrote:

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

src/java.logging/share/classes/java/util/logging/FileHandler.java line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2024, 2025, Oracle and/or its affiliates.

We usually just include the initial creation and the latest update years, so `2020, 2025,` is sufficient and `2024,` can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1945043551

From duke at openjdk.org  Wed Feb 12 15:25:52 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Feb 2025 15:25:52 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <Y97qAwzz2q1Y8ZWv-wJr420qaxwWFe-Hb6F6ykF21fk=.1b12da79-3a93-4e25-a1d7-f0cb1d2b07c6@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Y97qAwzz2q1Y8ZWv-wJr420qaxwWFe-Hb6F6ykF21fk=.1b12da79-3a93-4e25-a1d7-f0cb1d2b07c6@github.com>
Message-ID: <vgxVr8HkC1dWkTmuykmt765DPlqNa7pCuj5Ay3luH7k=.566017b6-11a8-4419-97f9-cb675e9e23b6@github.com>

On Thu, 6 Feb 2025 16:27:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> src/java.logging/share/classes/java/util/logging/FileHandler.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2000, 2024, 2025, Oracle and/or its affiliates.
> 
> We usually just include the initial creation and the latest update years, so `2020, 2025,` is sufficient and `2024,` can be removed.

Thank you, I'll sort this out in the next push.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1945150364

From duke at openjdk.org  Wed Feb 12 15:27:13 2025
From: duke at openjdk.org (duke)
Date: Wed, 12 Feb 2025 15:27:13 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v6]
In-Reply-To: <SSCxiJUNRkdEHOIJ2mbrBJ6Re8GzFwGBEtI4gqibvNA=.e9ba99b3-6c50-4a86-9de9-795f8045c9b3@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <SSCxiJUNRkdEHOIJ2mbrBJ6Re8GzFwGBEtI4gqibvNA=.e9ba99b3-6c50-4a86-9de9-795f8045c9b3@github.com>
Message-ID: <ZeuqDI3hd7hnUy3nK0Pt7JLVnbscjbyNpoG6mEhOOpo=.66a8950a-04e0-456b-b403-c654a50f278c@github.com>

On Tue, 11 Feb 2025 21:47:31 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>> 
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
>> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
>> 
>> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
>> 
>> 
>> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
>> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
>> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
>> 
>> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
>> 
>> ---
>> 
>> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments from Sandhya

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

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

PR Comment: https://git.openjdk.org/jdk/pull/22673#issuecomment-2654048613

From jpai at openjdk.org  Wed Feb 12 15:45:25 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Feb 2025 15:45:25 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases [v2]
In-Reply-To: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
Message-ID: <nKIj4qRUxHLipi-JZhWy0aXLH3MK8ltKK3nDEeKcyhs=.c9f7475b-8d64-488e-afe3-e769e2474d7d@github.com>

> Can I please get a review of this change in `jdk.tools.jlink.internal.plugins.ZipPlugin` which proposes to close the `Deflater` instance cleanly? This addresses https://bugs.openjdk.org/browse/JDK-8349907.
> 
> As noted in that issue, the `Deflater` instance wasn't being closed in the exception code path of this method. The commit in this PR merely changes the code to use a try-with-resources block on the `Deflater` instance.
> 
> No new tests have been introduced given the nature of the change. I've added a `noreg-hard` to the issue. Existing tier1, tier2 and tier3 tests continue to pass with this change without any related failures.

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

  Lance's suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23588/files
  - new: https://git.openjdk.org/jdk/pull/23588/files/411f0375..3437f9ba

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

  Stats: 13 lines in 1 file changed: 4 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23588/head:pull/23588

PR: https://git.openjdk.org/jdk/pull/23588

From jpai at openjdk.org  Wed Feb 12 15:45:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Feb 2025 15:45:26 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases
In-Reply-To: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
Message-ID: <dKQVWcIBs1cDtH-AVCFTNvKH5AtqxyxyuK8jxkIXajU=.6baada52-60e8-40b8-9ed1-5e6da1bb05b4@github.com>

On Wed, 12 Feb 2025 14:09:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change in `jdk.tools.jlink.internal.plugins.ZipPlugin` which proposes to close the `Deflater` instance cleanly? This addresses https://bugs.openjdk.org/browse/JDK-8349907.
> 
> As noted in that issue, the `Deflater` instance wasn't being closed in the exception code path of this method. The commit in this PR merely changes the code to use a try-with-resources block on the `Deflater` instance.
> 
> No new tests have been introduced given the nature of the change. I've added a `noreg-hard` to the issue. Existing tier1, tier2 and tier3 tests continue to pass with this change without any related failures.

Lance suggested including the `ByteArrayOutputStream` in the try-with-resources too to make the code more concise and cleaner. I have now updated the PR to follow that suggestion.

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

PR Comment: https://git.openjdk.org/jdk/pull/23588#issuecomment-2654099202

From liach at openjdk.org  Wed Feb 12 15:45:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Feb 2025 15:45:26 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases [v2]
In-Reply-To: <nKIj4qRUxHLipi-JZhWy0aXLH3MK8ltKK3nDEeKcyhs=.c9f7475b-8d64-488e-afe3-e769e2474d7d@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
 <nKIj4qRUxHLipi-JZhWy0aXLH3MK8ltKK3nDEeKcyhs=.c9f7475b-8d64-488e-afe3-e769e2474d7d@github.com>
Message-ID: <jxXzqZwzizEGWej0zeNrhLEdRmKortNBdhGEil87BgE=.11654c96-a71b-4d99-a6c7-1f64e06f7a12@github.com>

On Wed, 12 Feb 2025 15:42:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change in `jdk.tools.jlink.internal.plugins.ZipPlugin` which proposes to close the `Deflater` instance cleanly? This addresses https://bugs.openjdk.org/browse/JDK-8349907.
>> 
>> As noted in that issue, the `Deflater` instance wasn't being closed in the exception code path of this method. The commit in this PR merely changes the code to use a try-with-resources block on the `Deflater` instance.
>> 
>> No new tests have been introduced given the nature of the change. I've added a `noreg-hard` to the issue. Existing tier1, tier2 and tier3 tests continue to pass with this change without any related failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's suggestion

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ZipPlugin.java line 99:

> 97:                 stream.close();
> 98:             } catch (IOException ex) {
> 99:                 return bytesIn; // return the original uncompressed input

This really won't happen. The close for byte array in/out streams are no-op and can be omitted. I believe putting an assertion here is better too.

And by practice, calling methods on an in/out stream after close doesn't make much sense too. Here we are calling `toByteArray` after close, which looks weird.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23588#discussion_r1952903341

From jpai at openjdk.org  Wed Feb 12 15:45:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Feb 2025 15:45:27 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases [v2]
In-Reply-To: <jxXzqZwzizEGWej0zeNrhLEdRmKortNBdhGEil87BgE=.11654c96-a71b-4d99-a6c7-1f64e06f7a12@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
 <nKIj4qRUxHLipi-JZhWy0aXLH3MK8ltKK3nDEeKcyhs=.c9f7475b-8d64-488e-afe3-e769e2474d7d@github.com>
 <jxXzqZwzizEGWej0zeNrhLEdRmKortNBdhGEil87BgE=.11654c96-a71b-4d99-a6c7-1f64e06f7a12@github.com>
Message-ID: <cvlDbbRyjxtqD6iDEJwxxIO9GlS14xL8glhEfcWCSaM=.8df24cea-2bc7-4c16-8ac2-2681e068604a@github.com>

On Wed, 12 Feb 2025 15:39:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lance's suggestion
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ZipPlugin.java line 99:
> 
>> 97:                 stream.close();
>> 98:             } catch (IOException ex) {
>> 99:                 return bytesIn; // return the original uncompressed input
> 
> This really won't happen. The close for byte array in/out streams are no-op and can be omitted. I believe putting an assertion here is better too.
> 
> And by practice, calling methods on an in/out stream after close doesn't make much sense too. Here we are calling `toByteArray` after close, which looks weird.

Hello Chen, after Lance suggested a similar change, I've updated the PR and with that update this `stream.close()` is no longer explicitly done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23588#discussion_r1952909253

From vpaprotski at openjdk.org  Wed Feb 12 15:47:04 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 12 Feb 2025 15:47:04 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v7]
In-Reply-To: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
Message-ID: <SzSdKPYyETDTThD9eLpsrfIlgfWAbYFtx-m4HQWnkjU=.68c75ed4-1560-4af1-aaf5-9304b97780a3@github.com>

> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
> 
> This PR fixes two issues:
> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
> 
> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
> 
> 
> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
> 
> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
> 
> ---
> 
> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)

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

  Update src/hotspot/cpu/x86/macroAssembler_x86.cpp
  
  Co-authored-by: Julian Waters <32636402+TheShermanTanker at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22673/files
  - new: https://git.openjdk.org/jdk/pull/22673/files/b23764ab..cbd3812d

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

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

PR: https://git.openjdk.org/jdk/pull/22673

From jwaters at openjdk.org  Wed Feb 12 15:47:06 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 12 Feb 2025 15:47:06 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v6]
In-Reply-To: <SSCxiJUNRkdEHOIJ2mbrBJ6Re8GzFwGBEtI4gqibvNA=.e9ba99b3-6c50-4a86-9de9-795f8045c9b3@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <SSCxiJUNRkdEHOIJ2mbrBJ6Re8GzFwGBEtI4gqibvNA=.e9ba99b3-6c50-4a86-9de9-795f8045c9b3@github.com>
Message-ID: <OtUhGytjpvSqGh7gb5HylPBFNClPu54PpMO-dCJkCr4=.35172246-969c-4d6f-9d9c-30aa7ca56c6f@github.com>

On Tue, 11 Feb 2025 21:47:31 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>> 
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
>> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
>> 
>> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
>> 
>> 
>> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
>> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
>> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
>> 
>> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
>> 
>> ---
>> 
>> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments from Sandhya

Looks good otherwise

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 783:

> 781: 
> 782: #ifdef _WIN64
> 783:   // Windows always allocates space for it's register args

Suggestion:

  // Windows always allocates space for its register args

src/hotspot/os/windows/os_windows.cpp line 2757:

> 2755: 
> 2756: #if defined(_M_AMD64)
> 2757:     extern bool handle_FLT_exception(struct _EXCEPTION_POINTERS* exceptionInfo);

This seems strange to declare inside another method like this, not a showstopper but it might be better to declare it where handle_FLT_exception used to be defined in this file

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22673#pullrequestreview-2612367075
PR Review Comment: https://git.openjdk.org/jdk/pull/22673#discussion_r1952906388
PR Review Comment: https://git.openjdk.org/jdk/pull/22673#discussion_r1952902264

From vpaprotski at openjdk.org  Wed Feb 12 15:47:07 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 12 Feb 2025 15:47:07 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v6]
In-Reply-To: <OtUhGytjpvSqGh7gb5HylPBFNClPu54PpMO-dCJkCr4=.35172246-969c-4d6f-9d9c-30aa7ca56c6f@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <SSCxiJUNRkdEHOIJ2mbrBJ6Re8GzFwGBEtI4gqibvNA=.e9ba99b3-6c50-4a86-9de9-795f8045c9b3@github.com>
 <OtUhGytjpvSqGh7gb5HylPBFNClPu54PpMO-dCJkCr4=.35172246-969c-4d6f-9d9c-30aa7ca56c6f@github.com>
Message-ID: <CEZcxPkXJb2lMEH4wBpKbAfcBa5caI4kd4WLH-C82XA=.49067940-8afb-4f93-ad4d-7997e8170174@github.com>

On Wed, 12 Feb 2025 15:38:34 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from Sandhya
>
> src/hotspot/os/windows/os_windows.cpp line 2757:
> 
>> 2755: 
>> 2756: #if defined(_M_AMD64)
>> 2757:     extern bool handle_FLT_exception(struct _EXCEPTION_POINTERS* exceptionInfo);
> 
> This seems strange to declare inside another method like this, not a showstopper but it might be better to declare it where handle_FLT_exception used to be defined in this file

Oh.. I remember wondering where to put this. Meant to come back and find the right header

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22673#discussion_r1952907016

From lancea at openjdk.org  Wed Feb 12 15:50:18 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 12 Feb 2025 15:50:18 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases [v2]
In-Reply-To: <nKIj4qRUxHLipi-JZhWy0aXLH3MK8ltKK3nDEeKcyhs=.c9f7475b-8d64-488e-afe3-e769e2474d7d@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
 <nKIj4qRUxHLipi-JZhWy0aXLH3MK8ltKK3nDEeKcyhs=.c9f7475b-8d64-488e-afe3-e769e2474d7d@github.com>
Message-ID: <uQwFP_sO4U4DaMr3nnZxSmdAutaJmswEHiw_f3o_Lc4=.58be8d90-3bc6-49f8-81d7-ef7a3e3708f3@github.com>

On Wed, 12 Feb 2025 15:45:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change in `jdk.tools.jlink.internal.plugins.ZipPlugin` which proposes to close the `Deflater` instance cleanly? This addresses https://bugs.openjdk.org/browse/JDK-8349907.
>> 
>> As noted in that issue, the `Deflater` instance wasn't being closed in the exception code path of this method. The commit in this PR merely changes the code to use a try-with-resources block on the `Deflater` instance.
>> 
>> No new tests have been introduced given the nature of the change. I've added a `noreg-hard` to the issue. Existing tier1, tier2 and tier3 tests continue to pass with this change without any related failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's suggestion

Looks good overall Jai.

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23588#pullrequestreview-2612393750

From liach at openjdk.org  Wed Feb 12 15:50:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Feb 2025 15:50:19 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases [v2]
In-Reply-To: <nKIj4qRUxHLipi-JZhWy0aXLH3MK8ltKK3nDEeKcyhs=.c9f7475b-8d64-488e-afe3-e769e2474d7d@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
 <nKIj4qRUxHLipi-JZhWy0aXLH3MK8ltKK3nDEeKcyhs=.c9f7475b-8d64-488e-afe3-e769e2474d7d@github.com>
Message-ID: <_9SdRZAdjKqB5Ur7DbEuNCPay_spLSdgFaZf81Rf6to=.9fc78cb3-1640-4af7-9ad9-2a6737d2a98f@github.com>

On Wed, 12 Feb 2025 15:45:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change in `jdk.tools.jlink.internal.plugins.ZipPlugin` which proposes to close the `Deflater` instance cleanly? This addresses https://bugs.openjdk.org/browse/JDK-8349907.
>> 
>> As noted in that issue, the `Deflater` instance wasn't being closed in the exception code path of this method. The commit in this PR merely changes the code to use a try-with-resources block on the `Deflater` instance.
>> 
>> No new tests have been introduced given the nature of the change. I've added a `noreg-hard` to the issue. Existing tier1, tier2 and tier3 tests continue to pass with this change without any related failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's suggestion

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ZipPlugin.java line 99:

> 97:             return stream.toByteArray(); // the compressed output
> 98:         } catch (IOException e) {
> 99:             return bytesIn; // return the original uncompressed input

Can we add an `assert false : e;` assertion because this really shouldn't happen?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23588#discussion_r1952914841

From asemenyuk at openjdk.org  Wed Feb 12 15:51:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 12 Feb 2025 15:51:15 GMT
Subject: RFR: 8349564: Clean warnings found in jpackage tests when building
 them with -Xlint:all [v3]
In-Reply-To: <9_lTyilsx5gtMm8kzamnVlpF1DvRTB-VmvVGTp-pwk4=.8a11e80b-fa5f-4bf7-bbb9-8ad1a4815aff@github.com>
References: <oFpKSze5bbMk9sUB55IQib3sPGVyq4Fyp4EbsH3_B_k=.ce30c7e6-3b6c-4e70-bf8b-d7ff6f654375@github.com>
 <9_lTyilsx5gtMm8kzamnVlpF1DvRTB-VmvVGTp-pwk4=.8a11e80b-fa5f-4bf7-bbb9-8ad1a4815aff@github.com>
Message-ID: <IvAP_dKbId6JOZt2254y95L85ZECBwcPgPEaohekgwY=.7f3718b0-7f94-4f86-8f3d-7f5833d4a544@github.com>

On Thu, 6 Feb 2025 23:12:48 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Clean warnings found in jpackage tests when building them with `-Xlint:all` option in Eclipse IDE. 
>> 
>> They are:
>>  - redundant imports (solution: remove)
>>  - unused function/fields (solution: remove)
>>  - missing SuppressWarnings-s (solution: add what is missing)
>>  - redundant SuppressWarnings-s (solution: remove)
>>  - raw types used (solution: use wildcard or more specific types if appropriate)
>>  - generic varargs (solution: convert to single/double/list arguments)
>>  - an incomplete list of enum elements in switch statements (solution: add `default` branch)
>> 
>> To prevent regression, added `-Xlint:all -Werror` to the compiler command line of all jpackage tests
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fixed

Current limitations of jtreg don't allow us to avoid repeating `-Xlint:all -Werror` in every test, and there is no way to specify javac options for library code. It can be revisited when jtreg gets corresponding features. @sashamatveev please finalize the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23455#issuecomment-2654117677

From pminborg at openjdk.org  Wed Feb 12 16:04:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 12 Feb 2025 16:04:53 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v7]
In-Reply-To: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
References: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
Message-ID: <A9LTkDkme2lj0ZODXASxinjtVm1x6BjXcS7x8mDMKIc=.2e0acb22-ce3a-4814-b6e5-d5485bee06a8@github.com>

> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes to add a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively:
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.193 ? 0.268  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.268 ? 0.080  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  42.076 ? 1.003  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.801 ? 0.138  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.265 ? 0.087  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.285 ? 0.155  ns/op
> 
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.033 ? 0.423  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   3.676 ? 0.104  ns/op  // <- Happy path using an internal pool
> 
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.023 ? 0.736  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  22.013 ? 0.648  ns/op  // <- Allocating memory upon each invocation
> 
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  22.050 ? 0.233  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   3.756 ? 0.056  ns/op  // <- Using the pool explicitly from Java code
> 
> 
> Adapted system call:
> 
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> 
> 
> Explicit allocation:
> 
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> 
> 
> Thread Local allocation:
> 
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> 
> 
> The adapted system call exhibits a ~6x performanc...

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

  Add holding a reference to the original arena in the taken arena

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23517/files
  - new: https://git.openjdk.org/jdk/pull/23517/files/8b9b5087..a3af69e5

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

  Stats: 41 lines in 1 file changed: 20 ins; 13 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/23517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23517/head:pull/23517

PR: https://git.openjdk.org/jdk/pull/23517

From kvn at openjdk.org  Wed Feb 12 16:07:13 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 16:07:13 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v7]
In-Reply-To: <SzSdKPYyETDTThD9eLpsrfIlgfWAbYFtx-m4HQWnkjU=.68c75ed4-1560-4af1-aaf5-9304b97780a3@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <SzSdKPYyETDTThD9eLpsrfIlgfWAbYFtx-m4HQWnkjU=.68c75ed4-1560-4af1-aaf5-9304b97780a3@github.com>
Message-ID: <uMkOsmceGNbdLki5WVyp0zzPFcwMw_nReRsCfEXPQT8=.3d7bede6-23a1-4168-b890-46162288e130@github.com>

On Wed, 12 Feb 2025 15:47:04 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>> 
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
>> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
>> 
>> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
>> 
>> 
>> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
>> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
>> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
>> 
>> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
>> 
>> ---
>> 
>> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/cpu/x86/macroAssembler_x86.cpp
>   
>   Co-authored-by: Julian Waters <32636402+TheShermanTanker at users.noreply.github.com>

I submitted our internal testing. Please wait results.

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

PR Review: https://git.openjdk.org/jdk/pull/22673#pullrequestreview-2612451477

From vpaprotski at openjdk.org  Wed Feb 12 16:26:18 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 12 Feb 2025 16:26:18 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v6]
In-Reply-To: <SSCxiJUNRkdEHOIJ2mbrBJ6Re8GzFwGBEtI4gqibvNA=.e9ba99b3-6c50-4a86-9de9-795f8045c9b3@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <SSCxiJUNRkdEHOIJ2mbrBJ6Re8GzFwGBEtI4gqibvNA=.e9ba99b3-6c50-4a86-9de9-795f8045c9b3@github.com>
Message-ID: <aio-x4oiwL1bRurdNKiqMfAUGgX2A7Irs-y6a2TyQYk=.6caec12b-68ba-4fbf-a9a6-70b55c669750@github.com>

On Tue, 11 Feb 2025 21:47:31 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>> 
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
>> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
>> 
>> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
>> 
>> 
>> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
>> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
>> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
>> 
>> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
>> 
>> ---
>> 
>> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments from Sandhya

(deleted integrate command)

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

PR Comment: https://git.openjdk.org/jdk/pull/22673#issuecomment-2654045391

From vpaprotski at openjdk.org  Wed Feb 12 16:26:19 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 12 Feb 2025 16:26:19 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v7]
In-Reply-To: <uMkOsmceGNbdLki5WVyp0zzPFcwMw_nReRsCfEXPQT8=.3d7bede6-23a1-4168-b890-46162288e130@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <SzSdKPYyETDTThD9eLpsrfIlgfWAbYFtx-m4HQWnkjU=.68c75ed4-1560-4af1-aaf5-9304b97780a3@github.com>
 <uMkOsmceGNbdLki5WVyp0zzPFcwMw_nReRsCfEXPQT8=.3d7bede6-23a1-4168-b890-46162288e130@github.com>
Message-ID: <4xs7dpEQUvQu7Qpp84scCQXABz2FvtYCn9HpDzwNxcM=.af7bfa29-bcb5-4f36-9811-e5952f80b9f7@github.com>

On Wed, 12 Feb 2025 16:05:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I submitted our internal testing. Please wait results.

Thanks! Deleted the integrate command

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

PR Comment: https://git.openjdk.org/jdk/pull/22673#issuecomment-2654227936

From jwaters at openjdk.org  Wed Feb 12 16:35:18 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 12 Feb 2025 16:35:18 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v7]
In-Reply-To: <SzSdKPYyETDTThD9eLpsrfIlgfWAbYFtx-m4HQWnkjU=.68c75ed4-1560-4af1-aaf5-9304b97780a3@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <SzSdKPYyETDTThD9eLpsrfIlgfWAbYFtx-m4HQWnkjU=.68c75ed4-1560-4af1-aaf5-9304b97780a3@github.com>
Message-ID: <jZkq-aNer2zsws4PSVQAta3at6S0uFtq9_nRwMQ7vRc=.892d04ac-ffee-48b2-81cc-e6fd95e80ec3@github.com>

On Wed, 12 Feb 2025 15:47:04 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>> 
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
>> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
>> 
>> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
>> 
>> 
>> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
>> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
>> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
>> 
>> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
>> 
>> ---
>> 
>> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/cpu/x86/macroAssembler_x86.cpp
>   
>   Co-authored-by: Julian Waters <32636402+TheShermanTanker at users.noreply.github.com>

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22673#pullrequestreview-2612551969

From jpai at openjdk.org  Wed Feb 12 16:47:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Feb 2025 16:47:29 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases [v3]
In-Reply-To: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
Message-ID: <OEJXF6PdcqjKSzaZm0f3o8KkDdWBrSAv779QY3xk2hc=.b9fba9d3-e67e-4c5e-9b03-a1b60d1eb00a@github.com>

> Can I please get a review of this change in `jdk.tools.jlink.internal.plugins.ZipPlugin` which proposes to close the `Deflater` instance cleanly? This addresses https://bugs.openjdk.org/browse/JDK-8349907.
> 
> As noted in that issue, the `Deflater` instance wasn't being closed in the exception code path of this method. The commit in this PR merely changes the code to use a try-with-resources block on the `Deflater` instance.
> 
> No new tests have been introduced given the nature of the change. I've added a `noreg-hard` to the issue. Existing tier1, tier2 and tier3 tests continue to pass with this change without any related failures.

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

  Chen's suggestion - include an assert in catch block to make clear that the IOException isn't expected

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23588/files
  - new: https://git.openjdk.org/jdk/pull/23588/files/3437f9ba..8a7345d1

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

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

PR: https://git.openjdk.org/jdk/pull/23588

From jpai at openjdk.org  Wed Feb 12 16:47:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Feb 2025 16:47:29 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases [v2]
In-Reply-To: <_9SdRZAdjKqB5Ur7DbEuNCPay_spLSdgFaZf81Rf6to=.9fc78cb3-1640-4af7-9ad9-2a6737d2a98f@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
 <nKIj4qRUxHLipi-JZhWy0aXLH3MK8ltKK3nDEeKcyhs=.c9f7475b-8d64-488e-afe3-e769e2474d7d@github.com>
 <_9SdRZAdjKqB5Ur7DbEuNCPay_spLSdgFaZf81Rf6to=.9fc78cb3-1640-4af7-9ad9-2a6737d2a98f@github.com>
Message-ID: <wckN7fp4vhtYHenTHA4l_qWi4xca3HIMVLdPbdpmk1E=.711c7788-ce05-43f2-8989-ad2c28d11da9@github.com>

On Wed, 12 Feb 2025 15:45:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lance's suggestion
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ZipPlugin.java line 99:
> 
>> 97:             return stream.toByteArray(); // the compressed output
>> 98:         } catch (IOException e) {
>> 99:             return bytesIn; // return the original uncompressed input
> 
> Can we add an `assert false : e;` assertion because this really shouldn't happen?

I have updated the PR to add that assert and added a brief comment why we have it there. tier testing with this updated change is currently in progress.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23588#discussion_r1953039423

From jbhateja at openjdk.org  Wed Feb 12 17:08:25 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 12 Feb 2025 17:08:25 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v18]
In-Reply-To: <lmzYNgi6uBiqH8YxnqZb-lcmFB6ZRHscR8s4M4u-ZEk=.4eb0803e-b74a-4109-91da-c49ea84fb4a2@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <GTm_Er6CT-A4aFdVeWEMCXyJKWWrW56VLe9On4W02fk=.6bb331e3-3a26-4f5e-befb-42e955e4d994@github.com>
 <lmzYNgi6uBiqH8YxnqZb-lcmFB6ZRHscR8s4M4u-ZEk=.4eb0803e-b74a-4109-91da-c49ea84fb4a2@github.com>
Message-ID: <mi6t6CGWnnvZyEDJ1me11TvMj_50EnUWoINpmJKNiOQ=.6281007b-6f01-484c-b9e6-5d23f0f1a158@github.com>

On Wed, 12 Feb 2025 14:46:49 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions
>
> Looks good. I merged this PR with master, successfully (at the time) with no conflicts, and ran it through tier 1 to 3 testing and there were no failures.

Thanks @PaulSandoz , @eme64 and @sviswa7 for your  valuable feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2654337191

From jbhateja at openjdk.org  Wed Feb 12 17:08:28 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 12 Feb 2025 17:08:28 GMT
Subject: Integrated: 8342103: C2 compiler support for Float16 type and
 associated scalar operations
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <0jFE4E2Aewb7aCN5nZrmV3Lz3SSsNSmhhUEiL9JQjMA=.c202afcf-340c-4fca-8a2a-778c7677fe1f@github.com>

On Sun, 15 Dec 2024 18:05:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: 4b463ee7
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b463ee70eceb94fdfbffa5c49dd58dcc6a6c890
Stats:     2855 lines in 56 files changed: 2788 ins; 0 del; 67 mod

8342103: C2 compiler support for Float16 type and associated scalar operations

Co-authored-by: Paul Sandoz <psandoz at openjdk.org>
Co-authored-by: Bhavana Kilambi <bkilambi at openjdk.org>
Co-authored-by: Joe Darcy <darcy at openjdk.org>
Co-authored-by: Raffaello Giulietti <rgiulietti at openjdk.org>
Reviewed-by: psandoz, epeter, sviswanathan

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

PR: https://git.openjdk.org/jdk/pull/22754

From liach at openjdk.org  Wed Feb 12 17:28:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Feb 2025 17:28:14 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases [v3]
In-Reply-To: <OEJXF6PdcqjKSzaZm0f3o8KkDdWBrSAv779QY3xk2hc=.b9fba9d3-e67e-4c5e-9b03-a1b60d1eb00a@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
 <OEJXF6PdcqjKSzaZm0f3o8KkDdWBrSAv779QY3xk2hc=.b9fba9d3-e67e-4c5e-9b03-a1b60d1eb00a@github.com>
Message-ID: <KmDLbRWOC7vTZ24GVTeHwtttFXnQZlRNb113gFxBhAs=.2781de95-5a4d-4272-a8e0-287fbff98bc4@github.com>

On Wed, 12 Feb 2025 16:47:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change in `jdk.tools.jlink.internal.plugins.ZipPlugin` which proposes to close the `Deflater` instance cleanly? This addresses https://bugs.openjdk.org/browse/JDK-8349907.
>> 
>> As noted in that issue, the `Deflater` instance wasn't being closed in the exception code path of this method. The commit in this PR merely changes the code to use a try-with-resources block on the `Deflater` instance.
>> 
>> No new tests have been introduced given the nature of the change. I've added a `noreg-hard` to the issue. Existing tier1, tier2 and tier3 tests continue to pass with this change without any related failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's suggestion - include an assert in catch block to make clear that the IOException isn't expected

Thanks for the detailed comments.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23588#pullrequestreview-2612698244

From alanb at openjdk.org  Wed Feb 12 17:40:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Feb 2025 17:40:09 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases [v3]
In-Reply-To: <OEJXF6PdcqjKSzaZm0f3o8KkDdWBrSAv779QY3xk2hc=.b9fba9d3-e67e-4c5e-9b03-a1b60d1eb00a@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
 <OEJXF6PdcqjKSzaZm0f3o8KkDdWBrSAv779QY3xk2hc=.b9fba9d3-e67e-4c5e-9b03-a1b60d1eb00a@github.com>
Message-ID: <Un-NnRpS8Td3u4cHGGdoZwhkjOVlAfBbKHgvRyoCNQY=.65e50b0b-b366-4bce-b6b3-3e8a46c47dde@github.com>

On Wed, 12 Feb 2025 16:47:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change in `jdk.tools.jlink.internal.plugins.ZipPlugin` which proposes to close the `Deflater` instance cleanly? This addresses https://bugs.openjdk.org/browse/JDK-8349907.
>> 
>> As noted in that issue, the `Deflater` instance wasn't being closed in the exception code path of this method. The commit in this PR merely changes the code to use a try-with-resources block on the `Deflater` instance.
>> 
>> No new tests have been introduced given the nature of the change. I've added a `noreg-hard` to the issue. Existing tier1, tier2 and tier3 tests continue to pass with this change without any related failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's suggestion - include an assert in catch block to make clear that the IOException isn't expected

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23588#pullrequestreview-2612735434

From dfuchs at openjdk.org  Wed Feb 12 18:31:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Feb 2025 18:31:13 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <NLF7_Yjj-FhQ6yrd6qEdeTKBTl5hV68lwFSY7G5ShIg=.40640b4f-e5b8-4b5c-9d33-230db3614e45@github.com>

On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont <duke at openjdk.org> wrote:

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

The code changes look reasonable. WRT to detecting deadlocks a possibility is also to use `ManagementFactory.getThreadMXBean().findDeadlockedThreads();`

See for instance https://github.com/openjdk/jdk/blob/336d0d8592aed734e7b8139e1ecd71d33825c75a/test/jdk/java/util/logging/TestLogConfigurationDeadLock.java#L167

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

PR Review: https://git.openjdk.org/jdk/pull/23491#pullrequestreview-2612856987

From dfuchs at openjdk.org  Wed Feb 12 18:44:11 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Feb 2025 18:44:11 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <xqK2jkHwTDcXM-2BgD5xXwRgC3OslaGoPrkATKlmtiI=.edc8df74-6d5f-445f-bd2b-0680e9522441@github.com>

On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont <duke at openjdk.org> wrote:

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

test/jdk/java/util/logging/LoggingDeadlock5.java line 115:

> 113: 
> 114:     private static class DeadLocker {
> 115:         private final static Duration JOIN_WAIT = Duration.ofMillis(500);

You might want to use `jdk.test.lib.Utils.adjustTimeout()` here to account for the case when the test is run on slower configurations. Typically in higher tiers, this test might be run with -Xcomp or -Xint and on debug builds which might cause slow downs and cause the join() method to exit too early - reporting false positives.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1953217354

From dfuchs at openjdk.org  Wed Feb 12 18:47:11 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Feb 2025 18:47:11 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <QRm0548Nh3dmhBIi7XLWEgsRXJUQhIQGYPVfB2YnCIs=.cc9009ef-a435-4144-a2cc-86cbe9de096c@github.com>

On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont <duke at openjdk.org> wrote:

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

test/jdk/java/util/logging/LoggingDeadlock5.java line 31:

> 29:  *          java.logging
> 30:  * @compile -XDignore.symbol.file LoggingDeadlock5.java
> 31:  * @run main/othervm/timeout=10 LoggingDeadlock5

I would not specify any /timeout value here, and rather let jtreg deal with that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1953221796

From jlu at openjdk.org  Wed Feb 12 19:39:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Feb 2025 19:39:33 GMT
Subject: RFR: 8349883: Locale.LanguageRange.parse("-") throws
 ArrayIndexOutOfBoundsException
Message-ID: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>

Please review this PR which prevents a (non-specified) `AIOOBE` from leaking out of the range accepting endpoints in `Locale.LanguageRange`.

In the reported error case, the invalid range is a lone "-" which is `split` into an empty array. Checking if the range ends with "-" first, avoids indexing the empty array.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/23596/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23596&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349883
  Stats: 76 lines in 2 files changed: 71 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23596.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23596/head:pull/23596

PR: https://git.openjdk.org/jdk/pull/23596

From duke at openjdk.org  Wed Feb 12 19:47:14 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Wed, 12 Feb 2025 19:47:14 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>

On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont <duke at openjdk.org> wrote:

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

Changes requested by jmehrens at github.com (no known OpenJDK username).

src/java.logging/share/classes/java/util/logging/FileHandler.java line 755:

> 753:         synchronized(this) {
> 754:             flush();
> 755:             if (limit > 0 && (meter.written >= limit || meter.written < 0)) {

I don't think we want to write to meter.written and the re-aquire the monitor to then read meter.written.  Bytes written no longer corresponds to the formatted size of the current record. It could now include sum other records pending a rotate.

Any thought on creating a package private `StreamHandler::postPublish(LogRecord)` that is called from publish while holding monitor? Then FileHandler could just override that method to invoke flush, check, and rotate.

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

PR Review: https://git.openjdk.org/jdk/pull/23491#pullrequestreview-2613025345
PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1953295195

From dfuchs at openjdk.org  Wed Feb 12 20:14:10 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Feb 2025 20:14:10 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
Message-ID: <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>

On Wed, 12 Feb 2025 19:41:44 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> src/java.logging/share/classes/java/util/logging/FileHandler.java line 755:
> 
>> 753:         synchronized(this) {
>> 754:             flush();
>> 755:             if (limit > 0 && (meter.written >= limit || meter.written < 0)) {
> 
> I don't think we want to write to meter.written and the re-aquire the monitor to then read meter.written.  Bytes written no longer corresponds to the formatted size of the current record. It could now include sum other records pending a rotate.
> 
> Any thought on creating a package private `StreamHandler::postPublish(LogRecord)` that is called from publish while holding monitor? Then FileHandler could just override that method to invoke flush, check, and rotate.

hmmm... Thanks for chiming in Jason. Good point. So what can happen here is that if multiple threads log concurrently to the same FileHandler then log records might continue to get written to the file after the limit has been reached but before the check that would rotate is performed. In pathological cases where new records continue to arrive and manage to enter the monitor before the post-publish action that rotate can do so, this could become problematic.

I think what you are proposing would work, since we control the implementation of super.publish().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1953326840

From naoto at openjdk.org  Wed Feb 12 20:35:19 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Feb 2025 20:35:19 GMT
Subject: RFR: 8349873: StackOverflowError after JDK-8342550 if -Duser.timezone=
 is set to a deprecated zone id
Message-ID: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>

Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/23597/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23597&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349873
  Stats: 21 lines in 2 files changed: 10 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/23597.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23597/head:pull/23597

PR: https://git.openjdk.org/jdk/pull/23597

From almatvee at openjdk.org  Wed Feb 12 21:08:13 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 12 Feb 2025 21:08:13 GMT
Subject: RFR: 8349564: Clean warnings found in jpackage tests when building
 them with -Xlint:all [v3]
In-Reply-To: <9_lTyilsx5gtMm8kzamnVlpF1DvRTB-VmvVGTp-pwk4=.8a11e80b-fa5f-4bf7-bbb9-8ad1a4815aff@github.com>
References: <oFpKSze5bbMk9sUB55IQib3sPGVyq4Fyp4EbsH3_B_k=.ce30c7e6-3b6c-4e70-bf8b-d7ff6f654375@github.com>
 <9_lTyilsx5gtMm8kzamnVlpF1DvRTB-VmvVGTp-pwk4=.8a11e80b-fa5f-4bf7-bbb9-8ad1a4815aff@github.com>
Message-ID: <mxAGwlgewGSuZ78g78Iqj1Bi-pyIi7INBPehD2uBbO0=.064ba43a-0edb-44d5-be68-f72043204832@github.com>

On Thu, 6 Feb 2025 23:12:48 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Clean warnings found in jpackage tests when building them with `-Xlint:all` option in Eclipse IDE. 
>> 
>> They are:
>>  - redundant imports (solution: remove)
>>  - unused function/fields (solution: remove)
>>  - missing SuppressWarnings-s (solution: add what is missing)
>>  - redundant SuppressWarnings-s (solution: remove)
>>  - raw types used (solution: use wildcard or more specific types if appropriate)
>>  - generic varargs (solution: convert to single/double/list arguments)
>>  - an incomplete list of enum elements in switch statements (solution: add `default` branch)
>> 
>> To prevent regression, added `-Xlint:all -Werror` to the compiler command line of all jpackage tests
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fixed

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23455#pullrequestreview-2613203495

From iris at openjdk.org  Wed Feb 12 21:40:23 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 12 Feb 2025 21:40:23 GMT
Subject: RFR: 8349873: StackOverflowError after JDK-8342550 if
 -Duser.timezone= is set to a deprecated zone id
In-Reply-To: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
Message-ID: <qU-GXQ3ClAoY7UZd1c0WMDDmEfkRYF-UJ7jNUWiFDaI=.ed4d7135-7645-4cc1-90b5-3cd272708c16@github.com>

On Wed, 12 Feb 2025 19:35:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23597#pullrequestreview-2613267853

From kvn at openjdk.org  Wed Feb 12 21:43:17 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 21:43:17 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v7]
In-Reply-To: <SzSdKPYyETDTThD9eLpsrfIlgfWAbYFtx-m4HQWnkjU=.68c75ed4-1560-4af1-aaf5-9304b97780a3@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <SzSdKPYyETDTThD9eLpsrfIlgfWAbYFtx-m4HQWnkjU=.68c75ed4-1560-4af1-aaf5-9304b97780a3@github.com>
Message-ID: <0BCMqqyxnY7s24ohUTW90CJmOpQ919wDtBJt92XesWE=.519ad411-777d-4f31-97bb-6bad78253b45@github.com>

On Wed, 12 Feb 2025 15:47:04 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>> 
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
>> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
>> 
>> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
>> 
>> 
>> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
>> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
>> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
>> 
>> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
>> 
>> ---
>> 
>> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/cpu/x86/macroAssembler_x86.cpp
>   
>   Co-authored-by: Julian Waters <32636402+TheShermanTanker at users.noreply.github.com>

My tier1-4, stress, xcomp testing passed.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22673#pullrequestreview-2613271857

From naoto at openjdk.org  Wed Feb 12 21:43:16 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Feb 2025 21:43:16 GMT
Subject: RFR: 8349883: Locale.LanguageRange.parse("-") throws
 ArrayIndexOutOfBoundsException
In-Reply-To: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
References: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
Message-ID: <ViWemy9TBU3wIes2K72-boplIynghN2wnPGAzmPodLQ=.7e311da6-f77c-4b2b-8c31-78e939bb6cfb@github.com>

On Wed, 12 Feb 2025 19:34:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which prevents a (non-specified) `AIOOBE` from leaking out of the range accepting endpoints in `Locale.LanguageRange`.
> 
> In the reported error case, the invalid range is a lone "-" which is `split` into an empty array. Checking if the range ends with "-" first, avoids indexing the empty array.

Looks good

test/jdk/java/util/Locale/IllformedRangeTest.java line 40:

> 38: import static org.junit.jupiter.api.Assertions.assertThrows;
> 39: 
> 40: public class IllformedRangeTest {

Instead of creating a new test file, you might want to add this test into `LanguageRangeTest.java`

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

PR Review: https://git.openjdk.org/jdk/pull/23596#pullrequestreview-2613272653
PR Review Comment: https://git.openjdk.org/jdk/pull/23596#discussion_r1953439911

From vpaprotski at openjdk.org  Wed Feb 12 21:46:15 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 12 Feb 2025 21:46:15 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v7]
In-Reply-To: <SzSdKPYyETDTThD9eLpsrfIlgfWAbYFtx-m4HQWnkjU=.68c75ed4-1560-4af1-aaf5-9304b97780a3@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <SzSdKPYyETDTThD9eLpsrfIlgfWAbYFtx-m4HQWnkjU=.68c75ed4-1560-4af1-aaf5-9304b97780a3@github.com>
Message-ID: <Z8arA2OpvKOzvpc0Gb6VF7EAYnnfPrMPEWEyFx1YAqs=.ce564011-0b3e-4711-96e8-9a4202df6d43@github.com>

On Wed, 12 Feb 2025 15:47:04 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>> 
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
>> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
>> 
>> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
>> 
>> 
>> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
>> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
>> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
>> 
>> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
>> 
>> ---
>> 
>> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/cpu/x86/macroAssembler_x86.cpp
>   
>   Co-authored-by: Julian Waters <32636402+TheShermanTanker at users.noreply.github.com>

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22673#issuecomment-2654908526

From jlu at openjdk.org  Wed Feb 12 22:06:35 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Feb 2025 22:06:35 GMT
Subject: RFR: 8349883: Locale.LanguageRange.parse("-") throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <ViWemy9TBU3wIes2K72-boplIynghN2wnPGAzmPodLQ=.7e311da6-f77c-4b2b-8c31-78e939bb6cfb@github.com>
References: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
 <ViWemy9TBU3wIes2K72-boplIynghN2wnPGAzmPodLQ=.7e311da6-f77c-4b2b-8c31-78e939bb6cfb@github.com>
Message-ID: <RA92so1UWHAPBBL1r7iPTP4jc4D0av6tHQqopzvSKtE=.5a40d2d5-c5a3-4de9-b22c-c5a295145975@github.com>

On Wed, 12 Feb 2025 21:40:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naoto's review - Include test in LanguageRangeTest instead. Additionally, bundle existing LRToString test into LanguageRangeTest as well
>
> test/jdk/java/util/Locale/IllformedRangeTest.java line 40:
> 
>> 38: import static org.junit.jupiter.api.Assertions.assertThrows;
>> 39: 
>> 40: public class IllformedRangeTest {
> 
> Instead of creating a new test file, you might want to add this test into `LanguageRangeTest.java`

Moved `IllformedRangeTest.java` as well as the existing `LRToString.java` test into `LanguageRangeTest.java`, which can now serve as a general class test. Also converted the test to JUnit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23596#discussion_r1953464752

From jlu at openjdk.org  Wed Feb 12 22:06:34 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Feb 2025 22:06:34 GMT
Subject: RFR: 8349883: Locale.LanguageRange.parse("-") throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
References: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
Message-ID: <qPvb4UPZXdLgaEDQ8LQwZR_DjN2A1eNunC5TBHcHOgY=.a7a847b7-5587-45f7-9f51-ef318347aa98@github.com>

> Please review this PR which prevents a (non-specified) `AIOOBE` from leaking out of the range accepting endpoints in `Locale.LanguageRange`.
> 
> In the reported error case, the invalid range is a lone "-" which is `split` into an empty array. Checking if the range ends with "-" first, avoids indexing the empty array.

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

  Naoto's review - Include test in LanguageRangeTest instead. Additionally, bundle existing LRToString test into LanguageRangeTest as well

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23596/files
  - new: https://git.openjdk.org/jdk/pull/23596/files/f1a90f2a..797f69a7

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

  Stats: 204 lines in 3 files changed: 61 ins; 136 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23596.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23596/head:pull/23596

PR: https://git.openjdk.org/jdk/pull/23596

From joehw at openjdk.org  Wed Feb 12 22:18:18 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 12 Feb 2025 22:18:18 GMT
Subject: RFR: 8349873: StackOverflowError after JDK-8342550 if
 -Duser.timezone= is set to a deprecated zone id
In-Reply-To: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
Message-ID: <OZfzzUhemcIefF7DOq17RUhiEs54lylc_0sL62Xe7u4=.3e041519-cead-4e29-928f-2940f3ac2d21@github.com>

On Wed, 12 Feb 2025 19:35:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23597#pullrequestreview-2613339069

From duke at openjdk.org  Wed Feb 12 22:22:19 2025
From: duke at openjdk.org (duke)
Date: Wed, 12 Feb 2025 22:22:19 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v7]
In-Reply-To: <SzSdKPYyETDTThD9eLpsrfIlgfWAbYFtx-m4HQWnkjU=.68c75ed4-1560-4af1-aaf5-9304b97780a3@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <SzSdKPYyETDTThD9eLpsrfIlgfWAbYFtx-m4HQWnkjU=.68c75ed4-1560-4af1-aaf5-9304b97780a3@github.com>
Message-ID: <JiQ3-8LIu7iq5RSUdgAhdqMoaTNmrg1_DMFlAlaKNek=.1959d5f3-35d0-4afa-9ad4-0c869460be1d@github.com>

On Wed, 12 Feb 2025 15:47:04 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>> 
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
>> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
>> 
>> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
>> 
>> 
>> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
>> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
>> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
>> 
>> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
>> 
>> ---
>> 
>> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/cpu/x86/macroAssembler_x86.cpp
>   
>   Co-authored-by: Julian Waters <32636402+TheShermanTanker at users.noreply.github.com>

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

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

PR Comment: https://git.openjdk.org/jdk/pull/22673#issuecomment-2654966743

From jlu at openjdk.org  Wed Feb 12 22:24:10 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Feb 2025 22:24:10 GMT
Subject: RFR: 8349873: StackOverflowError after JDK-8342550 if
 -Duser.timezone= is set to a deprecated zone id
In-Reply-To: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
Message-ID: <LpTXlvpIQbictHsy6gKQCmeFUrMfTN-LP3-znzt8zVM=.3270a59d-8aac-4563-9093-dc8f8783022b@github.com>

On Wed, 12 Feb 2025 19:35:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.

lgtm

test/jdk/java/util/TimeZone/ThreeLetterZoneID.java line 52:

> 50:     @Test
> 51:     public void testExplicitGetTimeZone() throws Exception {
> 52:         ProcessTools.executeTestJava("ThreeLetterZoneID", "dummy").shouldMatch(WARNING);

Could use `stderrShouldMatch` here and below instead of `shouldMatch`

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23597#pullrequestreview-2613347789
PR Review Comment: https://git.openjdk.org/jdk/pull/23597#discussion_r1953484074

From vpaprotski at openjdk.org  Wed Feb 12 22:28:17 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 12 Feb 2025 22:28:17 GMT
Subject: Integrated: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni
In-Reply-To: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
Message-ID: <KiMhAKGK-4K99tLJkx-byWvust1zHwH3bbv6LiuiONI=.c93b9450-f822-4e76-ac34-56765d4cd84a@github.com>

On Tue, 10 Dec 2024 23:45:37 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
> 
> This PR fixes two issues:
> - the original issue is a crash caused by `__ warn` corrupting the stack on Windows only
> - This issue also uncovered that -Xcheck:jni test cases were getting 65k lines of warning on HelloWorld (on both Linux _and_ windows):
> 
> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
> 
> 
> First, the crash. Caused when FXRSTOR is attempting to write reserved bits into MXCSR. If those bits happen to be set, crash. (Hence the crash isn't deterministic. But frequent enough if `__ warn` is used). It is caused by the binding not reserving stack space for register parameters ()
> ![image](https://github.com/user-attachments/assets/4ad63908-088b-4e9d-9e7d-a3509bee046a)
> Prolog of the warn function then proceeds to store the for arg registers onto the stack, overriding the fxstore save area. (See https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#calling-convention-defaults)
> 
> Fix uses `frame::arg_reg_save_area_bytes` to bump the stack pointer.
> 
> ---
> 
> I also kept the fix to `verify_mxcsr` since without it, `-Xcheck:jni` is practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of warnings)

This pull request has now been integrated.

Changeset: 55097dd4
Author:    Volodymyr Paprotski <vpaprotski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/55097dd4cbb5d691c12cb0247d66dce593759d59
Stats:     127 lines in 9 files changed: 66 ins; 54 del; 7 mod

8344802: Crash in StubRoutines::verify_mxcsr with -XX:+EnableX86ECoreOpts and -Xcheck:jni

Reviewed-by: jwaters, kvn, sviswanathan

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

PR: https://git.openjdk.org/jdk/pull/22673

From naoto at openjdk.org  Wed Feb 12 22:55:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Feb 2025 22:55:25 GMT
Subject: RFR: 8349883: Locale.LanguageRange.parse("-") throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <qPvb4UPZXdLgaEDQ8LQwZR_DjN2A1eNunC5TBHcHOgY=.a7a847b7-5587-45f7-9f51-ef318347aa98@github.com>
References: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
 <qPvb4UPZXdLgaEDQ8LQwZR_DjN2A1eNunC5TBHcHOgY=.a7a847b7-5587-45f7-9f51-ef318347aa98@github.com>
Message-ID: <wHJ0SjCsj6eaU5FFd0Itl62znKv5srJauGrXqEmjWeo=.8273deb4-beae-4b52-ab73-1d7ea2c4ddaa@github.com>

On Wed, 12 Feb 2025 22:06:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which prevents a (non-specified) `AIOOBE` from leaking out of the range accepting endpoints in `Locale.LanguageRange`.
>> 
>> In the reported error case, the invalid range is a lone "-" which is `split` into an empty array. Checking if the range ends with "-" first, avoids indexing the empty array.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's review - Include test in LanguageRangeTest instead. Additionally, bundle existing LRToString test into LanguageRangeTest as well

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23596#pullrequestreview-2613404677

From naoto at openjdk.org  Wed Feb 12 23:07:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Feb 2025 23:07:26 GMT
Subject: RFR: 8349873: StackOverflowError after JDK-8342550 if
 -Duser.timezone= is set to a deprecated zone id [v2]
In-Reply-To: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
Message-ID: <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>

> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.

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

  Reflects review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23597/files
  - new: https://git.openjdk.org/jdk/pull/23597/files/197d50fb..d1b990f7

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

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

PR: https://git.openjdk.org/jdk/pull/23597

From jlu at openjdk.org  Wed Feb 12 23:12:09 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Feb 2025 23:12:09 GMT
Subject: RFR: 8349873: StackOverflowError after JDK-8342550 if
 -Duser.timezone= is set to a deprecated zone id [v2]
In-Reply-To: <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
 <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>
Message-ID: <HtgteRuqMEsakhUV5ledPYtxEDhgrOLN3L96HdLYMmI=.c72306b5-a277-4ef3-847b-dcf1b2aa12ac@github.com>

On Wed, 12 Feb 2025 23:07:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/23597#pullrequestreview-2613429565

From smarks at openjdk.org  Thu Feb 13 00:33:10 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 13 Feb 2025 00:33:10 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <L3hady6uuLM2m46z68sW18iMvt7CcuNOxEirq1BvfLo=.7603de81-8ecc-4cf3-90c3-8a3cdc9bf3ee@github.com>

On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont <duke at openjdk.org> wrote:

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

A couple days ago the bot warned

> This pull request contains merges that bring in commits not present in the target repository. 

I'm not sure why this happened. It might be because of this commit earlier in this branch:

> [Merge remote-tracking branch 'origin/JDK-8349206-1' into JDK-8349206-1](https://github.com/openjdk/jdk/pull/23491/commits/c35e5198838f1088e137e0e8ad480d44bb303057)

but I'm not sure. I'm also not sure whether or not this will have any ill effects if we proceed.... Not sure what to do about this.

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

PR Comment: https://git.openjdk.org/jdk/pull/23491#issuecomment-2655157065

From jiangli at openjdk.org  Thu Feb 13 00:55:19 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Feb 2025 00:55:19 GMT
Subject: RFR: 8349620: Add VMProps for static JDK
In-Reply-To: <DDkY02jwb9ew9lA0tBoGpL29CLfRf028eSiKdGVz8AY=.efbdfb9d-4c7e-492c-9628-88222f4b8bf8@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <JIm6MX4f6S8SxGx-IlJGov7rvsFZqLLQACrIZozjl5k=.0c185caf-30a2-4b1a-95bf-b526bc0012ec@github.com>
 <DDkY02jwb9ew9lA0tBoGpL29CLfRf028eSiKdGVz8AY=.efbdfb9d-4c7e-492c-9628-88222f4b8bf8@github.com>
Message-ID: <s1s0aXnoSYQra4-KB883tiu1H15OUhxnsYoC9w_Ow3A=.fbbd05f9-11cb-4042-a74f-785dc120b435@github.com>

On Tue, 11 Feb 2025 08:10:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> That's okay with me. I'm hoping Magnus will jump in when he gets a chance as he has experience with the "other" static build configurations.

@magicus Any thoughts and input on this?

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

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2655185633

From syan at openjdk.org  Thu Feb 13 03:02:21 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 13 Feb 2025 03:02:21 GMT
Subject: RFR: 8349787:
 java/lang/Thread/virtual/ThreadPollOnYield.java#default passes unexpectedly
 without libVThreadPinner.so [v4]
In-Reply-To: <U0JDyN2g5CJMsWE_G84eBq4UCHdX-lj3LyfWL0FiGrI=.564238f8-df23-42dc-8d40-89718b4207dc@github.com>
References: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
 <ljKyc7eN6gNLSPAkMmAFvC_GImSVMKiU5SMYeDeWMHo=.6cd62598-9129-4332-9023-af98c82ee4c9@github.com>
 <U0JDyN2g5CJMsWE_G84eBq4UCHdX-lj3LyfWL0FiGrI=.564238f8-df23-42dc-8d40-89718b4207dc@github.com>
Message-ID: <MYwvAamNAwCl03dFWIo5kxGPt_zqvAIs7U41iFsj2YY=.021a44d3-6c1e-43c6-8aaf-ecda63d0cf6a@github.com>

On Wed, 12 Feb 2025 08:27:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set started as final
>
> Marked as reviewed by alanb (Reviewer).

Thanks @AlanBateman for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23576#issuecomment-2655343267

From syan at openjdk.org  Thu Feb 13 03:02:21 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 13 Feb 2025 03:02:21 GMT
Subject: Integrated: 8349787:
 java/lang/Thread/virtual/ThreadPollOnYield.java#default passes unexpectedly
 without libVThreadPinner.so
In-Reply-To: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
References: <1uDFgNI3dQaLmn5JO6Jnn8Z0iEFzHLEt1yULVMo2L2E=.b36738a7-6c02-43a5-b19d-9ab32ae70146@github.com>
Message-ID: <jPKY_G4FHFnn0L32H5CHw27Uhr4JJv9ARiBLUIEBCBA=.903581fd-5ebd-4c7e-8892-fa60f3e7a3ee@github.com>

On Wed, 12 Feb 2025 03:24:07 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java run passed unexpected without native library or with the incorrect native library path. The test command with incorrect native library path shows below. We will seen this tests run passed unexpected before this PR, because the first virtual thread do not run normally without the dependent shared library libVThreadPinner.so, and there is no assert when the first virtual thread run abnormal.
> 
> 
> mkdir -p empty-directory ; jtreg -v:fail,error -w tmp -nr -jdk:build/linux-x86_64-server-release/images/jdk -nativepath:empty-directory test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java#default
> 
> 
> This PR add a latch variable will make sure the first virtual thread run once at least. After this PR run the same test command which with incorrect native library path, and we will seen this pass run timed out as expected.
> 
> Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: adc3f53d
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/adc3f53d2403cd414a91e71c079b4108b2346da0
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8349787: java/lang/Thread/virtual/ThreadPollOnYield.java#default passes unexpectedly without libVThreadPinner.so

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/23576

From duke at openjdk.org  Thu Feb 13 07:55:12 2025
From: duke at openjdk.org (Nicole Xu)
Date: Thu, 13 Feb 2025 07:55:12 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <ljxrhzoRck0LUkRbHYC_0hfPXiW_L1vuw0K7B8lKUKY=.fea555f9-651a-47a1-8c98-b33470d85a8b@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <ljxrhzoRck0LUkRbHYC_0hfPXiW_L1vuw0K7B8lKUKY=.fea555f9-651a-47a1-8c98-b33470d85a8b@github.com>
Message-ID: <ikTvrFILQiZVSo1YUW_Sc3k3ifMin9UN2eHpcscdcmQ=.eddf8a3c-9e82-40b9-bfca-c79a9d69902d@github.com>

On Tue, 4 Feb 2025 18:55:25 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86 and AArch64 with the following error:
>> 
>> 
>> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
>> 
>> 
>> The variable `long256_arr_idx` is misused when indexing  'LongVector l2, l3, l4, l5' in function `maskedLogicOperationsLongKernel()`. 'long256_arr_idx' increases by 4 every time the benchmark runs and ensures the incremented value remains within the bounds of the array. However, for `LongVector.SPECIES_512`, it loads 8 numbers from the array each time the benchmark runs, resulting in an out-of-range indexing issue.
>> 
>> Hence, we revised the index variables from `long256_arr_idx` to `long512_arr_idx`, which has a stride of 8, to ensure that the loaded vector is inside of the array boundary for all vector species. This is also consistent with other kernel functions.
>> 
>> Additionally, some defined but unused variables have been removed.
>
> Oh, the OCA-verify is still stuck. I'm sorry about that ? 
> I pinged my manager @TobiHartmann , he will reach out to see what's the issue.

Hi @eme64, do you see any risks here? Would you please help to review the patch? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2655780275

From shade at openjdk.org  Thu Feb 13 08:33:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 13 Feb 2025 08:33:12 GMT
Subject: RFR: 8138614: (spec str) StringBuffer and StringBuilder methods
 improperly require "new" String to be returned
In-Reply-To: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
References: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
Message-ID: <d0StTNAvknk15ukXrHy3N-fm_aYyo4EUUHxMHXsVaqQ=.62fa698b-652e-49e6-9fd5-3d45d177bc88@github.com>

On Wed, 12 Feb 2025 19:55:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A couple adjustments to the specs for four methods of StringBuilder and StringBuffer so that they no longer require new Strings to be created, just a String with the right contents. No implementation changes. Note that the actual specs (and implementations) are actually in AbstractStringBuilder, and they're inherited by StringBuilder and StringBuffer.

Looks good to me. Thanks for taking care of this!

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23599#pullrequestreview-2614217560

From epeter at openjdk.org  Thu Feb 13 08:34:14 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 13 Feb 2025 08:34:14 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <ikTvrFILQiZVSo1YUW_Sc3k3ifMin9UN2eHpcscdcmQ=.eddf8a3c-9e82-40b9-bfca-c79a9d69902d@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <ljxrhzoRck0LUkRbHYC_0hfPXiW_L1vuw0K7B8lKUKY=.fea555f9-651a-47a1-8c98-b33470d85a8b@github.com>
 <ikTvrFILQiZVSo1YUW_Sc3k3ifMin9UN2eHpcscdcmQ=.eddf8a3c-9e82-40b9-bfca-c79a9d69902d@github.com>
Message-ID: <Tf6SZVBD2ox3U45oNq0bkMLZkmmPEBeJe8s--_VIjEQ=.b6aa34c0-95dc-4254-ac2e-c9a5c36932dc@github.com>

On Thu, 13 Feb 2025 07:52:30 GMT, Nicole Xu <duke at openjdk.org> wrote:

>> Oh, the OCA-verify is still stuck. I'm sorry about that ? 
>> I pinged my manager @TobiHartmann , he will reach out to see what's the issue.
>
> Hi @eme64, do you see any risks here? Would you please help to review the patch? Thanks.

@xyyNicole This looks reasonable to me. But I do want the original author @jatin-bhateja to look at it too. I'll send him an email as he has not reacted to pings via GitHub yet ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2655866059

From duke at openjdk.org  Thu Feb 13 08:42:24 2025
From: duke at openjdk.org (Nicole Xu)
Date: Thu, 13 Feb 2025 08:42:24 GMT
Subject: RFR: 8349943: [JMH] Use jvmArgs consistently
Message-ID: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>

As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'.

All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency.

-------------

Commit messages:
 - 8349943: [JMH] Use jvmArgs consistently

Changes: https://git.openjdk.org/jdk/pull/23609/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23609&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349943
  Stats: 20 lines in 9 files changed: 2 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/23609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23609/head:pull/23609

PR: https://git.openjdk.org/jdk/pull/23609

From alanb at openjdk.org  Thu Feb 13 09:28:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Feb 2025 09:28:30 GMT
Subject: RFR: 8138614: (spec str) StringBuffer and StringBuilder methods
 improperly require "new" String to be returned
In-Reply-To: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
References: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
Message-ID: <mLLqpRZpgAuNgBxV5Y9MpQzzCSVQskykdK-lW32yuQw=.83f3c687-ca39-42e2-913a-67773e0faa76@github.com>

On Wed, 12 Feb 2025 19:55:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A couple adjustments to the specs for four methods of StringBuilder and StringBuffer so that they no longer require new Strings to be created, just a String with the right contents. No implementation changes. Note that the actual specs (and implementations) are actually in AbstractStringBuilder, and they're inherited by StringBuilder and StringBuffer.

I think this is okay. It is of course possible that something shows up that depended on a new string being created each time so a release note (in addition the CSR) would be helpful.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23599#pullrequestreview-2614382584

From duke at openjdk.org  Thu Feb 13 09:31:25 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 13 Feb 2025 09:31:25 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <L3hady6uuLM2m46z68sW18iMvt7CcuNOxEirq1BvfLo=.7603de81-8ecc-4cf3-90c3-8a3cdc9bf3ee@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <L3hady6uuLM2m46z68sW18iMvt7CcuNOxEirq1BvfLo=.7603de81-8ecc-4cf3-90c3-8a3cdc9bf3ee@github.com>
Message-ID: <7dUKMA08XJ0bnIUjsibK-Fz97HwoYT2_DxnZK2UI-iI=.c17b325c-1fdc-4180-836a-44eb73d2042b@github.com>

On Thu, 13 Feb 2025 00:30:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A couple days ago the bot warned
> 
> > This pull request contains merges that bring in commits not present in the target repository.
> 
> I'm not sure why this happened. It might be because of this commit earlier in this branch:
> 
> > [Merge remote-tracking branch 'origin/JDK-8349206-1' into JDK-8349206-1](https://github.com/openjdk/jdk/pull/23491/commits/c35e5198838f1088e137e0e8ad480d44bb303057)
> 
> but I'm not sure. I'm also not sure whether or not this will have any ill effects if we proceed.... Not sure what to do about this.

It's fine, I had done an append commit locally and this was just merging that. Nothing to see here :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23491#issuecomment-2656007679

From duke at openjdk.org  Thu Feb 13 09:35:13 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 13 Feb 2025 09:35:13 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
 <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>
Message-ID: <bfT8EMRk6msqkRF32_vQCfZvirTiWsvg0hrOpThz9i4=.1f6626ed-637e-4ff3-827d-f5dc34094910@github.com>

On Wed, 12 Feb 2025 20:07:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.logging/share/classes/java/util/logging/FileHandler.java line 755:
>> 
>>> 753:         synchronized(this) {
>>> 754:             flush();
>>> 755:             if (limit > 0 && (meter.written >= limit || meter.written < 0)) {
>> 
>> I don't think we want to write to meter.written and the re-aquire the monitor to then read meter.written.  Bytes written no longer corresponds to the formatted size of the current record. It could now include the sum of other records pending a rotate.
>> 
>> Any thought on creating a package private `StreamHandler::postPublish(LogRecord)` that is called from publish while holding monitor? Then FileHandler could just override that method to invoke flush, check, and rotate.
>
> hmmm... Thanks for chiming in Jason. Good point. So what can happen here is that if multiple threads log concurrently to the same FileHandler then log records might continue to get written to the file after the limit has been reached but before the check that would rotate is performed. In pathological cases where new records continue to arrive and manage to enter the monitor before the post-publish action that rotate can do so, this could become problematic.
> 
> I think what you are proposing would work, since we control the implementation of super.publish().

We could, but I don't think it matters. This issue is the first one pointed out in the CSR, and my current feeling is that since it's stated that the limit is "best effort" and there's always the chance that the final log before rotate was massive anyway, and the risk of this sort of interleaving is low, it's not going to make things qualitatively worse than they are now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1954145265

From duke at openjdk.org  Thu Feb 13 09:40:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 13 Feb 2025 09:40:10 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <NLF7_Yjj-FhQ6yrd6qEdeTKBTl5hV68lwFSY7G5ShIg=.40640b4f-e5b8-4b5c-9d33-230db3614e45@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <NLF7_Yjj-FhQ6yrd6qEdeTKBTl5hV68lwFSY7G5ShIg=.40640b4f-e5b8-4b5c-9d33-230db3614e45@github.com>
Message-ID: <9efir_z7Hk70OKrU67Tt3nt-_H6PFTRAbckO3ja03ds=.a183d40c-88e1-4af2-9a43-97803eb0d43a@github.com>

On Wed, 12 Feb 2025 18:28:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The code changes look reasonable. WRT to detecting deadlocks a possibility is also to use `ManagementFactory.getThreadMXBean().findDeadlockedThreads();`
> 
> See for instance
> 
> https://github.com/openjdk/jdk/blob/336d0d8592aed734e7b8139e1ecd71d33825c75a/test/jdk/java/util/logging/TestLogConfigurationDeadLock.java#L167

I don't think I need this because if there was a deadlock, I know it can only be between the 2 threads I started.

> test/jdk/java/util/logging/LoggingDeadlock5.java line 31:
> 
>> 29:  *          java.logging
>> 30:  * @compile -XDignore.symbol.file LoggingDeadlock5.java
>> 31:  * @run main/othervm/timeout=10 LoggingDeadlock5
> 
> I would not specify any /timeout value here, and rather let jtreg deal with that.

I was just copying the other timeout tests in this directory. This test is written to avoid blocking (apart from the self test case) and complete in about 1 second, so removing this should be fine. Will do so in the next push.

> test/jdk/java/util/logging/LoggingDeadlock5.java line 115:
> 
>> 113: 
>> 114:     private static class DeadLocker {
>> 115:         private final static Duration JOIN_WAIT = Duration.ofMillis(500);
> 
> You might want to use `jdk.test.lib.Utils.adjustTimeout()` here to account for the case when the test is run on slower configurations. Typically in higher tiers, this test might be run with -Xcomp or -Xint and on debug builds which might cause slow downs and cause the join() method to exit too early - reporting false positives.

None of the other logging deadlock tests use this mechanism, but thanks for pointing it out. I will investigate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23491#issuecomment-2656028524
PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1954151677
PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1954153098

From sundar at openjdk.org  Thu Feb 13 09:46:11 2025
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 13 Feb 2025 09:46:11 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases [v3]
In-Reply-To: <OEJXF6PdcqjKSzaZm0f3o8KkDdWBrSAv779QY3xk2hc=.b9fba9d3-e67e-4c5e-9b03-a1b60d1eb00a@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
 <OEJXF6PdcqjKSzaZm0f3o8KkDdWBrSAv779QY3xk2hc=.b9fba9d3-e67e-4c5e-9b03-a1b60d1eb00a@github.com>
Message-ID: <QN2nIcjeGQK048jg8HEACdYKlfwubbk-9CjPWEmvQbI=.6fbd9192-c8d6-4460-87e0-e4937de22cb5@github.com>

On Wed, 12 Feb 2025 16:47:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change in `jdk.tools.jlink.internal.plugins.ZipPlugin` which proposes to close the `Deflater` instance cleanly? This addresses https://bugs.openjdk.org/browse/JDK-8349907.
>> 
>> As noted in that issue, the `Deflater` instance wasn't being closed in the exception code path of this method. The commit in this PR merely changes the code to use a try-with-resources block on the `Deflater` instance.
>> 
>> No new tests have been introduced given the nature of the change. I've added a `noreg-hard` to the issue. Existing tier1, tier2 and tier3 tests continue to pass with this change without any related failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's suggestion - include an assert in catch block to make clear that the IOException isn't expected

LGTM

-------------

Marked as reviewed by sundar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23588#pullrequestreview-2614431315

From clanger at openjdk.org  Thu Feb 13 10:06:15 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Feb 2025 10:06:15 GMT
Subject: RFR: 8349648: Test tools/jpackage/share/JLinkOptionsTest.java
 fails with --enable-linkable-runtime set after JDK-8346434 [v2]
In-Reply-To: <RKzcjQBZoMagTwWIWJhFUH4nM6dY4KV_DftM7aEGqQ0=.87909bb9-7497-401f-ab23-bcf87a2cc601@github.com>
References: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
 <RKzcjQBZoMagTwWIWJhFUH4nM6dY4KV_DftM7aEGqQ0=.87909bb9-7497-401f-ab23-bcf87a2cc601@github.com>
Message-ID: <K11NiACKeshqaroZ5Y0e_rXZUfginizMuEg0YyULRV8=.86f1306b-77da-4c59-875e-5698bb6fe1fb@github.com>

On Tue, 11 Feb 2025 10:17:48 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The change for JDK-8346434 added a new test case to tools/jpackage/share/JLinkOptionsTest.java which does not respect the constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be part of the target image.
>> This can be circumvented by limiting the modules.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment to help understand the output

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23514#issuecomment-2656088499

From clanger at openjdk.org  Thu Feb 13 10:06:16 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 13 Feb 2025 10:06:16 GMT
Subject: Integrated: 8349648: Test tools/jpackage/share/JLinkOptionsTest.java
 fails with --enable-linkable-runtime set after JDK-8346434
In-Reply-To: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
References: <kUDoaF7sKV0QwEzXo9rSHk8hhwcHVD3110Wn0mmA8pE=.4fb070ca-0f5a-4307-9bb1-f1bee88b2a76@github.com>
Message-ID: <h0gpim51RpRJnP0-wdBEoBuq7yjUowAQNw-tnTQcXgQ=.90b32ee1-66af-4761-be66-c93ca91c0fe2@github.com>

On Fri, 7 Feb 2025 13:13:24 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The change for JDK-8346434 added a new test case to tools/jpackage/share/JLinkOptionsTest.java which does not respect the constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be part of the target image.
> This can be circumvented by limiting the modules.

This pull request has now been integrated.

Changeset: 29202d1f
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/29202d1fa7fc35796a5d2c9425eeb3e12f8c027a
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8349648: Test tools/jpackage/share/JLinkOptionsTest.java fails with --enable-linkable-runtime set after JDK-8346434

Reviewed-by: sgehwolf, asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/23514

From asemenyuk at openjdk.org  Thu Feb 13 10:25:16 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 13 Feb 2025 10:25:16 GMT
Subject: Integrated: 8349564: Clean warnings found in jpackage tests when
 building them with -Xlint:all
In-Reply-To: <oFpKSze5bbMk9sUB55IQib3sPGVyq4Fyp4EbsH3_B_k=.ce30c7e6-3b6c-4e70-bf8b-d7ff6f654375@github.com>
References: <oFpKSze5bbMk9sUB55IQib3sPGVyq4Fyp4EbsH3_B_k=.ce30c7e6-3b6c-4e70-bf8b-d7ff6f654375@github.com>
Message-ID: <jZ3gcdHYC2PBCTGzy3UrhBZxKiQzlUgVJN_oo6vW4do=.759022f7-7b25-4978-81c6-ad5f8ff6c63c@github.com>

On Wed, 5 Feb 2025 04:14:21 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Clean warnings found in jpackage tests when building them with `-Xlint:all` option in Eclipse IDE. 
> 
> They are:
>  - redundant imports (solution: remove)
>  - unused function/fields (solution: remove)
>  - missing SuppressWarnings-s (solution: add what is missing)
>  - redundant SuppressWarnings-s (solution: remove)
>  - raw types used (solution: use wildcard or more specific types if appropriate)
>  - generic varargs (solution: convert to single/double/list arguments)
>  - an incomplete list of enum elements in switch statements (solution: add `default` branch)
> 
> To prevent regression, added `-Xlint:all -Werror` to the compiler command line of all jpackage tests

This pull request has now been integrated.

Changeset: efc597bf
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/efc597bf47bff46596bb29b03b5750bfc5afe851
Stats:     352 lines in 83 files changed: 72 ins; 51 del; 229 mod

8349564: Clean warnings found in jpackage tests when building them with -Xlint:all

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/23455

From pminborg at openjdk.org  Thu Feb 13 11:33:23 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Feb 2025 11:33:23 GMT
Subject: Withdrawn: 8347408: Create an internal method handle adapter for
 system calls with errno
In-Reply-To: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
References: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
Message-ID: <UjD3avdhi02IBRYh8fM3PTW40vSNKZIJtZKQnScZonE=.56757bfb-ae33-4e03-af79-a76efe102154@github.com>

On Fri, 7 Feb 2025 14:46:06 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes to add a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively:
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.193 ? 0.268  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.268 ? 0.080  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  42.076 ? 1.003  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.801 ? 0.138  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.265 ? 0.087  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.285 ? 0.155  ns/op
> 
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.033 ? 0.423  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   3.676 ? 0.104  ns/op  // <- Happy path using an internal pool
> 
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.023 ? 0.736  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  22.013 ? 0.648  ns/op  // <- Allocating memory upon each invocation
> 
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  22.050 ? 0.233  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   3.756 ? 0.056  ns/op  // <- Using the pool explicitly from Java code
> 
> 
> Adapted system call:
> 
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> 
> 
> Explicit allocation:
> 
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> 
> 
> Thread Local allocation:
> 
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> 
> 
> The adapted system call exhibits a ~6x performanc...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23517

From pminborg at openjdk.org  Thu Feb 13 11:33:22 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Feb 2025 11:33:22 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v7]
In-Reply-To: <A9LTkDkme2lj0ZODXASxinjtVm1x6BjXcS7x8mDMKIc=.2e0acb22-ce3a-4814-b6e5-d5485bee06a8@github.com>
References: <2YGjVGJ_VBETkp6MrwtUBaSky5lEFdbZSW6I12Zho6M=.123ebd0f-e76e-45b8-9edc-779dbf2142e7@github.com>
 <A9LTkDkme2lj0ZODXASxinjtVm1x6BjXcS7x8mDMKIc=.2e0acb22-ce3a-4814-b6e5-d5485bee06a8@github.com>
Message-ID: <3yNN_P9eFyGOWz9mX8kKCIupxllvt91shVCLvQ7hxqA=.6892abb7-930a-4562-8645-f2d263a073a0@github.com>

On Wed, 12 Feb 2025 16:04:53 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes to add a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>> 
>> Here are some benchmarks that ran on a platform thread and virtual threads respectively:
>> 
>> 
>> Benchmark                                                  Mode  Cnt   Score   Error  Units
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.193 ? 0.268  ns/op
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.268 ? 0.080  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  42.076 ? 1.003  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.801 ? 0.138  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.265 ? 0.087  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.285 ? 0.155  ns/op
>> 
>> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.033 ? 0.423  ns/op
>> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   3.676 ? 0.104  ns/op  // <- Happy path using an internal pool
>> 
>> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.023 ? 0.736  ns/op
>> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  22.013 ? 0.648  ns/op  // <- Allocating memory upon each invocation
>> 
>> CaptureStateUtilBench.tlAllocationFail                     avgt   30  22.050 ? 0.233  ns/op
>> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   3.756 ? 0.056  ns/op  // <- Using the pool explicitly from Java code
>> 
>> 
>> Adapted system call:
>> 
>> 
>>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
>> 
>> 
>> Explicit allocation:
>> 
>> 
>>         try (var arena = Arena.ofConfined()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>>         }
>> 
>> 
>> Thread Local allocation:
>> 
>> 
>>         try (var arena = POOLS.take()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // ...
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add holding a reference to the original arena in the taken arena

Unfortunately, this PR would evolve in a direction that is hard to maintain if appropriate changes were made to cover some virtual thread corner cases. So, we need to rethink the overall solution and come back with another PR. Thanks for your feedback so far.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23517#issuecomment-2656315310

From epeter at openjdk.org  Thu Feb 13 11:39:15 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 13 Feb 2025 11:39:15 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
Message-ID: <BXFt3f0cRfeulvfxCIDM-MUWMxMtFYSuXHUjtnjBKUs=.efc82fb4-d82f-4464-bdcd-95ca56b5e42c@github.com>

On Mon, 10 Feb 2025 09:26:32 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> @eastig is helping with the results on aarch64, so I will verify the numbers in same way done below for x86_64 once he provides me with the results.
>> 
>> Here is a summary of the benchmarking results I'm seeing on x86_64 (I will push an update that just merges the latest master shortly).
>> 
>> First I will go through the results of `MinMaxVector`. This benchmark computes throughput by default so the higher the number the better.
>> 
>> # MinMaxVector AVX-512
>> 
>> Following are results with AVX-512 instructions:
>> 
>> Benchmark                       (probability)  (range)  (seed)  (size)   Mode  Cnt   Baseline     Patch   Units
>> MinMaxVector.longClippingRange            N/A       90       0    1000  thrpt    4    834.127  3688.961  ops/ms
>> MinMaxVector.longClippingRange            N/A      100       0    1000  thrpt    4   1147.010  3687.721  ops/ms
>> MinMaxVector.longLoopMax                   50      N/A     N/A    2048  thrpt    4   1126.718  1072.812  ops/ms
>> MinMaxVector.longLoopMax                   80      N/A     N/A    2048  thrpt    4   1070.921  1070.538  ops/ms
>> MinMaxVector.longLoopMax                  100      N/A     N/A    2048  thrpt    4    510.483  1073.081  ops/ms
>> MinMaxVector.longLoopMin                   50      N/A     N/A    2048  thrpt    4    935.658  1016.910  ops/ms
>> MinMaxVector.longLoopMin                   80      N/A     N/A    2048  thrpt    4   1007.410   933.774  ops/ms
>> MinMaxVector.longLoopMin                  100      N/A     N/A    2048  thrpt    4    536.582  1017.337  ops/ms
>> MinMaxVector.longReductionMax              50      N/A     N/A    2048  thrpt    4    967.288   966.945  ops/ms
>> MinMaxVector.longReductionMax              80      N/A     N/A    2048  thrpt    4    967.327   967.382  ops/ms
>> MinMaxVector.longReductionMax             100      N/A     N/A    2048  thrpt    4    849.689   967.327  ops/ms
>> MinMaxVector.longReductionMin              50      N/A     N/A    2048  thrpt    4    966.323   967.275  ops/ms
>> MinMaxVector.longReductionMin              80      N/A     N/A    2048  thrpt    4    967.340   967.228  ops/ms
>> MinMaxVector.longReductionMin             100      N/A     N/A    2048  thrpt    4    880.921   967.233  ops/ms
>> 
>> 
>> ### `longReduction[Min|Max]` performance improves slightly when probability is 100
>> 
>> Without the patch the code uses compare instructions:
>> 
>> 
>>    7.83%  ???? ????  ?           0x00007f4f700fb305:   imulq		$0xb, 0x20(%r14, %r8, 8), %rdi
>>           ???? ???...
>
>> At 100% probability baseline fails to vectorize because it observes a control flow. This control flow is not the one you see in min/max implementations, but this is one added by HotSpot as a result of the JIT profiling. It observes that one branch is always taken so it optimizes for that, and adds a branch for the uncommon case where the branch is not taken.
> 
> I've dug further into this to try to understand how the baseline hotspot code works, and the explanation above is not entirely correct. Let's look at the IR differences between say 100% vs 80% branch situations.
> 
> At branch 80% you see:
> 
>  1115  CountedLoop  === 1115 598 463  [[ 1101 1115 1116 1118 451 594 ]] inner stride: 2 main of N1115 strip mined !orig=[599],[590],[307] !jvms: MinMaxVector::longLoopMax @ bci:10 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
> 
>   692  LoadL  === 1083 1101 393  [[ 747 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9; #long (does not depend only on test, unknown control) !orig=[395] !jvms: MinMaxVector::longLoopMax @ bci:26 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
>   651  LoadL  === 1095 1101 355  [[ 747 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9; #long (does not depend only on test, unknown control) !orig=[357] !jvms: MinMaxVector::longLoopMax @ bci:20 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
>   747  MaxL  === _ 651 692  [[ 451 ]]  !orig=[608],[416] !jvms: Math::max @ bci:11 (line 2037) MinMaxVector::longLoopMax @ bci:27 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
> 
>   451  StoreL  === 1115 1101 449 747  [[ 1116 454 911 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9;  Memory: @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=9; !orig=1124 !jvms: MinMaxVector::longLoopMax @ bci:30 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
> 
>   594  CountedLoopEnd  === 1115 593  [[ 1123 463 ]] [lt] P=0.999731, C=780799.000000 !orig=[462] !jvms: MinMaxVector::longLoopMax @ bci:7 (line 235) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
> 
> 
> You see the counted loop with the LoadL for array loads and MaxL consuming those. The StoreL is for array assignment (I think).
> 
> At branch 100% you see:
> 
> 
>  ...

@galderz Thanks for all the explanations, that's really helpful ? 

**Discussion**

- AVX512: only imprivements.
  - Expecially with probability 100, where before we used the bytecode, which would then create an `unstable_if` with uncommon trap. That meant we could not re-discover the CMove / Max later in the IR. Now that we never inline the bytecode, and just intrinsify directly, we can use `vpmax` and that is faster.
  - Ah, maybe that was all incorrect, though it sounded reasonable. You seem to suggest that we actually did use to inline both branches, but that the issue was that `PhaseIdealLoop::conditional_move` does not like extreme probabilities, and so it did not convert 100% cases to CMove, and so it did not use to vectorize. Right. Getting the probability cutoff just right it a little tricky there, and the precise number can seem strange. But that's a discussion for another day.
  - The reduction case is only improved slightly... at least. Maybe we can further improve the throughput with [this](https://bugs.openjdk.org/browse/JDK-8345245) later on.

 - AVX2: mixed results
   - `longReductionMax/Min`: vector max / min is not implemented. We should investigate why.
   - It seems like the `MaxVL` and `MinVL` (e.g. `vpmaxsq`) instructions are only implemented directly for AVX512, see [this](https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#ig_expand=4669,2611&text=max_epi64).
   - As you suggested @galderz we could consider implementing it via `cmove` in the backend for `AVX2` and maybe lower. Maybe we can talk with @jatin-bhateja about this. That would probably already be worth it on its own, in a separate RFE. Because I would suspect it could give speedup in the non 100% cases as well. Maybe this would even have to be an RFE that makes it in first, so we don't have regressions here?
   - But even still: just intfinsifying should not get us a regression, because there will always be cases where the auto-vectorizer fails, and so the scalar code should not be slower with your patch than on master, right? So we need to investigate this scalar issue as well.

- VectorReduction2.WithSuperword on AVX-512
  - `long[Min|Max]Simple performance drops considerably`. Yes, this case is not yet supposed to vectorize, I'm working on that - it is the issue with "simple" reductions, i.e. those that do no work other than reduce. Our current reduction heuristic thinks these are not profitable to vectorize - but that is wrong in almost all cases. You even filed an issue for that a while back ;) see https://bugs.openjdk.org/browse/JDK-8345044 and related issues. We could bite the bullet on this, knowing that I'm working on it and it will probably fix that issue, or we just wait a little here. Let's discuss.

- VectorReduction2.NoSuperword on AVX-512 machine
  - Hmm, ok. So we seem to realize that the scalar case is slower with your patch in some cases, because now we have a `cmove` on the critical path, and previously we could just predict the branches, which was faster. Interesting that the number of other instructions has an effect here as well, you seem to see a speedup with the "big" benchmarks, but the "small" and "dot" benchmarks are slower. This is surprising. It would be great if we understood why it behaves this way.

**Summary**

Wow, things are more complicated than I would have thought, I hope you are not too discouraged ? 

We seem to have these issues, maybe there are more:
- AVX2 does not have long-vector-min/max implemented. That can be done in a separate RFE.
- Simple reductions do not vectorize, known issue see https://bugs.openjdk.org/browse/JDK-8345044, I'm working on that.
- Scalar reductions are slower with your patch for extreme probabilities. Before, they were done with branches, and branch prediction was fast. Now with cmove or max instructions, the critical path is longer, and that makes things slow. Maybe this could be alleviated by reordering / reassociating the reduction path, see [JDK-8345245](https://bugs.openjdk.org/browse/JDK-8345245). Alternatively, we could convert the `cmove` back to a branch, but for that we would probably need to know the branching probability, which we now do not have any more, right? Tricky. This seems the real issue we need to address and discuss.

@galderz What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2656328729

From epeter at openjdk.org  Thu Feb 13 11:49:18 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 13 Feb 2025 11:49:18 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
Message-ID: <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>

On Mon, 10 Feb 2025 09:26:32 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> @eastig is helping with the results on aarch64, so I will verify the numbers in same way done below for x86_64 once he provides me with the results.
>> 
>> Here is a summary of the benchmarking results I'm seeing on x86_64 (I will push an update that just merges the latest master shortly).
>> 
>> First I will go through the results of `MinMaxVector`. This benchmark computes throughput by default so the higher the number the better.
>> 
>> # MinMaxVector AVX-512
>> 
>> Following are results with AVX-512 instructions:
>> 
>> Benchmark                       (probability)  (range)  (seed)  (size)   Mode  Cnt   Baseline     Patch   Units
>> MinMaxVector.longClippingRange            N/A       90       0    1000  thrpt    4    834.127  3688.961  ops/ms
>> MinMaxVector.longClippingRange            N/A      100       0    1000  thrpt    4   1147.010  3687.721  ops/ms
>> MinMaxVector.longLoopMax                   50      N/A     N/A    2048  thrpt    4   1126.718  1072.812  ops/ms
>> MinMaxVector.longLoopMax                   80      N/A     N/A    2048  thrpt    4   1070.921  1070.538  ops/ms
>> MinMaxVector.longLoopMax                  100      N/A     N/A    2048  thrpt    4    510.483  1073.081  ops/ms
>> MinMaxVector.longLoopMin                   50      N/A     N/A    2048  thrpt    4    935.658  1016.910  ops/ms
>> MinMaxVector.longLoopMin                   80      N/A     N/A    2048  thrpt    4   1007.410   933.774  ops/ms
>> MinMaxVector.longLoopMin                  100      N/A     N/A    2048  thrpt    4    536.582  1017.337  ops/ms
>> MinMaxVector.longReductionMax              50      N/A     N/A    2048  thrpt    4    967.288   966.945  ops/ms
>> MinMaxVector.longReductionMax              80      N/A     N/A    2048  thrpt    4    967.327   967.382  ops/ms
>> MinMaxVector.longReductionMax             100      N/A     N/A    2048  thrpt    4    849.689   967.327  ops/ms
>> MinMaxVector.longReductionMin              50      N/A     N/A    2048  thrpt    4    966.323   967.275  ops/ms
>> MinMaxVector.longReductionMin              80      N/A     N/A    2048  thrpt    4    967.340   967.228  ops/ms
>> MinMaxVector.longReductionMin             100      N/A     N/A    2048  thrpt    4    880.921   967.233  ops/ms
>> 
>> 
>> ### `longReduction[Min|Max]` performance improves slightly when probability is 100
>> 
>> Without the patch the code uses compare instructions:
>> 
>> 
>>    7.83%  ???? ????  ?           0x00007f4f700fb305:   imulq		$0xb, 0x20(%r14, %r8, 8), %rdi
>>           ???? ???...
>
>> At 100% probability baseline fails to vectorize because it observes a control flow. This control flow is not the one you see in min/max implementations, but this is one added by HotSpot as a result of the JIT profiling. It observes that one branch is always taken so it optimizes for that, and adds a branch for the uncommon case where the branch is not taken.
> 
> I've dug further into this to try to understand how the baseline hotspot code works, and the explanation above is not entirely correct. Let's look at the IR differences between say 100% vs 80% branch situations.
> 
> At branch 80% you see:
> 
>  1115  CountedLoop  === 1115 598 463  [[ 1101 1115 1116 1118 451 594 ]] inner stride: 2 main of N1115 strip mined !orig=[599],[590],[307] !jvms: MinMaxVector::longLoopMax @ bci:10 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
> 
>   692  LoadL  === 1083 1101 393  [[ 747 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9; #long (does not depend only on test, unknown control) !orig=[395] !jvms: MinMaxVector::longLoopMax @ bci:26 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
>   651  LoadL  === 1095 1101 355  [[ 747 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9; #long (does not depend only on test, unknown control) !orig=[357] !jvms: MinMaxVector::longLoopMax @ bci:20 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
>   747  MaxL  === _ 651 692  [[ 451 ]]  !orig=[608],[416] !jvms: Math::max @ bci:11 (line 2037) MinMaxVector::longLoopMax @ bci:27 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
> 
>   451  StoreL  === 1115 1101 449 747  [[ 1116 454 911 ]]  @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=9;  Memory: @long[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=9; !orig=1124 !jvms: MinMaxVector::longLoopMax @ bci:30 (line 236) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
> 
>   594  CountedLoopEnd  === 1115 593  [[ 1123 463 ]] [lt] P=0.999731, C=780799.000000 !orig=[462] !jvms: MinMaxVector::longLoopMax @ bci:7 (line 235) MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub @ bci:19 (line 124)
> 
> 
> You see the counted loop with the LoadL for array loads and MaxL consuming those. The StoreL is for array assignment (I think).
> 
> At branch 100% you see:
> 
> 
>  ...

@galderz How sure are that intrinsifying directly is really the right approach?

Maybe the approach via `PhaseIdealLoop::conditional_move` where we know the branching probability is a better one. Though of course knowing the branching probability is no perfect heuristic for how good branch prediction is going to be, but it is at least something.

So I'm wondering if there could be a different approach that sees all the wins you get here, without any of the regressions?

If we are just interested in better vectorization: the current issue is that the auto-vectorizer cannot handle CFG, i.e. we do not yet do if-conversion. But if we had if-conversion, then the inlined CFG of min/max would just be converted to vector CMove (or vector min/max where available) at that point. We can take the branching probabilities into account, just like `PhaseIdealLoop::conditional_move` does - if that is necessary. Of course if-conversion is far away, and we will encounter a lot of issues with branch prediction etc, so I'm scared we might never get there - but I want to try ;)

Do we see any other wins with your patch, that are not due to vectorization, but just scalar code?

@galderz Maybe we can discuss this offline at some point as well :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2656350896
PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2656351785

From jpai at openjdk.org  Thu Feb 13 11:56:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Feb 2025 11:56:22 GMT
Subject: RFR: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not
 close the Deflater in exceptional cases [v3]
In-Reply-To: <OEJXF6PdcqjKSzaZm0f3o8KkDdWBrSAv779QY3xk2hc=.b9fba9d3-e67e-4c5e-9b03-a1b60d1eb00a@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
 <OEJXF6PdcqjKSzaZm0f3o8KkDdWBrSAv779QY3xk2hc=.b9fba9d3-e67e-4c5e-9b03-a1b60d1eb00a@github.com>
Message-ID: <FbXlqrgLBRqgemoEBL5h63iVNVA7O-LJLU2ovaW1pxo=.d409ae77-d191-40db-afdf-43b169c183bd@github.com>

On Wed, 12 Feb 2025 16:47:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change in `jdk.tools.jlink.internal.plugins.ZipPlugin` which proposes to close the `Deflater` instance cleanly? This addresses https://bugs.openjdk.org/browse/JDK-8349907.
>> 
>> As noted in that issue, the `Deflater` instance wasn't being closed in the exception code path of this method. The commit in this PR merely changes the code to use a try-with-resources block on the `Deflater` instance.
>> 
>> No new tests have been introduced given the nature of the change. I've added a `noreg-hard` to the issue. Existing tier1, tier2 and tier3 tests continue to pass with this change without any related failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's suggestion - include an assert in catch block to make clear that the IOException isn't expected

Thank you everyone for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23588#issuecomment-2656366802

From jpai at openjdk.org  Thu Feb 13 11:56:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Feb 2025 11:56:23 GMT
Subject: Integrated: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does
 not close the Deflater in exceptional cases
In-Reply-To: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
References: <UVOYGLCe4hOewdE8uiNSkFAQc9R-I3RXHd49FxShdr4=.91216ca5-d401-490f-8e50-fd44e071b2a1@github.com>
Message-ID: <PbQ3OGBLz8IL0GlrR86cBkxG9mq8Z2_sSKXNQxFhxmI=.cc892aea-a944-40b2-8eeb-12ca6a82b859@github.com>

On Wed, 12 Feb 2025 14:09:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change in `jdk.tools.jlink.internal.plugins.ZipPlugin` which proposes to close the `Deflater` instance cleanly? This addresses https://bugs.openjdk.org/browse/JDK-8349907.
> 
> As noted in that issue, the `Deflater` instance wasn't being closed in the exception code path of this method. The commit in this PR merely changes the code to use a try-with-resources block on the `Deflater` instance.
> 
> No new tests have been introduced given the nature of the change. I've added a `noreg-hard` to the issue. Existing tier1, tier2 and tier3 tests continue to pass with this change without any related failures.

This pull request has now been integrated.

Changeset: 5b75ff72
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b75ff7283340291bc87f83aba0e4416479899e3
Stats:     32 lines in 1 file changed: 13 ins; 13 del; 6 mod

8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not close the Deflater in exceptional cases

Reviewed-by: liach, alanb, sundar, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/23588

From jbhateja at openjdk.org  Thu Feb 13 12:15:19 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 13 Feb 2025 12:15:19 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
Message-ID: <x9ETYwOSiE2ZfaP4xus4S6WppTevakAr0hHsRlA7YF8=.a22172e1-e5b5-42f9-9d92-2df2e09fdb05@github.com>

On Wed, 8 Jan 2025 09:04:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86 and AArch64 with the following error:
> 
> 
> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
> 
> 
> The variable `long256_arr_idx` is misused when indexing  'LongVector l2, l3, l4, l5' in function `maskedLogicOperationsLongKernel()`. 'long256_arr_idx' increases by 4 every time the benchmark runs and ensures the incremented value remains within the bounds of the array. However, for `LongVector.SPECIES_512`, it loads 8 numbers from the array each time the benchmark runs, resulting in an out-of-range indexing issue.
> 
> Hence, we revised the index variables from `long256_arr_idx` to `long512_arr_idx`, which has a stride of 8, to ensure that the loaded vector is inside of the array boundary for all vector species. This is also consistent with other kernel functions.
> 
> Additionally, some defined but unused variables have been removed.

test/micro/org/openjdk/bench/jdk/incubator/vector/MaskedLogicOpts.java line 122:

> 120:     @Setup(Level.Invocation)
> 121:     public void init_per_invoc() {
> 122:         int512_arr_idx = (int512_arr_idx + 16) & (ARRAYLEN-1);

Benchmark assumes that ARRAYLEN is a POT value, thus it will also be good to use the modulous operator for rounding here, it will be expensive but will not impact the performance of the Benchmarking kernels.

test/micro/org/openjdk/bench/jdk/incubator/vector/MaskedLogicOpts.java line 126:

> 124:     }
> 125: 
> 126:     @CompilerControl(CompilerControl.Mode.INLINE)

By making the index hop over 16 ints or 8 longs we may leave gaps in between for 128-bit and 256-bit species, this will unnecessarily include the noise due to cache misses or (on some targets) prefetching additional cache lines which are not usable, thereby impacting the crispness of microbenchmark.

test/micro/org/openjdk/bench/jdk/incubator/vector/MaskedLogicOpts.java line 234:

> 232:     }
> 233: 
> 234:     @CompilerControl(CompilerControl.Mode.INLINE)

Benchmarking kernels are forced inlined, so passing a species specific index value may help.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22963#discussion_r1954379708
PR Review Comment: https://git.openjdk.org/jdk/pull/22963#discussion_r1954358833
PR Review Comment: https://git.openjdk.org/jdk/pull/22963#discussion_r1954385898

From jbhateja at openjdk.org  Thu Feb 13 12:15:19 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 13 Feb 2025 12:15:19 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <x9ETYwOSiE2ZfaP4xus4S6WppTevakAr0hHsRlA7YF8=.a22172e1-e5b5-42f9-9d92-2df2e09fdb05@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <x9ETYwOSiE2ZfaP4xus4S6WppTevakAr0hHsRlA7YF8=.a22172e1-e5b5-42f9-9d92-2df2e09fdb05@github.com>
Message-ID: <52HO_iL9asn1huCdJj82R1AwF1w8ON9HZetrdc9rQyQ=.28e137e0-a7f7-4839-a3e7-eda4f8a6c4f5@github.com>

On Thu, 13 Feb 2025 12:06:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86 and AArch64 with the following error:
>> 
>> 
>> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
>> 
>> 
>> The variable `long256_arr_idx` is misused when indexing  'LongVector l2, l3, l4, l5' in function `maskedLogicOperationsLongKernel()`. 'long256_arr_idx' increases by 4 every time the benchmark runs and ensures the incremented value remains within the bounds of the array. However, for `LongVector.SPECIES_512`, it loads 8 numbers from the array each time the benchmark runs, resulting in an out-of-range indexing issue.
>> 
>> Hence, we revised the index variables from `long256_arr_idx` to `long512_arr_idx`, which has a stride of 8, to ensure that the loaded vector is inside of the array boundary for all vector species. This is also consistent with other kernel functions.
>> 
>> Additionally, some defined but unused variables have been removed.
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/MaskedLogicOpts.java line 122:
> 
>> 120:     @Setup(Level.Invocation)
>> 121:     public void init_per_invoc() {
>> 122:         int512_arr_idx = (int512_arr_idx + 16) & (ARRAYLEN-1);
> 
> Benchmark assumes that ARRAYLEN is a POT value, thus it will also be good to use the modulous operator for rounding here, it will be expensive but will not impact the performance of the Benchmarking kernels.

Please try with following command line
`java -jar target/benchmarks.jar -f 1 -i 2 -wi 1 -w 30 -p ARRAYLEN=30 MaskedLogic`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22963#discussion_r1954384129

From asemenyuk at openjdk.org  Thu Feb 13 12:50:47 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 13 Feb 2025 12:50:47 GMT
Subject: RFR: 8285624: jpackage fails to create exe,
 msi when Windows OS is in FIPS mode
Message-ID: <hh7PqZEfclqWDX7GeLK_VDgGQO9MRSpXCfAlVcdH4c0=.02060519-5d3f-4107-ae2c-5456f4c48cb6@github.com>

8285624: jpackage fails to create exe, msi when Windows OS is in FIPS mode

-------------

Commit messages:
 - Update copyright year
 - 8285624: jpackage fails to create exe, msi when Windows OS is in FIPS mode

Changes: https://git.openjdk.org/jdk/pull/23612/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23612&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8285624
  Stats: 115 lines in 3 files changed: 67 ins; 18 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/23612.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23612/head:pull/23612

PR: https://git.openjdk.org/jdk/pull/23612

From asemenyuk at openjdk.org  Thu Feb 13 13:00:12 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 13 Feb 2025 13:00:12 GMT
Subject: RFR: 8285624: jpackage fails to create exe,
 msi when Windows OS is in FIPS mode
In-Reply-To: <hh7PqZEfclqWDX7GeLK_VDgGQO9MRSpXCfAlVcdH4c0=.02060519-5d3f-4107-ae2c-5456f4c48cb6@github.com>
References: <hh7PqZEfclqWDX7GeLK_VDgGQO9MRSpXCfAlVcdH4c0=.02060519-5d3f-4107-ae2c-5456f4c48cb6@github.com>
Message-ID: <bocXdRrpPMxYapxhQSuyMM6WULlXv0fR9KfMj_DT5MM=.06e91fb9-8a8d-48cc-925e-4ac3b1c31d03@github.com>

On Thu, 13 Feb 2025 12:43:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Make jpackage capable of using wix3 when Federal Information Processing Standard (FIPS) mode is enabled on Windows.
> 
> When FIPS mode is enabled, running `candle.exe -?` prints:
> 
> candle.exe : error CNDL0308 : The Federal Information Processing Standard (FIPS) appears to be enabled on the machine. You must either disable FIPS or use FIPS-compliant security algorithms to generate IDs by passing the -fips command-line switch or by setting <FipsCompliant>true</FipsCompliant> in your .wixproj project.
> 
> Though jpackage expects the following output:
> 
> Microsoft (R) Windows Installer Xml Compiler version 3.5.2519.0
> Copyright (C) Microsoft Corporation. All rights reserved.
> 
>  usage:  candle.exe [-?] [-nologo] [-out outputFile] sourceFile [sourceFile ...] [@responseFile]
> 
>  ...
> 
> 
> candle.exe also exits with an error code (308).
> 
> To workaround the problem, run `candle.exe -fips` to make it print standard help output regardless FIPS mode enable/disable.
> 
> Run candle.exe the second time to detect if it requires an `-fips` command line switch. If it does, jpackage will add it automatically.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23612#issuecomment-2656521943

From viktor.klang at oracle.com  Thu Feb 13 14:06:19 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 13 Feb 2025 14:06:19 +0000
Subject: JDK-8072840: Presizing for Stream Collectors
In-Reply-To: <CAHY-eHsUqc905OqqcYXsuVZjeM+A81OOV2K7CsJ1zg8uc4cPOQ@mail.gmail.com>
References: <CAHY-eHsUqc905OqqcYXsuVZjeM+A81OOV2K7CsJ1zg8uc4cPOQ@mail.gmail.com>
Message-ID: <MW4PR10MB57746C5D9561370300396D8FFFFF2@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Fabian,

Thanks for your patience, it took a bit of time to swap back in my thoughts on the matter, as I was considering this JBS issue as I was working on Gatherers (JEP461, JEP473, JEP485).

While it may look enticing to merely propagate expected element count as an input parameter to the supplier function,
I think it deserves some extra thought, specifically if it may make more sense to pass some sort of StreamInfo type which can provide more metadata in the future.

Another open question is how to propagate this information through Gatherers (i.e. a bigger scope than Collector-augmentation) to enable more sophisticated optimizations?because ultimately the availability of the information throughout the pipeline is going to be important for Collector.


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Fabian Meumertzheim <fabian at buildbuddy.io>
Sent: Wednesday, 12 February 2025 11:09
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: JDK-8072840: Presizing for Stream Collectors

As an avid user of Guava's ImmutableCollections, I have been
interested in ways to close the efficiency gap between the built-in
`Stream#toList()` and third-party `Collector` implementations such as
`ImmutableList#toImmutableList()`. I've found the biggest problem to
be the lack of sizing information in `Collector`s, which led to me to
draft a solution to JDK-8072840:
https://github.com/openjdk/jdk/pull/23461

The benchmark shows pretty significant gains for sized streams that
mostly reshape data (e.g. slice records or turn a list into a map by
associating keys), which I've found to be a pretty common use case.

Before I formally send out the PR for review, I would like to gather
feedback on the design aspects of it (rather than the exact
implementation). I will thus leave it in draft mode for now, but
invite anyone to comment on it or on this thread.

Fabian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250213/3b0f5762/attachment.htm>

From rriggs at openjdk.org  Thu Feb 13 15:57:15 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Feb 2025 15:57:15 GMT
Subject: RFR: 8138614: (spec str) StringBuffer and StringBuilder methods
 improperly require "new" String to be returned
In-Reply-To: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
References: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
Message-ID: <q73PgnvQiWJGmr-MGMBFsDkCCGNiE0R3jHnVrqKHI4U=.15304a9a-1f0c-4bbf-a144-871112b32695@github.com>

On Wed, 12 Feb 2025 19:55:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A couple adjustments to the specs for four methods of StringBuilder and StringBuffer so that they no longer require new Strings to be created, just a String with the right contents. No implementation changes. Note that the actual specs (and implementations) are actually in AbstractStringBuilder, and they're inherited by StringBuilder and StringBuffer.

Looks good

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23599#pullrequestreview-2615495168

From fabian at buildbuddy.io  Thu Feb 13 16:11:23 2025
From: fabian at buildbuddy.io (Fabian Meumertzheim)
Date: Thu, 13 Feb 2025 17:11:23 +0100
Subject: JDK-8072840: Presizing for Stream Collectors
In-Reply-To: <MW4PR10MB57746C5D9561370300396D8FFFFF2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAHY-eHsUqc905OqqcYXsuVZjeM+A81OOV2K7CsJ1zg8uc4cPOQ@mail.gmail.com>
 <MW4PR10MB57746C5D9561370300396D8FFFFF2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAHY-eHtyOb+DahSQoq+1JDzqc4J1TR=u73zAhDQ2yPAdLNyR8Q@mail.gmail.com>

On Thu, Feb 13, 2025 at 3:06?PM Viktor Klang <viktor.klang at oracle.com> wrote:
> While it may look enticing to merely propagate expected element count as an input parameter to the supplier function,
> I think it deserves some extra thought, specifically if it may make more sense to pass some sort of StreamInfo type which can provide more metadata in the future.

I could see that being useful for properties such as non-nullness,
which would allow collections such as ImmutableList to skip the null
check in the end.

> Another open question is how to propagate this information through Gatherers (i.e. a bigger scope than Collector-augmentation) to enable more sophisticated optimizations?because ultimately the availability of the information throughout the pipeline is going to be important for Collector.

Do you think that there could be a need to pass stream information to
anything other than the Gatherer's state initializer? Based on a
cursory glance, it looks straightforward to pass the same info to it
as to the Collector. If that's true and we go with a more extensible
design than a plain long, Gatherers could be opted in in follow-up
work.

Best,
Fabian

>
>
> Cheers,
> ?
>
>
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle
> ________________________________
> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Fabian Meumertzheim <fabian at buildbuddy.io>
> Sent: Wednesday, 12 February 2025 11:09
> To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> Subject: JDK-8072840: Presizing for Stream Collectors
>
> As an avid user of Guava's ImmutableCollections, I have been
> interested in ways to close the efficiency gap between the built-in
> `Stream#toList()` and third-party `Collector` implementations such as
> `ImmutableList#toImmutableList()`. I've found the biggest problem to
> be the lack of sizing information in `Collector`s, which led to me to
> draft a solution to JDK-8072840:
> https://github.com/openjdk/jdk/pull/23461
>
> The benchmark shows pretty significant gains for sized streams that
> mostly reshape data (e.g. slice records or turn a list into a map by
> associating keys), which I've found to be a pretty common use case.
>
> Before I formally send out the PR for review, I would like to gather
> feedback on the design aspects of it (rather than the exact
> implementation). I will thus leave it in draft mode for now, but
> invite anyone to comment on it or on this thread.
>
> Fabian

From viktor.klang at oracle.com  Thu Feb 13 16:45:19 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 13 Feb 2025 16:45:19 +0000
Subject: [External] : Re: JDK-8072840: Presizing for Stream Collectors
In-Reply-To: <CAHY-eHtyOb+DahSQoq+1JDzqc4J1TR=u73zAhDQ2yPAdLNyR8Q@mail.gmail.com>
References: <CAHY-eHsUqc905OqqcYXsuVZjeM+A81OOV2K7CsJ1zg8uc4cPOQ@mail.gmail.com>
 <MW4PR10MB57746C5D9561370300396D8FFFFF2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAHY-eHtyOb+DahSQoq+1JDzqc4J1TR=u73zAhDQ2yPAdLNyR8Q@mail.gmail.com>
Message-ID: <MW4PR10MB577456A59E55050AED6EFCD6FFFF2@MW4PR10MB5774.namprd10.prod.outlook.com>

>I could see that being useful for properties such as non-nullness,
which would allow collections such as ImmutableList to skip the null
check in the end.

I'm thinking things like ordered/unordered, whether the stream is parallel or not (might want to use different representation for a sequential stream), etc.

>Do you think that there could be a need to pass stream information to
anything other than the Gatherer's state initializer? Based on a
cursory glance, it looks straightforward to pass the same info to it
as to the Collector. If that's true and we go with a more extensible
design than a plain long, Gatherers could be opted in in follow-up
work.

It's more involved than that?as Gatherers produce output, it would be necessary to devise a scheme which allows Gatherers to communicate upper and lower bounds on the output. This information would then need to be threaded through the chain of gatherers and emerge on the other side. This is slightly more involved than just communicating characteristics, since it is information based off of the stream and not merely the operation itself.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Fabian Meumertzheim <fabian at buildbuddy.io>
Sent: Thursday, 13 February 2025 17:11
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [External] : Re: JDK-8072840: Presizing for Stream Collectors

On Thu, Feb 13, 2025 at 3:06?PM Viktor Klang <viktor.klang at oracle.com> wrote:
> While it may look enticing to merely propagate expected element count as an input parameter to the supplier function,
> I think it deserves some extra thought, specifically if it may make more sense to pass some sort of StreamInfo type which can provide more metadata in the future.

I could see that being useful for properties such as non-nullness,
which would allow collections such as ImmutableList to skip the null
check in the end.

> Another open question is how to propagate this information through Gatherers (i.e. a bigger scope than Collector-augmentation) to enable more sophisticated optimizations?because ultimately the availability of the information throughout the pipeline is going to be important for Collector.

Do you think that there could be a need to pass stream information to
anything other than the Gatherer's state initializer? Based on a
cursory glance, it looks straightforward to pass the same info to it
as to the Collector. If that's true and we go with a more extensible
design than a plain long, Gatherers could be opted in in follow-up
work.

Best,
Fabian

>
>
> Cheers,
> ?
>
>
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle
> ________________________________
> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Fabian Meumertzheim <fabian at buildbuddy.io>
> Sent: Wednesday, 12 February 2025 11:09
> To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> Subject: JDK-8072840: Presizing for Stream Collectors
>
> As an avid user of Guava's ImmutableCollections, I have been
> interested in ways to close the efficiency gap between the built-in
> `Stream#toList()` and third-party `Collector` implementations such as
> `ImmutableList#toImmutableList()`. I've found the biggest problem to
> be the lack of sizing information in `Collector`s, which led to me to
> draft a solution to JDK-8072840:
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23461__;!!ACWV5N9M2RV99hQ!N-RbriJ93dED1WYLFxFZ4dD5oTx5wqPCPTmv4Oivm3IFJTHNwZ1v3d228Ifs8SdFJwcc7YZnCuNZXG9LmQ3ZCA4$
>
> The benchmark shows pretty significant gains for sized streams that
> mostly reshape data (e.g. slice records or turn a list into a map by
> associating keys), which I've found to be a pretty common use case.
>
> Before I formally send out the PR for review, I would like to gather
> feedback on the design aspects of it (rather than the exact
> implementation). I will thus leave it in draft mode for now, but
> invite anyone to comment on it or on this thread.
>
> Fabian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250213/6fddea8e/attachment.htm>

From roland at openjdk.org  Thu Feb 13 16:46:16 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 13 Feb 2025 16:46:16 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
Message-ID: <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>

On Thu, 13 Feb 2025 11:46:35 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Do we see any other wins with your patch, that are not due to vectorization, but just scalar code?

I think there are some. 

The current transformation from the parsed version of min/max to a conditional move to a `Max`/`Min` node depends on the conditional move transformation which has its own set of heuristics and while it happens on simple test cases, that's not necessarily the case on all code shapes. I don't think we want to trust it too much.

With the intrinsic, the type of the min or max can be narrowed down in a way it can't be whether the code includes control flow or a conditional move. That in turn, once types have propagated, could cause some constant to appear and could be a significant win.

The `Min`/`Max` nodes are floating nodes. They can hoist out of loop and common reliably in ways that are not guaranteed  otherwise.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2657176312

From mullan at openjdk.org  Thu Feb 13 17:07:41 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Feb 2025 17:07:41 GMT
Subject: RFR: 8347946: Add API note that caller should validate/trust signers
 to the getCertificates and getCodeSigners methods of JarEntry and
 JarURLConnection
Message-ID: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>

This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates.

2 other smaller changes:
 - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead
 - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`)

-------------

Commit messages:
 - Fix whitespace.
 - Add additional text about trusting signers.
 - Merge
 - Initial fix.

Changes: https://git.openjdk.org/jdk/pull/23616/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23616&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347946
  Stats: 38 lines in 3 files changed: 32 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23616/head:pull/23616

PR: https://git.openjdk.org/jdk/pull/23616

From epeter at openjdk.org  Thu Feb 13 17:16:22 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 13 Feb 2025 17:16:22 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
Message-ID: <X4j1fJ5qlpnYbtZuhWWtSh5JfbmAE201_tpvrtCrkuU=.c41ddaa0-794a-4574-b0a0-845fb0afc093@github.com>

On Thu, 13 Feb 2025 16:43:22 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The current transformation from the parsed version of min/max to a conditional move to a Max/Min node depends on the conditional move transformation which has its own set of heuristics and while it happens on simple test cases, that's not necessarily the case on all code shapes. I don't think we want to trust it too much.

Well, actually people have tried to improve the conditonal move transformation, and it is really really difficult. It's hard not to get regressions. I'm wondering how much easier it is for min / max. Maybe we have similar limitations, especially with predicting how well branch prediction performs.

You are probably right about type propagation and `Min / Max` being floating nodes.

@rwestrel What do you think about the regressions in the scalar cases of this patch?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2657253439

From duke at openjdk.org  Thu Feb 13 17:20:13 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 13 Feb 2025 17:20:13 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <9efir_z7Hk70OKrU67Tt3nt-_H6PFTRAbckO3ja03ds=.a183d40c-88e1-4af2-9a43-97803eb0d43a@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <NLF7_Yjj-FhQ6yrd6qEdeTKBTl5hV68lwFSY7G5ShIg=.40640b4f-e5b8-4b5c-9d33-230db3614e45@github.com>
 <9efir_z7Hk70OKrU67Tt3nt-_H6PFTRAbckO3ja03ds=.a183d40c-88e1-4af2-9a43-97803eb0d43a@github.com>
Message-ID: <8CZPcxsI36WJBPwfEEBGcosakJQWJEtYglB2j896rlc=.1928cae3-2f9e-445d-ae7c-17918e59a3ea@github.com>

On Thu, 13 Feb 2025 09:36:08 GMT, David Beaumont <duke at openjdk.org> wrote:

>> test/jdk/java/util/logging/LoggingDeadlock5.java line 115:
>> 
>>> 113: 
>>> 114:     private static class DeadLocker {
>>> 115:         private final static Duration JOIN_WAIT = Duration.ofMillis(500);
>> 
>> You might want to use `jdk.test.lib.Utils.adjustTimeout()` here to account for the case when the test is run on slower configurations. Typically in higher tiers, this test might be run with -Xcomp or -Xint and on debug builds which might cause slow downs and cause the join() method to exit too early - reporting false positives.
>
> None of the other logging deadlock tests use this mechanism, but thanks for pointing it out. I will investigate.

After discussing it, I think I'll wait before complicating the code or increasing timeouts (since the timeout should only be used in the self-test case anyway, as we're testing primarily for the *lack* of deadlocks).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1954914913

From mullan at openjdk.org  Thu Feb 13 19:00:10 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Feb 2025 19:00:10 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms
In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
Message-ID: <mwAvxBimrifL95bjkjc6YUolA0aQ-UjAjjcaXjvY3NQ=.407cccb6-2fca-4213-a1d2-5dc16be3c545@github.com>

On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).

Bug needs a `noreg-self` label.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23566#issuecomment-2657471939

From paul.sandoz at oracle.com  Thu Feb 13 19:18:13 2025
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 13 Feb 2025 19:18:13 +0000
Subject: JDK-8072840: Presizing for Stream Collectors
In-Reply-To: <CAHY-eHsUqc905OqqcYXsuVZjeM+A81OOV2K7CsJ1zg8uc4cPOQ@mail.gmail.com>
References: <CAHY-eHsUqc905OqqcYXsuVZjeM+A81OOV2K7CsJ1zg8uc4cPOQ@mail.gmail.com>
Message-ID: <9288FDCA-0984-487B-9426-559CE9EA5632@oracle.com>

Hi Fabian,

Thanks for sharing and reaching out with the idea before getting too beholden to it.

I logged this is quite a while ago. It seemed like a possible good idea at the time, although I never liked the duplication of suppliers. I have become less enthusiastic overtime, especially so as Gatherers have been added. (Gatherer is the underlying primitive we could not find when we were furiously developing streams and meeting the Java 8 deadline.) My sense is if we are going to address we need to think more broadly about Gatherers. And, Viktor being the lead on Gatherers has a good take on where this might head.

Paul.

> On Feb 12, 2025, at 2:09?AM, Fabian Meumertzheim <fabian at buildbuddy.io> wrote:
> 
> As an avid user of Guava's ImmutableCollections, I have been
> interested in ways to close the efficiency gap between the built-in
> `Stream#toList()` and third-party `Collector` implementations such as
> `ImmutableList#toImmutableList()`. I've found the biggest problem to
> be the lack of sizing information in `Collector`s, which led to me to
> draft a solution to JDK-8072840:
> https://github.com/openjdk/jdk/pull/23461
> 
> The benchmark shows pretty significant gains for sized streams that
> mostly reshape data (e.g. slice records or turn a list into a map by
> associating keys), which I've found to be a pretty common use case.
> 
> Before I formally send out the PR for review, I would like to gather
> feedback on the design aspects of it (rather than the exact
> implementation). I will thus leave it in draft mode for now, but
> invite anyone to comment on it or on this thread.
> 
> Fabian


From kevin.bourrillion at oracle.com  Thu Feb 13 19:30:06 2025
From: kevin.bourrillion at oracle.com (Kevin Bourrillion)
Date: Thu, 13 Feb 2025 19:30:06 +0000
Subject: Adding BigDecimal.valueOf(float val) constructor
In-Reply-To: <CAHOiiwv0pBwPEHMtjbWV5wD0_-61-2zciK1oueitU5q9u8iroA@mail.gmail.com>
References: <CAHOiiwv-hG19KqbJ8Ew7VmuzmMnQ1gb8vxVB_i1EL1VaPL5c2w@mail.gmail.com>
 <7E17AB44-D674-4C0B-AF71-BF92A350A22C@oracle.com>
 <1595099054.75679369.1737671712186.JavaMail.zimbra@univ-eiffel.fr>
 <bb62797c-4bef-40b6-a3a8-2a0af73b8884@oracle.com>
 <CAHOiiwv0pBwPEHMtjbWV5wD0_-61-2zciK1oueitU5q9u8iroA@mail.gmail.com>
Message-ID: <037964EB-06D4-44B9-8156-080C26AD647D@oracle.com>

My latest thoughts; please advise if I have misunderstood anything.


On Jan 24, 2025, at 3:11?AM, Jan Kowalski <jan7493 at gmail.com> wrote:

I'd say that, if it's possible, we should reduce the arithmetic artifacts, rather than introduce them through not really needed, and not visible at the first sight, type conversions.

? Do you think introducing such change would be beneficial to simplify the code, or rather introduce minor precision improvement, while we still don?t have 100% decimal precision?

Okay, so what we?re looking for is a way to convert floats to BigDecimals in such a way that `0.1f` comes out the same as `new BigDecimal(?0.1?)`.

This thread is characterizing that outcome as ?reducing artifacts? and ?improving precision?, which seems fair on the surface, but I believe this is more like an illusion. I think the reason this looks like obvious ?improvement? to us is only because we happen to be using literals in our examples. But for a float value that isn?t a literal, like our friend `0.1f + 0.2f`, I think that the illusion is shattered. I think this ?exposes" that the scale chosen by BD.valueOf(double) is based on an ?artifact? of that value that isn?t really meant to be ?information carried by? the value. (Were we to think the latter way, it makes us think of a float-to-double cast as losing information, which feels like nonsense.)

I think the fact that a new overload would affect current behavior means we need to rule that option out. I don?t think this is a case that can justify that cost. So it would at best have to be a new separately-named method like `valueOfFloat`. So at best this issue will still bite users of `valueOf`, and we would still want the documentation of that method to advise users on what to do instead.

My feeling is that all we need it to do is advise the user to call `BigDecimal.valueOf(Float.toString(val))`. This is very transparent about what?s really happening. Here the user is intentionally choosing the representation/scale.

I personally don?t see this as a case where fast-enough benchmark result would justify adding a new method.

Your thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250213/d12ab62e/attachment-0001.htm>

From jnimeh at openjdk.org  Thu Feb 13 19:43:12 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 13 Feb 2025 19:43:12 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms
In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
Message-ID: <WaesxjpVqAuw3Q7MNCelHsibJWCpMcrNpvk8fw8XL7M=.81badfdd-63de-4518-95bd-3d5f7414d2ff@github.com>

On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).

test/lib-test/jdk/test/lib/security/CPVAlgTestWithOCSP.java line 26:

> 24: /**
> 25:  * @test
> 26:  * @bug 8179502

Cut-n-paste bug, update this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1955113230

From jnimeh at openjdk.org  Thu Feb 13 19:43:11 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 13 Feb 2025 19:43:11 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms
In-Reply-To: <mwAvxBimrifL95bjkjc6YUolA0aQ-UjAjjcaXjvY3NQ=.407cccb6-2fca-4213-a1d2-5dc16be3c545@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
 <mwAvxBimrifL95bjkjc6YUolA0aQ-UjAjjcaXjvY3NQ=.407cccb6-2fca-4213-a1d2-5dc16be3c545@github.com>
Message-ID: <TM4s0UxoAtSfCQA7S86WImvzBh1JzmQW9Fb6U07SXcY=.adbe0e90-612f-47c0-8855-3e710a3bf020@github.com>

On Thu, 13 Feb 2025 18:58:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).
>
> Bug needs a `noreg-self` label.

@seanjmullan I wasn't sure if I should add that label because there is a test of these changes in `test/lib-test/jdk/test/lib/security/CPVAlgTestWithOCSP.java`.  However I did notice that I forgot to change the bug ID and summary in that test code, so I will update that.  Given that there is a test included with the change, LMK if you still feel that it needs the noreg label and I will add it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23566#issuecomment-2657550465

From smarks at openjdk.org  Thu Feb 13 19:44:13 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 13 Feb 2025 19:44:13 GMT
Subject: RFR: 8138614: (spec str) StringBuffer and StringBuilder methods
 improperly require "new" String to be returned
In-Reply-To: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
References: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
Message-ID: <QAmUZu6AQ9NZFPZBAgfoaCxH5c8ECoXQP6A6jpYWqSc=.3b5716ed-b729-4310-93de-4bd97e234f32@github.com>

On Wed, 12 Feb 2025 19:55:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A couple adjustments to the specs for four methods of StringBuilder and StringBuffer so that they no longer require new Strings to be created, just a String with the right contents. No implementation changes. Note that the actual specs (and implementations) are actually in AbstractStringBuilder, and they're inherited by StringBuilder and StringBuffer.

Thanks. Will add CSR and release note next.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23599#issuecomment-2657554852

From duke at openjdk.org  Thu Feb 13 19:45:18 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Thu, 13 Feb 2025 19:45:18 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <bfT8EMRk6msqkRF32_vQCfZvirTiWsvg0hrOpThz9i4=.1f6626ed-637e-4ff3-827d-f5dc34094910@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
 <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>
 <bfT8EMRk6msqkRF32_vQCfZvirTiWsvg0hrOpThz9i4=.1f6626ed-637e-4ff3-827d-f5dc34094910@github.com>
Message-ID: <A_C2myp2dclvSO5vDmJD4sl9FMoWFCP-j1P7ihltcKc=.c1cb149b-0e33-4d6d-8399-8d6dfe5dbccc@github.com>

On Thu, 13 Feb 2025 09:32:29 GMT, David Beaumont <duke at openjdk.org> wrote:

>> hmmm... Thanks for chiming in Jason. Good point. So what can happen here is that if multiple threads log concurrently to the same FileHandler then log records might continue to get written to the file after the limit has been reached but before the check that would rotate is performed. In pathological cases where new records continue to arrive and manage to enter the monitor before the post-publish action that rotate can do so, this could become problematic.
>> 
>> I think what you are proposing would work, since we control the implementation of super.publish().
>
> We could, but I don't think it matters. This issue is the first one pointed out in the CSR, and my current feeling is that since it's stated that the limit is "best effort" and there's always the chance that the final log before rotate was massive anyway, and the risk of this sort of interleaving is low, it's not going to make things qualitatively worse than they are now. If the docs promised that file wouldn't grow beyond the limit, I'd definitely have done things something like you're suggesting.

To be clear I'm with you on your approach and hold much of the same views.

>We could, but I don't think it matters.

I'm just focusing on this aspect because it is usually the thing comes back to bite me.

I think it matters when resources are limited (diskspace) and file size limits are low.

Write a test with filehander set to 2 files at 1M in size.
2. Create a custom Formatter that uses a count down latch set to 10 and returns the log sequence as a string. Install it on the filehander.
3. Start 10 threads that log ~1M of data.
4. Assert that only 2 log sequences are seen when scanning both files.

Old code should only allow at most 2 records which helps control the overshoot of file size.

For context, I've built and have used custom Formatters that would have blocking behavior like the count down latch test.  This is not a strawman test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1955111379

From mullan at openjdk.org  Thu Feb 13 19:48:16 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Feb 2025 19:48:16 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms
In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
Message-ID: <YV-zo5wMDpN1Xbtylo2w6lvx1u3ngHbW89Dthc6o28w=.43cb563d-0857-4488-91dd-eca6a1eb0f66@github.com>

On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).

test/lib-test/jdk/test/lib/security/CPVAlgTestWithOCSP.java line 1:

> 1: /*

This test seems to be the more significant reason for this change - should the issue be renamed to something like "Add OCSP tests for various signature algorithms including PQC algorithms". The enhancements to the test library would then be more as an additional improvement in order to support this new test.

test/lib/jdk/test/lib/security/CertificateBuilder.java line 462:

> 460:             throws CertificateException, IOException, NoSuchAlgorithmException {
> 461: 
> 462:         AlgorithmId signAlg;

This variable looks like it is unused now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1955119146
PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1955105753

From mullan at openjdk.org  Thu Feb 13 19:52:10 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Feb 2025 19:52:10 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms
In-Reply-To: <mwAvxBimrifL95bjkjc6YUolA0aQ-UjAjjcaXjvY3NQ=.407cccb6-2fca-4213-a1d2-5dc16be3c545@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
 <mwAvxBimrifL95bjkjc6YUolA0aQ-UjAjjcaXjvY3NQ=.407cccb6-2fca-4213-a1d2-5dc16be3c545@github.com>
Message-ID: <uWyTlAPdTPGutz5F5BZBUIMWIF7veFpubzx97Ht9zS0=.5ac131eb-62c3-4b42-8edb-c8a4f91a2b93@github.com>

On Thu, 13 Feb 2025 18:58:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).
>
> Bug needs a `noreg-self` label.

> @seanjmullan I wasn't sure if I should add that label because there is a test of these changes in `test/lib-test/jdk/test/lib/security/CPVAlgTestWithOCSP.java`. However I did notice that I forgot to change the bug ID and summary in that test code, so I will update that. Given that there is a test included with the change, LMK if you still feel that it needs the noreg label and I will add it.

That's a good question. I usually add the `noreg-self` label even it it is a brand new test and not a fix to an existing test and there is no other JDK code changes. @JesperIRL do you have any advice for this situation?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23566#issuecomment-2657569848

From mullan at openjdk.org  Thu Feb 13 19:55:09 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Feb 2025 19:55:09 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms
In-Reply-To: <YV-zo5wMDpN1Xbtylo2w6lvx1u3ngHbW89Dthc6o28w=.43cb563d-0857-4488-91dd-eca6a1eb0f66@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
 <YV-zo5wMDpN1Xbtylo2w6lvx1u3ngHbW89Dthc6o28w=.43cb563d-0857-4488-91dd-eca6a1eb0f66@github.com>
Message-ID: <btzXCn5chalE5m6W0Yavh6miIYkZj1BtNA3Vx-dHLL8=.d6731282-8f47-4a8a-bab6-086179d9f36d@github.com>

On Thu, 13 Feb 2025 19:45:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).
>
> test/lib-test/jdk/test/lib/security/CPVAlgTestWithOCSP.java line 1:
> 
>> 1: /*
> 
> This test seems to be the more significant reason for this change - should the issue be renamed to something like "Add OCSP tests for various signature algorithms including PQC algorithms". The enhancements to the test library would then be more as an additional improvement in order to support this new test.

Also,  should it be moved to somewhere else like jdk/test/sun/security/provider/certpath?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1955130339

From liach at openjdk.org  Thu Feb 13 20:03:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Feb 2025 20:03:12 GMT
Subject: RFR: 8138614: (spec str) StringBuffer and StringBuilder methods
 improperly require "new" String to be returned
In-Reply-To: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
References: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
Message-ID: <YrYXY9qskrEEWzEmPmAj5_7IX4wD1ya4FmIl_e50vLE=.1333966e-e609-4bbe-b895-2f40e22be219@github.com>

On Wed, 12 Feb 2025 19:55:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A couple adjustments to the specs for four methods of StringBuilder and StringBuffer so that they no longer require new Strings to be created, just a String with the right contents. No implementation changes. Note that the actual specs (and implementations) are actually in AbstractStringBuilder, and they're inherited by StringBuilder and StringBuffer.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23599#pullrequestreview-2616094752

From jwilhelm at openjdk.org  Thu Feb 13 20:04:09 2025
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 13 Feb 2025 20:04:09 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms
In-Reply-To: <uWyTlAPdTPGutz5F5BZBUIMWIF7veFpubzx97Ht9zS0=.5ac131eb-62c3-4b42-8edb-c8a4f91a2b93@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
 <mwAvxBimrifL95bjkjc6YUolA0aQ-UjAjjcaXjvY3NQ=.407cccb6-2fca-4213-a1d2-5dc16be3c545@github.com>
 <uWyTlAPdTPGutz5F5BZBUIMWIF7veFpubzx97Ht9zS0=.5ac131eb-62c3-4b42-8edb-c8a4f91a2b93@github.com>
Message-ID: <O40gAC0YXHizK74HzVKOYdUPf80o7mNvHvK631WQaeQ=.65be6b25-353f-4d98-8aaa-cb9baa7d4e38@github.com>

On Thu, 13 Feb 2025 19:49:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> That's a good question. I usually add the `noreg-self` label even it it is a brand new test and not a fix to an existing test and there is no other JDK code changes. @JesperIRL do you have any advice for this situation?

`noreg-self` is used to indicate that a change touches test code only. It doesn't matter if it's adding new tests or changing existing tests. As long as there are no product code changes the label should be there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23566#issuecomment-2657594924

From liach at openjdk.org  Thu Feb 13 20:07:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Feb 2025 20:07:09 GMT
Subject: RFR: 8349943: [JMH] Use jvmArgs consistently
In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
Message-ID: <pA_crYq8d4pP02fOMviloSX-9AxrmmZu36Xjk6gszP4=.b2ba01bd-2328-40b5-9286-89b264123cc9@github.com>

On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'.
> 
> All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency.

The java.lang.foreign arg changes look fine.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23609#pullrequestreview-2616102653

From joehw at openjdk.org  Thu Feb 13 20:19:10 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 13 Feb 2025 20:19:10 GMT
Subject: RFR: 8349873: StackOverflowError after JDK-8342550 if
 -Duser.timezone= is set to a deprecated zone id [v2]
In-Reply-To: <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
 <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>
Message-ID: <ttPgLPeHj7XDRJjUtbhQgGMMFaN1iGfxDrcLOqJ62k0=.90cd59dc-cbe4-43c8-8d18-f1059228eaa9@github.com>

On Wed, 12 Feb 2025 23:07:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23597#pullrequestreview-2616127694

From smarks at openjdk.org  Thu Feb 13 20:51:26 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 13 Feb 2025 20:51:26 GMT
Subject: RFR: 8138614: (spec str) StringBuffer and StringBuilder methods
 improperly require "new" String to be returned [v2]
In-Reply-To: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
References: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
Message-ID: <iEAmP06a5g2yY0_IoYkWW1O85ko8ep7UCercBBgpXJ4=.6f2a5567-dcd4-4a98-89df-dd6978ecf0f9@github.com>

> A couple adjustments to the specs for four methods of StringBuilder and StringBuffer so that they no longer require new Strings to be created, just a String with the right contents. No implementation changes. Note that the actual specs (and implementations) are actually in AbstractStringBuilder, and they're inherited by StringBuilder and StringBuffer.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  A tiny bit of wordsmithing.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23599/files
  - new: https://git.openjdk.org/jdk/pull/23599/files/074bd261..0633c022

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23599&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23599&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23599.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23599/head:pull/23599

PR: https://git.openjdk.org/jdk/pull/23599

From naoto at openjdk.org  Thu Feb 13 21:00:16 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Feb 2025 21:00:16 GMT
Subject: RFR: 8349873: StackOverflowError after JDK-8342550 if
 -Duser.timezone= is set to a deprecated zone id [v2]
In-Reply-To: <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
 <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>
Message-ID: <QKEvw3muTRFs9pC5UVB0XhGAnNdD_WJMjoWHA1nUNig=.3d6df28b-e0db-4feb-bce3-6a3efeb0030a@github.com>

On Wed, 12 Feb 2025 23:07:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23597#issuecomment-2657694002

From naoto at openjdk.org  Thu Feb 13 21:00:17 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Feb 2025 21:00:17 GMT
Subject: Integrated: 8349873: StackOverflowError after JDK-8342550 if
 -Duser.timezone= is set to a deprecated zone id
In-Reply-To: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
Message-ID: <JTj6KZTqUXCu2xMJzcfwSEpbX3hP29uGj-v128kymsU=.0b8b6afc-7d12-4eb7-a7b1-bf7e917cdf9e@github.com>

On Wed, 12 Feb 2025 19:35:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.

This pull request has now been integrated.

Changeset: 3e7acfac
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e7acfac48229441b243a6ac564e719963e4f43d
Stats:     21 lines in 2 files changed: 10 ins; 1 del; 10 mod

8349873: StackOverflowError after JDK-8342550 if -Duser.timezone= is set to a deprecated zone id

Reviewed-by: joehw, jlu, iris

-------------

PR: https://git.openjdk.org/jdk/pull/23597

From smarks at openjdk.org  Thu Feb 13 21:11:10 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 13 Feb 2025 21:11:10 GMT
Subject: RFR: 8138614: (spec str) StringBuffer and StringBuilder methods
 improperly require "new" String to be returned [v2]
In-Reply-To: <iEAmP06a5g2yY0_IoYkWW1O85ko8ep7UCercBBgpXJ4=.6f2a5567-dcd4-4a98-89df-dd6978ecf0f9@github.com>
References: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
 <iEAmP06a5g2yY0_IoYkWW1O85ko8ep7UCercBBgpXJ4=.6f2a5567-dcd4-4a98-89df-dd6978ecf0f9@github.com>
Message-ID: <Ai-SJvHPVmlVK7W0e2zChYFC3mWE02PYiUQ5izSPv8M=.b344cd29-9d0e-45fa-a2d7-b2a2dbf35259@github.com>

On Thu, 13 Feb 2025 20:51:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> A couple adjustments to the specs for four methods of StringBuilder and StringBuffer so that they no longer require new Strings to be created, just a String with the right contents. No implementation changes. Note that the actual specs (and implementations) are actually in AbstractStringBuilder, and they're inherited by StringBuilder and StringBuffer.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A tiny bit of wordsmithing.

Please review CSR [JDK-8350031](https://bugs.openjdk.org/browse/JDK-8350031) and release note [JDK-8350042](https://bugs.openjdk.org/browse/JDK-8350042). Also, this PR probably needs to be re-reviewed because I pushed a commit that contains some changed wording. (This change is already reflected in the CSR.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23599#issuecomment-2657713295

From darcy at openjdk.org  Thu Feb 13 21:21:18 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 13 Feb 2025 21:21:18 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v31]
In-Reply-To: <rr-1SsRzTqZ5SD8XrbZtUKPrROkuLgs-XZx0RwVV7aA=.08d658b2-f59c-4185-bc5e-6d631ba20052@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <wmzwqSiFdhqcr8MsGA9FjLjix25b2xbUR6EMldc2k9c=.8f74f6ad-c453-459b-a6ed-8091e1a8794e@github.com>
 <rr-1SsRzTqZ5SD8XrbZtUKPrROkuLgs-XZx0RwVV7aA=.08d658b2-f59c-4185-bc5e-6d631ba20052@github.com>
Message-ID: <u492FtI94QYk8w_eKpNSpw8Eqsyq3PUcvaH_eLMrsHc=.237a5b0c-bb60-4c2f-9e17-f0ac1ff0e68a@github.com>

On Mon, 10 Feb 2025 09:17:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR seems to be targeting performance, yet no benchmarks are provided comparing the current vs. proposed branch with respect to performance. We need to understand the upside of the proposed changes.

At my request, reimplementing BigDecimal.sqrt was done separately from the (now integrated) improvements to BigInteger.sqrt.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2657731793

From almatvee at openjdk.org  Thu Feb 13 22:16:13 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 13 Feb 2025 22:16:13 GMT
Subject: RFR: 8285624: jpackage fails to create exe,
 msi when Windows OS is in FIPS mode
In-Reply-To: <hh7PqZEfclqWDX7GeLK_VDgGQO9MRSpXCfAlVcdH4c0=.02060519-5d3f-4107-ae2c-5456f4c48cb6@github.com>
References: <hh7PqZEfclqWDX7GeLK_VDgGQO9MRSpXCfAlVcdH4c0=.02060519-5d3f-4107-ae2c-5456f4c48cb6@github.com>
Message-ID: <ngpsQuZLGpdzO5O_Za5Mti507NTBfqV--ul-zGdwTdI=.f8de735a-cb6d-4117-9908-4e7565a232c5@github.com>

On Thu, 13 Feb 2025 12:43:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Make jpackage capable of using wix3 when Federal Information Processing Standard (FIPS) mode is enabled on Windows.
> 
> When FIPS mode is enabled, running `candle.exe -?` prints:
> 
> candle.exe : error CNDL0308 : The Federal Information Processing Standard (FIPS) appears to be enabled on the machine. You must either disable FIPS or use FIPS-compliant security algorithms to generate IDs by passing the -fips command-line switch or by setting <FipsCompliant>true</FipsCompliant> in your .wixproj project.
> 
> Though jpackage expects the following output:
> 
> Microsoft (R) Windows Installer Xml Compiler version 3.5.2519.0
> Copyright (C) Microsoft Corporation. All rights reserved.
> 
>  usage:  candle.exe [-?] [-nologo] [-out outputFile] sourceFile [sourceFile ...] [@responseFile]
> 
>  ...
> 
> 
> candle.exe also exits with an error code (308).
> 
> To workaround the problem, run `candle.exe -fips` to make it print standard help output regardless FIPS mode enable/disable.
> 
> Run candle.exe the second time to detect if it requires an `-fips` command line switch. If it does, jpackage will add it automatically.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23612#pullrequestreview-2616338388

From prr at openjdk.org  Thu Feb 13 22:18:11 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Feb 2025 22:18:11 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <evAenTOjoERTQqzy0mFSRfPw3pkiKTJGAGWWtUXBFnc=.288e0965-3e4b-4b91-946c-351d89c976f5@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
 <evAenTOjoERTQqzy0mFSRfPw3pkiKTJGAGWWtUXBFnc=.288e0965-3e4b-4b91-946c-351d89c976f5@github.com>
Message-ID: <cWLREUTKZi-TdD8Cg3UGHi_T_konPWUlo5no_cGJK9w=.7fbb02b9-6c74-476c-ab57-faee6c6cdb40@github.com>

On Thu, 6 Feb 2025 14:30:30 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
>> 
>> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.
>
> src/java.desktop/share/classes/javax/imageio/stream/ImageInputStreamImpl.java line 245:
> 
>> 243:             throw new EOFException();
>> 244:         }
>> 245:         return (byteOrder == ByteOrder.BIG_ENDIAN)
> 
> This could just be `ByteArray.getShortBO(byteBuff, 0, byteOrder == ByteOrder.BIG_ENDIAN)`. Same for the others.

That would look cleaner.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1955287769

From jlu at openjdk.org  Thu Feb 13 22:28:13 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Feb 2025 22:28:13 GMT
Subject: Integrated: 8349883: Locale.LanguageRange.parse("-") throws
 ArrayIndexOutOfBoundsException
In-Reply-To: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
References: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
Message-ID: <y8s5Kjl6cEtQJflyxkR2Y4uSFqKqtubgCngpCC7kwPc=.c7def4ca-0776-4aeb-a1b4-5859cb3a640f@github.com>

On Wed, 12 Feb 2025 19:34:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which prevents a (non-specified) `AIOOBE` from leaking out of the range accepting endpoints in `Locale.LanguageRange`.
> 
> In the reported error case, the invalid range is a lone "-" which is `split` into an empty array. Checking if the range ends with "-" first, avoids indexing the empty array.

This pull request has now been integrated.

Changeset: 3741c980
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3741c980b865b7122d07655353657d683923c40d
Stats:     138 lines in 3 files changed: 61 ins; 67 del; 10 mod

8349883: Locale.LanguageRange.parse("-") throws ArrayIndexOutOfBoundsException

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/23596

From viktor.klang at oracle.com  Thu Feb 13 22:30:59 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 13 Feb 2025 22:30:59 +0000
Subject: JDK-8072840: Presizing for Stream Collectors
In-Reply-To: <9288FDCA-0984-487B-9426-559CE9EA5632@oracle.com>
References: <CAHY-eHsUqc905OqqcYXsuVZjeM+A81OOV2K7CsJ1zg8uc4cPOQ@mail.gmail.com>
 <9288FDCA-0984-487B-9426-559CE9EA5632@oracle.com>
Message-ID: <MW4PR10MB5774BFFCD72E859A29A24CF8FFFF2@MW4PR10MB5774.namprd10.prod.outlook.com>

Indeed. I hope I didn't sound discouraging about the possibility to propagate the stream size information.

I merely want to emphasize that it may necessitate a slightly broader take on the problem of propagation of stream-instance metadata, especially in the face of Gatherers becoming a finalized feature.

It's great that you started this conversation, Fabian!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Paul Sandoz <paul.sandoz at oracle.com>
Sent: Thursday, 13 February 2025 20:18
To: Fabian Meumertzheim <fabian at buildbuddy.io>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: JDK-8072840: Presizing for Stream Collectors

Hi Fabian,

Thanks for sharing and reaching out with the idea before getting too beholden to it.

I logged this is quite a while ago. It seemed like a possible good idea at the time, although I never liked the duplication of suppliers. I have become less enthusiastic overtime, especially so as Gatherers have been added. (Gatherer is the underlying primitive we could not find when we were furiously developing streams and meeting the Java 8 deadline.) My sense is if we are going to address we need to think more broadly about Gatherers. And, Viktor being the lead on Gatherers has a good take on where this might head.

Paul.

> On Feb 12, 2025, at 2:09?AM, Fabian Meumertzheim <fabian at buildbuddy.io> wrote:
>
> As an avid user of Guava's ImmutableCollections, I have been
> interested in ways to close the efficiency gap between the built-in
> `Stream#toList()` and third-party `Collector` implementations such as
> `ImmutableList#toImmutableList()`. I've found the biggest problem to
> be the lack of sizing information in `Collector`s, which led to me to
> draft a solution to JDK-8072840:
> https://github.com/openjdk/jdk/pull/23461
>
> The benchmark shows pretty significant gains for sized streams that
> mostly reshape data (e.g. slice records or turn a list into a map by
> associating keys), which I've found to be a pretty common use case.
>
> Before I formally send out the PR for review, I would like to gather
> feedback on the design aspects of it (rather than the exact
> implementation). I will thus leave it in draft mode for now, but
> invite anyone to comment on it or on this thread.
>
> Fabian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250213/5cd111ec/attachment-0001.htm>

From jnimeh at openjdk.org  Thu Feb 13 22:32:10 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 13 Feb 2025 22:32:10 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms
In-Reply-To: <btzXCn5chalE5m6W0Yavh6miIYkZj1BtNA3Vx-dHLL8=.d6731282-8f47-4a8a-bab6-086179d9f36d@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
 <YV-zo5wMDpN1Xbtylo2w6lvx1u3ngHbW89Dthc6o28w=.43cb563d-0857-4488-91dd-eca6a1eb0f66@github.com>
 <btzXCn5chalE5m6W0Yavh6miIYkZj1BtNA3Vx-dHLL8=.d6731282-8f47-4a8a-bab6-086179d9f36d@github.com>
Message-ID: <vJxNHXpG4Phl_yAj3k_WpM4hOwWHfdYIVYG5q-h6tUc=.0a8ccf1b-a622-49cf-bae6-128ae154ced2@github.com>

On Thu, 13 Feb 2025 19:52:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Also, should it be moved to somewhere else like jdk/test/sun/security/provider/certpath?

Hmmm...not sure about that, but maybe an explanation is in order: Because the JDK only implements the client side with OCSP, we rely on CertPathValidator to handle the path validation and that has never been a problem with PQC.  When I did OCSP stapling a long time ago (JDK 9) that was when I wanted a way to build certs (good and malformed ones) and make OCSP servers that didn't need to fork processes outside the jtreg framework or need 3rd party code.  That meant I had to implement the server-side (consumption of requests and generation of responses) and that's where things needed some tuning up.  So it isn't really a CPV problem, it's a testcode problem.  In order to exercise it and ensure that it worked for all the algs we use to sign stuff, I made this test-the-test-code test and at the suggestion of @rhalade I located in the lib-test tree.  Using CPV in the test was mainly a way for me to drive the OCSP request from the JDK code.  that is also validates consumption of the signed
  response and the cert chain is a nice freebie.

Not opposed to making the changes, I just didn't know if it was the right way to go considering that I'm not changing any actual JDK code, just test helper classes so in the future we can do PQC cert chains and OCSP servers for our tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1955301602

From duke at openjdk.org  Thu Feb 13 22:46:13 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 13 Feb 2025 22:46:13 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <A_C2myp2dclvSO5vDmJD4sl9FMoWFCP-j1P7ihltcKc=.c1cb149b-0e33-4d6d-8399-8d6dfe5dbccc@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
 <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>
 <bfT8EMRk6msqkRF32_vQCfZvirTiWsvg0hrOpThz9i4=.1f6626ed-637e-4ff3-827d-f5dc34094910@github.com>
 <A_C2myp2dclvSO5vDmJD4sl9FMoWFCP-j1P7ihltcKc=.c1cb149b-0e33-4d6d-8399-8d6dfe5dbccc@github.com>
Message-ID: <dl48ChO5x4futsrtaAjvvlxb4Enekr9S1qFCwQtGVkU=.904d075e-786d-4fe2-980c-f6e9143ba86a@github.com>

On Thu, 13 Feb 2025 19:38:47 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> We could, but I don't think it matters. This issue is the first one pointed out in the CSR, and my current feeling is that since it's stated that the limit is "best effort" and there's always the chance that the final log before rotate was massive anyway, and the risk of this sort of interleaving is low, it's not going to make things qualitatively worse than they are now. If the docs promised that file wouldn't grow beyond the limit, I'd definitely have done things something like you're suggesting.
>
> To be clear I'm with you on your approach and hold much of the same views.
> 
>>We could, but I don't think it matters.
> 
> I'm just focusing on this aspect because it is usually the thing comes back to bite me.
> 
> I think it matters when resources are limited (diskspace) and file size limits are low.
> 
> Write a test with filehander set to 2 files at 1M in size.
> 2. Create a custom Formatter that uses a count down latch set to 10 and returns the log sequence as a string. Install it on the filehander.
> 3. Start 10 threads that log ~1M of data.
> 4. Assert that only 2 log sequences are seen when scanning both files.
> 
> Old code should only allow at most 2 records which helps control the overshoot of file size.
> 
> For context, I've built and have used custom Formatters that would have blocking behavior like the count down latch test.  This is not a strawman test.

Yes, it's certainly something you can deliberately provoke in a way that wasn't possible before.
However I'm not sure that the statement "Old code should only allow at most 2 records ...", while true of the code itself was ever something the docs/specification implied would be true, so I'm doubtful of the validity of asserting anything about it too strongly.

However, the general possibility of having blocking behavior in formatters is interesting. Can you explain more concretely why you did this and what problem it solved, so I can build a better model of the likelihood of this causing issues? Was the blocking just something like "acquire cached localized formatter", where several threads might contend over the cache entry when a new locale is seen? Or was it something more complex?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1955313943

From jnimeh at openjdk.org  Thu Feb 13 22:47:29 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 13 Feb 2025 22:47:29 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms [v2]
In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
Message-ID: <oaOdKSUZn7moxxy78XMLbbNUDOPm19m7aXU79czdauQ=.e098c846-ba9c-40d2-99c5-7b194be17b6e@github.com>

> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  Fix JBS ID and summary in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23566/files
  - new: https://git.openjdk.org/jdk/pull/23566/files/bec2b43c..8c16daba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23566.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23566/head:pull/23566

PR: https://git.openjdk.org/jdk/pull/23566

From jnimeh at openjdk.org  Thu Feb 13 22:47:29 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 13 Feb 2025 22:47:29 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms [v2]
In-Reply-To: <YV-zo5wMDpN1Xbtylo2w6lvx1u3ngHbW89Dthc6o28w=.43cb563d-0857-4488-91dd-eca6a1eb0f66@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
 <YV-zo5wMDpN1Xbtylo2w6lvx1u3ngHbW89Dthc6o28w=.43cb563d-0857-4488-91dd-eca6a1eb0f66@github.com>
Message-ID: <gUTcgnS02hs66TZGXARtoV9aO-BnUDdfGkuMkCuXv5s=.05b3fc16-80c8-4293-a38c-3a8022165c9c@github.com>

On Thu, 13 Feb 2025 19:34:04 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix JBS ID and summary in test
>
> test/lib/jdk/test/lib/security/CertificateBuilder.java line 462:
> 
>> 460:             throws CertificateException, IOException, NoSuchAlgorithmException {
>> 461: 
>> 462:         AlgorithmId signAlg;
> 
> This variable looks like it is unused now.

It's used on 476 for encoding the AlgorithmIdentifier of the certificate signature, and also on 530 to again provide that same AlgorithmIdentifier encoding in the TBSCertificate strructure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1955313651

From asemenyuk at openjdk.org  Thu Feb 13 22:56:13 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 13 Feb 2025 22:56:13 GMT
Subject: Integrated: 8285624: jpackage fails to create exe,
 msi when Windows OS is in FIPS mode
In-Reply-To: <hh7PqZEfclqWDX7GeLK_VDgGQO9MRSpXCfAlVcdH4c0=.02060519-5d3f-4107-ae2c-5456f4c48cb6@github.com>
References: <hh7PqZEfclqWDX7GeLK_VDgGQO9MRSpXCfAlVcdH4c0=.02060519-5d3f-4107-ae2c-5456f4c48cb6@github.com>
Message-ID: <fAzOqe5Jj3vccr_Zk3BbdwiboqPFyEEN5BHrodibBz8=.0164bfb0-ad9d-4638-ab4b-98f7dcbd8f7f@github.com>

On Thu, 13 Feb 2025 12:43:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Make jpackage capable of using wix3 when Federal Information Processing Standard (FIPS) mode is enabled on Windows.
> 
> When FIPS mode is enabled, running `candle.exe -?` prints:
> 
> candle.exe : error CNDL0308 : The Federal Information Processing Standard (FIPS) appears to be enabled on the machine. You must either disable FIPS or use FIPS-compliant security algorithms to generate IDs by passing the -fips command-line switch or by setting <FipsCompliant>true</FipsCompliant> in your .wixproj project.
> 
> Though jpackage expects the following output:
> 
> Microsoft (R) Windows Installer Xml Compiler version 3.5.2519.0
> Copyright (C) Microsoft Corporation. All rights reserved.
> 
>  usage:  candle.exe [-?] [-nologo] [-out outputFile] sourceFile [sourceFile ...] [@responseFile]
> 
>  ...
> 
> 
> candle.exe also exits with an error code (308).
> 
> To workaround the problem, run `candle.exe -fips` to make it print standard help output regardless FIPS mode enable/disable.
> 
> Run candle.exe the second time to detect if it requires an `-fips` command line switch. If it does, jpackage will add it automatically.

This pull request has now been integrated.

Changeset: ff52859d
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ff52859d2ad65b97c56dd19323213a0d07be47ae
Stats:     115 lines in 3 files changed: 67 ins; 18 del; 30 mod

8285624: jpackage fails to create exe, msi when Windows OS is in FIPS mode

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/23612

From asemenyuk at openjdk.org  Thu Feb 13 22:57:24 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 13 Feb 2025 22:57:24 GMT
Subject: RFR: 8350011: Convert jpackage test lib tests in JUnit format
Message-ID: <XI1LCl0OXIX0i02T3GpAC-BySPVSSzmNJyOoZtQpVCQ=.43e6f169-42ef-4e20-ad1f-9085d8a15f12@github.com>

Convert jpackage test library tests in JUnit format. This simplifies running them in IDE.

Added [JUnitAdapter](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a) class to simplify running jpackage test-lib tests with JUnit. `JUnitAdapter.runJPackageTests()` will run the jpackage test-lib test as a JUnit test. The test work directory will be created in a temporary directory supplied by JUnit.

All jpackage test-lib test classes changed to extend `JUnitAdapter`. As they didn't have a default ctor, they were converted accordingly.

Important: Set `test.src` system property if run these tests outside of jtreg (from IDE) or ad-hoc change `@@openJdkDir@@` token with the path to local OpenJDK repo at [JUnitAdapter.java:46](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a).

-------------

Commit messages:
 - Remove TKit.assertEquals(boolean) and TKit.assertNotEquals(boolean). They belong to different branch
 - Minor
 - Undo unrelated change
 - Fix AnnotationsTest to create test work directory in temp directory supplied by JUnit
 - Manual merge
 - Make junit pass
 - Convert helpers-test tests to junit format. It is easier to debug them in IDE this way.

Changes: https://git.openjdk.org/jdk/pull/23615/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23615&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350011
  Stats: 328 lines in 10 files changed: 142 ins; 127 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/23615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23615/head:pull/23615

PR: https://git.openjdk.org/jdk/pull/23615

From asemenyuk at openjdk.org  Thu Feb 13 22:57:24 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 13 Feb 2025 22:57:24 GMT
Subject: RFR: 8350011: Convert jpackage test lib tests in JUnit format
In-Reply-To: <XI1LCl0OXIX0i02T3GpAC-BySPVSSzmNJyOoZtQpVCQ=.43e6f169-42ef-4e20-ad1f-9085d8a15f12@github.com>
References: <XI1LCl0OXIX0i02T3GpAC-BySPVSSzmNJyOoZtQpVCQ=.43e6f169-42ef-4e20-ad1f-9085d8a15f12@github.com>
Message-ID: <NvLppuPLdCtgyurBiXhFzRGUCqgAHcwzJa5sia0otyQ=.3bfefa6b-e6fb-4576-b0eb-5546438dde32@github.com>

On Thu, 13 Feb 2025 14:37:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Convert jpackage test library tests in JUnit format. This simplifies running them in IDE.
> 
> Added [JUnitAdapter](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a) class to simplify running jpackage test-lib tests with JUnit. `JUnitAdapter.runJPackageTests()` will run the jpackage test-lib test as a JUnit test. The test work directory will be created in a temporary directory supplied by JUnit.
> 
> All jpackage test-lib test classes changed to extend `JUnitAdapter`. As they didn't have a default ctor, they were converted accordingly.
> 
> Important: Set `test.src` system property if run these tests outside of jtreg (from IDE) or ad-hoc change `@@openJdkDir@@` token with the path to local OpenJDK repo at [JUnitAdapter.java:46](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a).

@sashamatveev PTAL

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23615#issuecomment-2656897377
PR Comment: https://git.openjdk.org/jdk/pull/23615#issuecomment-2657877501

From jnimeh at openjdk.org  Thu Feb 13 23:50:50 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 13 Feb 2025 23:50:50 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms [v3]
In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
Message-ID: <yXW7xDe1zhc7KasqQMMYlMvCLcgMFBwxU_4gnZrnXtc=.7d3de331-d1d6-4df7-9125-d02ce9c3faf5@github.com>

> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary throws declarations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23566/files
  - new: https://git.openjdk.org/jdk/pull/23566/files/8c16daba..d0c95035

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=01-02

  Stats: 16 lines in 1 file changed: 0 ins; 11 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23566.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23566/head:pull/23566

PR: https://git.openjdk.org/jdk/pull/23566

From almatvee at openjdk.org  Thu Feb 13 23:55:10 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 13 Feb 2025 23:55:10 GMT
Subject: RFR: 8350011: Convert jpackage test lib tests in JUnit format
In-Reply-To: <XI1LCl0OXIX0i02T3GpAC-BySPVSSzmNJyOoZtQpVCQ=.43e6f169-42ef-4e20-ad1f-9085d8a15f12@github.com>
References: <XI1LCl0OXIX0i02T3GpAC-BySPVSSzmNJyOoZtQpVCQ=.43e6f169-42ef-4e20-ad1f-9085d8a15f12@github.com>
Message-ID: <6lyx6LD2ntwT0DPvKSq7Prx-VgLukGYjk07fegEeLeA=.a1bbf914-231e-470e-9fbc-5ed2f59466bc@github.com>

On Thu, 13 Feb 2025 14:37:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Convert jpackage test library tests in JUnit format. This simplifies running them in IDE.
> 
> Added [JUnitAdapter](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a) class to simplify running jpackage test-lib tests with JUnit. `JUnitAdapter.runJPackageTests()` will run the jpackage test-lib test as a JUnit test. The test work directory will be created in a temporary directory supplied by JUnit.
> 
> All jpackage test-lib test classes changed to extend `JUnitAdapter`. As they didn't have a default ctor, they were converted accordingly.
> 
> Important: Set `test.src` system property if run these tests outside of jtreg (from IDE) or ad-hoc replace `@@openJdkDir@@` token with the path to local OpenJDK repo at [JUnitAdapter.java:46](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a).

Looks good with one minor comment.

test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/AnnotationsTest.java line 322:

> 320:             t.printStackTrace(System.err);
> 321:             System.exit(1);
> 322:             return;

Do we need `return` here?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23615#pullrequestreview-2616454453
PR Review Comment: https://git.openjdk.org/jdk/pull/23615#discussion_r1955361325

From asemenyuk at openjdk.org  Fri Feb 14 01:30:15 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Feb 2025 01:30:15 GMT
Subject: RFR: 8350011: Convert jpackage test lib tests in JUnit format
In-Reply-To: <6lyx6LD2ntwT0DPvKSq7Prx-VgLukGYjk07fegEeLeA=.a1bbf914-231e-470e-9fbc-5ed2f59466bc@github.com>
References: <XI1LCl0OXIX0i02T3GpAC-BySPVSSzmNJyOoZtQpVCQ=.43e6f169-42ef-4e20-ad1f-9085d8a15f12@github.com>
 <6lyx6LD2ntwT0DPvKSq7Prx-VgLukGYjk07fegEeLeA=.a1bbf914-231e-470e-9fbc-5ed2f59466bc@github.com>
Message-ID: <YNlR5gHmg4sR9HrJzCYWaVAn2sXVs1qtU5OQ_mP9OGI=.7e672509-c2d4-4f4d-b2d9-c7977f9c3418@github.com>

On Thu, 13 Feb 2025 23:49:24 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Convert jpackage test library tests in JUnit format. This simplifies running them in IDE.
>> 
>> Added [JUnitAdapter](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a) class to simplify running jpackage test-lib tests with JUnit. `JUnitAdapter.runJPackageTests()` will run the jpackage test-lib test as a JUnit test. The test work directory will be created in a temporary directory supplied by JUnit.
>> 
>> All jpackage test-lib test classes changed to extend `JUnitAdapter`. As they didn't have a default ctor, they were converted accordingly.
>> 
>> Important: Set `test.src` system property if run these tests outside of jtreg (from IDE) or ad-hoc replace `@@openJdkDir@@` token with the path to local OpenJDK repo at [JUnitAdapter.java:46](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a).
>
> test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/AnnotationsTest.java line 322:
> 
>> 320:             t.printStackTrace(System.err);
>> 321:             System.exit(1);
>> 322:             return;
> 
> Do we need `return` here?

No. It sneaked in by an accident. Will fix it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23615#discussion_r1955430984

From asemenyuk at openjdk.org  Fri Feb 14 01:40:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Feb 2025 01:40:59 GMT
Subject: RFR: 8350011: Convert jpackage test lib tests in JUnit format [v2]
In-Reply-To: <XI1LCl0OXIX0i02T3GpAC-BySPVSSzmNJyOoZtQpVCQ=.43e6f169-42ef-4e20-ad1f-9085d8a15f12@github.com>
References: <XI1LCl0OXIX0i02T3GpAC-BySPVSSzmNJyOoZtQpVCQ=.43e6f169-42ef-4e20-ad1f-9085d8a15f12@github.com>
Message-ID: <mxnWLO8mzcIs-zbh-nnFkpw_CuM4bWvzm7fuFEmgwQU=.89faec19-1ea3-4214-a8db-6c5cfd9abbc7@github.com>

> Convert jpackage test library tests in JUnit format. This simplifies running them in IDE.
> 
> Added [JUnitAdapter](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a) class to simplify running jpackage test-lib tests with JUnit. `JUnitAdapter.runJPackageTests()` will run the jpackage test-lib test as a JUnit test. The test work directory will be created in a temporary directory supplied by JUnit.
> 
> All jpackage test-lib test classes changed to extend `JUnitAdapter`. As they didn't have a default ctor, they were converted accordingly.
> 
> Important: Set `test.src` system property if run these tests outside of jtreg (from IDE) or ad-hoc replace `@@openJdkDir@@` token with the path to local OpenJDK repo at [JUnitAdapter.java:46](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a).

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant "return"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23615/files
  - new: https://git.openjdk.org/jdk/pull/23615/files/d0c815d8..ae5ddc79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23615&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23615&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23615/head:pull/23615

PR: https://git.openjdk.org/jdk/pull/23615

From almatvee at openjdk.org  Fri Feb 14 01:52:14 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 14 Feb 2025 01:52:14 GMT
Subject: RFR: 8350011: Convert jpackage test lib tests in JUnit format [v2]
In-Reply-To: <mxnWLO8mzcIs-zbh-nnFkpw_CuM4bWvzm7fuFEmgwQU=.89faec19-1ea3-4214-a8db-6c5cfd9abbc7@github.com>
References: <XI1LCl0OXIX0i02T3GpAC-BySPVSSzmNJyOoZtQpVCQ=.43e6f169-42ef-4e20-ad1f-9085d8a15f12@github.com>
 <mxnWLO8mzcIs-zbh-nnFkpw_CuM4bWvzm7fuFEmgwQU=.89faec19-1ea3-4214-a8db-6c5cfd9abbc7@github.com>
Message-ID: <c9ISFhAbjLQ8kfnLvIN-n2TDZn4ZpUGfIH9AfVY_qrs=.293326d2-e665-4d3c-8a70-c4f079ba8684@github.com>

On Fri, 14 Feb 2025 01:40:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Convert jpackage test library tests in JUnit format. This simplifies running them in IDE.
>> 
>> Added [JUnitAdapter](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a) class to simplify running jpackage test-lib tests with JUnit. `JUnitAdapter.runJPackageTests()` will run the jpackage test-lib test as a JUnit test. The test work directory will be created in a temporary directory supplied by JUnit.
>> 
>> All jpackage test-lib test classes changed to extend `JUnitAdapter`. As they didn't have a default ctor, they were converted accordingly.
>> 
>> Important: Set `test.src` system property if run these tests outside of jtreg (from IDE) or ad-hoc replace `@@openJdkDir@@` token with the path to local OpenJDK repo at [JUnitAdapter.java:46](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a).
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant "return"

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23615#pullrequestreview-2616582376

From syan at openjdk.org  Fri Feb 14 01:59:09 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 14 Feb 2025 01:59:09 GMT
Subject: RFR: 8349943: [JMH] Use jvmArgs consistently
In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
Message-ID: <b8OvvYxwXrHlUB4NmasIKwvs_zTBv5Bk-9B6D87Co-g=.c3d869f5-1729-4a25-ab74-33860dff46f7@github.com>

On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'.
> 
> All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency.

LGTM

-------------

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23609#pullrequestreview-2616591288

From syan at openjdk.org  Fri Feb 14 02:28:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 14 Feb 2025 02:28:49 GMT
Subject: RFR: 8350049: [JMH] Float16OperationsBenchmark fails
 java.lang.NoClassDefFoundError
Message-ID: <MAUbF4zfQV2GpI0kgOaRNzNKvFC1sj5FGs49I4PARx0=.436c177b-1061-4e08-8c8c-08c24984faba@github.com>

Hi all,

The newly added JMH tests 'org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark' fails "java.lang.NoClassDefFoundError: jdk/incubator/vector/Float16" by below test command:


make test MICRO="FORK=1;WARMUP_ITER=2" TEST="micro:org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark.test_bm_pattern1"


The `@Fork(jvmArgsPrepend = ..)` in microbenchmarks should replaced as `@Fork(jvmArgs = ..)` since [JDK-8343345](https://bugs.openjdk.org/browse/JDK-8343345). Change has been verified locally, test-fix only, no risk.

-------------

Commit messages:
 - 8350049: [JMH] Float16OperationsBenchmark fails java.lang.NoClassDefFoundError

Changes: https://git.openjdk.org/jdk/pull/23624/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23624&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350049
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23624/head:pull/23624

PR: https://git.openjdk.org/jdk/pull/23624

From duke at openjdk.org  Fri Feb 14 06:29:12 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Fri, 14 Feb 2025 06:29:12 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <dl48ChO5x4futsrtaAjvvlxb4Enekr9S1qFCwQtGVkU=.904d075e-786d-4fe2-980c-f6e9143ba86a@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
 <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>
 <bfT8EMRk6msqkRF32_vQCfZvirTiWsvg0hrOpThz9i4=.1f6626ed-637e-4ff3-827d-f5dc34094910@github.com>
 <A_C2myp2dclvSO5vDmJD4sl9FMoWFCP-j1P7ihltcKc=.c1cb149b-0e33-4d6d-8399-8d6dfe5dbccc@github.com>
 <dl48ChO5x4futsrtaAjvvlxb4Enekr9S1qFCwQtGVkU=.904d075e-786d-4fe2-980c-f6e9143ba86a@github.com>
Message-ID: <fcvrEMeNBT-Cp7C5MR_zsON1WDWouU72qVik-DiN4k0=.7b655123-f2ff-4c12-8d94-0845be867d05@github.com>

On Thu, 13 Feb 2025 22:43:59 GMT, David Beaumont <duke at openjdk.org> wrote:

>Yes, it's certainly something you can deliberately provoke in a way that wasn't possible before.

Setting limit to 1 byte with a large count is a way to make sure each log file contains 0 or 1 log record.  I think this patch breaks that behavior when threads pile up resulting files containing 2 or more log records.  If so that is a breaking incompatibility that should be avoided as some formats only make sense to contain a single record or require post processing to be one record per file.

I'll answer your other questions as soon as I can.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1955603117

From duke at openjdk.org  Fri Feb 14 06:29:14 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Fri, 14 Feb 2025 06:29:14 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <Pj4COzHIujrQIrdVZaPbYc0V4uDR9jBXAAmZ6iDdI0s=.6e94d34f-6d57-4dd1-b232-23c54f4bc4b1@github.com>

On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont <duke at openjdk.org> wrote:

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

src/java.logging/share/classes/java/util/logging/StreamHandler.java line 210:

> 208:                 if (!doneHeader) {
> 209:                     writer.write(getFormatter().getHead(this));
> 210:                     doneHeader = true;

Should getHead and or getTail also not be called while holding lock?

I format a single record in: https://eclipse-ee4j.github.io/angus-mail/docs/api/org.eclipse.angus.mail/org/eclipse/angus/mail/util/logging/CollectorFormatter.html#getTail(java.util.logging.Handler)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1955610861

From kbarrett at openjdk.org  Fri Feb 14 06:29:25 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 14 Feb 2025 06:29:25 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v11]
In-Reply-To: <8Ci27Bl509_2RKPjvYfv2QOdZ7UzP9dNOoTZQIpcrgc=.01e9fbb8-a292-4ad8-97eb-fd9e6e65ffff@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <RQNxtymZk4gFgkve802B8cFKJEPReJwOoclLxHe43PA=.2fb4a5ed-0ef6-4914-b046-3cfab73ef8a0@github.com>
 <L-No84e66ZZFpxf_d3c2ePydWwzVN4-zSf3jY7Jj5GM=.d9dca630-dbe8-456a-8a2e-937bd49e09c8@github.com>
 <9e-kLX5DVX9v0teMvEFIrp6QaKM5g66WCaR8-pOwF2E=.a2be9c9f-804f-4228-9032-535dbcb5ff50@github.com>
 <Qg6LRxXXXTeW4eITWQ_06w1nfpQBrf7irmF_WLsx9Kg=.07000623-4c26-4440-9a27-3c2e804ec14c@github.com>
 <8Ci27Bl509_2RKPjvYfv2QOdZ7UzP9dNOoTZQIpcrgc=.01e9fbb8-a292-4ad8-97eb-fd9e6e65ffff@github.com>
Message-ID: <UoSAIMWk_0iNywNjPb8YBEQ8VumG_spdeVN0QIfVk8U=.30a59433-51df-4dc5-b74e-46f2512f1c87@github.com>

On Mon, 10 Feb 2025 09:28:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @AlanBateman I've not done any work on JDK-8305186.  There has also been discussion about making
>> that function non-private or even public (though with concerns about specification difficulty) for use in
>> places like this.
>> 
>> @shipilev I'm working on a reply, but it might be long-ish.  That outpacing issue for some tests is why this
>> code wasn't switched away from jdk.internal.ref.Cleaner a long time ago.  I'm still looking at it, but I currently
>> don't think the canary provides a reliable solution to that.
>
> I would like to integrate this PR. How are you doing, @kimbarrett? Have you found any major holes in it?

@shipilev I've been having computer issues.  I'm back to looking at this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1955619941

From jpai at openjdk.org  Fri Feb 14 07:36:09 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Feb 2025 07:36:09 GMT
Subject: RFR: 8347946: Add API note that caller should validate/trust
 signers to the getCertificates and getCodeSigners methods of JarEntry and
 JarURLConnection
In-Reply-To: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
References: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
Message-ID: <JAapBTNk4i-NuqEtLvwXqLOnZrWX4Ai3cP4W3GrXSF8=.03aeb483-adc8-4125-86a8-2d33979c84eb@github.com>

On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates.
> 
> 2 other smaller changes:
>  - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead
>  - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`)

Hello Sean, given the assertable change to the API documentation of `java.net.JarURLConnection.getCertificates()`, which now specifies the order of the returned certificates, would this require a CSR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23616#issuecomment-2658490788

From jpai at openjdk.org  Fri Feb 14 07:46:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Feb 2025 07:46:29 GMT
Subject: RFR: 8349909: jdk.internal.jimage.decompressor.ZipDecompressor does
 not close the Inflater in exceptional cases
Message-ID: <FYyDEN1cAcVMOfNC-iIiEIY9_1chS6CA-AvnWIAfNJs=.1bab94e4-f4fc-4e28-8204-7a7eea94ceab@github.com>

Can I please get a review of this change which proposes to properly close the `Inflater` instance used in `jdk.internal.jimage.decompressor.ZipDecompressor.decompress()` method? This addresses https://bugs.openjdk.org/browse/JDK-8349909.

As noted in that issue, in the exceptional case in the `decompress()` method, the `Inflater` instance isn't currently being closed. The commit in this PR uses a try/finally block to `end()` the `Inflater` instance.

Unlike some other places within the JDK, the code in `jdk.internal.jimage.decompressor.ZipDecompressor` is expected to maintain Java 8 (API) compatibility, so this part of the code cannot use the newly introduced `Inflater.close()` method and thus cannot use the try-with-resources statement too.

No new tests have been added given the nature of this change. A noreg label has been added to the JBS issue. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

-------------

Commit messages:
 - 8349909: jdk.internal.jimage.decompressor.ZipDecompressor does not close the Inflater in exceptional cases

Changes: https://git.openjdk.org/jdk/pull/23626/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23626&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349909
  Stats: 11 lines in 1 file changed: 4 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23626/head:pull/23626

PR: https://git.openjdk.org/jdk/pull/23626

From syan at openjdk.org  Fri Feb 14 07:49:20 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 14 Feb 2025 07:49:20 GMT
Subject: RFR: 8349959: Test CR6740048.java passes unexpectedly missing
 CR6740048.xsd
Message-ID: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>

Hi all,

Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes unexpectedly when missing the depentdent file test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a NULL check after call `getResourceAsStream("CR6740048.xsd")`.

This PR do not change the original test logic but make test more robustness. Change has been verified locally, test-fix only, no risk.

-------------

Commit messages:
 - 8349959: Test CR6740048.java passes unexpectedly missing CR6740048.xsd

Changes: https://git.openjdk.org/jdk/pull/23627/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23627&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349959
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23627/head:pull/23627

PR: https://git.openjdk.org/jdk/pull/23627

From pminborg at openjdk.org  Fri Feb 14 09:24:29 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 14 Feb 2025 09:24:29 GMT
Subject: RFR: 8350075: Performance difference between SegmentAllocator methods
Message-ID: <L3R-NcYaP4YXpH-dB2qfh6VeIDQoKIrYyClPRDhVqAY=.2e75cd2f-5d1c-43f5-8776-30ec6b722652@github.com>

This PR proposes to add `@ForceInline` to the `default` methods in `SegmentAllocator` that do not already have it.

-------------

Commit messages:
 - Add @ForceInline to default methods

Changes: https://git.openjdk.org/jdk/pull/23628/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23628&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350075
  Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23628/head:pull/23628

PR: https://git.openjdk.org/jdk/pull/23628

From mcimadamore at openjdk.org  Fri Feb 14 10:17:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Feb 2025 10:17:14 GMT
Subject: RFR: 8350075: Performance difference between SegmentAllocator
 methods
In-Reply-To: <L3R-NcYaP4YXpH-dB2qfh6VeIDQoKIrYyClPRDhVqAY=.2e75cd2f-5d1c-43f5-8776-30ec6b722652@github.com>
References: <L3R-NcYaP4YXpH-dB2qfh6VeIDQoKIrYyClPRDhVqAY=.2e75cd2f-5d1c-43f5-8776-30ec6b722652@github.com>
Message-ID: <2ciDBYPOmbetlf1KtB0adoMJ-wzl-gdfRJPKWNJ46zA=.95b9819d-0810-438e-9c88-2f2bf0973f89@github.com>

On Fri, 14 Feb 2025 09:19:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add `@ForceInline` to the `default` methods in `SegmentAllocator` that do not already have it.

Change is good. There should be a microbenchmark for this.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23628#pullrequestreview-2617339513

From duke at openjdk.org  Fri Feb 14 10:42:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 14 Feb 2025 10:42:10 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <fcvrEMeNBT-Cp7C5MR_zsON1WDWouU72qVik-DiN4k0=.7b655123-f2ff-4c12-8d94-0845be867d05@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
 <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>
 <bfT8EMRk6msqkRF32_vQCfZvirTiWsvg0hrOpThz9i4=.1f6626ed-637e-4ff3-827d-f5dc34094910@github.com>
 <A_C2myp2dclvSO5vDmJD4sl9FMoWFCP-j1P7ihltcKc=.c1cb149b-0e33-4d6d-8399-8d6dfe5dbccc@github.com>
 <dl48ChO5x4futsrtaAjvvlxb4Enekr9S1qFCwQtGVkU=.904d075e-786d-4fe2-980c-f6e9143ba86a@github.com>
 <fcvrEMeNBT-Cp7C5MR_zsON1WDWouU72qVik-DiN4k0=.7b655123-f2ff-4c12-8d94-0845be867d05@github.com>
Message-ID: <wmIgd_-kflkNtl_HeIq8sAgfBAeDGuYvT9xwsl1TnGc=.4e09a4cf-1f9a-441c-9f86-8f37a682757f@github.com>

On Fri, 14 Feb 2025 06:04:09 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> Yes, it's certainly something you can deliberately provoke in a way that wasn't possible before.
>> However I'm not sure that the statement "Old code should only allow at most 2 records ...", while true of the code itself was ever something the docs/specification implied would be true, so I'm doubtful of the validity of asserting anything about it too strongly.
>> 
>> However, the general possibility of having blocking behavior in formatters is interesting. Can you explain more concretely why you did this and what problem it solved, so I can build a better model of the likelihood of this causing issues? Was the blocking just something like "acquire cached localized formatter", where several threads might contend over the cache entry when a new locale is seen? Or was it something more complex?
>
>>Yes, it's certainly something you can deliberately provoke in a way that wasn't possible before.
> 
> Setting limit to 1 byte with a large count is a way to make sure each log file contains 0 or 1 log record.  I think this patch breaks that behavior when threads pile up resulting files containing 2 or more log records.  If so that is a breaking incompatibility that should be avoided as some formats only make sense to contain a single record or require post processing to be one record per file.
> 
> I'll answer your other questions as soon as I can.

I've looked through a lot of github logging properties files and see no evidence that the pattern of use you're suggesting is ever actually done, and any such attempt to force one-log-per-file is entirely unsupported by the existing specification already. Can you give me an example of a real-world case where there's a debug log format which "only makes sense to contain a single record"?
I'm not doubting that you've seen this, but if we're going to complicate the code somewhat over this issue, I need to be able to explain that it's actually likely to affect real-world users, rather than purely hypothetical ones.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1955931154

From duke at openjdk.org  Fri Feb 14 10:49:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 14 Feb 2025 10:49:10 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <wmIgd_-kflkNtl_HeIq8sAgfBAeDGuYvT9xwsl1TnGc=.4e09a4cf-1f9a-441c-9f86-8f37a682757f@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
 <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>
 <bfT8EMRk6msqkRF32_vQCfZvirTiWsvg0hrOpThz9i4=.1f6626ed-637e-4ff3-827d-f5dc34094910@github.com>
 <A_C2myp2dclvSO5vDmJD4sl9FMoWFCP-j1P7ihltcKc=.c1cb149b-0e33-4d6d-8399-8d6dfe5dbccc@github.com>
 <dl48ChO5x4futsrtaAjvvlxb4Enekr9S1qFCwQtGVkU=.904d075e-786d-4fe2-980c-f6e9143ba86a@github.com>
 <fcvrEMeNBT-Cp7C5MR_zsON1WDWouU72qVik-DiN4k0=.7b655123-f2ff-4c12-8d94-0845be867d05@github.com>
 <wmIgd_-kflkNtl_HeIq8sAgfBAeDGuYvT9xwsl1TnGc=.4e09a4cf-1f9a-441c-9f86-8f37a682757f@github.com>
Message-ID: <G0QHgSxgst6mR2wqn6_LdUAb1C5dGfTVcLonEMBbC8Q=.dd75c6a5-9dd4-4605-89c3-fda9b17cd080@github.com>

On Fri, 14 Feb 2025 10:39:54 GMT, David Beaumont <duke at openjdk.org> wrote:

>>>Yes, it's certainly something you can deliberately provoke in a way that wasn't possible before.
>> 
>> Setting limit to 1 byte with a large count is a way to make sure each log file contains 0 or 1 log record.  I think this patch breaks that behavior when threads pile up resulting files containing 2 or more log records.  If so that is a breaking incompatibility that should be avoided as some formats only make sense to contain a single record or require post processing to be one record per file.
>> 
>> I'll answer your other questions as soon as I can.
>
> I've looked through a lot of github logging properties files and see no evidence that the pattern of use you're suggesting is ever actually done, and any such attempt to force one-log-per-file is entirely unsupported by the existing specification already. Can you give me an example of a real-world case where there's a debug log format which "only makes sense to contain a single record"?
> I'm not doubting that you've seen this, but if we're going to complicate the code somewhat over this issue, I need to be able to explain that it's actually likely to affect real-world users, rather than purely hypothetical ones.

The reason I'm pushing back a little here is that the idea of making a "secret handshake" method between StreamHandler and FileHandler isn't a solution for anyone who made their own handler (e.g. an "EncryptedLogFileHandler" that's not a sub-class of FileHandler). The shape of the existing public API makes the additional promise that "post-processing" occurs synchronously with the last log written hard/impossible, and having it so only JDK classes can do this feels a bit wrong to me.

In other words, if you can convince me it's worth doing something to make FileHandler "more synchronized" in this way, I think we should change the API or find another way to allow any third-party sub-classes to also solve the issue. This is why I'm seeking real world examples of actual code that appear to rely on the invariant we're discussing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1955940900

From rgiulietti at openjdk.org  Fri Feb 14 12:56:24 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 14 Feb 2025 12:56:24 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v31]
In-Reply-To: <wmzwqSiFdhqcr8MsGA9FjLjix25b2xbUR6EMldc2k9c=.8f74f6ad-c453-459b-a6ed-8091e1a8794e@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <wmzwqSiFdhqcr8MsGA9FjLjix25b2xbUR6EMldc2k9c=.8f74f6ad-c453-459b-a6ed-8091e1a8794e@github.com>
Message-ID: <C6g8-IW6-Q2V34NFuF8JEl-o4DIRjJ8AdIOu-w8Q2Vg=.8c527aae-fe34-4322-ba48-8367824bc08b@github.com>

On Wed, 4 Dec 2024 14:56:02 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
>> 
>> The main steps of the algorithm are as follows:
>> first argument reduce the value to an integer using the following relations:
>> 
>> x = y * 10 ^ exp
>> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
>> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
>> 
>> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
>> 
>> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   An optimization

Work on this PR also revealed that the previous implementation of `stripTrailingZeros()`, while correct, was underperforming on instances with a long chain of trailing zeros.
In a side PR, @fabioromano1 improved this with [impressive speedups](https://github.com/openjdk/jdk/pull/21323#issuecomment-2403376022) on long chains, and without degradations on smaller cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2659270373

From asemenyuk at openjdk.org  Fri Feb 14 13:15:19 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Feb 2025 13:15:19 GMT
Subject: Integrated: 8350011: Convert jpackage test lib tests in JUnit format
In-Reply-To: <XI1LCl0OXIX0i02T3GpAC-BySPVSSzmNJyOoZtQpVCQ=.43e6f169-42ef-4e20-ad1f-9085d8a15f12@github.com>
References: <XI1LCl0OXIX0i02T3GpAC-BySPVSSzmNJyOoZtQpVCQ=.43e6f169-42ef-4e20-ad1f-9085d8a15f12@github.com>
Message-ID: <S4ufq3V5cII5LlIEm0879p52xZxHZ16GfHOnpwbjPlY=.ef9800f7-a9df-444e-8186-901544487c66@github.com>

On Thu, 13 Feb 2025 14:37:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Convert jpackage test library tests in JUnit format. This simplifies running them in IDE.
> 
> Added [JUnitAdapter](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a) class to simplify running jpackage test-lib tests with JUnit. `JUnitAdapter.runJPackageTests()` will run the jpackage test-lib test as a JUnit test. The test work directory will be created in a temporary directory supplied by JUnit.
> 
> All jpackage test-lib test classes changed to extend `JUnitAdapter`. As they didn't have a default ctor, they were converted accordingly.
> 
> Important: Set `test.src` system property if run these tests outside of jtreg (from IDE) or ad-hoc replace `@@openJdkDir@@` token with the path to local OpenJDK repo at [JUnitAdapter.java:46](https://github.com/openjdk/jdk/pull/23615/files#diff-8719943fb769c04daf413427dc812650763f588cbd0ef6b50cccd11260353c0a).

This pull request has now been integrated.

Changeset: db42a48d
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db42a48dc5d49783545757bd34aeead851f9288e
Stats:     327 lines in 10 files changed: 141 ins; 127 del; 59 mod

8350011: Convert jpackage test lib tests in JUnit format

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/23615

From mullan at openjdk.org  Fri Feb 14 14:01:18 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 14 Feb 2025 14:01:18 GMT
Subject: RFR: 8347946: Add API note that caller should validate/trust
 signers to the getCertificates and getCodeSigners methods of JarEntry and
 JarURLConnection
In-Reply-To: <JAapBTNk4i-NuqEtLvwXqLOnZrWX4Ai3cP4W3GrXSF8=.03aeb483-adc8-4125-86a8-2d33979c84eb@github.com>
References: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
 <JAapBTNk4i-NuqEtLvwXqLOnZrWX4Ai3cP4W3GrXSF8=.03aeb483-adc8-4125-86a8-2d33979c84eb@github.com>
Message-ID: <5-IbyV3FMMgxeor0wNyMY7oern2RMDpHUpFucsEM0wc=.4e43672a-60b6-461c-8a92-d279eb2f5e0e@github.com>

On Fri, 14 Feb 2025 07:33:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Sean, given the assertable change to the API documentation of `java.net.JarURLConnection.getCertificates()`, which now specifies the order of the returned certificates, would this require a CSR?

Yes, I think we should. I'll do that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23616#issuecomment-2659404074

From raffaello.giulietti at oracle.com  Fri Feb 14 14:12:30 2025
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 14 Feb 2025 15:12:30 +0100
Subject: Adding BigDecimal.valueOf(float val) constructor
In-Reply-To: <037964EB-06D4-44B9-8156-080C26AD647D@oracle.com>
References: <CAHOiiwv-hG19KqbJ8Ew7VmuzmMnQ1gb8vxVB_i1EL1VaPL5c2w@mail.gmail.com>
 <7E17AB44-D674-4C0B-AF71-BF92A350A22C@oracle.com>
 <1595099054.75679369.1737671712186.JavaMail.zimbra@univ-eiffel.fr>
 <bb62797c-4bef-40b6-a3a8-2a0af73b8884@oracle.com>
 <CAHOiiwv0pBwPEHMtjbWV5wD0_-61-2zciK1oueitU5q9u8iroA@mail.gmail.com>
 <037964EB-06D4-44B9-8156-080C26AD647D@oracle.com>
Message-ID: <2b1bdf93-67f5-454e-a3fe-dd04e65c0374@oracle.com>

I think that we should definitely improve the documentation of 
valueOf(double) to clarify that passing a float might not be the best 
usage of the method, and suggest using the idiom
	valueOf(Float.toString(f))
as already noted in this thread.

We can hardly add an override of valueOf(float).

Adding something like valueOfFloat(float) could be more viable, but 
personally I doubt that there's much "market demand" for it. Moreover, 
it would kind of break decades long naming conventions.

But more importantly, the models of binary floating-point values, like 
float and double, and of decimal floating-point value, like BD, are 
different.
Wanting to emulate decimal arithmetic with float/double or wishing to 
emulate binary arithmetic with BD is asking for troubles in most cases.
This is to say that one needs to be very careful when mixing 
float/double and BD and converting one value of one model to the other.


Greetings
Raffaello



On 2025-02-13 20:30, Kevin Bourrillion wrote:
> My latest thoughts; please advise if I have misunderstood anything.
> 
> 
>> On Jan 24, 2025, at 3:11?AM, Jan Kowalski <jan7493 at gmail.com> wrote:
>>
>> I'd say that, if it's possible, we should reduce the arithmetic 
>> artifacts, rather than introduce them through not really needed, and 
>> not visible at the first sight, type conversions.
>>
>> ? Do you think introducing such change would be beneficial to simplify 
>> the code, or rather introduce minor precision improvement, while we 
>> still don?t have 100% decimal precision?
> 
> Okay, so what we?re looking for is a way to convert floats to 
> BigDecimals in such a way that `0.1f` comes out the same as `new 
> BigDecimal(?0.1?)`.
> 
> This thread is characterizing that outcome as ?reducing artifacts? and 
> ?improving precision?, which seems fair on the surface, but I believe 
> this is more like an illusion. I think the reason this looks like 
> obvious ?improvement? to us is only because we happen to be using / 
> literals/?in our examples. But for a float value that isn?t a literal, 
> like our friend `0.1f + 0.2f`, I think that the illusion is shattered. I 
> think this ?exposes" that the scale chosen by BD.valueOf(double) is 
> based on an ?artifact? of that value that isn?t really meant to be 
> ?information carried by? the value. (Were we to think the latter way, it 
> makes us think of a float-to-double cast as /losing information/, which 
> feels like nonsense.)
> 
> I think the fact that a new overload would affect current behavior means 
> we need to rule that option out. I don?t think this is a case that can 
> justify that cost. So it would at best have to be a new separately-named 
> method like `valueOfFloat`. So at best this issue will /still/?bite 
> users of `valueOf`, and we would still want the documentation of that 
> method to advise users on what to do instead.
> 
> My feeling is that all we need it to do is advise the user to call 
> `BigDecimal.valueOf(Float.toString(val))`. This is very transparent 
> about what?s really happening. Here the user is intentionally / 
> choosing/?the representation/scale.
> 
> I personally don?t see this as a case where fast-enough benchmark result 
> would justify adding a new method.
> 
> Your thoughts?


From raffaello.giulietti at oracle.com  Fri Feb 14 14:26:29 2025
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 14 Feb 2025 15:26:29 +0100
Subject: Adding BigDecimal.valueOf(float val) constructor
In-Reply-To: <2b1bdf93-67f5-454e-a3fe-dd04e65c0374@oracle.com>
References: <CAHOiiwv-hG19KqbJ8Ew7VmuzmMnQ1gb8vxVB_i1EL1VaPL5c2w@mail.gmail.com>
 <7E17AB44-D674-4C0B-AF71-BF92A350A22C@oracle.com>
 <1595099054.75679369.1737671712186.JavaMail.zimbra@univ-eiffel.fr>
 <bb62797c-4bef-40b6-a3a8-2a0af73b8884@oracle.com>
 <CAHOiiwv0pBwPEHMtjbWV5wD0_-61-2zciK1oueitU5q9u8iroA@mail.gmail.com>
 <037964EB-06D4-44B9-8156-080C26AD647D@oracle.com>
 <2b1bdf93-67f5-454e-a3fe-dd04e65c0374@oracle.com>
Message-ID: <c9c9a762-911f-4e64-8309-ee5d8ea43674@oracle.com>

 > We can hardly add an override of valueOf(float).

correction
We can hardly add an overload of valueOf(float).


On 2025-02-14 15:12, Raffaello Giulietti wrote:
> I think that we should definitely improve the documentation of 
> valueOf(double) to clarify that passing a float might not be the best 
> usage of the method, and suggest using the idiom
>  ????valueOf(Float.toString(f))
> as already noted in this thread.
> 
> We can hardly add an override of valueOf(float).
> 
> Adding something like valueOfFloat(float) could be more viable, but 
> personally I doubt that there's much "market demand" for it. Moreover, 
> it would kind of break decades long naming conventions.
> 
> But more importantly, the models of binary floating-point values, like 
> float and double, and of decimal floating-point value, like BD, are 
> different.
> Wanting to emulate decimal arithmetic with float/double or wishing to 
> emulate binary arithmetic with BD is asking for troubles in most cases.
> This is to say that one needs to be very careful when mixing float/ 
> double and BD and converting one value of one model to the other.
> 
> 
> Greetings
> Raffaello
> 
> 
> 
> On 2025-02-13 20:30, Kevin Bourrillion wrote:
>> My latest thoughts; please advise if I have misunderstood anything.
>>
>>
>>> On Jan 24, 2025, at 3:11?AM, Jan Kowalski <jan7493 at gmail.com> wrote:
>>>
>>> I'd say that, if it's possible, we should reduce the arithmetic 
>>> artifacts, rather than introduce them through not really needed, and 
>>> not visible at the first sight, type conversions.
>>>
>>> ? Do you think introducing such change would be beneficial to 
>>> simplify the code, or rather introduce minor precision improvement, 
>>> while we still don?t have 100% decimal precision?
>>
>> Okay, so what we?re looking for is a way to convert floats to 
>> BigDecimals in such a way that `0.1f` comes out the same as `new 
>> BigDecimal(?0.1?)`.
>>
>> This thread is characterizing that outcome as ?reducing artifacts? and 
>> ?improving precision?, which seems fair on the surface, but I believe 
>> this is more like an illusion. I think the reason this looks like 
>> obvious ?improvement? to us is only because we happen to be using / 
>> literals/?in our examples. But for a float value that isn?t a literal, 
>> like our friend `0.1f + 0.2f`, I think that the illusion is shattered. 
>> I think this ?exposes" that the scale chosen by BD.valueOf(double) is 
>> based on an ?artifact? of that value that isn?t really meant to be 
>> ?information carried by? the value. (Were we to think the latter way, 
>> it makes us think of a float-to-double cast as /losing information/, 
>> which feels like nonsense.)
>>
>> I think the fact that a new overload would affect current behavior 
>> means we need to rule that option out. I don?t think this is a case 
>> that can justify that cost. So it would at best have to be a new 
>> separately-named method like `valueOfFloat`. So at best this issue 
>> will /still/?bite users of `valueOf`, and we would still want the 
>> documentation of that method to advise users on what to do instead.
>>
>> My feeling is that all we need it to do is advise the user to call 
>> `BigDecimal.valueOf(Float.toString(val))`. This is very transparent 
>> about what?s really happening. Here the user is intentionally / 
>> choosing/?the representation/scale.
>>
>> I personally don?t see this as a case where fast-enough benchmark 
>> result would justify adding a new method.
>>
>> Your thoughts?
> 


From mullan at openjdk.org  Fri Feb 14 14:33:10 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 14 Feb 2025 14:33:10 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms [v3]
In-Reply-To: <gUTcgnS02hs66TZGXARtoV9aO-BnUDdfGkuMkCuXv5s=.05b3fc16-80c8-4293-a38c-3a8022165c9c@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
 <YV-zo5wMDpN1Xbtylo2w6lvx1u3ngHbW89Dthc6o28w=.43cb563d-0857-4488-91dd-eca6a1eb0f66@github.com>
 <gUTcgnS02hs66TZGXARtoV9aO-BnUDdfGkuMkCuXv5s=.05b3fc16-80c8-4293-a38c-3a8022165c9c@github.com>
Message-ID: <2VARXTrDTQGfsXEIissc_EWqjZf2m8HZeJ2bse-qnII=.854008de-a31c-4b73-a609-3b2113c20df1@github.com>

On Thu, 13 Feb 2025 22:43:39 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> test/lib/jdk/test/lib/security/CertificateBuilder.java line 462:
>> 
>>> 460:             throws CertificateException, IOException, NoSuchAlgorithmException {
>>> 461: 
>>> 462:         AlgorithmId signAlg;
>> 
>> This variable looks like it is unused now.
>
> It's used on 476 for encoding the AlgorithmIdentifier of the certificate signature, and also on 530 to again provide that same AlgorithmIdentifier encoding in the TBSCertificate strructure.

You mean lines 458 and 466? Yes, I missed that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1956240646

From asemenyuk at openjdk.org  Fri Feb 14 14:38:44 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Feb 2025 14:38:44 GMT
Subject: RFR: 8350098: jpackage test lib erroneously will run methods without
 @Test annotation as tests
Message-ID: <v9H1ZMlFgkIVZgEY_AsxAg1HNcNYgjL_ZHGk9hw7pTE=.549bf283-6004-4bf2-b5b5-0bf6fe0a5fdb@github.com>

Don't consider functions without `jdk.jpackage.test.Annotations.Test` annotation as tests.

Additionally, enhance the functionality of `jdk.jpackage.test.Annotations.ParameterSupplier` annotation: make an empty string the default value. If the method name is empty (the default annotation value), then the name of the parameter supplier method is the same as the name of the annotated method. E.g.: `@Test @ParameterSupplier public void testInteger(int v)` is equivalent to `@Test @ParameterSupplier("testInteger") public void testInteger(int v)`.

-------------

Commit messages:
 - Fix javac error
 - Merge branch 'decouple-junit' into decouple-fix-annotations
 - Merge branch 'master' into decouple-junit
 - Remove redundant "return"
 - Merge branch 'decouple-junit' into decouple-fix-annotations
 - Remove TKit.assertEquals(boolean) and TKit.assertNotEquals(boolean). They belong to different branch
 - Merge branch 'decouple-junit' into decouple-fix-annotations
 - Minor
 - Fix typo
 - Revert "Undo unrelated change"
 - ... and 8 more: https://git.openjdk.org/jdk/compare/db42a48d...1247c84b

Changes: https://git.openjdk.org/jdk/pull/23632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350098
  Stats: 65 lines in 4 files changed: 43 ins; 10 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/23632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23632/head:pull/23632

PR: https://git.openjdk.org/jdk/pull/23632

From asemenyuk at openjdk.org  Fri Feb 14 14:57:12 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Feb 2025 14:57:12 GMT
Subject: RFR: 8350098: jpackage test lib erroneously will run methods
 without @Test annotation as tests
In-Reply-To: <v9H1ZMlFgkIVZgEY_AsxAg1HNcNYgjL_ZHGk9hw7pTE=.549bf283-6004-4bf2-b5b5-0bf6fe0a5fdb@github.com>
References: <v9H1ZMlFgkIVZgEY_AsxAg1HNcNYgjL_ZHGk9hw7pTE=.549bf283-6004-4bf2-b5b5-0bf6fe0a5fdb@github.com>
Message-ID: <TYiU6P9-y9ecnXe3x9BG2XisaydlZZPsvM-PWuDKcnE=.7478f72d-a2e0-4654-a5ca-916db7cacd70@github.com>

On Fri, 14 Feb 2025 14:30:25 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Don't consider functions without `jdk.jpackage.test.Annotations.Test` annotation as tests.
> 
> Additionally, enhance the functionality of `jdk.jpackage.test.Annotations.ParameterSupplier` annotation: make an empty string the default value. If the method name is empty (the default annotation value), then the name of the parameter supplier method is the same as the name of the annotated method. E.g.: `@Test @ParameterSupplier public void testInteger(int v)` is equivalent to `@Test @ParameterSupplier("testInteger") public void testInteger(int v)`.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23632#issuecomment-2659537549

From asemenyuk at openjdk.org  Fri Feb 14 14:58:41 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Feb 2025 14:58:41 GMT
Subject: RFR: 8350102: Decouple jpackage test-lib Executor.Result and Executor
 classes
Message-ID: <sMoAqlXBM8Xvt3zHIdPVHGfo4UopIxK7kOuIpnMLH-I=.45400301-529d-464e-baa8-144a1d0cc3f1@github.com>

8350102: Decouple jpackage test-lib Executor.Result and Executor classes

-------------

Commit messages:
 - Bugfix Executor.createResult() and add Executor.getExecutable()
 - Decouple Executor.Result and Executor classes

Changes: https://git.openjdk.org/jdk/pull/23636/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23636&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350102
  Stats: 48 lines in 3 files changed: 15 ins; 7 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/23636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23636/head:pull/23636

PR: https://git.openjdk.org/jdk/pull/23636

From asemenyuk at openjdk.org  Fri Feb 14 14:58:41 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 14 Feb 2025 14:58:41 GMT
Subject: RFR: 8350102: Decouple jpackage test-lib Executor.Result and
 Executor classes
In-Reply-To: <sMoAqlXBM8Xvt3zHIdPVHGfo4UopIxK7kOuIpnMLH-I=.45400301-529d-464e-baa8-144a1d0cc3f1@github.com>
References: <sMoAqlXBM8Xvt3zHIdPVHGfo4UopIxK7kOuIpnMLH-I=.45400301-529d-464e-baa8-144a1d0cc3f1@github.com>
Message-ID: <o9xJg0kMUMl6nnJNQ9krsQ36qOdXcw5wNXkq6yBinI0=.043fb515-3fa4-48ac-bbcc-2f404193aedb@github.com>

On Fri, 14 Feb 2025 14:52:38 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8350102: Decouple jpackage test-lib Executor.Result and Executor classes

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23636#issuecomment-2659538132

From duke at openjdk.org  Fri Feb 14 15:04:11 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 14 Feb 2025 15:04:11 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <Pj4COzHIujrQIrdVZaPbYc0V4uDR9jBXAAmZ6iDdI0s=.6e94d34f-6d57-4dd1-b232-23c54f4bc4b1@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Pj4COzHIujrQIrdVZaPbYc0V4uDR9jBXAAmZ6iDdI0s=.6e94d34f-6d57-4dd1-b232-23c54f4bc4b1@github.com>
Message-ID: <Xs0Wd1rYekZRiaPHys_89jY4TSXKwBhx8A-iz-jlYtU=.a9e83238-686a-4ef4-8ee0-81b3da941393@github.com>

On Fri, 14 Feb 2025 06:14:34 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> src/java.logging/share/classes/java/util/logging/StreamHandler.java line 210:
> 
>> 208:                 if (!doneHeader) {
>> 209:                     writer.write(getFormatter().getHead(this));
>> 210:                     doneHeader = true;
> 
> Should getHead and or getTail also not be called while holding lock?
> 
> I format a single record in: https://eclipse-ee4j.github.io/angus-mail/docs/api/org.eclipse.angus.mail/org/eclipse/angus/mail/util/logging/CollectorFormatter.html#getTail(java.util.logging.Handler)

Well spotted :) Yes, it's a theoretical risk, but not at the same level as that of log record formatting.

My original draft push of this PR had comments about lock expectations here, but I was asked to not change the JavaDoc on Formatter.

The getHead() and getTail() methods *could* cause deadlock, but only because of code directly associated with their implementation. They don't have any access to a log record (and no reason to have access to log records), so they aren't going to be calling into completely arbitrary user code.

It's also unlikely that a formatter implementation will do a lot of complex work in these methods since, semantically, they are called an arbitrary number of times (according to configuration) and at arbitrary times, so they really cannot meaningfully rely on user runtime data or much beyond things like timestamps and counters.

So while, in theory, it could be an issue, it's an issue that can almost certainly be fixed by the author of the Formatter class itself. This is contrasted with the issue at hand, which is inherent in the handler code and cannot be fixed in any other reasonable way by the user of the logging library.

I'd be happy to move the head/tail acquisition out of the locked regions if it were deemed a risk, but that's never something I've observed as an issue (I spent 10 years doing Java logging stuff and saw the publish() deadlock, but never issues with head/tail stuff). It's also hard to move it out, because tail writing happens in close(), called from flush(), both of which are much more expected to be synchronized, so you'd probably want to get and cache the tail() string when the file was opened.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1956287627

From duke at openjdk.org  Fri Feb 14 15:11:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 14 Feb 2025 15:11:12 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method
In-Reply-To: <Xs0Wd1rYekZRiaPHys_89jY4TSXKwBhx8A-iz-jlYtU=.a9e83238-686a-4ef4-8ee0-81b3da941393@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Pj4COzHIujrQIrdVZaPbYc0V4uDR9jBXAAmZ6iDdI0s=.6e94d34f-6d57-4dd1-b232-23c54f4bc4b1@github.com>
 <Xs0Wd1rYekZRiaPHys_89jY4TSXKwBhx8A-iz-jlYtU=.a9e83238-686a-4ef4-8ee0-81b3da941393@github.com>
Message-ID: <U9dqVBjuudxFSY8JmJJKf2qAa78SJGHAqDncQhf_1T8=.e5a7ca03-f5d5-4eb8-8ef1-2ae70c38ffab@github.com>

On Fri, 14 Feb 2025 15:01:37 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.logging/share/classes/java/util/logging/StreamHandler.java line 210:
>> 
>>> 208:                 if (!doneHeader) {
>>> 209:                     writer.write(getFormatter().getHead(this));
>>> 210:                     doneHeader = true;
>> 
>> Should getHead and or getTail also not be called while holding lock?
>> 
>> I format a single record in: https://eclipse-ee4j.github.io/angus-mail/docs/api/org.eclipse.angus.mail/org/eclipse/angus/mail/util/logging/CollectorFormatter.html#getTail(java.util.logging.Handler)
>
> Well spotted :) Yes, it's a theoretical risk, but not at the same level as that of log record formatting.
> 
> My original draft push of this PR had comments about lock expectations here, but I was asked to not change the JavaDoc on Formatter.
> 
> The getHead() and getTail() methods *could* cause deadlock, but only because of code directly associated with their implementation. They don't have any access to a log record (and no reason to have access to log records), so they aren't going to be calling into completely arbitrary user code.
> 
> It's also unlikely that a formatter implementation will do a lot of complex work in these methods since, semantically, they are called an arbitrary number of times (according to configuration) and at arbitrary times, so they really cannot meaningfully rely on user runtime data or much beyond things like timestamps and counters.
> 
> So while, in theory, it could be an issue, it's an issue that can almost certainly be fixed by the author of the Formatter class itself. This is contrasted with the issue at hand, which is inherent in the handler code and cannot be fixed in any other reasonable way by the user of the logging library.
> 
> I'd be happy to move the head/tail acquisition out of the locked regions if it were deemed a risk, but that's never something I've observed as an issue (I spent 10 years doing Java logging stuff and saw the publish() deadlock, but never issues with head/tail stuff). It's also hard to move it out, because tail writing happens in close(), called from flush(), both of which are much more expected to be synchronized, so you'd probably want to get and cache the tail() string when the file was opened.

As for the example you gave there, that is interesting. Keeping an unformatted log record around for any time after the log statement that created it has exited would be quite problematic (it prevents GC of arbitrary things).

If I were doing some kind of summary tail entry, I'd pull, format (user args) and cache anything I needed out of the log record when I had it, but not keep it around. Then when the tail is written I'd just have what I need ready to go.

But yes, right now, with or without this PR, that code looks like it's got a deadlock risk.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1956296341

From duke at openjdk.org  Fri Feb 14 15:18:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 14 Feb 2025 15:18:56 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v2]
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <ZJr7FEhjhx0kdFyjuyEs_yxSyd8sXHB7LQ_S4_KbGE8=.bb89d580-c325-473f-bdc0-62d79210187a@github.com>

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Reworking FileHandler so rotation occurs synchronously after the last log entry is written.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23491/files
  - new: https://git.openjdk.org/jdk/pull/23491/files/601e88fd..11ba7701

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=00-01

  Stats: 49 lines in 2 files changed: 32 ins; 14 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491

PR: https://git.openjdk.org/jdk/pull/23491

From rriggs at openjdk.org  Fri Feb 14 15:33:10 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Feb 2025 15:33:10 GMT
Subject: RFR: 8138614: (spec str) StringBuffer and StringBuilder methods
 improperly require "new" String to be returned [v2]
In-Reply-To: <iEAmP06a5g2yY0_IoYkWW1O85ko8ep7UCercBBgpXJ4=.6f2a5567-dcd4-4a98-89df-dd6978ecf0f9@github.com>
References: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
 <iEAmP06a5g2yY0_IoYkWW1O85ko8ep7UCercBBgpXJ4=.6f2a5567-dcd4-4a98-89df-dd6978ecf0f9@github.com>
Message-ID: <xfQBayxkAtTaR5By8H49_LI4916sIeaO-AamgbuW2Jk=.86fa0d75-cf7d-4c91-96dd-2c49bcbdb5c1@github.com>

On Thu, 13 Feb 2025 20:51:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> A couple adjustments to the specs for four methods of StringBuilder and StringBuffer so that they no longer require new Strings to be created, just a String with the right contents. No implementation changes. Note that the actual specs (and implementations) are actually in AbstractStringBuilder, and they're inherited by StringBuilder and StringBuffer.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A tiny bit of wordsmithing.

It should be pointed out (in the CSR) that this is aligning the spec with the current implementation, there no compatibility risk to existing programs.
Except for the empty string, neither StringBuilder or StringBuffer is holding a string, but a sequence of characters, so a String is created.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23599#issuecomment-2659630463

From dfuchs at openjdk.org  Fri Feb 14 15:53:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Feb 2025 15:53:13 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v2]
In-Reply-To: <ZJr7FEhjhx0kdFyjuyEs_yxSyd8sXHB7LQ_S4_KbGE8=.bb89d580-c325-473f-bdc0-62d79210187a@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <ZJr7FEhjhx0kdFyjuyEs_yxSyd8sXHB7LQ_S4_KbGE8=.bb89d580-c325-473f-bdc0-62d79210187a@github.com>
Message-ID: <hmGNm2yZANA1s2pJPz_GYB7KXbltiUegYNQn7tE20aA=.28c63519-de37-4515-af7e-8a6feff71a24@github.com>

On Fri, 14 Feb 2025 15:18:56 GMT, David Beaumont <duke at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reworking FileHandler so rotation occurs synchronously after the last log entry is written.

src/java.logging/share/classes/java/util/logging/FileHandler.java line 193:

> 191:             out.write(b);
> 192:             written++;
> 193:             flushOrRotateIfFull();

I don't think that's correct. You don't want to flush and rotate in the middle of publishing a LogRecord. You want to flush and rotate either before or after - but not in the middle.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1956360962

From duke at openjdk.org  Fri Feb 14 16:35:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 14 Feb 2025 16:35:12 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v2]
In-Reply-To: <hmGNm2yZANA1s2pJPz_GYB7KXbltiUegYNQn7tE20aA=.28c63519-de37-4515-af7e-8a6feff71a24@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <ZJr7FEhjhx0kdFyjuyEs_yxSyd8sXHB7LQ_S4_KbGE8=.bb89d580-c325-473f-bdc0-62d79210187a@github.com>
 <hmGNm2yZANA1s2pJPz_GYB7KXbltiUegYNQn7tE20aA=.28c63519-de37-4515-af7e-8a6feff71a24@github.com>
Message-ID: <re0LQW3Q-Q-dsQT8bRckKCb7KN8ahu-Dr0OwZIihETM=.ce4efa6b-1762-470a-9a08-8dfd4f4ea1fa@github.com>

On Fri, 14 Feb 2025 15:50:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reworking FileHandler so rotation occurs synchronously after the last log entry is written.
>
> src/java.logging/share/classes/java/util/logging/FileHandler.java line 193:
> 
>> 191:             out.write(b);
>> 192:             written++;
>> 193:             flushOrRotateIfFull();
> 
> I don't think that's correct. You don't want to flush and rotate in the middle of publishing a LogRecord. You want to flush and rotate either before or after - but not in the middle.

See the comment above about how the only calls to "write()" occur for a complete log entry. This is something we can control in StreamHandler (I'm happy to add a test to verify this if you want though - I'm writing a new StreamHandler test at the moment).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1956423950

From mullan at openjdk.org  Fri Feb 14 16:42:11 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 14 Feb 2025 16:42:11 GMT
Subject: RFR: 8347946: Add API note that caller should validate/trust
 signers to the getCertificates and getCodeSigners methods of JarEntry and
 JarURLConnection
In-Reply-To: <5-IbyV3FMMgxeor0wNyMY7oern2RMDpHUpFucsEM0wc=.4e43672a-60b6-461c-8a92-d279eb2f5e0e@github.com>
References: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
 <JAapBTNk4i-NuqEtLvwXqLOnZrWX4Ai3cP4W3GrXSF8=.03aeb483-adc8-4125-86a8-2d33979c84eb@github.com>
 <5-IbyV3FMMgxeor0wNyMY7oern2RMDpHUpFucsEM0wc=.4e43672a-60b6-461c-8a92-d279eb2f5e0e@github.com>
Message-ID: <phT2daxNSlAJmRixqmX7MRpOiR90QARKe01yj6fVVpI=.40f79e78-a7f5-4772-9fcf-1574dc74c46f@github.com>

On Fri, 14 Feb 2025 13:57:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > Hello Sean, given the assertable change to the API documentation of `java.net.JarURLConnection.getCertificates()`, which now specifies the order of the returned certificates, would this require a CSR?
> 
> Yes, I think we should. I'll do that.

Please review the CSR at https://bugs.openjdk.org/browse/JDK-8350117. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23616#issuecomment-2659794172

From dfuchs at openjdk.org  Fri Feb 14 16:48:21 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Feb 2025 16:48:21 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v2]
In-Reply-To: <re0LQW3Q-Q-dsQT8bRckKCb7KN8ahu-Dr0OwZIihETM=.ce4efa6b-1762-470a-9a08-8dfd4f4ea1fa@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <ZJr7FEhjhx0kdFyjuyEs_yxSyd8sXHB7LQ_S4_KbGE8=.bb89d580-c325-473f-bdc0-62d79210187a@github.com>
 <hmGNm2yZANA1s2pJPz_GYB7KXbltiUegYNQn7tE20aA=.28c63519-de37-4515-af7e-8a6feff71a24@github.com>
 <re0LQW3Q-Q-dsQT8bRckKCb7KN8ahu-Dr0OwZIihETM=.ce4efa6b-1762-470a-9a08-8dfd4f4ea1fa@github.com>
Message-ID: <iEOcN9-diTGN22iNmWL6Q2rAPPI-gzsr9ipRIzIPe5Q=.4f9a0e51-4fc6-4d07-bc06-520d98686e57@github.com>

On Fri, 14 Feb 2025 16:32:08 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.logging/share/classes/java/util/logging/FileHandler.java line 193:
>> 
>>> 191:             out.write(b);
>>> 192:             written++;
>>> 193:             flushOrRotateIfFull();
>> 
>> I don't think that's correct. You don't want to flush and rotate in the middle of publishing a LogRecord. You want to flush and rotate either before or after - but not in the middle.
>
> See the comment above about how the only calls to "write()" occur for a complete log entry. This is something we can control in StreamHandler (I'm happy to add a test to verify this if you want though - I'm writing a new StreamHandler test at the moment).

This sounds fragile to me. I'd rather use a package private method called within the lock to signal that a record has been written.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1956440843

From roland at openjdk.org  Fri Feb 14 16:55:14 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 14 Feb 2025 16:55:14 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
Message-ID: <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>

On Thu, 13 Feb 2025 16:43:22 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> @galderz How sure are that intrinsifying directly is really the right approach?
>> 
>> Maybe the approach via `PhaseIdealLoop::conditional_move` where we know the branching probability is a better one. Though of course knowing the branching probability is no perfect heuristic for how good branch prediction is going to be, but it is at least something.
>> 
>> So I'm wondering if there could be a different approach that sees all the wins you get here, without any of the regressions?
>> 
>> If we are just interested in better vectorization: the current issue is that the auto-vectorizer cannot handle CFG, i.e. we do not yet do if-conversion. But if we had if-conversion, then the inlined CFG of min/max would just be converted to vector CMove (or vector min/max where available) at that point. We can take the branching probabilities into account, just like `PhaseIdealLoop::conditional_move` does - if that is necessary. Of course if-conversion is far away, and we will encounter a lot of issues with branch prediction etc, so I'm scared we might never get there - but I want to try ;)
>> 
>> Do we see any other wins with your patch, that are not due to vectorization, but just scalar code?
>
>> Do we see any other wins with your patch, that are not due to vectorization, but just scalar code?
> 
> I think there are some. 
> 
> The current transformation from the parsed version of min/max to a conditional move to a `Max`/`Min` node depends on the conditional move transformation which has its own set of heuristics and while it happens on simple test cases, that's not necessarily the case on all code shapes. I don't think we want to trust it too much.
> 
> With the intrinsic, the type of the min or max can be narrowed down in a way it can't be whether the code includes control flow or a conditional move. That in turn, once types have propagated, could cause some constant to appear and could be a significant win.
> 
> The `Min`/`Max` nodes are floating nodes. They can hoist out of loop and common reliably in ways that are not guaranteed  otherwise.

> @rwestrel What do you think about the regressions in the scalar cases of this patch?

Shouldn't int `min`/`max` be affected the same way?

I suppose extracting the branch probability from the `MethodData` and attaching it to the `Min`/`Max` nodes is not impossible. I did something like that in the `ScopedValue` PR that you reviewed (and was put on hold). Now, that would be quite a bit of extra complexity for what feels like a corner case.

Another possibility would be to implement `CMove` with branches (https://bugs.openjdk.org/browse/JDK-8340206) or to move the implementation of `MinL`/`MovL` in the ad files and experiment with branches there. 

It seems overall, we likely win more than we loose with this intrinsic, so I would integrate this change as it is and file a bug to keep track of remaining issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2659821025

From lancea at openjdk.org  Fri Feb 14 17:12:11 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 14 Feb 2025 17:12:11 GMT
Subject: RFR: 8349909: jdk.internal.jimage.decompressor.ZipDecompressor
 does not close the Inflater in exceptional cases
In-Reply-To: <FYyDEN1cAcVMOfNC-iIiEIY9_1chS6CA-AvnWIAfNJs=.1bab94e4-f4fc-4e28-8204-7a7eea94ceab@github.com>
References: <FYyDEN1cAcVMOfNC-iIiEIY9_1chS6CA-AvnWIAfNJs=.1bab94e4-f4fc-4e28-8204-7a7eea94ceab@github.com>
Message-ID: <bVLDFwNCCRU_cIA0bz6KXpDHdC1TEaudvVYVgIW0hrs=.69258b2a-28fb-4d6a-a4e6-5f9e7c5a86a6@github.com>

On Fri, 14 Feb 2025 07:41:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to properly close the `Inflater` instance used in `jdk.internal.jimage.decompressor.ZipDecompressor.decompress()` method? This addresses https://bugs.openjdk.org/browse/JDK-8349909.
> 
> As noted in that issue, in the exceptional case in the `decompress()` method, the `Inflater` instance isn't currently being closed. The commit in this PR uses a try/finally block to `end()` the `Inflater` instance.
> 
> Unlike some other places within the JDK, the code in `jdk.internal.jimage.decompressor.ZipDecompressor` is expected to maintain Java 8 (API) compatibility, so this part of the code cannot use the newly introduced `Inflater.close()` method and thus cannot use the try-with-resources statement too.
> 
> No new tests have been added given the nature of this change. A noreg label has been added to the JBS issue. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23626#pullrequestreview-2618379931

From lancea at openjdk.org  Fri Feb 14 17:15:10 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 14 Feb 2025 17:15:10 GMT
Subject: RFR: 8347946: Add API note that caller should validate/trust
 signers to the getCertificates and getCodeSigners methods of JarEntry and
 JarURLConnection
In-Reply-To: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
References: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
Message-ID: <6vbP0qpKwSo0mMMTga3gxh-nfJ7LokJKxSxp_J_t9PU=.8c19f2c2-1e06-4cc4-916d-2596b34ed4dc@github.com>

On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates.
> 
> 2 other smaller changes:
>  - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead
>  - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`)

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23616#pullrequestreview-2618386370

From joehw at openjdk.org  Fri Feb 14 18:14:10 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 14 Feb 2025 18:14:10 GMT
Subject: RFR: 8349699: XSL transform fails with certain UTF-8 characters on
 1024 byte boundaries
In-Reply-To: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
References: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
Message-ID: <3QST3HkianfyXKP88L-89M298dtSrL1sBge7dz3HsU4=.e5ecca2f-1ffe-4689-bf25-3084b791a816@github.com>

On Fri, 14 Feb 2025 00:56:03 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an edge case in the patch for JDK-8207760.

Hello Skara (hopefully this will trigger the notification email).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23623#issuecomment-2659974504

From duke at openjdk.org  Fri Feb 14 18:14:24 2025
From: duke at openjdk.org (duke)
Date: Fri, 14 Feb 2025 18:14:24 GMT
Subject: Withdrawn: 8316804: Gracefully handle the case where --release is not
 specified last
In-Reply-To: <P_31GGK7WG72JM2gXTV9BBgCcX5x-I8N0LH9vhdytGQ=.a40d1769-f299-4b58-9bee-5ad6008dadd4@github.com>
References: <P_31GGK7WG72JM2gXTV9BBgCcX5x-I8N0LH9vhdytGQ=.a40d1769-f299-4b58-9bee-5ad6008dadd4@github.com>
Message-ID: <ssjmtv7RtNk8GBoilQSpWnK5m32-SLQlRKMvrznANeg=.72f47fd3-e1c6-49f9-9498-e7483783b2a1@github.com>

On Wed, 13 Nov 2024 15:24:43 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change for the `jar` tool to gracefully handle the case where `--release` is not specified as the last arguments.
> 
> Prior to this commit, operation modes `-d --describe-module` and `--validate` expected to read the optional `--release` option as a file argument: `jar -d -f a.jar --release 9`
> By adding a hidden GNU-style `--release` option, processing the optional arguments before in those two operation modes, the position is now no longer required to trail behind the `-f --file` option: `jar -d --release 9 -f a.jar`
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/tools/jar                             26    26     0     0
> ==============================
> TEST SUCCESS

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/22079

From lancea at openjdk.org  Fri Feb 14 18:29:10 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 14 Feb 2025 18:29:10 GMT
Subject: RFR: 8349699: XSL transform fails with certain UTF-8 characters on
 1024 byte boundaries
In-Reply-To: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
References: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
Message-ID: <tOvQ7w__pHwHzihga8mEdQlH2z5R9q1andkb-pwtcZk=.41fedc40-bb5b-4a47-bd35-231add192d11@github.com>

On Fri, 14 Feb 2025 00:56:03 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an edge case in the patch for JDK-8207760.

Marked as reviewed by lancea (Reviewer).

test/jaxp/javax/xml/jaxp/unittest/transform/JDK8207760.java line 125:

> 123:         Transformer t = createTransformerFromInputstream(
> 124:                 new ByteArrayInputStream(xsl.getBytes(StandardCharsets.UTF_8)));
> 125:         //t.setOutputProperty(OutputKeys.ENCODING, StandardCharsets.UTF_8.name());

This appears to be un-needed

-------------

PR Review: https://git.openjdk.org/jdk/pull/23623#pullrequestreview-2618533166
PR Review Comment: https://git.openjdk.org/jdk/pull/23623#discussion_r1956563848

From jiangli at openjdk.org  Fri Feb 14 18:37:58 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 14 Feb 2025 18:37:58 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK
Message-ID: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>

Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 

- Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
- Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
- Link with `-ldl` explicitly

The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224

-------------

Commit messages:
 - Remove 'lib' prefix from 'java.dll'.
 - Update copyright header year.
 - - Change to call JNU_GetStringPlatformChars, JNU_ClassString and JNU_NewStringPlatform

Changes: https://git.openjdk.org/jdk/pull/23646/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23646&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350041
  Stats: 61 lines in 2 files changed: 55 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23646/head:pull/23646

PR: https://git.openjdk.org/jdk/pull/23646

From joehw at openjdk.org  Fri Feb 14 19:09:53 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 14 Feb 2025 19:09:53 GMT
Subject: RFR: 8349699: XSL transform fails with certain UTF-8 characters on
 1024 byte boundaries [v2]
In-Reply-To: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
References: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
Message-ID: <aoZs52Ey8nLXT6JqDYoNl_8bXca9ZAfo8GuEUci2_Rg=.f54302ab-a30d-4472-adaf-3ae5da4a7851@github.com>

> Fix an edge case in the patch for JDK-8207760.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  un-needed property removed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23623/files
  - new: https://git.openjdk.org/jdk/pull/23623/files/d58db2ad..98d5dfc3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23623&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23623&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23623/head:pull/23623

PR: https://git.openjdk.org/jdk/pull/23623

From joehw at openjdk.org  Fri Feb 14 19:09:54 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 14 Feb 2025 19:09:54 GMT
Subject: RFR: 8349699: XSL transform fails with certain UTF-8 characters on
 1024 byte boundaries [v2]
In-Reply-To: <tOvQ7w__pHwHzihga8mEdQlH2z5R9q1andkb-pwtcZk=.41fedc40-bb5b-4a47-bd35-231add192d11@github.com>
References: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
 <tOvQ7w__pHwHzihga8mEdQlH2z5R9q1andkb-pwtcZk=.41fedc40-bb5b-4a47-bd35-231add192d11@github.com>
Message-ID: <qVJZT-PkoClAPuLdaehJ3IYNZh9XhMKGi_AQkbXbam8=.8c4e8549-b948-481f-81d8-489edcdedbc7@github.com>

On Fri, 14 Feb 2025 18:25:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   un-needed property removed
>
> test/jaxp/javax/xml/jaxp/unittest/transform/JDK8207760.java line 125:
> 
>> 123:         Transformer t = createTransformerFromInputstream(
>> 124:                 new ByteArrayInputStream(xsl.getBytes(StandardCharsets.UTF_8)));
>> 125:         //t.setOutputProperty(OutputKeys.ENCODING, StandardCharsets.UTF_8.name());
> 
> This appears to be un-needed

Thanks Lance. Removed the un-needed property setting.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23623#discussion_r1956605186

From lancea at openjdk.org  Fri Feb 14 19:43:10 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 14 Feb 2025 19:43:10 GMT
Subject: RFR: 8349699: XSL transform fails with certain UTF-8 characters on
 1024 byte boundaries [v2]
In-Reply-To: <aoZs52Ey8nLXT6JqDYoNl_8bXca9ZAfo8GuEUci2_Rg=.f54302ab-a30d-4472-adaf-3ae5da4a7851@github.com>
References: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
 <aoZs52Ey8nLXT6JqDYoNl_8bXca9ZAfo8GuEUci2_Rg=.f54302ab-a30d-4472-adaf-3ae5da4a7851@github.com>
Message-ID: <d2dn1Trd37Q_XjqwFiEIZTMHenqhnVK_2eRC-ujbLFw=.e12a7a8b-0c43-4463-9c3a-f8a53e3fc08f@github.com>

On Fri, 14 Feb 2025 19:09:53 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fix an edge case in the patch for JDK-8207760.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   un-needed property removed

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23623#pullrequestreview-2618661407

From duke at openjdk.org  Fri Feb 14 19:55:12 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Fri, 14 Feb 2025 19:55:12 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v2]
In-Reply-To: <G0QHgSxgst6mR2wqn6_LdUAb1C5dGfTVcLonEMBbC8Q=.dd75c6a5-9dd4-4605-89c3-fda9b17cd080@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
 <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>
 <bfT8EMRk6msqkRF32_vQCfZvirTiWsvg0hrOpThz9i4=.1f6626ed-637e-4ff3-827d-f5dc34094910@github.com>
 <A_C2myp2dclvSO5vDmJD4sl9FMoWFCP-j1P7ihltcKc=.c1cb149b-0e33-4d6d-8399-8d6dfe5dbccc@github.com>
 <dl48ChO5x4futsrtaAjvvlxb4Enekr9S1qFCwQtGVkU=.904d075e-786d-4fe2-980c-f6e9143ba86a@github.com>
 <fcvrEMeNBT-Cp7C5MR_zsON1WDWouU72qVik-DiN4k0=.7b655123-f2ff-4c12-8d94-0845be867d05@github.com>
 <wmIgd_-kflkNtl_HeIq8sAgfBAeDGuYvT9xwsl1TnGc=.4e09a4cf-1f9a-441c-9f86-8f37a682757f@github.com>
 <G0QHgSxgst6mR2wqn6_LdUAb1C5dGfTVcLonEMBbC8Q=.dd75c6a5-9dd4-4605-89c3-fda9b17cd080@github.com>
Message-ID: <T6tLX_u6tuehydDgOk-Zy90LEIsKMBVHyAtukZgZETo=.dcfd7512-360d-4f51-8b49-7d42199aa6d7@github.com>

On Fri, 14 Feb 2025 10:46:08 GMT, David Beaumont <duke at openjdk.org> wrote:

>> I've looked through a lot of github logging properties files and see no evidence that the pattern of use you're suggesting is ever actually done, and any such attempt to force one-log-per-file is entirely unsupported by the existing specification already. Can you give me an example of a real-world case where there's a debug log format which "only makes sense to contain a single record"?
>> I'm not doubting that you've seen this, but if we're going to complicate the code somewhat over this issue, I need to be able to explain that it's actually likely to affect real-world users, rather than purely hypothetical ones.
>
> The reason I'm pushing back a little here is that the idea of making a "secret handshake" method between StreamHandler and FileHandler isn't a solution for anyone who made their own handler (e.g. an "EncryptedLogFileHandler" that's not a sub-class of FileHandler). The shape of the existing public API makes the additional promise that "post-processing" occurs synchronously with the last log written hard/impossible, and having it so only JDK classes can do this feels a bit wrong to me.
> 
> In other words, if you can convince me it's worth doing something to make FileHandler "more synchronized" in this way, I think we should change the API or find another way to allow any third-party sub-classes to also solve the issue. This is why I'm seeking real world examples of actual code that appear to rely on the invariant we're discussing.

>I've looked through a lot of github logging properties files and see no evidence that the pattern of use...

Closed source GOTS/COTS products that require troubleshooting require using all of the logging API features when other solutions are forbidden for non-tech reasons.

To the point though, limit one with a count makes FileHandler work like the MemoryHandler in that at the end of say a batch run you have exactly the last N records in the form of N files.  That is a feature.

>The reason I'm pushing back a little here is that the idea of making a "secret handshake"

The behavior is what i care about not the implementation.  I would rather focus on fitting your change and retain old behavior. Behaviorly, i think deadlock can be fixed with retaining existing log rollover behavior. Secret handshake off the table then. Done and dead.

New idea. All JDK subclass of StreamHandler call flush.

1. Put rotate check in FileHandler::flush
2. Make StreamHandler call flush while holding lock.
3. Remove explicit flush call in subclasses.
4. Add auto flush property to StreamHandler, default false.
5. Set auto flush true in subclass.


>..."EncryptedLogFileHandler" that's not a sub-class of FileHandler.

That example does apply because if it is not a FileHandler there is no check to call rotate method.  What am I missing?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1956648922

From naoto at openjdk.org  Fri Feb 14 20:01:16 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 14 Feb 2025 20:01:16 GMT
Subject: RFR: 8349699: XSL transform fails with certain UTF-8 characters on
 1024 byte boundaries [v2]
In-Reply-To: <aoZs52Ey8nLXT6JqDYoNl_8bXca9ZAfo8GuEUci2_Rg=.f54302ab-a30d-4472-adaf-3ae5da4a7851@github.com>
References: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
 <aoZs52Ey8nLXT6JqDYoNl_8bXca9ZAfo8GuEUci2_Rg=.f54302ab-a30d-4472-adaf-3ae5da4a7851@github.com>
Message-ID: <JcnZzZcxsft9LFBh6mibjIJJybhthduDAVZegsgy4bA=.443969ab-fe63-4159-8760-e6b0f7aa02c0@github.com>

On Fri, 14 Feb 2025 19:09:53 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fix an edge case in the patch for JDK-8207760.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   un-needed property removed

test/jaxp/javax/xml/jaxp/unittest/transform/JDK8207760.java line 112:

> 110:     public final void testBug8349699() throws Exception {
> 111:         String xs = "x".repeat(1017);
> 112:         String expected = xs + "\uD835\uDF03\uD835\uDF00\uD835\uDF00\uD835\uDF00\uD835\uDF00";

Would it be meaningful if we provided invalid sequences e.g, high/high and or low/low at the boundary to see if the logic successfully detects them?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23623#discussion_r1956652456

From almatvee at openjdk.org  Fri Feb 14 22:48:10 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 14 Feb 2025 22:48:10 GMT
Subject: RFR: 8350098: jpackage test lib erroneously will run methods
 without @Test annotation as tests
In-Reply-To: <v9H1ZMlFgkIVZgEY_AsxAg1HNcNYgjL_ZHGk9hw7pTE=.549bf283-6004-4bf2-b5b5-0bf6fe0a5fdb@github.com>
References: <v9H1ZMlFgkIVZgEY_AsxAg1HNcNYgjL_ZHGk9hw7pTE=.549bf283-6004-4bf2-b5b5-0bf6fe0a5fdb@github.com>
Message-ID: <IpZ0yo4m3XbxCCa_wZSMaCZOHEevwzgnTSuBDwzMOZ4=.0e7d2926-80a0-4e6f-8fe2-c8157add2e8d@github.com>

On Fri, 14 Feb 2025 14:30:25 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Don't consider functions without `jdk.jpackage.test.Annotations.Test` annotation as tests.
> 
> Additionally, enhance the functionality of `jdk.jpackage.test.Annotations.ParameterSupplier` annotation: make an empty string the default value. If the method name is empty (the default annotation value), then the name of the parameter supplier method is the same as the name of the annotated method. E.g.: `@Test @ParameterSupplier public void testInteger(int v)` is equivalent to `@Test @ParameterSupplier("testInteger") public void testInteger(int v)`.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23632#pullrequestreview-2618944131

From almatvee at openjdk.org  Fri Feb 14 22:57:11 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 14 Feb 2025 22:57:11 GMT
Subject: RFR: 8350102: Decouple jpackage test-lib Executor.Result and
 Executor classes
In-Reply-To: <sMoAqlXBM8Xvt3zHIdPVHGfo4UopIxK7kOuIpnMLH-I=.45400301-529d-464e-baa8-144a1d0cc3f1@github.com>
References: <sMoAqlXBM8Xvt3zHIdPVHGfo4UopIxK7kOuIpnMLH-I=.45400301-529d-464e-baa8-144a1d0cc3f1@github.com>
Message-ID: <tVnrP_948t6fgxzj_dpqS-h5RmVX1IkbSoRTXyxd3hs=.ad68db57-e441-4ffb-8114-ff07381deff1@github.com>

On Fri, 14 Feb 2025 14:52:38 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8350102: Decouple jpackage test-lib Executor.Result and Executor classes

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23636#pullrequestreview-2618958519

From fabian at buildbuddy.io  Sat Feb 15 12:15:26 2025
From: fabian at buildbuddy.io (Fabian Meumertzheim)
Date: Sat, 15 Feb 2025 13:15:26 +0100
Subject: JDK-8072840: Presizing for Stream Collectors
In-Reply-To: <MW4PR10MB5774BFFCD72E859A29A24CF8FFFF2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAHY-eHsUqc905OqqcYXsuVZjeM+A81OOV2K7CsJ1zg8uc4cPOQ@mail.gmail.com>
 <9288FDCA-0984-487B-9426-559CE9EA5632@oracle.com>
 <MW4PR10MB5774BFFCD72E859A29A24CF8FFFF2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAHY-eHuzqNuad8Kt9s7N5ipMVutS0b6JMaavZ-+AE-VgF9ESzg@mail.gmail.com>

Thanks for your feedback and for making me aware of the complications
around Gatherers.

I will also put more thought into how this could work for Gatherers.

On Thu, Feb 13, 2025, 23:31 Viktor Klang <viktor.klang at oracle.com> wrote:

> Indeed. I hope I didn't sound discouraging about the possibility to
> propagate the stream size information.
>
> I merely want to emphasize that it may necessitate a slightly broader take
> on the problem of propagation of stream-instance metadata, especially in
> the face of Gatherers becoming a finalized feature.
>
> It's great that you started this conversation, Fabian!
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Paul
> Sandoz <paul.sandoz at oracle.com>
> *Sent:* Thursday, 13 February 2025 20:18
> *To:* Fabian Meumertzheim <fabian at buildbuddy.io>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: JDK-8072840: Presizing for Stream Collectors
>
> Hi Fabian,
>
> Thanks for sharing and reaching out with the idea before getting too
> beholden to it.
>
> I logged this is quite a while ago. It seemed like a possible good idea at
> the time, although I never liked the duplication of suppliers. I have
> become less enthusiastic overtime, especially so as Gatherers have been
> added. (Gatherer is the underlying primitive we could not find when we were
> furiously developing streams and meeting the Java 8 deadline.) My sense is
> if we are going to address we need to think more broadly about Gatherers.
> And, Viktor being the lead on Gatherers has a good take on where this might
> head.
>
> Paul.
>
> > On Feb 12, 2025, at 2:09?AM, Fabian Meumertzheim <fabian at buildbuddy.io>
> wrote:
> >
> > As an avid user of Guava's ImmutableCollections, I have been
> > interested in ways to close the efficiency gap between the built-in
> > `Stream#toList()` and third-party `Collector` implementations such as
> > `ImmutableList#toImmutableList()`. I've found the biggest problem to
> > be the lack of sizing information in `Collector`s, which led to me to
> > draft a solution to JDK-8072840:
> > https://github.com/openjdk/jdk/pull/23461
> >
> > The benchmark shows pretty significant gains for sized streams that
> > mostly reshape data (e.g. slice records or turn a list into a map by
> > associating keys), which I've found to be a pretty common use case.
> >
> > Before I formally send out the PR for review, I would like to gather
> > feedback on the design aspects of it (rather than the exact
> > implementation). I will thus leave it in draft mode for now, but
> > invite anyone to comment on it or on this thread.
> >
> > Fabian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250215/a3179de9/attachment.htm>

From asemenyuk at openjdk.org  Sat Feb 15 14:34:20 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 15 Feb 2025 14:34:20 GMT
Subject: Integrated: 8350098: jpackage test lib erroneously will run methods
 without @Test annotation as tests
In-Reply-To: <v9H1ZMlFgkIVZgEY_AsxAg1HNcNYgjL_ZHGk9hw7pTE=.549bf283-6004-4bf2-b5b5-0bf6fe0a5fdb@github.com>
References: <v9H1ZMlFgkIVZgEY_AsxAg1HNcNYgjL_ZHGk9hw7pTE=.549bf283-6004-4bf2-b5b5-0bf6fe0a5fdb@github.com>
Message-ID: <Ty6tDBm6YaqCKT_kVLbvuFGnyCUe3Z5sFba1QeckAhQ=.9fe7998c-b7d3-4214-b46d-58b8a5d6066f@github.com>

On Fri, 14 Feb 2025 14:30:25 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Don't consider functions without `jdk.jpackage.test.Annotations.Test` annotation as tests.
> 
> Additionally, enhance the functionality of `jdk.jpackage.test.Annotations.ParameterSupplier` annotation: make an empty string the default value. If the method name is empty (the default annotation value), then the name of the parameter supplier method is the same as the name of the annotated method. E.g.: `@Test @ParameterSupplier public void testInteger(int v)` is equivalent to `@Test @ParameterSupplier("testInteger") public void testInteger(int v)`.

This pull request has now been integrated.

Changeset: 5cf11324
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cf11324afdeed0189e0491845a7ffe78c7c1e13
Stats:     65 lines in 4 files changed: 43 ins; 10 del; 12 mod

8350098: jpackage test lib erroneously will run methods without @Test annotation as tests

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/23632

From forax at univ-mlv.fr  Sat Feb 15 14:44:09 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 15 Feb 2025 15:44:09 +0100 (CET)
Subject: JDK-8072840: Presizing for Stream Collectors
In-Reply-To: <MW4PR10MB5774BFFCD72E859A29A24CF8FFFF2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAHY-eHsUqc905OqqcYXsuVZjeM+A81OOV2K7CsJ1zg8uc4cPOQ@mail.gmail.com>
 <9288FDCA-0984-487B-9426-559CE9EA5632@oracle.com>
 <MW4PR10MB5774BFFCD72E859A29A24CF8FFFF2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <2128797827.112041113.1739630649423.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Paul Sandoz" <paul.sandoz at oracle.com>, "Fabian Meumertzheim"
> <fabian at buildbuddy.io>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Thursday, February 13, 2025 11:30:59 PM
> Subject: Re: JDK-8072840: Presizing for Stream Collectors

> Indeed. I hope I didn't sound discouraging about the possibility to propagate
> the stream size information.

> I merely want to emphasize that it may necessitate a slightly broader take on
> the problem of propagation of stream-instance metadata, especially in the face
> of Gatherers becoming a finalized feature.

We already have an abstraction for propagating metadata, it's the query part of Spliterator (characteristics/estimateSize/comparator etc, technically all abstract methods that does not starts with "try"). 
For a Gatherer, we need a way to say if a characteristics is preserved or removed. 
For a collector, we need a way to have a supplier that takes a Spliterator (a synthetic one, not the one that powers the actual stream) so the characteristics can be queried. 

> It's great that you started this conversation, Fabian!

> Cheers,
> ?

regards, 
R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Paul Sandoz
> <paul.sandoz at oracle.com>
> Sent: Thursday, 13 February 2025 20:18
> To: Fabian Meumertzheim <fabian at buildbuddy.io>
> Cc: core-libs-dev <core-libs-dev at openjdk.org>
> Subject: Re: JDK-8072840: Presizing for Stream Collectors
> Hi Fabian,

> Thanks for sharing and reaching out with the idea before getting too beholden to
> it.

> I logged this is quite a while ago. It seemed like a possible good idea at the
> time, although I never liked the duplication of suppliers. I have become less
> enthusiastic overtime, especially so as Gatherers have been added. (Gatherer is
> the underlying primitive we could not find when we were furiously developing
> streams and meeting the Java 8 deadline.) My sense is if we are going to
> address we need to think more broadly about Gatherers. And, Viktor being the
> lead on Gatherers has a good take on where this might head.

> Paul.

> > On Feb 12, 2025, at 2:09 AM, Fabian Meumertzheim <fabian at buildbuddy.io> wrote:

> > As an avid user of Guava's ImmutableCollections, I have been
> > interested in ways to close the efficiency gap between the built-in
> > `Stream#toList()` and third-party `Collector` implementations such as
> > `ImmutableList#toImmutableList()`. I've found the biggest problem to
> > be the lack of sizing information in `Collector`s, which led to me to
> > draft a solution to JDK-8072840:
>> [ https://github.com/openjdk/jdk/pull/23461 |
> > https://github.com/openjdk/jdk/pull/23461 ]

> > The benchmark shows pretty significant gains for sized streams that
> > mostly reshape data (e.g. slice records or turn a list into a map by
> > associating keys), which I've found to be a pretty common use case.

> > Before I formally send out the PR for review, I would like to gather
> > feedback on the design aspects of it (rather than the exact
> > implementation). I will thus leave it in draft mode for now, but
> > invite anyone to comment on it or on this thread.

> > Fabian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250215/e09d9f89/attachment.htm>

From jpai at openjdk.org  Sat Feb 15 15:27:09 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 15 Feb 2025 15:27:09 GMT
Subject: RFR: 8347946: Add API note that caller should validate/trust
 signers to the getCertificates and getCodeSigners methods of JarEntry and
 JarURLConnection
In-Reply-To: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
References: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
Message-ID: <AhStz-BYLkSamu1Wm1w4ycjpAF4H2FrDNA_6i-qgGpU=.9658f499-ee39-4ffc-95a1-34c2c04000f0@github.com>

On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates.
> 
> 2 other smaller changes:
>  - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead
>  - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`)

Thank you Sean, this looks good to me. I've reviewed the CSR as well.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23616#pullrequestreview-2619433656

From lmesnik at openjdk.org  Sat Feb 15 19:48:45 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 15 Feb 2025 19:48:45 GMT
Subject: RFR: 8350151: Support requires property to filer tests incompatible
 with --enable-preview
Message-ID: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>

It might be useful to be able to run testing with --enable-preview for feature development. The tests incompatible with this mode must be filtered out.

I chose name 'java.enablePreview' , because it is more java property than vm or jdk. And 'enablePreview' to be similar with jtreg tag. 

Tested by running all test suites, and verifying that test is correctly selected.
There are more tests incompatible with --enable-preview, will mark them in the following bug.

-------------

Commit messages:
 - Update VPProps

Changes: https://git.openjdk.org/jdk/pull/23653/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23653&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350151
  Stats: 27 lines in 5 files changed: 19 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/23653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23653/head:pull/23653

PR: https://git.openjdk.org/jdk/pull/23653

From acobbs at openjdk.org  Sat Feb 15 21:27:56 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 15 Feb 2025 21:27:56 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v12]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into SuppressWarningsCleanup-core-libs to fix conflicts.
 - Remove a few more unnecessary suppressions.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Update @LastModified tags.
 - Revert changes under src/java.desktop (to be moved into a separate PR).
 - Bump copyright year to 2025.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove more unnecessary suppressions.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove more unnecessary @SuppressWarnings annotations.
 - ... and 12 more: https://git.openjdk.org/jdk/compare/ba281196...340ca514

-------------

Changes: https://git.openjdk.org/jdk/pull/21852/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=11
  Stats: 211 lines in 93 files changed: 0 ins; 90 del; 121 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

PR: https://git.openjdk.org/jdk/pull/21852

From jpai at openjdk.org  Sun Feb 16 11:50:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 16 Feb 2025 11:50:50 GMT
Subject: RFR: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
Message-ID: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>

Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes?

As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`.

The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes.

I'll draft a CSR once we agree on the proposed text.

-------------

Commit messages:
 - update DeflaterInputStream and InflaterInputStream
 - 8066583: DeflaterOutputStream and InflaterOutputStream should explain responsibility for freeing resources

Changes: https://git.openjdk.org/jdk/pull/23655/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8066583
  Stats: 81 lines in 4 files changed: 74 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23655/head:pull/23655

PR: https://git.openjdk.org/jdk/pull/23655

From jpai at openjdk.org  Sun Feb 16 12:48:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 16 Feb 2025 12:48:54 GMT
Subject: RFR: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
 [v2]
In-Reply-To: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
Message-ID: <US6S889qKyKtHnZ-YpxkJ2CdefzaLvHD9bS6hdhmIy0=.e4620d80-53ed-489d-bb75-ec1a69402194@github.com>

> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`.
> 
> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes.
> 
> I'll draft a CSR once we agree on the proposed text.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  add tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23655/files
  - new: https://git.openjdk.org/jdk/pull/23655/files/69255115..102b04a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23655&range=00-01

  Stats: 187 lines in 2 files changed: 186 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23655/head:pull/23655

PR: https://git.openjdk.org/jdk/pull/23655

From jpai at openjdk.org  Sun Feb 16 12:48:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 16 Feb 2025 12:48:54 GMT
Subject: RFR: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
In-Reply-To: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
Message-ID: <tWexmLKqij5R6NKsUWtap_bUMsADG8AGYRUvFJeqnMM=.fd8bb8cc-69a1-40d0-b259-5a42597cb46d@github.com>

On Sun, 16 Feb 2025 11:44:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`.
> 
> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes.
> 
> I'll draft a CSR once we agree on the proposed text.

There are one or two places in existing jtreg tests where this behaviour is already verified, but they are not exhaustive. So I've updated a couple of existing test classes to include new test methods to verify the expectation of all these constructors. The tests continue to pass.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23655#issuecomment-2661415933

From jpai at openjdk.org  Mon Feb 17 05:53:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Feb 2025 05:53:10 GMT
Subject: RFR: 8349909: jdk.internal.jimage.decompressor.ZipDecompressor
 does not close the Inflater in exceptional cases
In-Reply-To: <FYyDEN1cAcVMOfNC-iIiEIY9_1chS6CA-AvnWIAfNJs=.1bab94e4-f4fc-4e28-8204-7a7eea94ceab@github.com>
References: <FYyDEN1cAcVMOfNC-iIiEIY9_1chS6CA-AvnWIAfNJs=.1bab94e4-f4fc-4e28-8204-7a7eea94ceab@github.com>
Message-ID: <uMZc-QBByYcPitFG0eD63kra8VBkVx1Ax-LSBzrQ3-M=.96ff5fd7-74a3-435f-8451-49d62f59d164@github.com>

On Fri, 14 Feb 2025 07:41:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to properly close the `Inflater` instance used in `jdk.internal.jimage.decompressor.ZipDecompressor.decompress()` method? This addresses https://bugs.openjdk.org/browse/JDK-8349909.
> 
> As noted in that issue, in the exceptional case in the `decompress()` method, the `Inflater` instance isn't currently being closed. The commit in this PR uses a try/finally block to `end()` the `Inflater` instance.
> 
> Unlike some other places within the JDK, the code in `jdk.internal.jimage.decompressor.ZipDecompressor` is expected to maintain Java 8 (API) compatibility, so this part of the code cannot use the newly introduced `Inflater.close()` method and thus cannot use the try-with-resources statement too.
> 
> No new tests have been added given the nature of this change. A noreg label has been added to the JBS issue. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

Thank you Lance for the review. tier testing with this change has completed without any related failures.

Alan @AlanBateman, would it be OK to integrate this one?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23626#pullrequestreview-2620084610

From duke at openjdk.org  Mon Feb 17 06:44:11 2025
From: duke at openjdk.org (Nicole Xu)
Date: Mon, 17 Feb 2025 06:44:11 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <52HO_iL9asn1huCdJj82R1AwF1w8ON9HZetrdc9rQyQ=.28e137e0-a7f7-4839-a3e7-eda4f8a6c4f5@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <x9ETYwOSiE2ZfaP4xus4S6WppTevakAr0hHsRlA7YF8=.a22172e1-e5b5-42f9-9d92-2df2e09fdb05@github.com>
 <52HO_iL9asn1huCdJj82R1AwF1w8ON9HZetrdc9rQyQ=.28e137e0-a7f7-4839-a3e7-eda4f8a6c4f5@github.com>
Message-ID: <Zzk64psydzXMRGpewo7BcvKmqBOwFL5cT0kgkXvY6GI=.b0def6d9-53ec-4be7-af67-d91354135546@github.com>

On Thu, 13 Feb 2025 12:09:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/jdk/incubator/vector/MaskedLogicOpts.java line 122:
>> 
>>> 120:     @Setup(Level.Invocation)
>>> 121:     public void init_per_invoc() {
>>> 122:         int512_arr_idx = (int512_arr_idx + 16) & (ARRAYLEN-1);
>> 
>> Benchmark assumes that ARRAYLEN is a POT value, thus it will also be good to use the modulous operator for rounding here, it will be expensive but will not impact the performance of the Benchmarking kernels.
>
> Please try with following command line
> `java -jar target/benchmarks.jar -f 1 -i 2 -wi 1 -w 30 -p ARRAYLEN=30 MaskedLogic`

Thanks for pointing that out. Typically, ARRAYLEN is almost always a POT value, which is also assumed by many other benchmarks. Are we realistically going to test with an ARRAYLEN of 30? 

I think the POT assumption is reasonable for our purposes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22963#discussion_r1957691283

From duke at openjdk.org  Mon Feb 17 06:44:12 2025
From: duke at openjdk.org (Nicole Xu)
Date: Mon, 17 Feb 2025 06:44:12 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <x9ETYwOSiE2ZfaP4xus4S6WppTevakAr0hHsRlA7YF8=.a22172e1-e5b5-42f9-9d92-2df2e09fdb05@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <x9ETYwOSiE2ZfaP4xus4S6WppTevakAr0hHsRlA7YF8=.a22172e1-e5b5-42f9-9d92-2df2e09fdb05@github.com>
Message-ID: <FIjeAUr_eL-jqYTu3JlcMS-qeVgUGzakrZ58BLGgN50=.51e9e550-2154-4fd0-ae44-f4a451c3f9cb@github.com>

On Thu, 13 Feb 2025 11:51:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86 and AArch64 with the following error:
>> 
>> 
>> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
>> 
>> 
>> The variable `long256_arr_idx` is misused when indexing  'LongVector l2, l3, l4, l5' in function `maskedLogicOperationsLongKernel()`. 'long256_arr_idx' increases by 4 every time the benchmark runs and ensures the incremented value remains within the bounds of the array. However, for `LongVector.SPECIES_512`, it loads 8 numbers from the array each time the benchmark runs, resulting in an out-of-range indexing issue.
>> 
>> Hence, we revised the index variables from `long256_arr_idx` to `long512_arr_idx`, which has a stride of 8, to ensure that the loaded vector is inside of the array boundary for all vector species. This is also consistent with other kernel functions.
>> 
>> Additionally, some defined but unused variables have been removed.
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/MaskedLogicOpts.java line 126:
> 
>> 124:     }
>> 125: 
>> 126:     @CompilerControl(CompilerControl.Mode.INLINE)
> 
> By making the index hop over 16 ints or 8 longs we may leave gaps in between for 128-bit and 256-bit species, this will unnecessarily include the noise due to cache misses or (on some targets) prefetching additional cache lines which are not usable, thereby impacting the crispness of microbenchmark.

Thanks, @jatin-bhateja, for your thorough review.

Yes, you're right, the current design does introduce gaps when accessing the data. And other cases in this suite are also designed in a similar way. I am wondering if you're interested in refactoring the code to address this more comprehensively.

The primary goal of this pull request is to address an out-of-bounds issue that was blocking our tests. We aimed to ensure all test cases pass and become unblocked. Additionally, our available hardware resources limit our ability to rigorously test a wide range of scenarios at this time.

Therefore, we opted to maintain consistency with the existing logic in other cases within the suite and simply fix the crash issue. This approach allows us to unblock the current tests and keep things moving for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22963#discussion_r1957668625

From alanb at openjdk.org  Mon Feb 17 08:31:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Feb 2025 08:31:15 GMT
Subject: RFR: 8350151: Support requires property to filer tests
 incompatible with --enable-preview
In-Reply-To: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
References: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
Message-ID: <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com>

On Sat, 15 Feb 2025 19:43:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> It might be useful to be able to run testing with --enable-preview for feature development. The tests incompatible with this mode must be filtered out.
> 
> I chose name 'java.enablePreview' , because it is more java property than vm or jdk. And 'enablePreview' to be similar with jtreg tag. 
> 
> Tested by running all test suites, and verifying that test is correctly selected.
> There are more tests incompatible with --enable-preview, will mark them in the following bug.

test/jdk/java/lang/System/SecurityManagerWarnings.java line 28:

> 26:  * @bug 8266459 8268349 8269543 8270380
> 27:  * @summary check various warnings
> 28:  * @requires !java.enablePreview

What it the reason that this. test failures with --enable-preview?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23653#discussion_r1957804120

From epeter at openjdk.org  Mon Feb 17 08:40:17 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 17 Feb 2025 08:40:17 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
Message-ID: <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>

On Fri, 14 Feb 2025 16:52:17 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> I suppose extracting the branch probability from the MethodData and attaching it to the Min/Max nodes is not impossible.

That is basically what `PhaseIdealLoop::conditional_move` already does, right? It detects the diamond and converts it to `CMove`. We could special case for `min / max`, and then we'd have the probability for the branch, which we could store at the node.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2662409450

From roland at openjdk.org  Mon Feb 17 08:47:22 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 17 Feb 2025 08:47:22 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
Message-ID: <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>

On Mon, 17 Feb 2025 08:37:56 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> > I suppose extracting the branch probability from the MethodData and attaching it to the Min/Max nodes is not impossible.
> 
> That is basically what `PhaseIdealLoop::conditional_move` already does, right? It detects the diamond and converts it to `CMove`. We could special case for `min / max`, and then we'd have the probability for the branch, which we could store at the node.

Possibly. We could also create the intrinsic they way it's done in the patch and extract the frequency from the `MethoData` for the min or max methods. The shape of the bytecodes for these methods should be simple enough that it should be feasible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2662424292

From epeter at openjdk.org  Mon Feb 17 10:39:15 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 17 Feb 2025 10:39:15 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
 <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
Message-ID: <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>

On Mon, 17 Feb 2025 08:44:46 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>>> I suppose extracting the branch probability from the MethodData and attaching it to the Min/Max nodes is not impossible.
>> 
>> That is basically what `PhaseIdealLoop::conditional_move` already does, right? It detects the diamond and converts it to `CMove`. We could special case for `min / max`, and then we'd have the probability for the branch, which we could store at the node.
>
>> > I suppose extracting the branch probability from the MethodData and attaching it to the Min/Max nodes is not impossible.
>> 
>> That is basically what `PhaseIdealLoop::conditional_move` already does, right? It detects the diamond and converts it to `CMove`. We could special case for `min / max`, and then we'd have the probability for the branch, which we could store at the node.
> 
> Possibly. We could also create the intrinsic they way it's done in the patch and extract the frequency from the `MethoData` for the min or max methods. The shape of the bytecodes for these methods should be simple enough that it should be feasible.

@rwestrel @galderz 

> It seems overall, we likely win more than we loose with this intrinsic, so I would integrate this change as it is and file a bug to keep track of remaining issues.

I'm a little scared to just accept the regressions, especially for this "most average looking case":
Imagine you have an array with random numbers. Or at least numbers in a random order. If we take the max, then we expect the first number to be max with probability 1, the second 1/2, the third 1/3, the i'th 1/i. So the average branch probability is `n / (sum_i 1/i)`. This goes closer and closer to zero, the larger the array. This means that the "average" case has an extreme probability. And so if we do not vectorize, then this gets us a regression with the current patch. And vectorization is a little fragile, it only takes very little for vectorization not to kick in.

> The Min/Max nodes are floating nodes. They can hoist out of loop and common reliably in ways that are not guaranteed otherwise.

I suppose we could write an optimization that can hoist out loop independent if-diamonds out of a loop. If the condition and all phi inputs are loop invariant, you could just cut the diamond out of the loop, and paste it before the loop entry.

> Shouldn't int min/max be affected the same way?

I think we should be able to see the same issue here, actually. Yes. Here a quick benchmark below:


java -XX:CompileCommand=compileonly,TestIntMax::test* -XX:CompileCommand=printcompilation,TestIntMax::test* -XX:+TraceNewVectors TestIntMax.java
CompileCommand: compileonly TestIntMax.test* bool compileonly = true
CompileCommand: PrintCompilation TestIntMax.test* bool PrintCompilation = true
Warmup
5225   93 %     3       TestIntMax::test1 @ 5 (27 bytes)
5226   94       3       TestIntMax::test1 (27 bytes)
5226   95 %     4       TestIntMax::test1 @ 5 (27 bytes)
5238   96       4       TestIntMax::test1 (27 bytes)
Run
Time: 542056319
Warmup
6320  101 %     3       TestIntMax::test2 @ 5 (34 bytes)
6322  102 %     4       TestIntMax::test2 @ 5 (34 bytes)
6329  103       4       TestIntMax::test2 (34 bytes)
Run
Time: 166815209

That's a 4x regression on random input data!

With:

import java.util.Random;

public class TestIntMax {
    private static Random RANDOM = new Random();

    public static void main(String[] args) {
        int[] a = new int[64 * 1024];
        for (int i = 0; i < a.length; i++) {
            a[i] = RANDOM.nextInt();
        }


        {
            System.out.println("Warmup"); 
            for (int i = 0; i < 10_000; i++) { test1(a); }
            System.out.println("Run"); 
            long t0 = System.nanoTime();
            for (int i = 0; i < 10_000; i++) { test1(a); }
            long t1 = System.nanoTime();
            System.out.println("Time: " + (t1 - t0)); 
        }

        {
            System.out.println("Warmup"); 
            for (int i = 0; i < 10_000; i++) { test2(a); }
            System.out.println("Run"); 
            long t0 = System.nanoTime();
            for (int i = 0; i < 10_000; i++) { test2(a); }
            long t1 = System.nanoTime();
            System.out.println("Time: " + (t1 - t0)); 
        }
    }

    public static int test1(int[] a) {
        int x = Integer.MIN_VALUE;
        for (int i = 0; i < a.length; i++) {
            x = Math.max(x, a[i]);
        }
        return x;
    }

    public static int test2(int[] a) {
        int x = Integer.MIN_VALUE;
        for (int i = 0; i < a.length; i++) {
            x = (x >= a[i]) ? x : a[i];
        }
        return x;
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2662706564

From epeter at openjdk.org  Mon Feb 17 10:46:12 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 17 Feb 2025 10:46:12 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <ikTvrFILQiZVSo1YUW_Sc3k3ifMin9UN2eHpcscdcmQ=.eddf8a3c-9e82-40b9-bfca-c79a9d69902d@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <ljxrhzoRck0LUkRbHYC_0hfPXiW_L1vuw0K7B8lKUKY=.fea555f9-651a-47a1-8c98-b33470d85a8b@github.com>
 <ikTvrFILQiZVSo1YUW_Sc3k3ifMin9UN2eHpcscdcmQ=.eddf8a3c-9e82-40b9-bfca-c79a9d69902d@github.com>
Message-ID: <z9kfMe4n2F1-bfTSNFATXVEBeMCUWx0eya6zelKq0eI=.461fb031-4a24-4afd-b948-1b67155f1161@github.com>

On Thu, 13 Feb 2025 07:52:30 GMT, Nicole Xu <duke at openjdk.org> wrote:

>> Oh, the OCA-verify is still stuck. I'm sorry about that ? 
>> I pinged my manager @TobiHartmann , he will reach out to see what's the issue.
>
> Hi @eme64, do you see any risks here? Would you please help to review the patch? Thanks.

@xyyNicole @jatin-bhateja I think it is reasonable to just fix the benchmark so that it still has the same behaviour, just without the out-of-bounds exception. @jatin-bhateja you originally wrote the benchmark, and it could make sense if you fixed it up to what it should be more ideally. @xyyNicole I propose that we file a follow-up RFE to fix the benchmark, and just mention that issue in the benchmark.

What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2662722979

From roland at openjdk.org  Mon Feb 17 10:50:22 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 17 Feb 2025 10:50:22 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
 <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
 <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
Message-ID: <U6wVxiGwEunYY_rfxNj6Fl3qN7OLATbZLdF3F-3-gz0=.272a5579-3012-4199-8f25-8d7c4136153d@github.com>

On Mon, 17 Feb 2025 10:36:52 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> I suppose we could write an optimization that can hoist out loop independent if-diamonds out of a loop. If the condition and all phi inputs are loop invariant, you could just cut the diamond out of the loop, and paste it before the loop entry.

Right. But, it would likely not optimize as well. The new optimization will possibly have heuristics to limit complexity so could be limited. The diamond could be transformed to something else by some other optimization before it gets a chance to get hoisted. There are likely other optimizations that apply to floating nodes that would still not apply: for instance, `MinL`/`MaxL` can be split thru phi even if the `min` call is not right after the merge point. With branches that's not true. Also, with more compexity comes more bugs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2662733218

From alanb at openjdk.org  Mon Feb 17 10:52:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Feb 2025 10:52:09 GMT
Subject: RFR: 8349909: jdk.internal.jimage.decompressor.ZipDecompressor
 does not close the Inflater in exceptional cases
In-Reply-To: <FYyDEN1cAcVMOfNC-iIiEIY9_1chS6CA-AvnWIAfNJs=.1bab94e4-f4fc-4e28-8204-7a7eea94ceab@github.com>
References: <FYyDEN1cAcVMOfNC-iIiEIY9_1chS6CA-AvnWIAfNJs=.1bab94e4-f4fc-4e28-8204-7a7eea94ceab@github.com>
Message-ID: <9Qe5a3tpovQtwGmXr3A-8XILQtyrQLtPcxTELTXPc0o=.78993cf3-3aa6-4345-b02e-80b8a12e6cba@github.com>

On Fri, 14 Feb 2025 07:41:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to properly close the `Inflater` instance used in `jdk.internal.jimage.decompressor.ZipDecompressor.decompress()` method? This addresses https://bugs.openjdk.org/browse/JDK-8349909.
> 
> As noted in that issue, in the exceptional case in the `decompress()` method, the `Inflater` instance isn't currently being closed. The commit in this PR uses a try/finally block to `end()` the `Inflater` instance.
> 
> Unlike some other places within the JDK, the code in `jdk.internal.jimage.decompressor.ZipDecompressor` is expected to maintain Java 8 (API) compatibility, so this part of the code cannot use the newly introduced `Inflater.close()` method and thus cannot use the try-with-resources statement too.
> 
> No new tests have been added given the nature of this change. A noreg label has been added to the JBS issue. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

Looks fine although I assume we've never had any reports of an exception here.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23626#pullrequestreview-2620700726

From jpai at openjdk.org  Mon Feb 17 11:02:09 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Feb 2025 11:02:09 GMT
Subject: RFR: 8349909: jdk.internal.jimage.decompressor.ZipDecompressor
 does not close the Inflater in exceptional cases
In-Reply-To: <9Qe5a3tpovQtwGmXr3A-8XILQtyrQLtPcxTELTXPc0o=.78993cf3-3aa6-4345-b02e-80b8a12e6cba@github.com>
References: <FYyDEN1cAcVMOfNC-iIiEIY9_1chS6CA-AvnWIAfNJs=.1bab94e4-f4fc-4e28-8204-7a7eea94ceab@github.com>
 <9Qe5a3tpovQtwGmXr3A-8XILQtyrQLtPcxTELTXPc0o=.78993cf3-3aa6-4345-b02e-80b8a12e6cba@github.com>
Message-ID: <Y5QndLLqtpEtbRtIfqZh3aSgbxH7edcsy2tnN26fsZA=.98866b3e-c372-4098-8957-6486dbea8437@github.com>

On Mon, 17 Feb 2025 10:49:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Looks fine although I assume we've never had any reports of an exception here.

Right - given the nature of this tool, I doubt it would ever be an issue in practice.

Thank you for the review. I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23626#issuecomment-2662762095

From alanb at openjdk.org  Mon Feb 17 11:07:22 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Feb 2025 11:07:22 GMT
Subject: RFR: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
 [v2]
In-Reply-To: <US6S889qKyKtHnZ-YpxkJ2CdefzaLvHD9bS6hdhmIy0=.e4620d80-53ed-489d-bb75-ec1a69402194@github.com>
References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
 <US6S889qKyKtHnZ-YpxkJ2CdefzaLvHD9bS6hdhmIy0=.e4620d80-53ed-489d-bb75-ec1a69402194@github.com>
Message-ID: <xQuzHqp-JdO6Yv0WpLrrl-ExtEDSGX5PcAzpsKTZi7o=.191e47bb-0e38-4492-834d-0ce45b1d1896@github.com>

On Sun, 16 Feb 2025 12:48:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`.
>> 
>> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes.
>> 
>> I'll draft a CSR once we agree on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add tests

I don't think using implSpec works here as that is specification for implementers / subclasess. I think what you are looking for here is an API note to inform developers how to use the API to ensure that resources are freed. So I think consider an API note on the constructors and the close method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23655#issuecomment-2662772796

From jpai at openjdk.org  Mon Feb 17 11:09:21 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Feb 2025 11:09:21 GMT
Subject: Integrated: 8349909: jdk.internal.jimage.decompressor.ZipDecompressor
 does not close the Inflater in exceptional cases
In-Reply-To: <FYyDEN1cAcVMOfNC-iIiEIY9_1chS6CA-AvnWIAfNJs=.1bab94e4-f4fc-4e28-8204-7a7eea94ceab@github.com>
References: <FYyDEN1cAcVMOfNC-iIiEIY9_1chS6CA-AvnWIAfNJs=.1bab94e4-f4fc-4e28-8204-7a7eea94ceab@github.com>
Message-ID: <MCmiJ-7ilnGoPhf2IjsdSXjXFHF4a6thpGrC1bWthyc=.46ccbfd0-09ae-41c7-b6dc-792a248d82f6@github.com>

On Fri, 14 Feb 2025 07:41:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to properly close the `Inflater` instance used in `jdk.internal.jimage.decompressor.ZipDecompressor.decompress()` method? This addresses https://bugs.openjdk.org/browse/JDK-8349909.
> 
> As noted in that issue, in the exceptional case in the `decompress()` method, the `Inflater` instance isn't currently being closed. The commit in this PR uses a try/finally block to `end()` the `Inflater` instance.
> 
> Unlike some other places within the JDK, the code in `jdk.internal.jimage.decompressor.ZipDecompressor` is expected to maintain Java 8 (API) compatibility, so this part of the code cannot use the newly introduced `Inflater.close()` method and thus cannot use the try-with-resources statement too.
> 
> No new tests have been added given the nature of this change. A noreg label has been added to the JBS issue. Existing tests in tier1, tier2 and tier3 continue to pass with this change.

This pull request has now been integrated.

Changeset: 071c8f51
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/071c8f515537d6030ae7055e309b4f4a6a495bc8
Stats:     11 lines in 1 file changed: 4 ins; 2 del; 5 mod

8349909: jdk.internal.jimage.decompressor.ZipDecompressor does not close the Inflater in exceptional cases

Reviewed-by: lancea, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/23626

From eirbjo at openjdk.org  Mon Feb 17 12:50:14 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 17 Feb 2025 12:50:14 GMT
Subject: RFR: 8066583: DeflaterInput/OutputStream and
 InflaterInput/OutputStream should explain responsibility for freeing resources
In-Reply-To: <tWexmLKqij5R6NKsUWtap_bUMsADG8AGYRUvFJeqnMM=.fd8bb8cc-69a1-40d0-b259-5a42597cb46d@github.com>
References: <_-vPn2mBKy7Wj1THhp1-BUWsamET0AvVLxoX4Kh8G3E=.b6d5a3c0-baa6-4ec0-a155-430ea9116fe9@github.com>
 <tWexmLKqij5R6NKsUWtap_bUMsADG8AGYRUvFJeqnMM=.fd8bb8cc-69a1-40d0-b259-5a42597cb46d@github.com>
Message-ID: <zxJYvcJp8-d7jmB7wVISLokEKaKsdhNd6RGx5Qaktas=.53f1e97f-11a5-4f73-a5a8-ef7eefd0038d@github.com>

On Sun, 16 Feb 2025 12:45:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to improve the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, `InflaterInputStream` and `InflaterOutputStream` classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the constructors of these classes allow callers to pass a `Deflater`/`Inflater` instance. The implementation of these classes do not close the given `Deflater`/`Inflater` when the corresponding instance of the class itself is closed. This isn't documented and can lead to situations where callers aren't aware that they are responsible for closing the given `Deflater`/`Inflater` instance. That can then lead to resource leaks of resources held by the `Deflater`/`Inflater`.
>> 
>> The commit in this PR updates the relevant constructors of these classes to add an `@implSpec` explaining the responsibility of closing the given `Inflater`/`Deflater`. I chose the `@implSpec` since each of these classes whose documentation is being updated are `public` and can be sub-classed and the `close()` method overridden. The text being added merely specifies the implementation of these classes and not the sub-classes.
>> 
>> I'll draft a CSR once we agree on the proposed text.
>
> There are one or two places in existing jtreg tests where this behaviour is already verified, but they are not exhaustive. So I've updated a couple of existing test classes to include new test methods to verify the expectation of all these constructors. The tests continue to pass.

Hey @jaikiran 

I'm wondering if a class level note, perhaps with an example snippet demonstrating a safe use of the API class using custom deflater / inflater would be warranted here?

The reasoning is as follows:

* Users may start out using a "safe" constructor, then switching over to a constructor taking a custom inflater / deflater
* When doing so, they may skip reading special notes for that particular constructor. (I have no data on this, I'm just assuming that constructor Javadoc notes are less frequently visited compared to the class-level description)
* People like to copy-paste code from SO and similar, perhaps better if they have a class level snippet demonstrating safe use. We don't want to repeat this when multiple constructors are "unsafe"
* The "danger" kind-of-sort-of lives at the class level, since some constuctors are safe, other not. It's sort of insidious. 

* Perhaps the class level is a place to note that there some constructors are safe, some not, then each "unsafe" constructor could have a short note as well.

Just a thought, there are probably reasons to not do this as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23655#issuecomment-2663019823

From duke at openjdk.org  Mon Feb 17 13:55:16 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 17 Feb 2025 13:55:16 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v2]
In-Reply-To: <T6tLX_u6tuehydDgOk-Zy90LEIsKMBVHyAtukZgZETo=.dcfd7512-360d-4f51-8b49-7d42199aa6d7@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
 <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>
 <bfT8EMRk6msqkRF32_vQCfZvirTiWsvg0hrOpThz9i4=.1f6626ed-637e-4ff3-827d-f5dc34094910@github.com>
 <A_C2myp2dclvSO5vDmJD4sl9FMoWFCP-j1P7ihltcKc=.c1cb149b-0e33-4d6d-8399-8d6dfe5dbccc@github.com>
 <dl48ChO5x4futsrtaAjvvlxb4Enekr9S1qFCwQtGVkU=.904d075e-786d-4fe2-980c-f6e9143ba86a@github.com>
 <fcvrEMeNBT-Cp7C5MR_zsON1WDWouU72qVik-DiN4k0=.7b655123-f2ff-4c12-8d94-0845be867d05@github.com>
 <wmIgd_-kflkNtl_HeIq8sAgfBAeDGuYvT9xwsl1TnGc=.4e09a4cf-1f9a-441c-9f86-8f37a682757f@github.com>
 <G0QHgSxgst6mR2wqn6_LdUAb1C5dGfTVcLonEMBbC8Q=.dd75c6a5-9dd4-4605-89c3-fda9b17cd080@github.com>
 <T6tLX_u6tuehydDgOk-Zy90LEIsKMBVHyAtukZgZETo=.dcfd7512-360d-4f51-8b49-7d42199aa6d7@github.com>
Message-ID: <Cpc_kxrUHuC3Sj2zluPHtPICI63z2swogYec43ycS-I=.b034cc18-7472-4a0c-88d7-2f50eb258692@github.com>

On Fri, 14 Feb 2025 19:51:19 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> The reason I'm pushing back a little here is that the idea of making a "secret handshake" method between StreamHandler and FileHandler isn't a solution for anyone who made their own handler (e.g. an "EncryptedLogFileHandler" that's not a sub-class of FileHandler). The shape of the existing public API makes the additional promise that "post-processing" occurs synchronously with the last log written hard/impossible, and having it so only JDK classes can do this feels a bit wrong to me.
>> 
>> In other words, if you can convince me it's worth doing something to make FileHandler "more synchronized" in this way, I think we should change the API or find another way to allow any third-party sub-classes to also solve the issue. This is why I'm seeking real world examples of actual code that appear to rely on the invariant we're discussing.
>
>>I've looked through a lot of github logging properties files and see no evidence that the pattern of use...
> 
> Closed source GOTS/COTS products that require troubleshooting require using all of the logging API features when other solutions are forbidden for non-tech reasons.
> 
> To the point though, limit one with a count makes FileHandler work like the MemoryHandler in that at the end of say a batch run you have exactly the last N records in the form of N files.  That is a feature.
> 
>>The reason I'm pushing back a little here is that the idea of making a "secret handshake"
> 
> The behavior is what i care about not the implementation.  I would rather focus on fitting your change and retain old behavior. Behaviorly, i think deadlock can be fixed with retaining existing log rollover behavior. Secret handshake off the table then. Done and dead.
> 
> New idea. All JDK subclass of StreamHandler call flush.
> 
> 1. Put rotate check in FileHandler::flush
> 2. Make StreamHandler call flush while holding lock.
> 3. Remove explicit flush call in subclasses.
> 4. Add auto flush property to StreamHandler, default false.
> 5. Set auto flush true in subclass.
> 
> 
>>..."EncryptedLogFileHandler" that's not a sub-class of FileHandler.
> 
> That example does apply because if it is not a FileHandler there is no check to call rotate method.  What am I missing?

The issue with a non-JDK stream handler subclass, is that it doesn't have the privilege of being able to do anything before the `super.publish(...)` call has finished and the handler instance is unlocked.

Using a package protected method to achieve this only for JDK classes is just leaving a slightly bad taste in my mouth.

There's just nothing in the API, other than perhaps brittle things like using an overridden stream and detecting writes (which Daniel has convinced me is too brittle to be in the JDK) to allow a non-JDK version of FileHandler to be implemented with "synchronous post publish() actions". And I personally dislike the idea that people can't write their own equivalent of FileHandler (with some extra feature) outside the JDK.

And, just FYI, there's basically almost no chance we'd consider adding new methods or properties to the logging package at this point. I'd be far more scarred about adding "auto flushing" to existing handler sub-classes than changing the never specified behaviour with respect to file size (though the pathological 1-byte file to force rotation per log record is something I hadn't considered, but has also never been promised to actually work).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1958277870

From duke at openjdk.org  Mon Feb 17 14:01:25 2025
From: duke at openjdk.org (duke)
Date: Mon, 17 Feb 2025 14:01:25 GMT
Subject: Withdrawn: 8342486: Implement JEP draft: Structured Concurrency (Fifth
 Preview)
In-Reply-To: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
Message-ID: <sZFnsR_n514NKzR1oDX-KjBbApHJqXHpbaR9CByjw9o=.043eb465-6429-4a75-b606-e06a0f45eb2e@github.com>

On Wed, 6 Nov 2024 15:47:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Changes for [JEP draft: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical roadmap yet. The proposal is to re-preview the API with some changes, specifically:
> 
> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>  
> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21934

From sgehwolf at openjdk.org  Mon Feb 17 14:06:25 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 17 Feb 2025 14:06:25 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
Message-ID: <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>

On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added details in the log message

`CgroupV1Controller::set_subsystem_path` needs high level comment update to describe the logic happening.

Testing:
>>And after the patch this would become this, right?
>>```
>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>>/sys/fs/cgroup/cpu,cpuacct/
>>```
>
>It depends on whether it was a subgroup in the initial path. If bad/2f57368b-0eda-4e52-64d8-af5c is the subgroup, the reduction will be
>
>```
>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>/sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c
>/sys/fs/cgroup/cpu,cpuacct/bad
>/sys/fs/cgroup/cpu,cpuacct/
>```

The above case, doesn't seem to be reflected by any gtest test case (or others), please add those.

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 75:

> 73:               break;
> 74:             }
> 75:             suffix = strchr(suffix+1, '/');

Style:

Suggestion:

            suffix = strchr(suffix + 1, '/');

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 63:

> 61:                         Path cgp = Path.of(cgroupPath);
> 62:                         int nameCount = cgp.getNameCount();
> 63:                         for (int i=0; i<nameCount; ++i) {

Style:

Suggestion:

                        for (int i=0; i < nameCount; i++) {

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 73:

> 71:                                 break;
> 72:                             }
> 73:                             cgp = (cgp.getNameCount() > 1) ? cgp.subpath(1, cgp.getNameCount()) : Path.of("");

Suggestion:

                            cgp = (nameCount > 1) ? cgp.subpath(1, nameCount) : Path.of("");

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 60:

> 58: 
> 59:             Common.prepareWhiteBox();
> 60:             DockerTestUtils.buildJdkContainerImage(imageName);

This can be moved out of the condition. It's there in both cases.

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 85:

> 83:         } else {
> 84:             System.out.println("Metrics are from neither cgroup v1 nor v2, skipped for now.");
> 85:         }

Suggestion:

        throw new RuntimeException("cgroup version not known? was: " + metrics.getProvider());

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 98:

> 96:         opts.addDockerOpts("--privileged")
> 97:             .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host"))
> 98:             .addDockerOpts("--memory", "1g");

Please extract this "larger" memory limit out of this function. The expectation is to have:


Container memory limit => X
Some lower limit in a moved path => Y

Expect that the lower limit of Y is being detected.


For example:


testMemoryLimitSubgroupV1("1g", "100m", "104857600", false);

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 118:

> 116:         opts.addDockerOpts("--privileged")
> 117:             .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host"))
> 118:             .addDockerOpts("--memory", "1g");

Same here with the `1g` container memory limit. Move it to a parameter.

test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 72:

> 70:         } else {
> 71:             System.out.println("Metrics are from neither cgroup v1 nor v2, skipped for now.");
> 72:         }

Please `throw` here.

-------------

Changes requested by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2620718790
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958032435
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958043532
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958048577
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958073462
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958075672
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958059439
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958061783
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958077572

From roland at openjdk.org  Mon Feb 17 15:05:17 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 17 Feb 2025 15:05:17 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
 <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
 <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
Message-ID: <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FFeVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>

On Mon, 17 Feb 2025 10:36:52 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> I think we should be able to see the same issue here, actually. Yes. Here a quick benchmark below:

I observe the same:


Warmup
751    3    b        TestIntMax::test1 (27 bytes)
Run
Time: 360 550 158
Warmup
1862   15    b        TestIntMax::test2 (34 bytes)
Run
Time: 92 116 170


But then with this:


diff --git a/src/hotspot/cpu/x86/x86_64.ad b/src/hotspot/cpu/x86/x86_64.ad
index 8cc4a970bfd..9abda8f4178 100644
--- a/src/hotspot/cpu/x86/x86_64.ad
+++ b/src/hotspot/cpu/x86/x86_64.ad
@@ -12037,16 +12037,20 @@ instruct cmovI_reg_l(rRegI dst, rRegI src, rFlagsReg cr)
 %}
 
 
-instruct maxI_rReg(rRegI dst, rRegI src)
+instruct maxI_rReg(rRegI dst, rRegI src, rFlagsReg cr)
 %{
   match(Set dst (MaxI dst src));
+  effect(KILL cr);
 
   ins_cost(200);
-  expand %{
-    rFlagsReg cr;
-    compI_rReg(cr, dst, src);
-    cmovI_reg_l(dst, src, cr);
+  ins_encode %{
+    Label done;
+    __ cmpl($src$$Register, $dst$$Register);
+    __ jccb(Assembler::less, done);
+    __ mov($dst$$Register, $src$$Register);
+    __ bind(done);
   %}
+  ins_pipe(pipe_cmov_reg);
 %}
 
 // ============================================================================


the performance gap narrows:


Warmup
770    3    b        TestIntMax::test1 (27 bytes)
Run
Time: 94 951 677
Warmup
1312   15    b        TestIntMax::test2 (34 bytes)
Run
Time: 70 053 824


(the number of test2 fluctuates quite a bit). Does it ever make sense to implement `MaxI` with a conditional move then?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2663379660

From alanb at openjdk.org  Mon Feb 17 15:26:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Feb 2025 15:26:14 GMT
Subject: RFR: 8347123: Add missing @serial tags to other modules [v2]
In-Reply-To: <wj4VAEKMgc-CPtcZH_LZUtt2Z2a3VyUmGZUdnpuwR_A=.92ee1263-2bbe-4a2f-8f52-1d1d86b9b4f5@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
 <wj4VAEKMgc-CPtcZH_LZUtt2Z2a3VyUmGZUdnpuwR_A=.92ee1263-2bbe-4a2f-8f52-1d1d86b9b4f5@github.com>
Message-ID: <F3PCXiegB-EjgfP54T6G4Z_B23Ef5_nN9q-kl9M-V0o=.944af930-79bc-48a6-9041-52b8b7b82844@github.com>

On Fri, 24 Jan 2025 10:58:24 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19.
>> 
>> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931
>> 
>> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. 
>> 
>> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update @serialData text to CSR-approved version

I think this is oky, the CSR for the change writeExternal has already been reviewed.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22980#pullrequestreview-2621362315

From alanb at openjdk.org  Mon Feb 17 15:28:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Feb 2025 15:28:06 GMT
Subject: RFR: 8342486: Implement JEP draft: Structured Concurrency (Fifth
 Preview) [v5]
In-Reply-To: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
Message-ID: <mu7rFuLKhZaU7uPJBZUVLYB5rYFEF4XBM9uS9uuomfw=.6dbcdbe1-b11d-4c80-8748-53bcfd18c03d@github.com>

> Changes for [JEP draft: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical roadmap yet. The proposal is to re-preview the API with some changes, specifically:
> 
> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>  
> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge branch 'master' into JDK-8342486
 - Fix link
 - Merge branch 'master' into JDK-8342486
 - Sync up impl/tests form loom repo
 - Merge branch 'master' into JDK-8342486
 - Pull latest API docs + impl from loom repo
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Initial commit

-------------

Changes: https://git.openjdk.org/jdk/pull/21934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=04
  Stats: 4074 lines in 14 files changed: 1869 ins; 1458 del; 747 mod
  Patch: https://git.openjdk.org/jdk/pull/21934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21934/head:pull/21934

PR: https://git.openjdk.org/jdk/pull/21934

From hannesw at openjdk.org  Mon Feb 17 15:34:16 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 17 Feb 2025 15:34:16 GMT
Subject: Integrated: 8347123: Add missing @serial tags to other modules
In-Reply-To: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
Message-ID: <bpKNHxlo8g-0-F1SySvfie5_pj0K2tEXiu2cbLyHZ10=.140f9f54-7a24-4633-9901-3bd7ad507871@github.com>

On Wed, 8 Jan 2025 20:13:50 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19.
> 
> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931
> 
> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. 
> 
> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation.

This pull request has now been integrated.

Changeset: 3f0c1370
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f0c1370269db978072814c2170fc3987efade85
Stats:     104 lines in 39 files changed: 45 ins; 0 del; 59 mod

8347123: Add missing @serial tags to other modules

Reviewed-by: prr, nbenalla, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22980

From mbaesken at openjdk.org  Mon Feb 17 15:51:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Feb 2025 15:51:14 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
Message-ID: <odVIQQDcyKJtY-WCiVhkFgwVDn_BwD0PLMqz6sEscHw=.19efc5b7-a33a-4e10-b624-037b5cba6e98@github.com>

On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added details in the log message

src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2SubsystemController.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2024, Red Hat Inc.

You did not touch the test but change the COPYRIGHT year, why ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958449655

From galder at openjdk.org  Mon Feb 17 16:49:15 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 17 Feb 2025 16:49:15 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FFeVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
 <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
 <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
 <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FF
 eVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>
Message-ID: <_SUoth7bTq41M5TpGjQ5ADL2TOesK2tIIxmL21BZ6RU=.65284948-b4a8-4d01-a924-e9dfeefe1c88@github.com>

On Mon, 17 Feb 2025 15:02:32 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> @rwestrel @galderz 
>> 
>>> It seems overall, we likely win more than we loose with this intrinsic, so I would integrate this change as it is and file a bug to keep track of remaining issues.
>> 
>> I'm a little scared to just accept the regressions, especially for this "most average looking case":
>> Imagine you have an array with random numbers. Or at least numbers in a random order. If we take the max, then we expect the first number to be max with probability 1, the second 1/2, the third 1/3, the i'th 1/i. So the average branch probability is `n / (sum_i 1/i)`. This goes closer and closer to zero, the larger the array. This means that the "average" case has an extreme probability. And so if we do not vectorize, then this gets us a regression with the current patch. And vectorization is a little fragile, it only takes very little for vectorization not to kick in.
>> 
>>> The Min/Max nodes are floating nodes. They can hoist out of loop and common reliably in ways that are not guaranteed otherwise.
>> 
>> I suppose we could write an optimization that can hoist out loop independent if-diamonds out of a loop. If the condition and all phi inputs are loop invariant, you could just cut the diamond out of the loop, and paste it before the loop entry.
>> 
>>> Shouldn't int min/max be affected the same way?
>> 
>> I think we should be able to see the same issue here, actually. Yes. Here a quick benchmark below:
>> 
>> 
>> java -XX:CompileCommand=compileonly,TestIntMax::test* -XX:CompileCommand=printcompilation,TestIntMax::test* -XX:+TraceNewVectors TestIntMax.java
>> CompileCommand: compileonly TestIntMax.test* bool compileonly = true
>> CompileCommand: PrintCompilation TestIntMax.test* bool PrintCompilation = true
>> Warmup
>> 5225   93 %     3       TestIntMax::test1 @ 5 (27 bytes)
>> 5226   94       3       TestIntMax::test1 (27 bytes)
>> 5226   95 %     4       TestIntMax::test1 @ 5 (27 bytes)
>> 5238   96       4       TestIntMax::test1 (27 bytes)
>> Run
>> Time: 542056319
>> Warmup
>> 6320  101 %     3       TestIntMax::test2 @ 5 (34 bytes)
>> 6322  102 %     4       TestIntMax::test2 @ 5 (34 bytes)
>> 6329  103       4       TestIntMax::test2 (34 bytes)
>> Run
>> Time: 166815209
>> 
>> That's a 4x regression on random input data!
>> 
>> With:
>> 
>> import java.util.Random;
>> 
>> public class TestIntMax {
>>     private static Random RANDOM = new Random();
>> 
>>     public static void main(String[] args) {
>>         int[] a = new int[64 * 1024];
>>         for (int i = 0; i < a.length; i++) {
>>...
>
>> I think we should be able to see the same issue here, actually. Yes. Here a quick benchmark below:
> 
> I observe the same:
> 
> 
> Warmup
> 751    3    b        TestIntMax::test1 (27 bytes)
> Run
> Time: 360 550 158
> Warmup
> 1862   15    b        TestIntMax::test2 (34 bytes)
> Run
> Time: 92 116 170
> 
> 
> But then with this:
> 
> 
> diff --git a/src/hotspot/cpu/x86/x86_64.ad b/src/hotspot/cpu/x86/x86_64.ad
> index 8cc4a970bfd..9abda8f4178 100644
> --- a/src/hotspot/cpu/x86/x86_64.ad
> +++ b/src/hotspot/cpu/x86/x86_64.ad
> @@ -12037,16 +12037,20 @@ instruct cmovI_reg_l(rRegI dst, rRegI src, rFlagsReg cr)
>  %}
>  
>  
> -instruct maxI_rReg(rRegI dst, rRegI src)
> +instruct maxI_rReg(rRegI dst, rRegI src, rFlagsReg cr)
>  %{
>    match(Set dst (MaxI dst src));
> +  effect(KILL cr);
>  
>    ins_cost(200);
> -  expand %{
> -    rFlagsReg cr;
> -    compI_rReg(cr, dst, src);
> -    cmovI_reg_l(dst, src, cr);
> +  ins_encode %{
> +    Label done;
> +    __ cmpl($src$$Register, $dst$$Register);
> +    __ jccb(Assembler::less, done);
> +    __ mov($dst$$Register, $src$$Register);
> +    __ bind(done);
>    %}
> +  ins_pipe(pipe_cmov_reg);
>  %}
>  
>  // ============================================================================
> 
> 
> the performance gap narrows:
> 
> 
> Warmup
> 770    3    b        TestIntMax::test1 (27 bytes)
> Run
> Time: 94 951 677
> Warmup
> 1312   15    b        TestIntMax::test2 (34 bytes)
> Run
> Time: 70 053 824
> 
> 
> (the number of test2 fluctuates quite a bit). Does it ever make sense to implement `MaxI` with a conditional move then?

@rwestrel @eme64 I think that the data distribution in the `TestIntMax` above matters (see my explanations in https://github.com/openjdk/jdk/pull/20098#issuecomment-2642788364), so I've enhanced the test to control data distribution in the int[] (see at the bottom).

Here are the results I see on my AVX-512 machine:


Probability: 50%
Warmup
7834   92 %  b  3       TestIntMax::test1 @ 5 (27 bytes)
7836   93    b  3       TestIntMax::test1 (27 bytes)
7838   94 %  b  4       TestIntMax::test1 @ 5 (27 bytes)
7851   95    b  4       TestIntMax::test1 (27 bytes)
Run
Time: 699 923 014
Warmup
9272   96 %  b  3       TestIntMax::test2 @ 5 (34 bytes)
9274   97    b  3       TestIntMax::test2 (34 bytes)
9275   98 %  b  4       TestIntMax::test2 @ 5 (34 bytes)
9287   99    b  4       TestIntMax::test2 (34 bytes)
Run
Time: 699 815 792

Probability: 80%
Warmup
7872   92 %  b  3       TestIntMax::test1 @ 5 (27 bytes)
7874   93    b  3       TestIntMax::test1 (27 bytes)
7875   94 %  b  4       TestIntMax::test1 @ 5 (27 bytes)
7889   95    b  4       TestIntMax::test1 (27 bytes)
Run
Time: 699 947 633
Warmup
9310   96 %  b  3       TestIntMax::test2 @ 5 (34 bytes)
9311   97    b  3       TestIntMax::test2 (34 bytes)
9312   98 %  b  4       TestIntMax::test2 @ 5 (34 bytes)
9325   99    b  4       TestIntMax::test2 (34 bytes)
Run
Time: 699 827 882

Probability: 100%
Warmup
7884   92 %  b  3       TestIntMax::test1 @ 5 (27 bytes)
7886   93    b  3       TestIntMax::test1 (27 bytes)
7888   94 %  b  4       TestIntMax::test1 @ 5 (27 bytes)
7901   95    b  4       TestIntMax::test1 (27 bytes)
Run
Time: 699 931 243
Warmup
9322   96 %  b  3       TestIntMax::test2 @ 5 (34 bytes)
9323   97    b  3       TestIntMax::test2 (34 bytes)
9324   98 %  b  4       TestIntMax::test2 @ 5 (34 bytes)
9336   99    b  4       TestIntMax::test2 (34 bytes)
Run
Time: 1 077 937 282



import java.util.Random;
import java.util.concurrent.ThreadLocalRandom;
import java.text.DecimalFormat;
import java.text.DecimalFormatSymbols;

class TestIntMax
{
    static final int RANGE = 16 * 1024;
    static final int ITER = 100_000;

    public static void main(String[] args)
    {
        final int probability = Integer.parseInt(args[0]);

        final DecimalFormatSymbols symbols = new DecimalFormatSymbols();
        symbols.setGroupingSeparator(' ');
        final DecimalFormat format = new DecimalFormat("#,###", symbols);

        System.out.printf("Probability: %d%%%n", probability);
        int[] a = new int[64 * 1024];
        init(a, probability);

        {
            System.out.println("Warmup");
            for (int i = 0; i < 10_000; i++)
            {
                test1(a);
            }
            System.out.println("Run");
            long t0 = System.nanoTime();
            for (int i = 0; i < 10_000; i++)
            {
                test1(a);
            }
            long t1 = System.nanoTime();
            System.out.println("Time: " + format.format(t1 - t0));
        }

        {
            System.out.println("Warmup");
            for (int i = 0; i < 10_000; i++)
            {
                test2(a);
            }
            System.out.println("Run");
            long t0 = System.nanoTime();
            for (int i = 0; i < 10_000; i++)
            {
                test2(a);
            }
            long t1 = System.nanoTime();
            System.out.println("Time: " + format.format(t1 - t0));
        }
    }

    public static int test1(int[] a)
    {
        int x = Integer.MIN_VALUE;
        for (int i = 0; i < a.length; i++)
        {
            x = Math.max(x, a[i]);
        }
        return x;
    }

    public static int test2(int[] a)
    {
        int x = Integer.MIN_VALUE;
        for (int i = 0; i < a.length; i++)
        {
            x = (x >= a[i]) ? x : a[i];
        }
        return x;
    }

    public static void init(int[] ints, int probability)
    {
        int aboveCount, abovePercent;

        do
        {
            int max = ThreadLocalRandom.current().nextInt(10);
            ints[0] = max;

            aboveCount = 0;
            for (int i = 1; i < ints.length; i++)
            {
                int value;
                if (ThreadLocalRandom.current().nextInt(101) <= probability)
                {
                    int increment = ThreadLocalRandom.current().nextInt(10);
                    value = max + increment;
                    aboveCount++;
                }
                else
                {
                    // Decrement by at least 1
                    int decrement = ThreadLocalRandom.current().nextInt(10) + 1;
                    value = max - decrement;
                }
                ints[i] = value;
                max = Math.max(max, value);
            }

            abovePercent = ((aboveCount + 1) * 100) / ints.length;
        } while (abovePercent != probability);
    }
}


Focusing my comment below on 100% which is where the differences appear:

test2 (100%):

 ;; B12: #	out( B21 B13 ) <- in( B11 B20 )  Freq: 1.6744e+09
  0x00007f15bcada2e9:   movl		0x14(%rsi, %rdx, 4), %r11d
                                                            ;*iaload {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestIntMax::test2 at 14 (line 71)
  0x00007f15bcada2ee:   cmpl		%r11d, %r10d
  0x00007f15bcada2f1:   jge		0x7f15bcada362      ;*istore_1 {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestIntMax::test2 at 25 (line 71)


test1 (100%)

 ;; B10: #	out( B10 B11 ) <- in( B9 B10 ) Loop( B10-B10 inner main of N64 strip mined) Freq: 1.6744e+09
  0x00007f15bcad9a70:   movl		0x4c(%rsi, %rdx, 4), %r11d
  0x00007f15bcad9a75:   movl		%r11d, (%rsp)
  0x00007f15bcad9a79:   movl		0x48(%rsi, %rdx, 4), %r10d
  0x00007f15bcad9a7e:   movl		%r10d, 4(%rsp)
  0x00007f15bcad9a83:   movl		0x10(%rsi, %rdx, 4), %r11d
  0x00007f15bcad9a88:   movl		0x14(%rsi, %rdx, 4), %r9d
  0x00007f15bcad9a8d:   movl		0x44(%rsi, %rdx, 4), %r10d
  0x00007f15bcad9a92:   movl		%r10d, 8(%rsp)
  0x00007f15bcad9a97:   movl		0x18(%rsi, %rdx, 4), %r8d
  0x00007f15bcad9a9c:   cmpl		%r11d, %eax
  0x00007f15bcad9a9f:   cmovll		%r11d, %eax
  0x00007f15bcad9aa3:   cmpl		%r9d, %eax
  0x00007f15bcad9aa6:   cmovll		%r9d, %eax
  0x00007f15bcad9aaa:   movl		0x20(%rsi, %rdx, 4), %r10d
  0x00007f15bcad9aaf:   cmpl		%r8d, %eax
  0x00007f15bcad9ab2:   cmovll		%r8d, %eax
  0x00007f15bcad9ab6:   movl		0x24(%rsi, %rdx, 4), %r8d
  0x00007f15bcad9abb:   movl		0x28(%rsi, %rdx, 4), %r11d
                                                            ;   {no_reloc}
  0x00007f15bcad9ac0:   movl		0x2c(%rsi, %rdx, 4), %ecx
  0x00007f15bcad9ac4:   movl		0x30(%rsi, %rdx, 4), %r9d
  0x00007f15bcad9ac9:   movl		0x34(%rsi, %rdx, 4), %edi
  0x00007f15bcad9acd:   movl		0x38(%rsi, %rdx, 4), %ebx
  0x00007f15bcad9ad1:   movl		0x3c(%rsi, %rdx, 4), %ebp
  0x00007f15bcad9ad5:   movl		0x40(%rsi, %rdx, 4), %r13d
  0x00007f15bcad9ada:   movl		0x1c(%rsi, %rdx, 4), %r14d
  0x00007f15bcad9adf:   cmpl		%r14d, %eax
  0x00007f15bcad9ae2:   cmovll		%r14d, %eax
  0x00007f15bcad9ae6:   cmpl		%r10d, %eax
  0x00007f15bcad9ae9:   cmovll		%r10d, %eax
  0x00007f15bcad9aed:   cmpl		%r8d, %eax
  0x00007f15bcad9af0:   cmovll		%r8d, %eax
  0x00007f15bcad9af4:   cmpl		%r11d, %eax
  0x00007f15bcad9af7:   cmovll		%r11d, %eax
  0x00007f15bcad9afb:   cmpl		%ecx, %eax
  0x00007f15bcad9afd:   cmovll		%ecx, %eax
  0x00007f15bcad9b00:   cmpl		%r9d, %eax
  0x00007f15bcad9b03:   cmovll		%r9d, %eax
  0x00007f15bcad9b07:   cmpl		%edi, %eax
  0x00007f15bcad9b09:   cmovll		%edi, %eax
  0x00007f15bcad9b0c:   cmpl		%ebx, %eax
  0x00007f15bcad9b0e:   cmovll		%ebx, %eax
  0x00007f15bcad9b11:   cmpl		%ebp, %eax
  0x00007f15bcad9b13:   cmovll		%ebp, %eax
  0x00007f15bcad9b16:   cmpl		%r13d, %eax
  0x00007f15bcad9b19:   cmovll		%r13d, %eax
  0x00007f15bcad9b1d:   cmpl		8(%rsp), %eax
  0x00007f15bcad9b21:   movl		8(%rsp), %r11d
  0x00007f15bcad9b26:   cmovll		%r11d, %eax
  0x00007f15bcad9b2a:   cmpl		4(%rsp), %eax
  0x00007f15bcad9b2e:   movl		4(%rsp), %r10d
  0x00007f15bcad9b33:   cmovll		%r10d, %eax
  0x00007f15bcad9b37:   cmpl		(%rsp), %eax
  0x00007f15bcad9b3a:   movl		(%rsp), %r11d
  0x00007f15bcad9b3e:   cmovll		%r11d, %eax         ;*invokestatic max {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestIntMax::test1 at 15 (line 61)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2663633050

From jbhateja at openjdk.org  Mon Feb 17 16:53:13 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 17 Feb 2025 16:53:13 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <ikTvrFILQiZVSo1YUW_Sc3k3ifMin9UN2eHpcscdcmQ=.eddf8a3c-9e82-40b9-bfca-c79a9d69902d@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <ljxrhzoRck0LUkRbHYC_0hfPXiW_L1vuw0K7B8lKUKY=.fea555f9-651a-47a1-8c98-b33470d85a8b@github.com>
 <ikTvrFILQiZVSo1YUW_Sc3k3ifMin9UN2eHpcscdcmQ=.eddf8a3c-9e82-40b9-bfca-c79a9d69902d@github.com>
Message-ID: <m19jTjei4Qn7ddtd3AIHPuxlsv2tCx6CmfNMZjttsks=.15b8d18e-3139-4665-b53a-6cd21f64d1c0@github.com>

On Thu, 13 Feb 2025 07:52:30 GMT, Nicole Xu <duke at openjdk.org> wrote:

>> Oh, the OCA-verify is still stuck. I'm sorry about that ? 
>> I pinged my manager @TobiHartmann , he will reach out to see what's the issue.
>
> Hi @eme64, do you see any risks here? Would you please help to review the patch? Thanks.

> @xyyNicole @jatin-bhateja I think it is reasonable to just fix the benchmark so that it still has the same behaviour, just without the out-of-bounds exception. @jatin-bhateja you originally wrote the benchmark, and it could make sense if you fixed it up to what it should be more ideally. @xyyNicole I propose that we file a follow-up RFE to fix the benchmark, and just mention that issue in the benchmark.
> 
> What do you think?

Hi @xyyNicole , 

May I request you to kindly file a follow up RFE mentioning the discussed issues.
Performance of lanewise operations works best without any noise if its fed contiguous memory locations.

Best Regards,
Jatin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2663639602

From galder at openjdk.org  Mon Feb 17 17:05:28 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 17 Feb 2025 17:05:28 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
Message-ID: <WmvAVC0dQC0czj5aQWgjKPqKAVaHGnVhoqUbR_B8dB0=.ae621dd5-172e-41ce-be78-402acaad8b31@github.com>

On Fri, 7 Feb 2025 12:39:24 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Fix typo
>  - Renaming methods and variables and add docu on algorithms
>  - Fix copyright years
>  - Make sure it runs with cpus with either avx512 or asimd
>  - Test can only run with 256 bit registers or bigger
>    
>    * Remove platform dependant check
>    and use platform independent configuration instead.
>  - Fix license header
>  - Tests should also run on aarch64 asimd=true envs
>  - Added comment around the assertions
>  - Adjust min/max identity IR test expectations after changes
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/ba549afe...a190ae68

Another interesting comparison arises above when comparing `test2` in 80% vs 100%:

test2 (100%):

 ;; B12: #	out( B21 B13 ) <- in( B11 B20 )  Freq: 1.6744e+09
  0x00007f15bcada2e9:   movl		0x14(%rsi, %rdx, 4), %r11d
                                                            ;*iaload {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestIntMax::test2 at 14 (line 71)
  0x00007f15bcada2ee:   cmpl		%r11d, %r10d
  0x00007f15bcada2f1:   jge		0x7f15bcada362      ;*istore_1 {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestIntMax::test2 at 25 (line 71)


test2(80%):

 ;; B10: #	out( B10 B11 ) <- in( B9 B10 ) Loop( B10-B10 inner main of N64 strip mined) Freq: 1.6744e+09
  0x00007fe850ada2f0:   movl		0x4c(%rsi, %rdx, 4), %r11d
  0x00007fe850ada2f5:   movl		%r11d, (%rsp)
  0x00007fe850ada2f9:   movl		0x48(%rsi, %rdx, 4), %r10d
  0x00007fe850ada2fe:   movl		%r10d, 4(%rsp)
  0x00007fe850ada303:   movl		0x10(%rsi, %rdx, 4), %r11d
  0x00007fe850ada308:   movl		0x14(%rsi, %rdx, 4), %r9d
  0x00007fe850ada30d:   movl		0x44(%rsi, %rdx, 4), %r10d
  0x00007fe850ada312:   movl		%r10d, 8(%rsp)
  0x00007fe850ada317:   movl		0x18(%rsi, %rdx, 4), %r8d
  0x00007fe850ada31c:   cmpl		%r11d, %eax
  0x00007fe850ada31f:   cmovll		%r11d, %eax
  0x00007fe850ada323:   cmpl		%r9d, %eax
  0x00007fe850ada326:   cmovll		%r9d, %eax
  0x00007fe850ada32a:   movl		0x20(%rsi, %rdx, 4), %r10d
  0x00007fe850ada32f:   cmpl		%r8d, %eax
  0x00007fe850ada332:   cmovll		%r8d, %eax
  0x00007fe850ada336:   movl		0x24(%rsi, %rdx, 4), %r8d
  0x00007fe850ada33b:   movl		0x28(%rsi, %rdx, 4), %r11d
                                                            ;   {no_reloc}
  0x00007fe850ada340:   movl		0x2c(%rsi, %rdx, 4), %ecx
  0x00007fe850ada344:   movl		0x30(%rsi, %rdx, 4), %r9d
  0x00007fe850ada349:   movl		0x34(%rsi, %rdx, 4), %edi
  0x00007fe850ada34d:   movl		0x38(%rsi, %rdx, 4), %ebx
  0x00007fe850ada351:   movl		0x3c(%rsi, %rdx, 4), %ebp
  0x00007fe850ada355:   movl		0x40(%rsi, %rdx, 4), %r13d
  0x00007fe850ada35a:   movl		0x1c(%rsi, %rdx, 4), %r14d
  0x00007fe850ada35f:   cmpl		%r14d, %eax
  0x00007fe850ada362:   cmovll		%r14d, %eax
  0x00007fe850ada366:   cmpl		%r10d, %eax
  0x00007fe850ada369:   cmovll		%r10d, %eax
  0x00007fe850ada36d:   cmpl		%r8d, %eax
  0x00007fe850ada370:   cmovll		%r8d, %eax
  0x00007fe850ada374:   cmpl		%r11d, %eax
  0x00007fe850ada377:   cmovll		%r11d, %eax
  0x00007fe850ada37b:   cmpl		%ecx, %eax
  0x00007fe850ada37d:   cmovll		%ecx, %eax
  0x00007fe850ada380:   cmpl		%r9d, %eax
  0x00007fe850ada383:   cmovll		%r9d, %eax
  0x00007fe850ada387:   cmpl		%edi, %eax
  0x00007fe850ada389:   cmovll		%edi, %eax
  0x00007fe850ada38c:   cmpl		%ebx, %eax
  0x00007fe850ada38e:   cmovll		%ebx, %eax
  0x00007fe850ada391:   cmpl		%ebp, %eax
  0x00007fe850ada393:   cmovll		%ebp, %eax
  0x00007fe850ada396:   cmpl		%r13d, %eax
  0x00007fe850ada399:   cmovll		%r13d, %eax
  0x00007fe850ada39d:   cmpl		8(%rsp), %eax
  0x00007fe850ada3a1:   movl		8(%rsp), %r11d
  0x00007fe850ada3a6:   cmovll		%r11d, %eax
  0x00007fe850ada3aa:   cmpl		4(%rsp), %eax
  0x00007fe850ada3ae:   movl		4(%rsp), %r10d
  0x00007fe850ada3b3:   cmovll		%r10d, %eax
  0x00007fe850ada3b7:   cmpl		(%rsp), %eax
  0x00007fe850ada3ba:   movl		(%rsp), %r11d
  0x00007fe850ada3be:   cmovll		%r11d, %eax         ;*istore_1 {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - TestIntMax::test2 at 25 (line 71)


There are a couple of things is puzzling me. This test is like a reduction test and no vectorization appears to be kicking in any of the percentages (I've not enabled vectorization SW rejections to check). The other thing that is strange is the overall time. When no vectorization kicks in and the code uses cmovs, I've been seeing worse performance numbers compared to say compare and jumps, particularly in 100% tests. With `TestIntMax` it appears to be the opposite, test2 at 100% uses jpm+cmp, which performs worse than cmov versions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2663665858

From galder at openjdk.org  Mon Feb 17 17:21:15 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 17 Feb 2025 17:21:15 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <WmvAVC0dQC0czj5aQWgjKPqKAVaHGnVhoqUbR_B8dB0=.ae621dd5-172e-41ce-be78-402acaad8b31@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
 <WmvAVC0dQC0czj5aQWgjKPqKAVaHGnVhoqUbR_B8dB0=.ae621dd5-172e-41ce-be78-402acaad8b31@github.com>
Message-ID: <GOYBbeJu9CPh96LNBu-zbWHeMd1U8chVdXCIkoQmz48=.1cd35133-6aae-4d1c-ad3e-60dece9d2744@github.com>

On Mon, 17 Feb 2025 17:02:47 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> This test is like a reduction test and no vectorization appears to be kicking in any of the percentages (I've not enabled vectorization SW rejections to check).

Ah, that's probably because of profitable vectorization checks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2663710153

From duke at openjdk.org  Mon Feb 17 19:52:21 2025
From: duke at openjdk.org (duke)
Date: Mon, 17 Feb 2025 19:52:21 GMT
Subject: Withdrawn: 8342869: Errors related to unused code on Windows after
 8339120 in awt
In-Reply-To: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
References: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
Message-ID: <y5sbvad1Y5n2bzxGQK97vWP8RTQKIgsvg8EW8xXmJk4=.8629765e-ff9d-4f6b-a609-ff631a30e0d2@github.com>

On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
> 
> build.log on release configuration:
> 
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=]
>  3560 |                     static const UINT _VKS_ALT_MASK = 0x04;
>       |                                       ^~~~~~~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs]
>  1361 | } SUBTABLE, *PSUBTABLE;
>       |              ^~~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs]
>  1588 | } HEAD, *PHEAD;
>       |          ^~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs]
>  1595 | } ENTRY, *PENTRY;
>       |           ^~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21655

From duke at openjdk.org  Mon Feb 17 19:57:20 2025
From: duke at openjdk.org (duke)
Date: Mon, 17 Feb 2025 19:57:20 GMT
Subject: Withdrawn: 8310996: Add JFR event for connect operations
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <6sD5BK942SQuYweZCugrpTIeQYwDu_5TTfqxXn2iyxI=.79bae3dc-9ad0-4a1c-be03-b62d39d41043@github.com>

On Wed, 16 Oct 2024 01:19:15 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21528

From duke at openjdk.org  Tue Feb 18 02:11:17 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Tue, 18 Feb 2025 02:11:17 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v2]
In-Reply-To: <Cpc_kxrUHuC3Sj2zluPHtPICI63z2swogYec43ycS-I=.b034cc18-7472-4a0c-88d7-2f50eb258692@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
 <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>
 <bfT8EMRk6msqkRF32_vQCfZvirTiWsvg0hrOpThz9i4=.1f6626ed-637e-4ff3-827d-f5dc34094910@github.com>
 <A_C2myp2dclvSO5vDmJD4sl9FMoWFCP-j1P7ihltcKc=.c1cb149b-0e33-4d6d-8399-8d6dfe5dbccc@github.com>
 <dl48ChO5x4futsrtaAjvvlxb4Enekr9S1qFCwQtGVkU=.904d075e-786d-4fe2-980c-f6e9143ba86a@github.com>
 <fcvrEMeNBT-Cp7C5MR_zsON1WDWouU72qVik-DiN4k0=.7b655123-f2ff-4c12-8d94-0845be867d05@github.com>
 <wmIgd_-kflkNtl_HeIq8sAgfBAeDGuYvT9xwsl1TnGc=.4e09a4cf-1f9a-441c-9f86-8f37a682757f@github.com>
 <G0QHgSxgst6mR2wqn6_LdUAb1C5dGfTVcLonEMBbC8Q=.dd75c6a5-9dd4-4605-89c3-fda9b17cd080@github.com>
 <T6tLX_u6tuehydDgOk-Zy90LEIsKMBVHyAtukZgZETo=.dcfd7512-360d-4f51-8b49-7d42199aa6d7@github.com>
 <Cpc_kxrUHuC3Sj2zluPHtPICI63z2swogYe
 c43ycS-I=.b034cc18-7472-4a0c-88d7-2f50eb258692@github.com>
Message-ID: <HKYrg1nnFMjktEeAAeqF2XE3gy7wQ6-nR7s30Fqecbo=.604a4916-dc31-4bec-a90d-62d5eff16d5b@github.com>

On Mon, 17 Feb 2025 13:52:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>>>I've looked through a lot of github logging properties files and see no evidence that the pattern of use...
>> 
>> Closed source GOTS/COTS products that require troubleshooting require using all of the logging API features when other solutions are forbidden for non-tech reasons.
>> 
>> To the point though, limit one with a count makes FileHandler work like the MemoryHandler in that at the end of say a batch run you have exactly the last N records in the form of N files.  That is a feature.
>> 
>>>The reason I'm pushing back a little here is that the idea of making a "secret handshake"
>> 
>> The behavior is what i care about not the implementation.  I would rather focus on fitting your change and retain old behavior. Behaviorly, i think deadlock can be fixed with retaining existing log rollover behavior. Secret handshake off the table then. Done and dead.
>> 
>> New idea. All JDK subclass of StreamHandler call flush.
>> 
>> 1. Put rotate check in FileHandler::flush
>> 2. Make StreamHandler call flush while holding lock.
>> 3. Remove explicit flush call in subclasses.
>> 4. Add auto flush property to StreamHandler, default false.
>> 5. Set auto flush true in subclass.
>> 
>> 
>>>..."EncryptedLogFileHandler" that's not a sub-class of FileHandler.
>> 
>> That example does apply because if it is not a FileHandler there is no check to call rotate method.  What am I missing?
>
> The issue with a non-JDK stream handler subclass, is that it doesn't have the privilege of being able to do anything before the `super.publish(...)` call has finished and the handler instance is unlocked.
> 
> Using a package protected method to achieve this only for JDK classes is just leaving a slightly bad taste in my mouth.
> 
> There's just nothing in the API, other than perhaps brittle things like using an overridden stream and detecting writes (which Daniel has convinced me is too brittle to be in the JDK) to allow a non-JDK version of FileHandler to be implemented with "synchronous post publish() actions". And I personally dislike the idea that people can't write their own equivalent of FileHandler (with some extra feature) outside the JDK.
> 
> And, just FYI, there's basically almost no chance we'd consider adding new methods or properties to the logging package at this point. I'd be far more scared about adding "auto flushing" to existing handler sub-classes than changing the never specified behaviour with respect to file size (though the pathological 1-byte file to force rotation per log record is something I hadn't considered, but has also never been promised to actually work).

My notes from 2006 on post publish actions suggested promoting `public void push` to StreamHandler and perhaps Handler as a handler defined action. Same for pushLevel but that is not radically different from auto flush I just proposed.

Another option here is to check written before and after super.publish in FileHandler. That way when 2nd record knows a rotate is required before writing. The if check is a bit different between before and after.  That should cover all scheduling combinations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1958964838

From jwaters at openjdk.org  Tue Feb 18 02:39:25 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 18 Feb 2025 02:39:25 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v18]
In-Reply-To: <GTm_Er6CT-A4aFdVeWEMCXyJKWWrW56VLe9On4W02fk=.6bb331e3-3a26-4f5e-befb-42e955e4d994@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <GTm_Er6CT-A4aFdVeWEMCXyJKWWrW56VLe9On4W02fk=.6bb331e3-3a26-4f5e-befb-42e955e4d994@github.com>
Message-ID: <npCqs_ZZsS5MkLbKdkH2HqSrD8KI0loTBdo1DEIMfe4=.ac942c11-d10a-4bc2-a820-396656331758@github.com>

On Tue, 11 Feb 2025 06:32:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions

Is anyone else getting compile failures after this was integrated? This weirdly seems to only happen on Linux

* For target hotspot_variant-server_libjvm_objs_mulnode.o:
/home/runner/work/jdk/jdk/src/hotspot/share/opto/mulnode.cpp: In member function ?virtual const Type* FmaHFNode::Value(PhaseGVN*) const?:
/home/runner/work/jdk/jdk/src/hotspot/share/opto/mulnode.cpp:1944:37: error: call of overloaded ?make(double)? is ambiguous
 1944 |   return TypeH::make(fma(f1, f2, f3));
      |                                     ^
In file included from /home/runner/work/jdk/jdk/src/hotspot/share/opto/node.hpp:31,
                 from /home/runner/work/jdk/jdk/src/hotspot/share/opto/addnode.hpp:28,
                 from /home/runner/work/jdk/jdk/src/hotspot/share/opto/mulnode.cpp:26:
/home/runner/work/jdk/jdk/src/hotspot/share/opto/type.hpp:544:23: note: candidate: ?static const TypeH* TypeH::make(float)?
  544 |   static const TypeH* make(float f);
      |                       ^~~~
/home/runner/work/jdk/jdk/src/hotspot/share/opto/type.hpp:545:23: note: candidate: ?static const TypeH* TypeH::make(short int)?
  545 |   static const TypeH* make(short f);
      |                       ^~~~

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2664473623

From duke at openjdk.org  Tue Feb 18 03:53:12 2025
From: duke at openjdk.org (Nicole Xu)
Date: Tue, 18 Feb 2025 03:53:12 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
Message-ID: <kaboVW6MtayTPC-GSt_U-S8KjPsenaU87af71HBem0U=.d4be0c75-637d-45d7-a291-bf8a3ee8313b@github.com>

On Wed, 8 Jan 2025 09:04:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86 and AArch64 with the following error:
> 
> 
> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
> 
> 
> The variable `long256_arr_idx` is misused when indexing  'LongVector l2, l3, l4, l5' in function `maskedLogicOperationsLongKernel()`. 'long256_arr_idx' increases by 4 every time the benchmark runs and ensures the incremented value remains within the bounds of the array. However, for `LongVector.SPECIES_512`, it loads 8 numbers from the array each time the benchmark runs, resulting in an out-of-range indexing issue.
> 
> Hence, we revised the index variables from `long256_arr_idx` to `long512_arr_idx`, which has a stride of 8, to ensure that the loaded vector is inside of the array boundary for all vector species. This is also consistent with other kernel functions.
> 
> Additionally, some defined but unused variables have been removed.

Sure. Since I am very new to openJDK, I asked my teammate for help to file the follow-up RFE.

Here is the https://bugs.openjdk.org/browse/JDK-8350215 with description of the discussed issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2664543916

From galder at openjdk.org  Tue Feb 18 08:04:21 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 18 Feb 2025 08:04:21 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
Message-ID: <zQC1cGYzePtgsQhjhK3FFht5BwWRGsyBxQJJm61LaW8=.b013acaf-b904-4a9a-8eeb-c49aab65ca2b@github.com>

On Fri, 7 Feb 2025 12:39:24 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Fix typo
>  - Renaming methods and variables and add docu on algorithms
>  - Fix copyright years
>  - Make sure it runs with cpus with either avx512 or asimd
>  - Test can only run with 256 bit registers or bigger
>    
>    * Remove platform dependant check
>    and use platform independent configuration instead.
>  - Fix license header
>  - Tests should also run on aarch64 asimd=true envs
>  - Added comment around the assertions
>  - Adjust min/max identity IR test expectations after changes
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/6ad0c61a...a190ae68

What is happening with int min/max needs a separate investigation because based on my testing, the int min/max intrinsic is both a regression and a performance improvement! Check this out:


make test TEST="micro:org.openjdk.bench.java.lang.MinMaxVector.intReductionSimpleMax" MICRO="FORK=1"
Benchmark                           (probability)  (size)   Mode  Cnt    Score   Error   Units
MinMaxVector.intReductionSimpleMax             50    2048  thrpt    4  460.585 ? 0.348  ops/ms
MinMaxVector.intReductionSimpleMax             80    2048  thrpt    4  460.633 ? 0.103  ops/ms
MinMaxVector.intReductionSimpleMax            100    2048  thrpt    4  460.580 ? 0.091  ops/ms

make test TEST="micro:org.openjdk.bench.java.lang.MinMaxVector.intReductionSimpleMax" MICRO="FORK=1;OPTIONS=-jvmArgs -XX:CompileCommand=option,org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_intReductionSimpleMax_jmhTest::intReductionSimpleMax_thrpt_jmhStub,ccstrlist,DisableIntrinsic,_max"
Benchmark                           (probability)  (size)   Mode  Cnt     Score   Error   Units
MinMaxVector.intReductionSimpleMax             50    2048  thrpt    4   460.479 ? 0.044  ops/ms
MinMaxVector.intReductionSimpleMax             80    2048  thrpt    4   460.587 ? 0.106  ops/ms
MinMaxVector.intReductionSimpleMax            100    2048  thrpt    4  1027.831 ? 9.353  ops/ms
80%:
          ??      ?   0x00007ffb200fa089:   cmpl		%r11d, %r10d
   3.04%  ??      ?   0x00007ffb200fa08c:   cmovll		%r11d, %r10d
   4.38%  ??      ?   0x00007ffb200fa090:   cmpl		%ebx, %r10d
   1.61%  ??      ?   0x00007ffb200fa093:   cmovll		%ebx, %r10d
   2.79%  ??      ?   0x00007ffb200fa097:   cmpl		%edi, %r10d
   2.92%  ??      ?   0x00007ffb200fa09a:   cmovll		%edi, %r10d         ;*ireturn {reexecute=0 rethrow=0 return_oop=0}
          ??      ?                                                             ; - java.lang.Math::max at 10 (line 2023)
          ??      ?                                                             ; - org.openjdk.bench.java.lang.MinMaxVector::intReductionSimpleMax at 23 (line 232)
100%:
   3.11%  ???????   ??????    ?             0x00007f26c00f8f9c:   nopl		(%rax)
   3.31%  ???????   ??????    ?             0x00007f26c00f8fa0:   cmpl		%r10d, %ecx
          ????????  ??????    ?             0x00007f26c00f8fa3:   jge		0x7f26c00f8ff1      ;*ireturn {reexecute=0 rethrow=0 return_oop=0}
          ????????  ??????    ?                                                                       ; - java.lang.Math::max at 10 (line 2023)
          ????????  ??????    ?                                                                       ; - org.openjdk.bench.java.lang.MinMaxVector::intReductionSimpleMax at 23 (line 232)
          ????????  ??????    ?                                                                       ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_intReductionSimpleMax_jmhTest::intReductionSimpleMax_thrpt_jmhStub at 19 (line 124)

make test TEST="micro:org.openjdk.bench.java.lang.MinMaxVector.intReductionMultiplyMax" MICRO="FORK=1"
Benchmark                             (probability)  (size)   Mode  Cnt     Score   Error   Units
MinMaxVector.intReductionMultiplyMax             50    2048  thrpt    4  2815.614 ? 0.406  ops/ms
MinMaxVector.intReductionMultiplyMax             80    2048  thrpt    4  2814.943 ? 2.174  ops/ms
MinMaxVector.intReductionMultiplyMax            100    2048  thrpt    4  2815.285 ? 1.725  ops/ms

make test TEST="micro:org.openjdk.bench.java.lang.MinMaxVector.intReductionMultiplyMax" MICRO="FORK=1;OPTIONS=-jvmArgs -XX:CompileCommand=option,org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_intReductionMultiplyMax_jmhTest::intReductionMultiplyMax_thrpt_jmhStub,ccstrlist,DisableIntrinsic,_max"
Benchmark                             (probability)  (size)   Mode  Cnt     Score   Error   Units
MinMaxVector.intReductionMultiplyMax             50    2048  thrpt    4  2802.062 ? 0.710  ops/ms
MinMaxVector.intReductionMultiplyMax             80    2048  thrpt    4  2814.874 ? 4.058  ops/ms
MinMaxVector.intReductionMultiplyMax            100    2048  thrpt    4   883.879 ? 0.327  ops/ms
80%:
   3.54%  ?    ?? ?????  0x00007faa700fa177:   vpmaxsd		%ymm4, %ymm5, %ymm13;*ireturn {reexecute=0 rethrow=0 return_oop=0}
          ?    ?? ?????                                                            ; - java.lang.Math::max at 10 (line 2023)

100:
   7.50%  ??????????????????? ?             0x00007f75280f8849:   imull		$0xb, 0x2c(%rbp, %r11, 4), %r10d
          ??????????????????? ?                                                                       ;*imul {reexecute=0 rethrow=0 return_oop=0}
          ??????????????????? ?                                                                       ; - org.openjdk.bench.java.lang.MinMaxVector::intReductionMultiplyMax at 20 (line 221)
          ??????????????????? ?                                                                       ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_intReductionMultiplyMax_jmhTest::intReductionMultiplyMax_thrpt_jmhStub at 19 (line 124)
   3.85%  ??????????????????? ?             0x00007f75280f884f:   cmpl		%r10d, %r8d
          ??????????????????? ?             0x00007f75280f8852:   jl		0x7f75280f87d0      ;*if_icmplt {reexecute=0 rethrow=0 return_oop=0}
          ?????????? ???????? ?                                                                       ; - java.lang.Math::max at 2 (line 2023)
          ?????????? ???????? ?                                                                       ; - org.openjdk.bench.java.lang.MinMaxVector::intReductionMultiplyMax at 26 (line 222)
          ?????????? ???????? ?                                                                       ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_intReductionMultiplyMax_jmhTest::intReductionMultiplyMax_thrpt_jmhStub at 19 (line 124)


I ran the exact same test with longs and I don't see such an issue. The performance is always the same either with the intrisinc or disabling it as shown above.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2664871838

From galder at openjdk.org  Tue Feb 18 08:16:19 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 18 Feb 2025 08:16:19 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FFeVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
 <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
 <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
 <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FF
 eVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>
Message-ID: <G9nejN6fsDD5TrseZaI4aJAIv2hqZOy2aNwRRjd460M=.5ade26c5-f6eb-4cf8-af80-9dd469c6bf3f@github.com>

On Mon, 17 Feb 2025 15:02:32 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> @rwestrel @galderz 
>> 
>>> It seems overall, we likely win more than we loose with this intrinsic, so I would integrate this change as it is and file a bug to keep track of remaining issues.
>> 
>> I'm a little scared to just accept the regressions, especially for this "most average looking case":
>> Imagine you have an array with random numbers. Or at least numbers in a random order. If we take the max, then we expect the first number to be max with probability 1, the second 1/2, the third 1/3, the i'th 1/i. So the average branch probability is `n / (sum_i 1/i)`. This goes closer and closer to zero, the larger the array. This means that the "average" case has an extreme probability. And so if we do not vectorize, then this gets us a regression with the current patch. And vectorization is a little fragile, it only takes very little for vectorization not to kick in.
>> 
>>> The Min/Max nodes are floating nodes. They can hoist out of loop and common reliably in ways that are not guaranteed otherwise.
>> 
>> I suppose we could write an optimization that can hoist out loop independent if-diamonds out of a loop. If the condition and all phi inputs are loop invariant, you could just cut the diamond out of the loop, and paste it before the loop entry.
>> 
>>> Shouldn't int min/max be affected the same way?
>> 
>> I think we should be able to see the same issue here, actually. Yes. Here a quick benchmark below:
>> 
>> 
>> java -XX:CompileCommand=compileonly,TestIntMax::test* -XX:CompileCommand=printcompilation,TestIntMax::test* -XX:+TraceNewVectors TestIntMax.java
>> CompileCommand: compileonly TestIntMax.test* bool compileonly = true
>> CompileCommand: PrintCompilation TestIntMax.test* bool PrintCompilation = true
>> Warmup
>> 5225   93 %     3       TestIntMax::test1 @ 5 (27 bytes)
>> 5226   94       3       TestIntMax::test1 (27 bytes)
>> 5226   95 %     4       TestIntMax::test1 @ 5 (27 bytes)
>> 5238   96       4       TestIntMax::test1 (27 bytes)
>> Run
>> Time: 542056319
>> Warmup
>> 6320  101 %     3       TestIntMax::test2 @ 5 (34 bytes)
>> 6322  102 %     4       TestIntMax::test2 @ 5 (34 bytes)
>> 6329  103       4       TestIntMax::test2 (34 bytes)
>> Run
>> Time: 166815209
>> 
>> That's a 4x regression on random input data!
>> 
>> With:
>> 
>> import java.util.Random;
>> 
>> public class TestIntMax {
>>     private static Random RANDOM = new Random();
>> 
>>     public static void main(String[] args) {
>>         int[] a = new int[64 * 1024];
>>         for (int i = 0; i < a.length; i++) {
>>...
>
>> I think we should be able to see the same issue here, actually. Yes. Here a quick benchmark below:
> 
> I observe the same:
> 
> 
> Warmup
> 751    3    b        TestIntMax::test1 (27 bytes)
> Run
> Time: 360 550 158
> Warmup
> 1862   15    b        TestIntMax::test2 (34 bytes)
> Run
> Time: 92 116 170
> 
> 
> But then with this:
> 
> 
> diff --git a/src/hotspot/cpu/x86/x86_64.ad b/src/hotspot/cpu/x86/x86_64.ad
> index 8cc4a970bfd..9abda8f4178 100644
> --- a/src/hotspot/cpu/x86/x86_64.ad
> +++ b/src/hotspot/cpu/x86/x86_64.ad
> @@ -12037,16 +12037,20 @@ instruct cmovI_reg_l(rRegI dst, rRegI src, rFlagsReg cr)
>  %}
>  
>  
> -instruct maxI_rReg(rRegI dst, rRegI src)
> +instruct maxI_rReg(rRegI dst, rRegI src, rFlagsReg cr)
>  %{
>    match(Set dst (MaxI dst src));
> +  effect(KILL cr);
>  
>    ins_cost(200);
> -  expand %{
> -    rFlagsReg cr;
> -    compI_rReg(cr, dst, src);
> -    cmovI_reg_l(dst, src, cr);
> +  ins_encode %{
> +    Label done;
> +    __ cmpl($src$$Register, $dst$$Register);
> +    __ jccb(Assembler::less, done);
> +    __ mov($dst$$Register, $src$$Register);
> +    __ bind(done);
>    %}
> +  ins_pipe(pipe_cmov_reg);
>  %}
>  
>  // ============================================================================
> 
> 
> the performance gap narrows:
> 
> 
> Warmup
> 770    3    b        TestIntMax::test1 (27 bytes)
> Run
> Time: 94 951 677
> Warmup
> 1312   15    b        TestIntMax::test2 (34 bytes)
> Run
> Time: 70 053 824
> 
> 
> (the number of test2 fluctuates quite a bit). Does it ever make sense to implement `MaxI` with a conditional move then?

Note something I spoke with @rwestrel yesterday in the context of long min/max vs int min/max.

Int has an ad implementation for min/max whereas long as not. My very first prototype of this issue was to mimmic what int did with log, but talking to @rwestrel we decided it would be better to implement this without introducing platform specific changes.

So, following Roland's thread in https://github.com/openjdk/jdk/pull/20098#issuecomment-2663379660, I could add ad changes for say x86 and aarch64 for long such that it uses branch instead of cmov. Note that the cmov fallback of long min/max comes from macro expansion, not platform specific changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2664893516

From galder at openjdk.org  Tue Feb 18 08:20:15 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 18 Feb 2025 08:20:15 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FFeVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
 <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
 <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
 <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FF
 eVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>
Message-ID: <ajuhBKoDVKmn_D9vg3O3OVUQVVunAT02KhXcaapMokE=.5b8f2f36-6521-4389-97de-0bf8deeb47dc@github.com>

On Mon, 17 Feb 2025 15:02:32 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> @rwestrel @galderz 
>> 
>>> It seems overall, we likely win more than we loose with this intrinsic, so I would integrate this change as it is and file a bug to keep track of remaining issues.
>> 
>> I'm a little scared to just accept the regressions, especially for this "most average looking case":
>> Imagine you have an array with random numbers. Or at least numbers in a random order. If we take the max, then we expect the first number to be max with probability 1, the second 1/2, the third 1/3, the i'th 1/i. So the average branch probability is `n / (sum_i 1/i)`. This goes closer and closer to zero, the larger the array. This means that the "average" case has an extreme probability. And so if we do not vectorize, then this gets us a regression with the current patch. And vectorization is a little fragile, it only takes very little for vectorization not to kick in.
>> 
>>> The Min/Max nodes are floating nodes. They can hoist out of loop and common reliably in ways that are not guaranteed otherwise.
>> 
>> I suppose we could write an optimization that can hoist out loop independent if-diamonds out of a loop. If the condition and all phi inputs are loop invariant, you could just cut the diamond out of the loop, and paste it before the loop entry.
>> 
>>> Shouldn't int min/max be affected the same way?
>> 
>> I think we should be able to see the same issue here, actually. Yes. Here a quick benchmark below:
>> 
>> 
>> java -XX:CompileCommand=compileonly,TestIntMax::test* -XX:CompileCommand=printcompilation,TestIntMax::test* -XX:+TraceNewVectors TestIntMax.java
>> CompileCommand: compileonly TestIntMax.test* bool compileonly = true
>> CompileCommand: PrintCompilation TestIntMax.test* bool PrintCompilation = true
>> Warmup
>> 5225   93 %     3       TestIntMax::test1 @ 5 (27 bytes)
>> 5226   94       3       TestIntMax::test1 (27 bytes)
>> 5226   95 %     4       TestIntMax::test1 @ 5 (27 bytes)
>> 5238   96       4       TestIntMax::test1 (27 bytes)
>> Run
>> Time: 542056319
>> Warmup
>> 6320  101 %     3       TestIntMax::test2 @ 5 (34 bytes)
>> 6322  102 %     4       TestIntMax::test2 @ 5 (34 bytes)
>> 6329  103       4       TestIntMax::test2 (34 bytes)
>> Run
>> Time: 166815209
>> 
>> That's a 4x regression on random input data!
>> 
>> With:
>> 
>> import java.util.Random;
>> 
>> public class TestIntMax {
>>     private static Random RANDOM = new Random();
>> 
>>     public static void main(String[] args) {
>>         int[] a = new int[64 * 1024];
>>         for (int i = 0; i < a.length; i++) {
>>...
>
>> I think we should be able to see the same issue here, actually. Yes. Here a quick benchmark below:
> 
> I observe the same:
> 
> 
> Warmup
> 751    3    b        TestIntMax::test1 (27 bytes)
> Run
> Time: 360 550 158
> Warmup
> 1862   15    b        TestIntMax::test2 (34 bytes)
> Run
> Time: 92 116 170
> 
> 
> But then with this:
> 
> 
> diff --git a/src/hotspot/cpu/x86/x86_64.ad b/src/hotspot/cpu/x86/x86_64.ad
> index 8cc4a970bfd..9abda8f4178 100644
> --- a/src/hotspot/cpu/x86/x86_64.ad
> +++ b/src/hotspot/cpu/x86/x86_64.ad
> @@ -12037,16 +12037,20 @@ instruct cmovI_reg_l(rRegI dst, rRegI src, rFlagsReg cr)
>  %}
>  
>  
> -instruct maxI_rReg(rRegI dst, rRegI src)
> +instruct maxI_rReg(rRegI dst, rRegI src, rFlagsReg cr)
>  %{
>    match(Set dst (MaxI dst src));
> +  effect(KILL cr);
>  
>    ins_cost(200);
> -  expand %{
> -    rFlagsReg cr;
> -    compI_rReg(cr, dst, src);
> -    cmovI_reg_l(dst, src, cr);
> +  ins_encode %{
> +    Label done;
> +    __ cmpl($src$$Register, $dst$$Register);
> +    __ jccb(Assembler::less, done);
> +    __ mov($dst$$Register, $src$$Register);
> +    __ bind(done);
>    %}
> +  ins_pipe(pipe_cmov_reg);
>  %}
>  
>  // ============================================================================
> 
> 
> the performance gap narrows:
> 
> 
> Warmup
> 770    3    b        TestIntMax::test1 (27 bytes)
> Run
> Time: 94 951 677
> Warmup
> 1312   15    b        TestIntMax::test2 (34 bytes)
> Run
> Time: 70 053 824
> 
> 
> (the number of test2 fluctuates quite a bit). Does it ever make sense to implement `MaxI` with a conditional move then?

To make it more explicit: implementing long min/max in ad files as cmp will likely remove all the 100% regressions that are observed here. I'm going to repeat the same MinMaxVector int min/max reduction test above with the ad changes @rwestrel suggested to see what effect they have.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2664903731

From jwtang at openjdk.org  Tue Feb 18 08:45:17 2025
From: jwtang at openjdk.org (Jiawei Tang)
Date: Tue, 18 Feb 2025 08:45:17 GMT
Subject: Withdrawn: 8349763: Expose more ForkJoinPool parameters to configure
 virtual thread scheduler
In-Reply-To: <YeyueE6v3n473qGjXlegW9ISOE-DSqoC7VbNH1TaDTg=.d8d2ba47-d8a2-4460-a77d-822b432c5b60@github.com>
References: <YeyueE6v3n473qGjXlegW9ISOE-DSqoC7VbNH1TaDTg=.d8d2ba47-d8a2-4460-a77d-822b432c5b60@github.com>
Message-ID: <aMnxbkjgdrVLXZjYN9YlqH3y6ReMUBtJRpPWx1CsVkw=.29ce75f1-1f49-415e-80dd-6f03dd059afd@github.com>

On Tue, 11 Feb 2025 02:36:14 GMT, Jiawei Tang <jwtang at openjdk.org> wrote:

> Since the parameters `-Djdk.virtualThreadScheduler.parallelism=N` , `-Djdk.virtualThreadScheduler.maxPoolSize=M`, `-Djdk.virtualThreadScheduler.minimumRunnable=Y` have already been made available, it would be worth considering opening up additional ForkJoinPool-related parameters: `-Djdk.virtualThreadScheduler.corePoolSize=X`, `-Djdk.virtualThreadScheduler.keepAliveTime=Z` and `-Djdk.virtualThreadScheduler.timeUnit`.
> 
> In particular, configuring corePoolSize can help reduce jitter caused by thread ramp-up during application startup, while keepAliveTime and timeUnit ensures more threads are available within the time expected by users. Opening these parameters would be highly meaningful for optimizing virtual thread scheduling.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23549

From epeter at openjdk.org  Tue Feb 18 08:46:17 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 18 Feb 2025 08:46:17 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <ajuhBKoDVKmn_D9vg3O3OVUQVVunAT02KhXcaapMokE=.5b8f2f36-6521-4389-97de-0bf8deeb47dc@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
 <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
 <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
 <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FF
 eVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>
 <ajuhBKoDVKmn_D9vg3O3OVUQVVunAT02KhXcaapMokE=.5b8f2f36-6521-4389-97de-0bf8deeb47dc@github.com>
Message-ID: <N-faJEFC3vJg5m-H3EyMnAkBg3ecpx_YduxpPyXRz8o=.fee546a6-61d3-4ce7-9939-80a1a9e2748e@github.com>

On Tue, 18 Feb 2025 08:17:59 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>>> I think we should be able to see the same issue here, actually. Yes. Here a quick benchmark below:
>> 
>> I observe the same:
>> 
>> 
>> Warmup
>> 751    3    b        TestIntMax::test1 (27 bytes)
>> Run
>> Time: 360 550 158
>> Warmup
>> 1862   15    b        TestIntMax::test2 (34 bytes)
>> Run
>> Time: 92 116 170
>> 
>> 
>> But then with this:
>> 
>> 
>> diff --git a/src/hotspot/cpu/x86/x86_64.ad b/src/hotspot/cpu/x86/x86_64.ad
>> index 8cc4a970bfd..9abda8f4178 100644
>> --- a/src/hotspot/cpu/x86/x86_64.ad
>> +++ b/src/hotspot/cpu/x86/x86_64.ad
>> @@ -12037,16 +12037,20 @@ instruct cmovI_reg_l(rRegI dst, rRegI src, rFlagsReg cr)
>>  %}
>>  
>>  
>> -instruct maxI_rReg(rRegI dst, rRegI src)
>> +instruct maxI_rReg(rRegI dst, rRegI src, rFlagsReg cr)
>>  %{
>>    match(Set dst (MaxI dst src));
>> +  effect(KILL cr);
>>  
>>    ins_cost(200);
>> -  expand %{
>> -    rFlagsReg cr;
>> -    compI_rReg(cr, dst, src);
>> -    cmovI_reg_l(dst, src, cr);
>> +  ins_encode %{
>> +    Label done;
>> +    __ cmpl($src$$Register, $dst$$Register);
>> +    __ jccb(Assembler::less, done);
>> +    __ mov($dst$$Register, $src$$Register);
>> +    __ bind(done);
>>    %}
>> +  ins_pipe(pipe_cmov_reg);
>>  %}
>>  
>>  // ============================================================================
>> 
>> 
>> the performance gap narrows:
>> 
>> 
>> Warmup
>> 770    3    b        TestIntMax::test1 (27 bytes)
>> Run
>> Time: 94 951 677
>> Warmup
>> 1312   15    b        TestIntMax::test2 (34 bytes)
>> Run
>> Time: 70 053 824
>> 
>> 
>> (the number of test2 fluctuates quite a bit). Does it ever make sense to implement `MaxI` with a conditional move then?
>
> To make it more explicit: implementing long min/max in ad files as cmp will likely remove all the 100% regressions that are observed here. I'm going to repeat the same MinMaxVector int min/max reduction test above with the ad changes @rwestrel suggested to see what effect they have.

@galderz I think we will have the same issue with both `int` and `long`: As far as I know, it is really a difficult problem to decide at compile-time if a `cmove` or `branch` is the better choice. I'm not sure there is any heuristic for which you will not find a micro-benchmark where the heuristic made the wrong choice.

To my understanding, these are the factors that impact the performance:
- `cmove` requires all inputs to complete before it can execute, and it has an inherent latency of a cycle or so itself. But you cannot have any branch mispredictions, and hence no branch misprediction penalties (i.e. when the CPU has to flush out the ops from the wrong branch and restart at the branch).
- `branch` can hide some latencies, because we can already continue with the branch that is speculated on. We do not need to wait for the inputs of the comparison to arrive, and we can already continue with the speculated resulting value. But if the speculation is ever wrong, we have to pay the misprediction penalty.

In my understanding, there are roughly 3 scenarios:
- The branch probability is so extreme that the branch predictor would be correct almost always, and so it is profitable to do branching code.
- The branching probability is somewhere in the middle, and the branch is not predictable. Branch mispredictions are very expensive, and so it is better to use `cmove`.
- The branching probability is somewhere in the middle, but the branch is predictable (e.g. swapps back and forth). The branch predictor will have almost no mispredictions, and it is faster to use branching code.

Modeling this precisely is actually a little complex. You would have to know the cost of the `cmove` and the `branching` version of the code. That depends on the latency of the inputs, and the outputs: does the `cmove` dramatically increase the latency on the critical path, and `branching` could hide some of that latency? And you would have to know how good the branch predictor is, which you cannot derive from the branching probability of our profiling (at least not when the probabilities are in the middle, and you don't know if it is a random or predictable pattern).

If we can find a perfect heuristic - that would be fantastic ;)

If we cannot find a perfect heuristic, then we should think about what are the most "common" or "relevant" scenarios, I think.

But let's discuss all of this in a call / offline :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2664956307

From galder at openjdk.org  Tue Feb 18 09:24:18 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 18 Feb 2025 09:24:18 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <N-faJEFC3vJg5m-H3EyMnAkBg3ecpx_YduxpPyXRz8o=.fee546a6-61d3-4ce7-9939-80a1a9e2748e@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
 <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
 <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
 <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FF
 eVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>
 <ajuhBKoDVKmn_D9vg3O3OVUQVVunAT02KhXcaapMokE=.5b8f2f36-6521-4389-97de-0bf8deeb47dc@github.com>
 <N-faJEFC3vJg5m-H3EyMnAkBg3ecpx_YduxpPyXRz8o=.fee546a6-61d3-4ce7-9939-80a1a9e2748e@github.com>
Message-ID: <ilwTxx7G5Uh2ZmiVAv334-cVnqTIyKIyHTmtsdkYUxQ=.f10760eb-0e02-462c-a61a-80c1bada28fe@github.com>

On Tue, 18 Feb 2025 08:43:38 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> But let's discuss all of this in a call / offline :)

Yup.

> I ran the exact same test with longs and I don't see such an issue. The performance is always the same either with the intrisinc or disabling it as shown above.

For the equivalent long tests I think I made a mistake in the id of the disabled intrinsic, it should be `_maxL` and not `_max`. I will repeat the tests and post if any similar differences observed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2665045881

From aturbanov at openjdk.org  Tue Feb 18 09:26:16 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 18 Feb 2025 09:26:16 GMT
Subject: RFR: 8350049: [JMH] Float16OperationsBenchmark fails
 java.lang.NoClassDefFoundError
In-Reply-To: <MAUbF4zfQV2GpI0kgOaRNzNKvFC1sj5FGs49I4PARx0=.436c177b-1061-4e08-8c8c-08c24984faba@github.com>
References: <MAUbF4zfQV2GpI0kgOaRNzNKvFC1sj5FGs49I4PARx0=.436c177b-1061-4e08-8c8c-08c24984faba@github.com>
Message-ID: <tXYEXcPfSPX0zPHo2JLCDrxuGeygqq1eNDuPL1hYVGA=.eb056fd0-14a6-47ae-820c-35a45c0b2efa@github.com>

On Fri, 14 Feb 2025 02:23:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The newly added JMH tests 'org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark' fails "java.lang.NoClassDefFoundError: jdk/incubator/vector/Float16" by below test command:
> 
> 
> make test MICRO="FORK=1;WARMUP_ITER=2" TEST="micro:org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark.test_bm_pattern1"
> 
> 
> The `@Fork(jvmArgsPrepend = ..)` in microbenchmarks should replaced as `@Fork(jvmArgs = ..)` since [JDK-8343345](https://bugs.openjdk.org/browse/JDK-8343345). Change has been verified locally, test-fix only, no risk.

test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java line 34:

> 32: @OutputTimeUnit(TimeUnit.MILLISECONDS)
> 33: @State(Scope.Thread)
> 34: @Fork(jvmArgs = {"--add-modules=jdk.incubator.vector", "-Xbatch",  "-XX:-TieredCompilation"})

Suggestion:

@Fork(jvmArgs = {"--add-modules=jdk.incubator.vector", "-Xbatch", "-XX:-TieredCompilation"})

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23624#discussion_r1959361602

From pkumaraswamy at openjdk.org  Tue Feb 18 09:29:39 2025
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Tue, 18 Feb 2025 09:29:39 GMT
Subject: RFR: 8349547: Document jlink and jmods Supported Usage
Message-ID: <AexZULgyOat3caRVyoDemL4uokSDwHWWAGkF2CAtvCQ=.81d4b5a2-dff0-49e2-a9ab-0edb991ec48a@github.com>

Document supported usage of jlink with JDK jmod's
The document will reflect the future work from JDK-8347831

-------------

Commit messages:
 - 8349547: Document jlink and jmods Supported Usage

Changes: https://git.openjdk.org/jdk/pull/23672/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23672&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349547
  Stats: 41 lines in 1 file changed: 40 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23672.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23672/head:pull/23672

PR: https://git.openjdk.org/jdk/pull/23672

From syan at openjdk.org  Tue Feb 18 09:58:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 18 Feb 2025 09:58:50 GMT
Subject: RFR: 8350049: [JMH] Float16OperationsBenchmark fails
 java.lang.NoClassDefFoundError [v2]
In-Reply-To: <MAUbF4zfQV2GpI0kgOaRNzNKvFC1sj5FGs49I4PARx0=.436c177b-1061-4e08-8c8c-08c24984faba@github.com>
References: <MAUbF4zfQV2GpI0kgOaRNzNKvFC1sj5FGs49I4PARx0=.436c177b-1061-4e08-8c8c-08c24984faba@github.com>
Message-ID: <vjxCfs6qvdqL9zU2jBVoxgV8OgH8zbuboi-7rBJhOWs=.1b8779f3-c9b9-4771-b629-c579965e8a98@github.com>

> Hi all,
> 
> The newly added JMH tests 'org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark' fails "java.lang.NoClassDefFoundError: jdk/incubator/vector/Float16" by below test command:
> 
> 
> make test MICRO="FORK=1;WARMUP_ITER=2" TEST="micro:org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark.test_bm_pattern1"
> 
> 
> The `@Fork(jvmArgsPrepend = ..)` in microbenchmarks should replaced as `@Fork(jvmArgs = ..)` since [JDK-8343345](https://bugs.openjdk.org/browse/JDK-8343345). Change has been verified locally, test-fix only, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove the extra whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23624/files
  - new: https://git.openjdk.org/jdk/pull/23624/files/1742b09d..7135e60b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23624&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23624&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23624/head:pull/23624

PR: https://git.openjdk.org/jdk/pull/23624

From syan at openjdk.org  Tue Feb 18 09:58:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 18 Feb 2025 09:58:51 GMT
Subject: RFR: 8350049: [JMH] Float16OperationsBenchmark fails
 java.lang.NoClassDefFoundError [v2]
In-Reply-To: <tXYEXcPfSPX0zPHo2JLCDrxuGeygqq1eNDuPL1hYVGA=.eb056fd0-14a6-47ae-820c-35a45c0b2efa@github.com>
References: <MAUbF4zfQV2GpI0kgOaRNzNKvFC1sj5FGs49I4PARx0=.436c177b-1061-4e08-8c8c-08c24984faba@github.com>
 <tXYEXcPfSPX0zPHo2JLCDrxuGeygqq1eNDuPL1hYVGA=.eb056fd0-14a6-47ae-820c-35a45c0b2efa@github.com>
Message-ID: <JRaHKqg1GHHPRPFmPJcSdohQHzz_9MVma45qun4jt5Y=.3585f6cc-56da-4ed8-b448-338fd0e42b81@github.com>

On Tue, 18 Feb 2025 09:23:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the extra whitespace
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java line 34:
> 
>> 32: @OutputTimeUnit(TimeUnit.MILLISECONDS)
>> 33: @State(Scope.Thread)
>> 34: @Fork(jvmArgs = {"--add-modules=jdk.incubator.vector", "-Xbatch",  "-XX:-TieredCompilation"})
> 
> Suggestion:
> 
> @Fork(jvmArgs = {"--add-modules=jdk.incubator.vector", "-Xbatch", "-XX:-TieredCompilation"})

Thanks, the extra whitespace has been removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23624#discussion_r1959415307

From duke at openjdk.org  Tue Feb 18 09:59:17 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 18 Feb 2025 09:59:17 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v2]
In-Reply-To: <HKYrg1nnFMjktEeAAeqF2XE3gy7wQ6-nR7s30Fqecbo=.604a4916-dc31-4bec-a90d-62d5eff16d5b@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
 <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>
 <bfT8EMRk6msqkRF32_vQCfZvirTiWsvg0hrOpThz9i4=.1f6626ed-637e-4ff3-827d-f5dc34094910@github.com>
 <A_C2myp2dclvSO5vDmJD4sl9FMoWFCP-j1P7ihltcKc=.c1cb149b-0e33-4d6d-8399-8d6dfe5dbccc@github.com>
 <dl48ChO5x4futsrtaAjvvlxb4Enekr9S1qFCwQtGVkU=.904d075e-786d-4fe2-980c-f6e9143ba86a@github.com>
 <fcvrEMeNBT-Cp7C5MR_zsON1WDWouU72qVik-DiN4k0=.7b655123-f2ff-4c12-8d94-0845be867d05@github.com>
 <wmIgd_-kflkNtl_HeIq8sAgfBAeDGuYvT9xwsl1TnGc=.4e09a4cf-1f9a-441c-9f86-8f37a682757f@github.com>
 <G0QHgSxgst6mR2wqn6_LdUAb1C5dGfTVcLonEMBbC8Q=.dd75c6a5-9dd4-4605-89c3-fda9b17cd080@github.com>
 <T6tLX_u6tuehydDgOk-Zy90LEIsKMBVHyAtukZgZETo=.dcfd7512-360d-4f51-8b49-7d42199aa6d7@github.com>
 <Cpc_kxrUHuC3Sj2zluPHtPICI63z2swogYe
 c43ycS-I=.b034cc18-7472-4a0c-88d7-2f50eb258692@github.com>
 <HKYrg1nnFMjktEeAAeqF2XE3gy7wQ6-nR7s30Fqecbo=.604a4916-dc31-4bec-a90d-62d5eff16d5b@github.com>
Message-ID: <cFpOX8erhzm1BkIDvun1TkXpj4YCwv3osFT-4NsT9Qw=.44d2ec66-dba4-43ec-b308-13ace56877d8@github.com>

On Tue, 18 Feb 2025 02:08:58 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> The issue with a non-JDK stream handler subclass, is that it doesn't have the privilege of being able to do anything before the `super.publish(...)` call has finished and the handler instance is unlocked.
>> 
>> Using a package protected method to achieve this only for JDK classes is just leaving a slightly bad taste in my mouth.
>> 
>> There's just nothing in the API, other than perhaps brittle things like using an overridden stream and detecting writes (which Daniel has convinced me is too brittle to be in the JDK) to allow a non-JDK version of FileHandler to be implemented with "synchronous post publish() actions". And I personally dislike the idea that people can't write their own equivalent of FileHandler (with some extra feature) outside the JDK.
>> 
>> And, just FYI, there's basically almost no chance we'd consider adding new methods or properties to the logging package at this point. I'd be far more scared about adding "auto flushing" to existing handler sub-classes than changing the never specified behaviour with respect to file size (though the pathological 1-byte file to force rotation per log record is something I hadn't considered, but has also never been promised to actually work).
>
> My notes from 2006 on post publish actions suggested promoting `public void push` to StreamHandler and perhaps Handler as a handler defined action. Same for pushLevel but that is not radically different from auto flush I just proposed.
> 
> Another option here is to check written before and after super.publish in FileHandler. That way when 2nd record knows a rotate is required before writing. The if check is a bit different between before and after.  That should cover all scheduling combinations.

I'm afraid I don't see how the double-check idea would work if `publish()` is no longer synchronized.

Thread 1. lock(), check, no rotate, unlock() <yield>
Thread 2. lock(), check, no rotate, unlock() <yield>
Thread 1. `super.publish()` (writes past the file size limit) <yield>
Thread 2. `super.publish()` <yield>
Thread 1. lock(), check, rotate...

Essentially to have a "synchronous post publish action", the rotate() must occur in the same locked section which wrote the final log entry (the one which pushed the size over the limit). This can only occur by either:
1. Calling from StreamHandler into FileHandler explicitly (a new, package protected method but this only works for JDK classes)
2. Using some existing implicit call (e.g. making assumptions in the stream callbacks)

The other option is to just allow the lock to be dropped, and occasionally you get slightly larger files than you might expect. Since FileHandler never promised anything about file size limits, this is "in spec" and you could suggest that if someone wants stronger promises about when files are rotated etc, it's not difficult to write your own custom handler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1959416827

From galder at openjdk.org  Tue Feb 18 10:09:18 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 18 Feb 2025 10:09:18 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <ilwTxx7G5Uh2ZmiVAv334-cVnqTIyKIyHTmtsdkYUxQ=.f10760eb-0e02-462c-a61a-80c1bada28fe@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
 <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
 <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
 <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FF
 eVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>
 <ajuhBKoDVKmn_D9vg3O3OVUQVVunAT02KhXcaapMokE=.5b8f2f36-6521-4389-97de-0bf8deeb47dc@github.com>
 <N-faJEFC3vJg5m-H3EyMnAkBg3ecpx_YduxpPyXRz8o=.fee546a6-61d3-4ce7-9939-80a1a9e2748e@github.com>
 <ilwTxx7G5Uh2ZmiVAv334-cVnqTIyKIyHTmtsdkYUxQ=.f10760eb-0e02-462c-a61a-80c1bada28fe@github.com>
Message-ID: <50uPQ3ue90Xr_LSEm8z3XLTL1yx2A-Q0SJ8rdmv-gsg=.960a6c31-9850-4ce3-bd88-41d4342a5605@github.com>

On Tue, 18 Feb 2025 09:21:46 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> For the equivalent long tests I think I made a mistake in the id of the disabled intrinsic, it should be _maxL and not _max. I will repeat the tests and post if any similar differences observed.

FYI Indeed a similar pattern is observed for long min/max (with the patch in this PR):


make test TEST="micro:org.openjdk.bench.java.lang.MinMaxVector.longReductionSimpleMax" MICRO="FORK=1"
Benchmark                            (probability)  (size)   Mode  Cnt    Score   Error   Units
MinMaxVector.longReductionSimpleMax             50    2048  thrpt    4  460.392 ? 0.076  ops/ms
MinMaxVector.longReductionSimpleMax             80    2048  thrpt    4  460.459 ? 0.438  ops/ms
MinMaxVector.longReductionSimpleMax            100    2048  thrpt    4  460.469 ? 0.057  ops/ms

make test TEST="micro:org.openjdk.bench.java.lang.MinMaxVector.longReductionSimpleMax" MICRO="FORK=1;OPTIONS=-jvmArgs -XX:CompileCommand=option,org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionSimpleMax_jmhTest::longReductionSimpleMax_thrpt_jmhStub,ccstrlist,DisableIntrinsic,_maxL"
Benchmark                            (probability)  (size)   Mode  Cnt     Score   Error   Units
MinMaxVector.longReductionSimpleMax             50    2048  thrpt    4   460.453 ? 0.188  ops/ms
MinMaxVector.longReductionSimpleMax             80    2048  thrpt    4   460.507 ? 0.192  ops/ms
MinMaxVector.longReductionSimpleMax            100    2048  thrpt    4  1013.498 ? 1.607  ops/ms

make test TEST="micro:org.openjdk.bench.java.lang.MinMaxVector.longReductionMultiplyMax" MICRO="FORK=1"
Benchmark                              (probability)  (size)   Mode  Cnt    Score   Error   Units
MinMaxVector.longReductionMultiplyMax             50    2048  thrpt    4  966.429 ? 0.359  ops/ms
MinMaxVector.longReductionMultiplyMax             80    2048  thrpt    4  966.569 ? 0.338  ops/ms
MinMaxVector.longReductionMultiplyMax            100    2048  thrpt    4  966.548 ? 0.575  ops/ms

make test TEST="micro:org.openjdk.bench.java.lang.MinMaxVector.longReductionMultiplyMax" MICRO="FORK=1;OPTIONS=-jvmArgs -XX:CompileCommand=option,org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMultiplyMax_jmhTest::longReductionMultiplyMax_thrpt_jmhStub,ccstrlist,DisableIntrinsic,_maxL"
Benchmark                              (probability)  (size)   Mode  Cnt    Score   Error   Units
MinMaxVector.longReductionMultiplyMax             50    2048  thrpt    4  966.130 ? 5.549  ops/ms
MinMaxVector.longReductionMultiplyMax             80    2048  thrpt    4  966.380 ? 0.663  ops/ms
MinMaxVector.longReductionMultiplyMax            100    2048  thrpt    4  859.233 ? 7.817  ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2665159015

From kbarrett at openjdk.org  Tue Feb 18 11:04:24 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 18 Feb 2025 11:04:24 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v11]
In-Reply-To: <RQNxtymZk4gFgkve802B8cFKJEPReJwOoclLxHe43PA=.2fb4a5ed-0ef6-4914-b046-3cfab73ef8a0@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <RQNxtymZk4gFgkve802B8cFKJEPReJwOoclLxHe43PA=.2fb4a5ed-0ef6-4914-b046-3cfab73ef8a0@github.com>
Message-ID: <zm1DNJf23_u3UsjIy5JTRPH99494NdpFugBLbn7adjY=.a70bc2df-65d0-4b63-aeb1-6182eaac2dbc@github.com>

On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
>> 
>> We can migrate DBBs to use `java.lang.ref.Cleaner`.
>> 
>> There are two pecularities during this rewrite.
>> 
>> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
>> 
>> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
>> 
>> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert waitForReferenceProcessing removals, see JDK-8305186

There are several changes here that I think are of interest.

(1) Put the cleanables for DirectByteBuffer in a separate j.l.r.Cleaner.  I
don't think that was done in previous experiments with eliminating the use of
j.i.r.Cleaner.  That seems like a good thing to do, to avoid interleaving the
processing of these short and potentially more performance-critical cleanables
with others.

(2) Do a GC for each iteraton of the slow path (i.e. after each exponentially
increasing sleep period).  Neither the existing code (which I had a hand in)
nor its predecessor did that.  I'm currently doubtful of this being a good
idea.  The exponential backoff in the current code was just retained from the
prior code, and I think doesn't actually do much other than delay OOME to
allow other threads to happen to close any direct buffers they might be using.
In the current code (using j.i.r.Cleaner), once waitForReference returns false
all Cleaners discovered by a prior GC will have been processed.  I wonder,
with the current code, under what circumstances do we actually get into those
sleeps, but don't ultimately OOME?

To provide something similar with j.l.r.Cleaner would require an operation
on that class similar to waitForReferenceProcessing.  If there is pending
cleanup work then wait for some and then return true.  If there isn't any
pending cleanup work then return false.  I've spent some time thinking about
how this could be done, and think it's feasible (working on a prototype that
seems like it should work, but hasn't been tested at all yet), though not as
simple as one might wish.

(3) Put the slow path under a lock.  That seems clearly essential with the
change to iterate GCs.  It might be that it's a mistake in the old code to not
do something similar.  The current code allows essentially back to back to
back GCs as multiple threads hit the slow path more or less simultaneously.
You could have several threads come in and all waitForReferenceProcessing, all
finish that loop at the same time and gang-request GCs.  That doesn't seem
good.

(4) Add the canary mechanism.  I think this is a poor replacement for what
waitForReferenceProcessing does currently, since it is not even remotely
reliable.  It might make the path to OOME less likely, but bad luck could make
it do nothing useful at all.

src/java.base/share/classes/java/nio/Bits.java line 122:

> 120:         // Short on memory, with potentially many threads competing for it.
> 121:         // To alleviate progress races, acquire the lock and go slow.
> 122:         synchronized (Bits.class) {

Using a (somewhat) public object for this seems questionable.  Why not a
private lock object?

src/java.base/share/classes/java/nio/Bits.java line 156:

> 154:                 // Exponentially back off waiting for Cleaner to catch up.
> 155:                 try {
> 156:                     Thread.sleep(sleepTime);

There isn't a tryReserveMemory after the last sleep period, so that period is
just completely wasted time.  This is why the old code didn't use a for-loop
over the sleep counter, but instead checked for reaching the limit in the
middle of the loop.

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22165#pullrequestreview-2623158486
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1959508352
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1959509819

From pminborg at openjdk.org  Tue Feb 18 11:45:16 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 18 Feb 2025 11:45:16 GMT
Subject: RFR: 8350075: Performance difference between SegmentAllocator
 methods
In-Reply-To: <L3R-NcYaP4YXpH-dB2qfh6VeIDQoKIrYyClPRDhVqAY=.2e75cd2f-5d1c-43f5-8776-30ec6b722652@github.com>
References: <L3R-NcYaP4YXpH-dB2qfh6VeIDQoKIrYyClPRDhVqAY=.2e75cd2f-5d1c-43f5-8776-30ec6b722652@github.com>
Message-ID: <3dNsGU0tZ5Ti6YppwTZg39SfV-CWoWNgDZsYiwUiQbU=.3e9bc141-9136-4d9c-8667-d2bd4f4f3c71@github.com>

On Fri, 14 Feb 2025 09:19:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add `@ForceInline` to the `default` methods in `SegmentAllocator` that do not already have it.

There is [a microbenchmark from another PR](test/micro/org/openjdk/bench/java/lang/foreign/ArenaPoolFromBench.java) which is hard to isolate as it depends on changes in the JDK. The changes in this (and not the other) PR has the following implications in said benchmark:

Baseline:

Benchmark                                                                   Mode  Cnt     Score      Error   Units
ArenaPoolFromBench.OfVirtual.pooledInt                                 N/A  avgt   30    29.465 ?    0.922   ns/op
ArenaPoolFromBench.OfVirtual.pooledInt:gc.alloc.rate                   N/A  avgt   30  6482.707 ?  176.227  MB/sec
ArenaPoolFromBench.OfVirtual.pooledInt:gc.alloc.rate.norm              N/A  avgt   30   200.001 ?    0.001    B/op
ArenaPoolFromBench.OfVirtual.pooledInt:gc.count                        N/A  avgt   30   182.000             counts
ArenaPoolFromBench.OfVirtual.pooledInt:gc.time                         N/A  avgt   30   110.000                 ms


Patch:

Benchmark                                                      Mode  Cnt   Score    Error   Units
ArenaPoolFromBench.OfVirtual.pooledInt                         avgt   30   8.351 ?  0.297   ns/op
ArenaPoolFromBench.OfVirtual.pooledInt:gc.alloc.rate           avgt   30   0.013 ?  0.001  MB/sec
ArenaPoolFromBench.OfVirtual.pooledInt:gc.alloc.rate.norm      avgt   30  ? 10??             B/op
ArenaPoolFromBench.OfVirtual.pooledInt:gc.count                avgt   30     ? 0           counts

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23628#issuecomment-2665418353

From shade at openjdk.org  Tue Feb 18 11:57:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Feb 2025 11:57:53 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v12]
In-Reply-To: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
Message-ID: <Gdz5tPwVohdf2BhnVS2juESrMlPCRXcmIxu2ydLgpHg=.b0679476-5134-4b30-bf51-db25e565a49f@github.com>

> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
> 
> We can migrate DBBs to use `java.lang.ref.Cleaner`.
> 
> There are two pecularities during this rewrite.
> 
> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
> 
> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
> 
> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:

 - Minor post-review adjustments
 - Introduce explicit lock instead of relying on Bits.class
 - Merge branch 'master' into JDK-8344332-dbb-cleaner
 - Revert waitForReferenceProcessing removals, see JDK-8305186
 - Merge branch 'master' into JDK-8344332-dbb-cleaner
 - No instantiation for BufferCleaner, javadocs
 - Remove hasReferencePendingList
 - Revert test exclusion, moved to JDK-8348301
 - Alan's review
 - Remove vestigial reference to waitForReferenceProcessing in tests
 - ... and 8 more: https://git.openjdk.org/jdk/compare/bfcfce2e...a6ffce2e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22165/files
  - new: https://git.openjdk.org/jdk/pull/22165/files/dc3dab7f..a6ffce2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=10-11

  Stats: 49548 lines in 2079 files changed: 26691 ins; 11892 del; 10965 mod
  Patch: https://git.openjdk.org/jdk/pull/22165.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165

PR: https://git.openjdk.org/jdk/pull/22165

From shade at openjdk.org  Tue Feb 18 11:57:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Feb 2025 11:57:54 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v11]
In-Reply-To: <zm1DNJf23_u3UsjIy5JTRPH99494NdpFugBLbn7adjY=.a70bc2df-65d0-4b63-aeb1-6182eaac2dbc@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <RQNxtymZk4gFgkve802B8cFKJEPReJwOoclLxHe43PA=.2fb4a5ed-0ef6-4914-b046-3cfab73ef8a0@github.com>
 <zm1DNJf23_u3UsjIy5JTRPH99494NdpFugBLbn7adjY=.a70bc2df-65d0-4b63-aeb1-6182eaac2dbc@github.com>
Message-ID: <nTLuM2AB3FYpqO3wTBuvWBSqsAHkipQfWcTfJ6y9hwI=.7497cd81-ce48-4e55-b2cb-04f8a11f43e3@github.com>

On Tue, 18 Feb 2025 10:54:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert waitForReferenceProcessing removals, see JDK-8305186
>
> src/java.base/share/classes/java/nio/Bits.java line 122:
> 
>> 120:         // Short on memory, with potentially many threads competing for it.
>> 121:         // To alleviate progress races, acquire the lock and go slow.
>> 122:         synchronized (Bits.class) {
> 
> Using a (somewhat) public object for this seems questionable.  Why not a
> private lock object?

This class is package-private, so I judged the possibility of leaking the lock impractically low. We can do a separate lock, if that reads cleaner, sure. Done in new commit.

> src/java.base/share/classes/java/nio/Bits.java line 156:
> 
>> 154:                 // Exponentially back off waiting for Cleaner to catch up.
>> 155:                 try {
>> 156:                     Thread.sleep(sleepTime);
> 
> There isn't a tryReserveMemory after the last sleep period, so that period is
> just completely wasted time.  This is why the old code didn't use a for-loop
> over the sleep counter, but instead checked for reaching the limit in the
> middle of the loop.

Right, that's an overlook. I wanted to make the first non-sleep-ed attempt in the loop, so that it covers the semi-optimistic case where we could have reserved the memory immediately after taking the lock. But we can peel that out from the loop. Done in new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1959590847
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1959590929

From duke at openjdk.org  Tue Feb 18 12:46:50 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 18 Feb 2025 12:46:50 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v3]
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <lLvJy7CrvCk58jJkzZNFiIkLKyLDKIE61mc4mqbPSEk=.ea3be17e-3bc8-478e-9136-36b407c06fdf@github.com>

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Revert to original state (no stream hooks).

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23491/files
  - new: https://git.openjdk.org/jdk/pull/23491/files/11ba7701..0c6ec9ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=01-02

  Stats: 48 lines in 1 file changed: 14 ins; 32 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491

PR: https://git.openjdk.org/jdk/pull/23491

From shade at openjdk.org  Tue Feb 18 14:33:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Feb 2025 14:33:16 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
Message-ID: <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>

> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
> 
> We can migrate DBBs to use `java.lang.ref.Cleaner`.
> 
> There are two pecularities during this rewrite.
> 
> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
> 
> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
> 
> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  A bit more comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22165/files
  - new: https://git.openjdk.org/jdk/pull/22165/files/a6ffce2e..249ac2a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=11-12

  Stats: 34 lines in 1 file changed: 33 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22165.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165

PR: https://git.openjdk.org/jdk/pull/22165

From shade at openjdk.org  Tue Feb 18 14:33:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Feb 2025 14:33:17 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v11]
In-Reply-To: <zm1DNJf23_u3UsjIy5JTRPH99494NdpFugBLbn7adjY=.a70bc2df-65d0-4b63-aeb1-6182eaac2dbc@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <RQNxtymZk4gFgkve802B8cFKJEPReJwOoclLxHe43PA=.2fb4a5ed-0ef6-4914-b046-3cfab73ef8a0@github.com>
 <zm1DNJf23_u3UsjIy5JTRPH99494NdpFugBLbn7adjY=.a70bc2df-65d0-4b63-aeb1-6182eaac2dbc@github.com>
Message-ID: <D1DCQzvJNrxP6FxWXLPXnTQ6dV7hDcOvZJPSUGGap4w=.91c10819-d491-457b-987f-2bb2d251697f@github.com>

On Tue, 18 Feb 2025 11:01:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert waitForReferenceProcessing removals, see JDK-8305186
>
> There are several changes here that I think are of interest.
> 
> (1) Put the cleanables for DirectByteBuffer in a separate j.l.r.Cleaner.  I
> don't think that was done in previous experiments with eliminating the use of
> j.i.r.Cleaner.  That seems like a good thing to do, to avoid interleaving the
> processing of these short and potentially more performance-critical cleanables
> with others.
> 
> (2) Do a GC for each iteraton of the slow path (i.e. after each exponentially
> increasing sleep period).  Neither the existing code (which I had a hand in)
> nor its predecessor did that.  I'm currently doubtful of this being a good
> idea.  The exponential backoff in the current code was just retained from the
> prior code, and I think doesn't actually do much other than delay OOME to
> allow other threads to happen to close any direct buffers they might be using.
> In the current code (using j.i.r.Cleaner), once waitForReference returns false
> all Cleaners discovered by a prior GC will have been processed.  I wonder,
> with the current code, under what circumstances do we actually get into those
> sleeps, but don't ultimately OOME?
> 
> To provide something similar with j.l.r.Cleaner would require an operation
> on that class similar to waitForReferenceProcessing.  If there is pending
> cleanup work then wait for some and then return true.  If there isn't any
> pending cleanup work then return false.  I've spent some time thinking about
> how this could be done, and think it's feasible (working on a prototype that
> seems like it should work, but hasn't been tested at all yet), though not as
> simple as one might wish.
> 
> (3) Put the slow path under a lock.  That seems clearly essential with the
> change to iterate GCs.  It might be that it's a mistake in the old code to not
> do something similar.  The current code allows essentially back to back to
> back GCs as multiple threads hit the slow path more or less simultaneously.
> You could have several threads come in and all waitForReferenceProcessing, all
> finish that loop at the same time and gang-request GCs.  That doesn't seem
> good.
> 
> (4) Add the canary mechanism.  I think this is a poor replacement for what
> waitForReferenceProcessing does currently, since it is not even remotely
> reliable.  It might make the path to OOME less likely, but bad luck could make
> it do nothing useful at all.

Thanks for the comment, @kimbarrett!

I started replying, but then figured my reply on current canary mechanics would be better captured in the code comment, so I pushed it right there. Then I ran out of time. I would think about this a bit more and try to reply to the your comments sometime later this week.

So far, I still believe Cleaner canaries are the best way to balance the probability of success for the best effort attempt to allocate when short on memory and the implementation simplicity. Maybe filling the only theoretical gap I see at the moment (see code comments) would be marginally better with waiting for `Cleaner` directly, maybe not. Maybe waiting approaches strike a better balance, maybe not.

What I am sure, though, is that lots of theoretical arguments I made to myself, including re-using waiting infrastructure, failed empirical reliability/performance tests after my attempts at implementing them. Admittedly, I have not tried to go as far as coordinating _both_ reference processing and Cleaner threads, maybe, _maybe_ the answer is there. So I would reserve final judgement on whether GC+RefProc+Cleaner waiting approaches really work until I see them actually work :) In contrast, current PR both fits my theoretical understanding why it works, and passes the empirical tests. Looking forward to your attempt!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2665881712

From jiangli at openjdk.org  Tue Feb 18 19:26:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Feb 2025 19:26:09 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v2]
In-Reply-To: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
Message-ID: <YVwfrmVt9jVlJpszfC_dXQqUqbFKZM92mItl8vy0jIY=.92356897-db71-407a-8b4a-88be1a9342c4@github.com>

> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
> 
> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
> 
> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.

Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8349620
 - - Add 'jdk.static' in VMProps. It can be used to skip tests not for running on static JDK.
   - Add WhiteBox isStatic() native method. It's used by VMProps to determine of it's static at runtime.
   - Add in '@requires !jdk.static' in test/hotspot/jtreg/runtime/modules/ModulesSymLink.java to skip the test on static JDK since it requires bin/jlink.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23528/files
  - new: https://git.openjdk.org/jdk/pull/23528/files/e01ce5b1..e4d2e49e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23528&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23528&range=00-01

  Stats: 19883 lines in 961 files changed: 13314 ins; 3171 del; 3398 mod
  Patch: https://git.openjdk.org/jdk/pull/23528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23528/head:pull/23528

PR: https://git.openjdk.org/jdk/pull/23528

From alanb at openjdk.org  Tue Feb 18 19:26:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Feb 2025 19:26:13 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v2]
In-Reply-To: <YVwfrmVt9jVlJpszfC_dXQqUqbFKZM92mItl8vy0jIY=.92356897-db71-407a-8b4a-88be1a9342c4@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <YVwfrmVt9jVlJpszfC_dXQqUqbFKZM92mItl8vy0jIY=.92356897-db71-407a-8b4a-88be1a9342c4@github.com>
Message-ID: <oHDdC-B8-kFqPiz3DDHgsLsi-dKMnW-6fIWdTh14rI8=.0e4231a3-e929-4e51-bc0b-7fab94a27b94@github.com>

On Tue, 18 Feb 2025 19:09:00 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
>> 
>> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
>> 
>> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8349620
>  - - Add 'jdk.static' in VMProps. It can be used to skip tests not for running on static JDK.
>    - Add WhiteBox isStatic() native method. It's used by VMProps to determine of it's static at runtime.
>    - Add in '@requires !jdk.static' in test/hotspot/jtreg/runtime/modules/ModulesSymLink.java to skip the test on static JDK since it requires bin/jlink.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23528#pullrequestreview-2624487575

From jiangli at openjdk.org  Tue Feb 18 19:26:17 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Feb 2025 19:26:17 GMT
Subject: RFR: 8349620: Add VMProps for static JDK
In-Reply-To: <DDkY02jwb9ew9lA0tBoGpL29CLfRf028eSiKdGVz8AY=.efbdfb9d-4c7e-492c-9628-88222f4b8bf8@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <JIm6MX4f6S8SxGx-IlJGov7rvsFZqLLQACrIZozjl5k=.0c185caf-30a2-4b1a-95bf-b526bc0012ec@github.com>
 <DDkY02jwb9ew9lA0tBoGpL29CLfRf028eSiKdGVz8AY=.efbdfb9d-4c7e-492c-9628-88222f4b8bf8@github.com>
Message-ID: <gP2tW1TccXCiE4BrJ8fmhHxZec60dft48dwYt2AtHOs=.55447433-472a-45dd-a688-7c94112cfeed@github.com>

On Tue, 11 Feb 2025 08:10:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I think this looks okay, I'm just wondering is one property is enough to cover all the configurations.
>
>> Thanks, @AlanBateman.
>> 
>> > I'm just wondering is one property is enough to cover all the configurations.
>> 
>> +1
>> 
>> It's not easy to predict all different cases for now. How about adding/refining when we find any new cases? 
> 
> That's okay with me. I'm hoping Magnus will jump in when he gets a chance as he has experience with the "other" static build configurations.

Thanks, @AlanBateman!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2666666915

From jiangli at openjdk.org  Tue Feb 18 19:29:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Feb 2025 19:29:10 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v3]
In-Reply-To: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
Message-ID: <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>

> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
> 
> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
> 
> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.

Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  - Add 'jdk.static' in VMProps. It can be used to skip tests not for running on static JDK.
  - Add WhiteBox isStatic() native method. It's used by VMProps to determine of it's static at runtime.
  - Add in '@requires !jdk.static' in test/hotspot/jtreg/runtime/modules/ModulesSymLink.java to skip the test on static JDK since it requires bin/jlink.

-------------

Changes: https://git.openjdk.org/jdk/pull/23528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23528&range=02
  Stats: 19 lines in 6 files changed: 16 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23528/head:pull/23528

PR: https://git.openjdk.org/jdk/pull/23528

From alanb at openjdk.org  Tue Feb 18 19:23:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Feb 2025 19:23:44 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK
In-Reply-To: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
Message-ID: <MUcHC8O6BM1CsuMRKvD0u3s_V4BsZN85kV-AtB2tvxc=.07bf4c72-9e72-48f5-a1c3-bf88837f1a3c@github.com>

On Fri, 14 Feb 2025 18:31:52 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 
> 
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
> - Link with `-ldl` explicitly
> 
> The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224

I don't object to changing this test but it might be simpler to just skip this test, once we can use `@requires !jdk.static`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23646#issuecomment-2666321144

From jiangli at openjdk.org  Tue Feb 18 19:37:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Feb 2025 19:37:15 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v3]
In-Reply-To: <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
Message-ID: <8Fq79TB_4TxUkCy25DGptRJ3Q7Brm6QZK1ZdJtyVRtI=.0fe9ff90-31b9-427e-9979-b03d8ea4f02d@github.com>

On Tue, 18 Feb 2025 19:29:10 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
>> 
>> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
>> 
>> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

Can anyone help do a second review for this change? Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2666758082

From erikj at openjdk.org  Tue Feb 18 20:25:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 18 Feb 2025 20:25:54 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE
In-Reply-To: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
Message-ID: <-nxQxCDHWuroNGeE6l6zqhd636a3PZY23KaC1SXg2oU=.e59377c5-4a25-4737-8389-6b558db943c6@github.com>

On Fri, 14 Feb 2025 07:21:27 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
> 
> After this PR, below JMH tests will run passes.
> 
> 
> org.openjdk.bench.javax.xml.DOM.testBuild
> org.openjdk.bench.javax.xml.DOM.testModify
> org.openjdk.bench.javax.xml.DOM.testWalk
> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
> org.openjdk.bench.javax.xml.STAX.testParse
> 
> 
> Test command:
> 
> 
> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
> 
> 
> Change has been verified locally, no risk.

I'm not sure if this is the right way to solve this. I would really like someone more familiar with the microbenchmarks to weigh in on how this was originally meant to work.

make/test/BuildMicrobenchmark.gmk line 127:

> 125:             $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/message_12.xml \
> 126:             $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml \
> 127:             $(MICROBENCHMARK_CLASSES)/org/openjdk/bench/javax/xml

If this is the correct solution, then copying these files should be handled separately from unpacking jars, preferably using a SetupCopyFiles macro call. Something like this (untested):

$(eval $(call SetupCopyFiles, COPY_JAXP_TEST_XML, \
    DEST := $(MICROBENCHMARK_CLASSES)/org/openjdk/bench/javax/xml, \
    FILES := \
        $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/validation/tck/reZ003vExc23082309.xml \
        $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/message_12.xml \
        $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml, \
    FLATTEN := true, \
))

And then add $(COPY_JAXP_TEST_XML) to the list of dependencies in the `SetupJarArchive` call below.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23625#pullrequestreview-2624942656
PR Review Comment: https://git.openjdk.org/jdk/pull/23625#discussion_r1960535658

From jiangli at openjdk.org  Tue Feb 18 21:29:52 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Feb 2025 21:29:52 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK
In-Reply-To: <MUcHC8O6BM1CsuMRKvD0u3s_V4BsZN85kV-AtB2tvxc=.07bf4c72-9e72-48f5-a1c3-bf88837f1a3c@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
 <MUcHC8O6BM1CsuMRKvD0u3s_V4BsZN85kV-AtB2tvxc=.07bf4c72-9e72-48f5-a1c3-bf88837f1a3c@github.com>
Message-ID: <lorIpSLqQ937bakcDSCAnkJyGGeCAQ9HVOnXYZ_hEQo=.5f848525-7d25-4bbc-bec2-217ea424b069@github.com>

On Tue, 18 Feb 2025 17:05:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I don't object to changing this test but it might be simpler to just skip this test, once we can use `@requires !jdk.static`.

Thanks, @AlanBateman. I think skipping this test for static JDK sounds reasonable to me, since this test seems to explicitly test these JNU_ functions. Changing to do dynamic lookup may alter the original intention. I'll update after https://github.com/openjdk/jdk/pull/23528.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23646#issuecomment-2666964844

From imyers at openjdk.org  Tue Feb 18 23:08:57 2025
From: imyers at openjdk.org (Ian Myers)
Date: Tue, 18 Feb 2025 23:08:57 GMT
Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>
References: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
 <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>
Message-ID: <kkbh1U2d4-82E1OOPq_SBkYolMqLmZz68XcT6ThMjEQ=.0e58b6b4-8e95-412e-8d3f-752e7af1a33e@github.com>

On Wed, 29 Jan 2025 23:15:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links.
>> 
>> - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location.
>> 
>> - Contacted ietf, these are the new links to use.
>> 
>> This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either.
>> 
>> Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs.
>
> make/common/Modules.gmk line 95:
> 
>> 93: SPEC_SUBDIRS += share/specs
>> 94: 
>> 95: MAN_SUBDIRS += share/man windows/man
> 
> Hm, normally I'd say you should use `$(TARGET_OS)/man`, but we typically generate docs for all platforms at the same time. So I guess this is okay.

Hi @magicus we are seeing build failures because linux builds contain man pages for windows-only tools as reported by https://bugs.openjdk.org/browse/JDK-8350137. Would replacing `windows/man` with `$(TARGET_OS)/man` prevent windows-only tools man pages being generated for linux builds?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23351#discussion_r1960715214

From coleenp at openjdk.org  Tue Feb 18 23:49:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 18 Feb 2025 23:49:52 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
Message-ID: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>

Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
Tested with tier1-4 and performance tests.

-------------

Commit messages:
 - Add ')' removed from jvmci test.
 - Shrink modifiers flag so isPrimitive can share word.
 - Remove isPrimitive intrinsic in favor of a boolean.
 - Make isInterface non-native.
 - Make isArray non-native

Changes: https://git.openjdk.org/jdk/pull/23572/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349860
  Stats: 178 lines in 19 files changed: 37 ins; 115 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/23572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23572/head:pull/23572

PR: https://git.openjdk.org/jdk/pull/23572

From liach at openjdk.org  Tue Feb 18 23:49:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Feb 2025 23:49:54 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <6EpQLprXKfUDUQ6UIl0Vo0M5OPmCJ4SjcnOeprbO40w=.7d6cd0d3-ec59-4935-adb9-484764f0235c@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

We often need to determine what primitive type a `class` is. Currently we do it through `Wrapper.forPrimitiveType`. Do you see potential value in encoding the primitive status in a byte, so primitive info also knows what primitive type this class is instead of doing identity comparisons?

@cl4es Can you offer some insight here?

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 59:

> 57:             Reflection.class, ALL_MEMBERS,
> 58:             AccessibleObject.class, ALL_MEMBERS,
> 59:             Class.class, Set.of("classLoader", "classData", "modifiers", "isPrimitive"),

I think the field is named `isPrimitive`, right?

test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java line 933:

> 931:         if (f.getDeclaringClass().equals(metaAccess.lookupJavaType(Class.class))) {
> 932:             String name = f.getName();
> 933:             return name.equals("classLoader") || name.equals("classData") || name.equals("modifiers") || name.equals("isPrimitive");

Same field name remark.

test/jdk/jdk/internal/reflect/Reflection/Filtering.java line 59:

> 57:             { Class.class, "classData" },
> 58:             { Class.class, "modifiers" },
> 59:             { Class.class, "isPrimitive" },

Same field name remark.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23572#issuecomment-2654120983
PR Comment: https://git.openjdk.org/jdk/pull/23572#issuecomment-2659605250
PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1951773863
PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1951774073
PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1951774214

From redestad at openjdk.org  Tue Feb 18 23:49:54 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 18 Feb 2025 23:49:54 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <bRJ_xGw_OElD7FwDegvz5FUoEvnosOjJHQcaXO6yIYs=.8e353192-da4d-4c06-901c-a504f19d6d60@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

Touching `Wrapper` seems out of scope for this PR, but if `Class.isPrimitive` gets cheaper from this then `Wrapper.forPrimitiveType` should definitely be examined in a follow-up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23572#issuecomment-2661970849

From coleenp at openjdk.org  Tue Feb 18 23:49:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 18 Feb 2025 23:49:54 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <m2mXAVAOTN37xUEBUnMyZqZXk1QinoEySwzh8w_W83c=.3c7669f8-e0e8-4dab-bac2-d208af8a3680@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

I had a look at Wrapper.forPrimitiveType() and it's not an intrinsic so I don't really know how hot it is.  It's a comparison, vs getting a field out of Class<?>.  Not sure how to measure it.  So I can't address it in this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23572#issuecomment-2659396480

From coleenp at openjdk.org  Tue Feb 18 23:49:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 18 Feb 2025 23:49:55 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <6EpQLprXKfUDUQ6UIl0Vo0M5OPmCJ4SjcnOeprbO40w=.7d6cd0d3-ec59-4935-adb9-484764f0235c@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <6EpQLprXKfUDUQ6UIl0Vo0M5OPmCJ4SjcnOeprbO40w=.7d6cd0d3-ec59-4935-adb9-484764f0235c@github.com>
Message-ID: <oIkFtLHt8zVGSYcgzTIiQUarrANFHe2XjVYufDlqKPM=.b8a2516f-1668-44fd-b4b7-16a8f9703167@github.com>

On Wed, 12 Feb 2025 00:05:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 59:
> 
>> 57:             Reflection.class, ALL_MEMBERS,
>> 58:             AccessibleObject.class, ALL_MEMBERS,
>> 59:             Class.class, Set.of("classLoader", "classData", "modifiers", "isPrimitive"),
> 
> I think the field is named `isPrimitive`, right?

The method is isPrimitive so I think I had to give the field isPrimitiveType as a name, so this is wrong.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1952521536

From manc at openjdk.org  Wed Feb 19 00:09:54 2025
From: manc at openjdk.org (Man Cao)
Date: Wed, 19 Feb 2025 00:09:54 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v2]
In-Reply-To: <YVwfrmVt9jVlJpszfC_dXQqUqbFKZM92mItl8vy0jIY=.92356897-db71-407a-8b4a-88be1a9342c4@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <YVwfrmVt9jVlJpszfC_dXQqUqbFKZM92mItl8vy0jIY=.92356897-db71-407a-8b4a-88be1a9342c4@github.com>
Message-ID: <nbHaMj5m8fzvs_l2eqpLdkavq4HfUuRXABCrlbBPd0U=.a46f7596-43ab-47c2-b27c-4e29cff55f7d@github.com>

On Tue, 18 Feb 2025 19:26:09 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
>> 
>> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
>> 
>> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8349620
>  - - Add 'jdk.static' in VMProps. It can be used to skip tests not for running on static JDK.
>    - Add WhiteBox isStatic() native method. It's used by VMProps to determine of it's static at runtime.
>    - Add in '@requires !jdk.static' in test/hotspot/jtreg/runtime/modules/ModulesSymLink.java to skip the test on static JDK since it requires bin/jlink.

Changes look good.

>  I'm also wondering if we would want to merge the isStatic into isHermetic check in the future.

I guess it is unlikely we will package each jtreg test into single, hermetic files, each containing the whole JDK? If so, we probably won't need `isHermetic` for jtreg tests.

-------------

Marked as reviewed by manc (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23528#pullrequestreview-2625325934

From joehw at openjdk.org  Wed Feb 19 00:16:13 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 19 Feb 2025 00:16:13 GMT
Subject: RFR: 8349699: XSL transform fails with certain UTF-8 characters on
 1024 byte boundaries [v3]
In-Reply-To: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
References: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
Message-ID: <1MZGlrgj8IuFnPe_XC8wJw1yBtUtrAMri7DTjEuM8uI=.487e785e-62cd-4d1c-ad0e-98486fa990d7@github.com>

> Fix an edge case in the patch for JDK-8207760.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  add tests verifying invalid sequence; also add tests to verify cases where the pairs are at the edges or anywhere in the text

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23623/files
  - new: https://git.openjdk.org/jdk/pull/23623/files/98d5dfc3..19dd8a23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23623&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23623&range=01-02

  Stats: 121 lines in 1 file changed: 105 ins; 12 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23623/head:pull/23623

PR: https://git.openjdk.org/jdk/pull/23623

From joehw at openjdk.org  Wed Feb 19 00:16:13 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 19 Feb 2025 00:16:13 GMT
Subject: RFR: 8349699: XSL transform fails with certain UTF-8 characters on
 1024 byte boundaries [v2]
In-Reply-To: <JcnZzZcxsft9LFBh6mibjIJJybhthduDAVZegsgy4bA=.443969ab-fe63-4159-8760-e6b0f7aa02c0@github.com>
References: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
 <aoZs52Ey8nLXT6JqDYoNl_8bXca9ZAfo8GuEUci2_Rg=.f54302ab-a30d-4472-adaf-3ae5da4a7851@github.com>
 <JcnZzZcxsft9LFBh6mibjIJJybhthduDAVZegsgy4bA=.443969ab-fe63-4159-8760-e6b0f7aa02c0@github.com>
Message-ID: <KZjOKy9SUsQv377BhtfsIJx30e_G_ZRo12ulOUWEosQ=.1075c593-ac78-4ad4-923b-195564e87424@github.com>

On Fri, 14 Feb 2025 19:55:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   un-needed property removed
>
> test/jaxp/javax/xml/jaxp/unittest/transform/JDK8207760.java line 112:
> 
>> 110:     public final void testBug8349699() throws Exception {
>> 111:         String xs = "x".repeat(1017);
>> 112:         String expected = xs + "\uD835\uDF03\uD835\uDF00\uD835\uDF00\uD835\uDF00\uD835\uDF00";
> 
> Would it be meaningful if we provided invalid sequences e.g, high/high and or low/low at the boundary to see if the logic successfully detects them?

Thanks Naoto. Added test cases with invalid sequences (high/high, low/low). Also added test cases to verify both edge and normal cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23623#discussion_r1960764599

From jiangli at openjdk.org  Wed Feb 19 00:31:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 19 Feb 2025 00:31:55 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v2]
In-Reply-To: <nbHaMj5m8fzvs_l2eqpLdkavq4HfUuRXABCrlbBPd0U=.a46f7596-43ab-47c2-b27c-4e29cff55f7d@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <YVwfrmVt9jVlJpszfC_dXQqUqbFKZM92mItl8vy0jIY=.92356897-db71-407a-8b4a-88be1a9342c4@github.com>
 <nbHaMj5m8fzvs_l2eqpLdkavq4HfUuRXABCrlbBPd0U=.a46f7596-43ab-47c2-b27c-4e29cff55f7d@github.com>
Message-ID: <t6ZFkQtMY0YmB15HkZJncynn__JC9wlrRkJpcuxLGTM=.5ffe8fc1-7ff7-4ffd-a9d8-dbf4ef6f4ffe@github.com>

On Wed, 19 Feb 2025 00:06:52 GMT, Man Cao <manc at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8349620
>>  - - Add 'jdk.static' in VMProps. It can be used to skip tests not for running on static JDK.
>>    - Add WhiteBox isStatic() native method. It's used by VMProps to determine of it's static at runtime.
>>    - Add in '@requires !jdk.static' in test/hotspot/jtreg/runtime/modules/ModulesSymLink.java to skip the test on static JDK since it requires bin/jlink.
>
> Changes look good.
> 
>>  I'm also wondering if we would want to merge the isStatic into isHermetic check in the future.
> 
> I guess it is unlikely we will package each jtreg test into single, hermetic files, each containing the whole JDK? If so, we probably won't need `isHermetic` for jtreg tests.

@caoman Thanks for reviewing!

> > I'm also wondering if we would want to merge the isStatic into isHermetic check in the future.
> 
> I guess it is unlikely we will package each jtreg test into single, hermetic files, each containing the whole JDK? If so, we probably won't need `isHermetic` for jtreg tests.

When hermetic is supported, I think we will want to add new tests to explicitly exercise packaging a single executable image including the runtime and run using the single image. Those would be dedicated tests, instead of testing all/most jtreg tests in hermetic mode. `isHermetic` could be useful when we add such tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2667226529

From naoto at openjdk.org  Wed Feb 19 00:34:11 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Feb 2025 00:34:11 GMT
Subject: RFR: 8349699: XSL transform fails with certain UTF-8 characters on
 1024 byte boundaries [v3]
In-Reply-To: <1MZGlrgj8IuFnPe_XC8wJw1yBtUtrAMri7DTjEuM8uI=.487e785e-62cd-4d1c-ad0e-98486fa990d7@github.com>
References: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
 <1MZGlrgj8IuFnPe_XC8wJw1yBtUtrAMri7DTjEuM8uI=.487e785e-62cd-4d1c-ad0e-98486fa990d7@github.com>
Message-ID: <31fyKp_cC2-nw8nVGWGT0x_xZRm1NpyxlJkfNcrZVic=.68549675-72aa-4f46-9d85-698f0f2a7f59@github.com>

On Wed, 19 Feb 2025 00:16:13 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fix an edge case in the patch for JDK-8207760.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add tests verifying invalid sequence; also add tests to verify cases where the pairs are at the edges or anywhere in the text

The surrogate test now looks very comprehensive. Thanks, Joe!

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23623#pullrequestreview-2625349505

From syan at openjdk.org  Wed Feb 19 01:56:52 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Feb 2025 01:56:52 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE
In-Reply-To: <-nxQxCDHWuroNGeE6l6zqhd636a3PZY23KaC1SXg2oU=.e59377c5-4a25-4737-8389-6b558db943c6@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <-nxQxCDHWuroNGeE6l6zqhd636a3PZY23KaC1SXg2oU=.e59377c5-4a25-4737-8389-6b558db943c6@github.com>
Message-ID: <3AN5Fwk8TfNv_1V-7E7W-t6Q8qe92s7wyr8ZZSmq2G0=.bccb9375-93ed-4b8e-8e2a-86c1cc4e7a4a@github.com>

On Tue, 18 Feb 2025 20:23:05 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I'm not sure if this is the right way to solve this. I would really like someone more familiar with the microbenchmarks to weigh in on how this was originally meant to work.

Hi, @cl4es, Could you take took this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23625#issuecomment-2667323936

From smarks at openjdk.org  Wed Feb 19 02:05:58 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 19 Feb 2025 02:05:58 GMT
Subject: RFR: 8138614: (spec str) StringBuffer and StringBuilder methods
 improperly require "new" String to be returned [v2]
In-Reply-To: <xfQBayxkAtTaR5By8H49_LI4916sIeaO-AamgbuW2Jk=.86fa0d75-cf7d-4c91-96dd-2c49bcbdb5c1@github.com>
References: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
 <iEAmP06a5g2yY0_IoYkWW1O85ko8ep7UCercBBgpXJ4=.6f2a5567-dcd4-4a98-89df-dd6978ecf0f9@github.com>
 <xfQBayxkAtTaR5By8H49_LI4916sIeaO-AamgbuW2Jk=.86fa0d75-cf7d-4c91-96dd-2c49bcbdb5c1@github.com>
Message-ID: <y3myIF4w-sF8vtk9odHTHlI1gbUWFdLfDDZ56koW3Cw=.78e19ff0-84bb-4a51-a034-b3ddc934cfd7@github.com>

On Fri, 14 Feb 2025 15:30:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   A tiny bit of wordsmithing.
>
> It should be pointed out (in the CSR) that this is aligning the spec with the current implementation, there no compatibility risk to existing programs.
> Except for the empty string, neither StringBuilder or StringBuffer is holding a string, but a sequence of characters, so a String is created.

@RogerRiggs See updated CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23599#issuecomment-2667335678

From dlong at openjdk.org  Wed Feb 19 02:38:03 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 19 Feb 2025 02:38:03 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <oIkFtLHt8zVGSYcgzTIiQUarrANFHe2XjVYufDlqKPM=.b8a2516f-1668-44fd-b4b7-16a8f9703167@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <6EpQLprXKfUDUQ6UIl0Vo0M5OPmCJ4SjcnOeprbO40w=.7d6cd0d3-ec59-4935-adb9-484764f0235c@github.com>
 <oIkFtLHt8zVGSYcgzTIiQUarrANFHe2XjVYufDlqKPM=.b8a2516f-1668-44fd-b4b7-16a8f9703167@github.com>
Message-ID: <S35E5eUCp-oDpwRdgMUzaHEIo8wv16ACZb7iDRzzm0g=.0d482ee0-73cb-494b-a98c-c0aaed5d07f2@github.com>

On Wed, 12 Feb 2025 12:05:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 59:
>> 
>>> 57:             Reflection.class, ALL_MEMBERS,
>>> 58:             AccessibleObject.class, ALL_MEMBERS,
>>> 59:             Class.class, Set.of("classLoader", "classData", "modifiers", "isPrimitive"),
>> 
>> I think the field is named `isPrimitive`, right?
>
> The method is isPrimitive so I think I had to give the field isPrimitiveType as a name, so this is wrong.

I don't know if we have a style guide that covers this, but I believe the method and field could both be named `isPrimitive`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1960863953

From dlong at openjdk.org  Wed Feb 19 02:56:57 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 19 Feb 2025 02:56:57 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <E9GPjreqeKFJmZAIjHGQ-1y6FnyqaT94FHUPuK65kmE=.48bd4ecc-ac91-4f7b-895b-a32280d8b437@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

src/hotspot/share/classfile/javaClasses.inline.hpp line 301:

> 299: #ifdef ASSERT
> 300:   // The heapwalker walks through Classes that have had their Klass pointers removed, so can't assert this.
> 301:   // assert(is_primitive == java_class->bool_field(_is_primitive_offset), "must match what we told Java");

I don't understand this comment about the heapwalker.  It sounds like we could have `is_primitive` set to true incorrectly.  If so, what prevents the asserts below from failing?  And why not use the value from _is_primitive_offset instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1960876174

From liach at openjdk.org  Wed Feb 19 02:56:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Feb 2025 02:56:58 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <S35E5eUCp-oDpwRdgMUzaHEIo8wv16ACZb7iDRzzm0g=.0d482ee0-73cb-494b-a98c-c0aaed5d07f2@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <6EpQLprXKfUDUQ6UIl0Vo0M5OPmCJ4SjcnOeprbO40w=.7d6cd0d3-ec59-4935-adb9-484764f0235c@github.com>
 <oIkFtLHt8zVGSYcgzTIiQUarrANFHe2XjVYufDlqKPM=.b8a2516f-1668-44fd-b4b7-16a8f9703167@github.com>
 <S35E5eUCp-oDpwRdgMUzaHEIo8wv16ACZb7iDRzzm0g=.0d482ee0-73cb-494b-a98c-c0aaed5d07f2@github.com>
Message-ID: <o0OOTu12p_xatdRLah4eYogKT3R1je0CKtw-mQVsi2Y=.c16a1780-0e76-4d9d-b9f7-5f9b45695c7d@github.com>

On Wed, 19 Feb 2025 02:35:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> The method is isPrimitive so I think I had to give the field isPrimitiveType as a name, so this is wrong.
>
> I don't know if we have a style guide that covers this, but I believe the method and field could both be named `isPrimitive`.

I would personally name such a boolean field `primitive`, but I don't have a strong preference on the field naming as long as its references in tests and other locations are correct. In addition, I believe this field may soon be widened to carry more hotspot-specific flags (such as hidden, etc.) so the name is bound to change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1960876569

From syan at openjdk.org  Wed Feb 19 03:21:37 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Feb 2025 03:21:37 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
Message-ID: <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>

> Hi all,
> 
> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
> 
> After this PR, below JMH tests will run passes.
> 
> 
> org.openjdk.bench.javax.xml.DOM.testBuild
> org.openjdk.bench.javax.xml.DOM.testModify
> org.openjdk.bench.javax.xml.DOM.testWalk
> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
> org.openjdk.bench.javax.xml.STAX.testParse
> 
> 
> Test command:
> 
> 
> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
> 
> 
> Change has been verified locally, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Use SetupCopyFiles macro to copy the dependency files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23625/files
  - new: https://git.openjdk.org/jdk/pull/23625/files/ba555448..f553bf77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23625&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23625&range=00-01

  Stats: 17 lines in 1 file changed: 11 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23625/head:pull/23625

PR: https://git.openjdk.org/jdk/pull/23625

From syan at openjdk.org  Wed Feb 19 03:25:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Feb 2025 03:25:01 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <-nxQxCDHWuroNGeE6l6zqhd636a3PZY23KaC1SXg2oU=.e59377c5-4a25-4737-8389-6b558db943c6@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <-nxQxCDHWuroNGeE6l6zqhd636a3PZY23KaC1SXg2oU=.e59377c5-4a25-4737-8389-6b558db943c6@github.com>
Message-ID: <XLIwiLDEeKWSyctkgPl4NiLli-vthEmxbAZPQG82d2I=.301b05c8-3228-4bd6-8e35-f31d6b4dec6d@github.com>

On Tue, 18 Feb 2025 20:18:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use SetupCopyFiles macro to copy the dependency files
>
> make/test/BuildMicrobenchmark.gmk line 127:
> 
>> 125:             $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/message_12.xml \
>> 126:             $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml \
>> 127:             $(MICROBENCHMARK_CLASSES)/org/openjdk/bench/javax/xml
> 
> If this is the correct solution, then copying these files should be handled separately from unpacking jars, preferably using a SetupCopyFiles macro call. Something like this (untested):
> 
> $(eval $(call SetupCopyFiles, COPY_JAXP_TEST_XML, \
>     DEST := $(MICROBENCHMARK_CLASSES)/org/openjdk/bench/javax/xml, \
>     FILES := \
>         $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/validation/tck/reZ003vExc23082309.xml \
>         $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/message_12.xml \
>         $(TOPDIR)/test/jaxp/javax/xml/jaxp/unittest/transform/msgAttach.xml, \
>     FLATTEN := true, \
> ))
> 
> And then add $(COPY_JAXP_TEST_XML) to the list of dependencies in the `SetupJarArchive` call below.

The `SetupCopyFiles` macro seems do not support multiple absolute path `FILES` arguments, so I use relative path instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23625#discussion_r1960893035

From dlong at openjdk.org  Wed Feb 19 03:32:53 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 19 Feb 2025 03:32:53 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <n1Pm6orA_ufoz5E6FWMNMpfCypAT_q2FyImG4oqpVtM=.2e64b4d5-7805-4f7f-8a5c-0c4dfbc3f6c9@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

src/java.base/share/classes/java/lang/Class.java line 1287:

> 1285:      */
> 1286:     public Class<?> getComponentType() {
> 1287:         // Only return for array types. Storage may be reused for Class for instance types.

I don't see any changes to componentType related to reuse.  So was this comment and the code below already obsolete?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1960897176

From dlong at openjdk.org  Wed Feb 19 03:37:52 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 19 Feb 2025 03:37:52 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <C5MOTd1RwlSiawDFup2fui2I6qr9DHU44yQKeLq_3XY=.942a29c3-4738-457d-b335-a5891a65af19@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

src/hotspot/share/prims/jvm.cpp line 2283:

> 2281: // Otherwise it returns its argument value which is the _the_class Klass*.
> 2282: // Please, refer to the description in the jvmtiThreadState.hpp.
> 2283: 

Does this "RedefineClasses support" comment still belong here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1960900041

From redestad at openjdk.org  Wed Feb 19 05:07:52 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 19 Feb 2025 05:07:52 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
Message-ID: <NTnn-GmvGAAvqSggfaI1bhZ8mIyCpZwT11ga0tH-IcY=.434a9c7f-bb70-435f-862d-916e0b54424b@github.com>

On Wed, 19 Feb 2025 03:21:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
>> 
>> After this PR, below JMH tests will run passes.
>> 
>> 
>> org.openjdk.bench.javax.xml.DOM.testBuild
>> org.openjdk.bench.javax.xml.DOM.testModify
>> org.openjdk.bench.javax.xml.DOM.testWalk
>> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
>> org.openjdk.bench.javax.xml.STAX.testParse
>> 
>> 
>> Test command:
>> 
>> 
>> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
>> 
>> 
>> Change has been verified locally, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SetupCopyFiles macro to copy the dependency files

The issue here looks like an oversight (of mine) in the migration from the standalone JMH repo. There we simply held a copy of the needed XML files, e.g. https://github.com/openjdk/jmh-jdk-microbenchmarks/blob/master/micros-jdk8/src/main/resources/org/openjdk/bench/javax/xml/msgAttach.xml

As we're now in-tree I guess it makes sense to copy these over at build time as per this fix - though it creates an undocumented dependency. If anyone changes these tests on the functional side we'd silently break. Perhaps needs a unit test to guard and document the dependency?

Taking a step back: If these particular micros have all been broken since JEP 230 was integrated in JDK 12 and no-one noticed until now - maybe they aren't really worth their weight and should instead be removed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23625#issuecomment-2667518427

From dholmes at openjdk.org  Wed Feb 19 05:14:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Feb 2025 05:14:58 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <FrlPjmMb7CgcaoCNXLWwybw-pcHprdWIP8whY8fJU9g=.2564ab5c-9d30-4e5d-95cc-7a85955643b0@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

Just a few passing comments as this is mainly compiler stuff.

Does the SA not need any updates in relation to this?

src/hotspot/share/classfile/javaClasses.cpp line 1371:

> 1369: #endif
> 1370:   set_modifiers(java_class, JVM_ACC_ABSTRACT | JVM_ACC_FINAL | JVM_ACC_PUBLIC);
> 1371:   set_is_primitive(java_class);

Just wondering what the comments at the start of this method are alluding to now that we do have a field at the Java level. ???

src/hotspot/share/prims/jvm.cpp line 1262:

> 1260: JVM_END
> 1261: 
> 1262: JVM_ENTRY(jboolean, JVM_IsArrayClass(JNIEnv *env, jclass cls))

Where are the changes to jvm.h?

src/java.base/share/classes/java/lang/Class.java line 1009:

> 1007:     private transient Object classData; // Set by VM
> 1008:     private transient Object[] signers; // Read by VM, mutable
> 1009:     private final transient char modifiers;  // Set by the VM

Why the change of type here?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23572#pullrequestreview-2625638624
PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1960955739
PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1960959718
PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1960960668

From jpai at openjdk.org  Wed Feb 19 06:53:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Feb 2025 06:53:03 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v3]
In-Reply-To: <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
Message-ID: <7Xbnn-2LkNv3Gsj6nFHXdrdvvPO7vXi3K3MWm33E-jw=.8341aa47-99de-4a67-8339-64b46fa7bb36@github.com>

On Tue, 18 Feb 2025 19:29:10 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
>> 
>> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
>> 
>> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

Hello Jiangli, the change to introduce a `@requires` property for identifying a static JDK looks OK to me.

> @requires !jdk.static is added in test/hotspot/jtreg/runtime/modules/ModulesSymLink.java to skip running the test on static JDK. This test uses bin/jlink, which is not provided on static JDK. There are other tests that require tools in bin/. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.

This part however feels odd. Updating this (and other tests in future) to use the `@requires !jdk.static` to identify the presence or absence of a specific tool in the JDK installation doesn't seem right. Perhaps they should instead rely on a tool-specific property (like maybe `@requires jdk.tool.jlink`)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2667657019

From jpai at openjdk.org  Wed Feb 19 06:58:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Feb 2025 06:58:02 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v3]
In-Reply-To: <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
Message-ID: <38QCGfzFNUhE69hUlz5o4H_74wR0lw4sivYa-jGgHXg=.ec9d2a40-e71d-404e-8b8c-2cf284d5b876@github.com>

On Tue, 18 Feb 2025 19:29:10 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
>> 
>> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
>> 
>> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

On a more general note, is it a goal to have the static JDK build run against all these tests that are part of the JDK repo? Would that mean that a lot of these will have to start using `@requires` to accomodate this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2667664308

From syan at openjdk.org  Wed Feb 19 07:07:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Feb 2025 07:07:53 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <NTnn-GmvGAAvqSggfaI1bhZ8mIyCpZwT11ga0tH-IcY=.434a9c7f-bb70-435f-862d-916e0b54424b@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
 <NTnn-GmvGAAvqSggfaI1bhZ8mIyCpZwT11ga0tH-IcY=.434a9c7f-bb70-435f-862d-916e0b54424b@github.com>
Message-ID: <yIvILphjOebjUcqXe-u-sMJd60FKYfFQ1zDL5Pl2Z4s=.d74931fc-728a-4be0-8c5e-079657f053b1@github.com>

On Wed, 19 Feb 2025 05:05:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> If anyone changes these tests on the functional side we'd silently break.

After this PR, if the dependency XML files been removed will make `make test-image` fails. So maybe we do not need a new unit test to guard it.

> Perhaps needs a unit test to guard and document the dependency?

Where should I document the dependency, does anyone could give some suggestions. OTOH maybe we should remove this JMH test?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23625#issuecomment-2667685552

From alanb at openjdk.org  Wed Feb 19 07:35:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Feb 2025 07:35:53 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v3]
In-Reply-To: <7Xbnn-2LkNv3Gsj6nFHXdrdvvPO7vXi3K3MWm33E-jw=.8341aa47-99de-4a67-8339-64b46fa7bb36@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
 <7Xbnn-2LkNv3Gsj6nFHXdrdvvPO7vXi3K3MWm33E-jw=.8341aa47-99de-4a67-8339-64b46fa7bb36@github.com>
Message-ID: <c4gZ8K3QMWzK46zOYrMj24MWrnVUGFDUEbqogI2tCDw=.1c802402-bf5d-40b4-881b-932dc2ba9dc1@github.com>

On Wed, 19 Feb 2025 06:50:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This part however feels odd. Updating this (and other tests in future) to use the `@requires !jdk.static` to identify the presence or absence of a specific tool in the JDK installation doesn't seem right. Perhaps they should instead rely on a tool-specific property (like maybe `@requires jdk.tool.jlink`)?

The property will be useful to select the tests that can or cannot be selected by jtreg when the JDK under test is static image. Three are a number of tests that depend on layout or specific files in the modular run-time image so they will need to skipped when the JDK is a static image. So nothing to do with whether specific tools are present or not. The specific test updated here is a bit strange because lib/modules should never be a sym link in the first place and motivation for that is probably a different discussion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2667741172

From alanb at openjdk.org  Wed Feb 19 07:59:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Feb 2025 07:59:52 GMT
Subject: RFR: 8349547: Document jlink and jmods Supported Usage
In-Reply-To: <AexZULgyOat3caRVyoDemL4uokSDwHWWAGkF2CAtvCQ=.81d4b5a2-dff0-49e2-a9ab-0edb991ec48a@github.com>
References: <AexZULgyOat3caRVyoDemL4uokSDwHWWAGkF2CAtvCQ=.81d4b5a2-dff0-49e2-a9ab-0edb991ec48a@github.com>
Message-ID: <AmDQv1bbyIDVEME4xMaVwGOpQa65bzC9dEaP3Hyd0Ng=.d2b6d2a2-1eb9-44db-8022-25a0051e44ff@github.com>

On Tue, 18 Feb 2025 09:24:38 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

> Document supported usage of jlink with JDK jmod's
> The document will reflect the future work from JDK-8347831

There are several issues with the proposed update. I think it would be better to close this PR and we'll update the jlink docs when a solution for JDK-8347831 is proposed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23672#issuecomment-2667832133

From redestad at openjdk.org  Wed Feb 19 08:04:53 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 19 Feb 2025 08:04:53 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
Message-ID: <OQFh3DTyFqCcNT3Tuo21MV-_-uTGgV_8QUvDvaAtHWs=.16070bd1-8714-44b8-a5c5-843eb50fd03e@github.com>

On Wed, 19 Feb 2025 03:21:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
>> 
>> After this PR, below JMH tests will run passes.
>> 
>> 
>> org.openjdk.bench.javax.xml.DOM.testBuild
>> org.openjdk.bench.javax.xml.DOM.testModify
>> org.openjdk.bench.javax.xml.DOM.testWalk
>> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
>> org.openjdk.bench.javax.xml.STAX.testParse
>> 
>> 
>> Test command:
>> 
>> 
>> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
>> 
>> 
>> Change has been verified locally, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SetupCopyFiles macro to copy the dependency files

If you have manually verified that the build fails if any of these files are removed then I'm happy. No new tests or documentation needed, really. 

I could cast my vote towards removing these particular micros. But as the work is done I say let's accept your change, (re-)evaluate their usefulness, and file a RFE to have them removed if they aren't. We have been building out the set of micros we regularly test in nightly / promotion testing, but due to resource constraints only a fraction is run on a regular basis - and javax.xml has not been a priority.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23625#issuecomment-2667842084

From syan at openjdk.org  Wed Feb 19 08:51:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Feb 2025 08:51:53 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <OQFh3DTyFqCcNT3Tuo21MV-_-uTGgV_8QUvDvaAtHWs=.16070bd1-8714-44b8-a5c5-843eb50fd03e@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
 <OQFh3DTyFqCcNT3Tuo21MV-_-uTGgV_8QUvDvaAtHWs=.16070bd1-8714-44b8-a5c5-843eb50fd03e@github.com>
Message-ID: <W-hxtaAW4Ysb4I5jQ87eTGBphlCdPe9X4S_6ePm1G-E=.25bacaec-1899-4b21-8e18-fb34b9815847@github.com>

On Wed, 19 Feb 2025 08:02:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> have manually verified that the build fails if any of these files are removed.

Yes. I have verified that. If I remove the dependency XML file, then `make test-image CONF=release JOBS=1` will report below failure.


gmake[3]: *** No rule to make target '/home/yansendao/git/jdk-ysd/test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/message_12.xml', needed by '/home/yansendao/git/jdk-ysd/build/linux-x86_64-server-release/support/test/micro/classes/org/openjdk/bench/javax/xml/message_12.xml'.  Stop.
gmake[2]: *** [make/Main.gmk:788: build-microbenchmark] Error 2

ERROR: Build failed for target 'test-image' in configuration 'linux-x86_64-server-release' (exit code 2)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23625#issuecomment-2667943440

From pminborg at openjdk.org  Wed Feb 19 09:18:26 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 19 Feb 2025 09:18:26 GMT
Subject: RFR: 8349653: Clarify the docs for MemorySegment::reinterpret
Message-ID: <L94NPSTuSp_-0febenOUpVNuqpoXd91mMReM3sS3INc=.82f12e00-7737-4a35-9585-309ddcb4ecef@github.com>

This PR proposes to clarify the documentation for two of the `MemorySegment::reinterpret` overloads.

-------------

Commit messages:
 - Revise MemorySegment::reinterpret docs

Changes: https://git.openjdk.org/jdk/pull/23688/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23688&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349653
  Stats: 18 lines in 1 file changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/23688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23688/head:pull/23688

PR: https://git.openjdk.org/jdk/pull/23688

From pminborg at openjdk.org  Wed Feb 19 09:29:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 19 Feb 2025 09:29:05 GMT
Subject: RFR: 8347814: Make all imports consistent in the FFM API tests and
 benchmarks
Message-ID: <5KNH2AAZ_KnLt2xRMfHFFNmJ8zf0p6n-arS-XSq5jm8=.3b36aafe-b403-4bf4-89e3-548829d46673@github.com>

This PR proposes to make all imports consistent in the FFM API tests and benchmarks.

This is a follow-up PR from https://github.com/openjdk/jdk/pull/22827

Passes tier1-3

-------------

Commit messages:
 - Merge branch 'master' into fix-imports-tests
 - Fix copyright year
 - Fix imports

Changes: https://git.openjdk.org/jdk/pull/23689/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23689&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347814
  Stats: 1239 lines in 155 files changed: 553 ins; 426 del; 260 mod
  Patch: https://git.openjdk.org/jdk/pull/23689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23689/head:pull/23689

PR: https://git.openjdk.org/jdk/pull/23689

From duke at openjdk.org  Wed Feb 19 09:34:26 2025
From: duke at openjdk.org (Nicole Xu)
Date: Wed, 19 Feb 2025 09:34:26 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe
Message-ID: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>

The UnsafeOps JMH benchmark fails with the following error:

      java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426

To resolve this, we add the required `--add-opens` flag to grant access for the benchmark.

-------------

Commit messages:
 - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe

Changes: https://git.openjdk.org/jdk/pull/23686/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23686&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349944
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23686.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23686/head:pull/23686

PR: https://git.openjdk.org/jdk/pull/23686

From duke at openjdk.org  Wed Feb 19 10:06:51 2025
From: duke at openjdk.org (Nicole Xu)
Date: Wed, 19 Feb 2025 10:06:51 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe
In-Reply-To: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
Message-ID: <qf1iFNAeSZ8qQEUoZnORUPTPzyj5DDb_BF_J2dCAGB0=.6ade0e0b-6698-4c33-abde-9a021aed04cc@github.com>

On Wed, 19 Feb 2025 07:53:15 GMT, Nicole Xu <duke at openjdk.org> wrote:

> The UnsafeOps JMH benchmark fails with the following error:
> 
>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
> 
> To resolve this, we add the required `--add-opens` flag to grant access for the benchmark.

Hi @AlanBateman. Here is a bug fix for the micro benchmark of class Unsafe. Could you please review the changes? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2668146656

From alanb at openjdk.org  Wed Feb 19 10:32:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Feb 2025 10:32:53 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe
In-Reply-To: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
Message-ID: <dg51oG90Zbe9buwCEbLKqG4ikVzWS0SBm3XoIcyE4yU=.e883f8e1-b548-41da-8378-13fae69cb687@github.com>

On Wed, 19 Feb 2025 07:53:15 GMT, Nicole Xu <duke at openjdk.org> wrote:

> The UnsafeOps JMH benchmark fails with the following error:
> 
>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
> 
> To resolve this, we add the required `--add-opens` flag to grant access for the benchmark.

This micro was created for sun.misc.Unsafe, not jdk.internal.misc.Unsafe.  The change for JDK-8332744 should not have changed this test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2668214764

From viktor.klang at oracle.com  Wed Feb 19 10:43:33 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 19 Feb 2025 10:43:33 +0000
Subject: [External] : Re: JDK-8072840: Presizing for Stream Collectors
In-Reply-To: <2128797827.112041113.1739630649423.JavaMail.zimbra@univ-eiffel.fr>
References: <CAHY-eHsUqc905OqqcYXsuVZjeM+A81OOV2K7CsJ1zg8uc4cPOQ@mail.gmail.com>
 <9288FDCA-0984-487B-9426-559CE9EA5632@oracle.com>
 <MW4PR10MB5774BFFCD72E859A29A24CF8FFFF2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <2128797827.112041113.1739630649423.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB5774FE8F8342AB1DA56C14E5FFC52@MW4PR10MB5774.namprd10.prod.outlook.com>

Might be possible to extract the "descriptive" accessors to a superinterface of Spliterator.
And Gatherer could either transform an incoming such instance to an estimated outbound instance, plus an overload of initializer, and Collector would likely only need the supplier overload.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Remi Forax <forax at univ-mlv.fr>
Sent: Saturday, 15 February 2025 15:44
To: Viktor Klang <viktor.klang at oracle.com>; Fabian Meumertzheim <fabian at buildbuddy.io>
Cc: Paul Sandoz <paul.sandoz at oracle.com>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: [External] : Re: JDK-8072840: Presizing for Stream Collectors



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "Paul Sandoz" <paul.sandoz at oracle.com>, "Fabian Meumertzheim" <fabian at buildbuddy.io>
Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
Sent: Thursday, February 13, 2025 11:30:59 PM
Subject: Re: JDK-8072840: Presizing for Stream Collectors
Indeed. I hope I didn't sound discouraging about the possibility to propagate the stream size information.

I merely want to emphasize that it may necessitate a slightly broader take on the problem of propagation of stream-instance metadata, especially in the face of Gatherers becoming a finalized feature.

We already have an abstraction for propagating metadata, it's the query part of Spliterator (characteristics/estimateSize/comparator etc, technically all abstract methods that does not starts with "try").
For a Gatherer, we need a way to say if a characteristics is preserved or removed.
For a collector, we need a way to have a supplier that takes a Spliterator (a synthetic one, not the one that powers the actual stream) so the characteristics can be queried.


It's great that you started this conversation, Fabian!

Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Paul Sandoz <paul.sandoz at oracle.com>
Sent: Thursday, 13 February 2025 20:18
To: Fabian Meumertzheim <fabian at buildbuddy.io>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: JDK-8072840: Presizing for Stream Collectors

Hi Fabian,

Thanks for sharing and reaching out with the idea before getting too beholden to it.

I logged this is quite a while ago. It seemed like a possible good idea at the time, although I never liked the duplication of suppliers. I have become less enthusiastic overtime, especially so as Gatherers have been added. (Gatherer is the underlying primitive we could not find when we were furiously developing streams and meeting the Java 8 deadline.) My sense is if we are going to address we need to think more broadly about Gatherers. And, Viktor being the lead on Gatherers has a good take on where this might head.

Paul.

> On Feb 12, 2025, at 2:09?AM, Fabian Meumertzheim <fabian at buildbuddy.io> wrote:
>
> As an avid user of Guava's ImmutableCollections, I have been
> interested in ways to close the efficiency gap between the built-in
> `Stream#toList()` and third-party `Collector` implementations such as
> `ImmutableList#toImmutableList()`. I've found the biggest problem to
> be the lack of sizing information in `Collector`s, which led to me to
> draft a solution to JDK-8072840:
> https://github.com/openjdk/jdk/pull/23461<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23461__;!!ACWV5N9M2RV99hQ!LTEREzHdc6ygpw-3ySfNxSnGgAE_lEgi-NVIohRizUbXqPEDTxxWv25DQMlv_BO37jHevX51iL7Jtzd7YAOB$>
>
> The benchmark shows pretty significant gains for sized streams that
> mostly reshape data (e.g. slice records or turn a list into a map by
> associating keys), which I've found to be a pretty common use case.
>
> Before I formally send out the PR for review, I would like to gather
> feedback on the design aspects of it (rather than the exact
> implementation). I will thus leave it in draft mode for now, but
> invite anyone to comment on it or on this thread.
>
> Fabian


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250219/a7efe516/attachment-0001.htm>

From duke at openjdk.org  Wed Feb 19 10:45:54 2025
From: duke at openjdk.org (Marcono1234)
Date: Wed, 19 Feb 2025 10:45:54 GMT
Subject: RFR: 8347946: Add API note that caller should validate/trust
 signers to the getCertificates and getCodeSigners methods of JarEntry and
 JarURLConnection
In-Reply-To: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
References: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
Message-ID: <FqHa_AlrtRYs9zpT1UmtpxZgRWLqZKd2XjA7IgZt3tY=.86d25736-a2f3-470e-96b2-e867d7a1bc13@github.com>

On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates.
> 
> 2 other smaller changes:
>  - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead
>  - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`)

src/java.base/share/classes/java/util/jar/JarEntry.java line 100:

> 98:      * reached. Otherwise, this method will return {@code null}.
> 99:      *
> 100:      * <p>It is recommended to use the {@link getCodeSigners} method instead,

Isn't this missing a `#` to be a valid link?
Suggestion:

     * <p>It is recommended to use the {@link #getCodeSigners} method instead,


(Please don't use the "Commit suggestion" button to not include me as author)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23616#discussion_r1961440218

From jpai at openjdk.org  Wed Feb 19 10:52:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Feb 2025 10:52:59 GMT
Subject: RFR: 8347946: Add API note that caller should validate/trust
 signers to the getCertificates and getCodeSigners methods of JarEntry and
 JarURLConnection
In-Reply-To: <FqHa_AlrtRYs9zpT1UmtpxZgRWLqZKd2XjA7IgZt3tY=.86d25736-a2f3-470e-96b2-e867d7a1bc13@github.com>
References: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
 <FqHa_AlrtRYs9zpT1UmtpxZgRWLqZKd2XjA7IgZt3tY=.86d25736-a2f3-470e-96b2-e867d7a1bc13@github.com>
Message-ID: <GqCa4zI-4F2cZdgWwPthnQ8gaJZcz0Bo3GE0MseOMCY=.e58c7db8-9d90-43e0-9a8e-7a10e1f7e454@github.com>

On Wed, 19 Feb 2025 10:43:06 GMT, Marcono1234 <duke at openjdk.org> wrote:

>> This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates.
>> 
>> 2 other smaller changes:
>>  - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead
>>  - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`)
>
> src/java.base/share/classes/java/util/jar/JarEntry.java line 100:
> 
>> 98:      * reached. Otherwise, this method will return {@code null}.
>> 99:      *
>> 100:      * <p>It is recommended to use the {@link getCodeSigners} method instead,
> 
> Isn't this missing a `#` to be a valid link?
> Suggestion:
> 
>      * <p>It is recommended to use the {@link #getCodeSigners} method instead,
> 
> 
> (Please don't use the "Commit suggestion" button to not include me as author)

I had a similar reaction when I first saw it. So I checked the javadoc specification the other day and it states https://docs.oracle.com/en/java/javase/23/docs/specs/javadoc/doc-comment-spec.html#references:


The most general form of a reference is:

    module/package.class#member

This form is used by the see, link and linkplain tags.

Leading components can be omitted when they can be inferred from the surrounding context. Trailing components can be omitted when they are not required.

... When the reference is to a member of the same class as that containing the documentation comment, all parts of the reference up to and including the # may be omitted, although the '#' may be retained for clarity.


So, syntactically, it's fine in the current form.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23616#discussion_r1961450370

From forax at univ-mlv.fr  Wed Feb 19 10:59:09 2025
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 19 Feb 2025 11:59:09 +0100 (CET)
Subject: [External] : Re: JDK-8072840: Presizing for Stream Collectors
In-Reply-To: <MW4PR10MB5774FE8F8342AB1DA56C14E5FFC52@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAHY-eHsUqc905OqqcYXsuVZjeM+A81OOV2K7CsJ1zg8uc4cPOQ@mail.gmail.com>
 <9288FDCA-0984-487B-9426-559CE9EA5632@oracle.com>
 <MW4PR10MB5774BFFCD72E859A29A24CF8FFFF2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <2128797827.112041113.1739630649423.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774FE8F8342AB1DA56C14E5FFC52@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <973984977.118694078.1739962749681.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "Fabian Meumertzheim"
> <fabian at buildbuddy.io>
> Cc: "Paul Sandoz" <paul.sandoz at oracle.com>, "core-libs-dev"
> <core-libs-dev at openjdk.org>
> Sent: Wednesday, February 19, 2025 11:43:33 AM
> Subject: Re: [External] : Re: JDK-8072840: Presizing for Stream Collectors

> Might be possible to extract the "descriptive" accessors to a superinterface of
> Spliterator.
> And Gatherer could either transform an incoming such instance to an estimated
> outbound instance, plus an overload of initializer , and Collector would likely
> only need the supplier overload.

yes, something like that. 

> Cheers,
> ?

regards, 
R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: Remi Forax <forax at univ-mlv.fr>
> Sent: Saturday, 15 February 2025 15:44
> To: Viktor Klang <viktor.klang at oracle.com>; Fabian Meumertzheim
> <fabian at buildbuddy.io>
> Cc: Paul Sandoz <paul.sandoz at oracle.com>; core-libs-dev
> <core-libs-dev at openjdk.org>
> Subject: [External] : Re: JDK-8072840: Presizing for Stream Collectors

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "Paul Sandoz" <paul.sandoz at oracle.com>, "Fabian Meumertzheim"
>> <fabian at buildbuddy.io>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
>> Sent: Thursday, February 13, 2025 11:30:59 PM
>> Subject: Re: JDK-8072840: Presizing for Stream Collectors

>> Indeed. I hope I didn't sound discouraging about the possibility to propagate
>> the stream size information.

>> I merely want to emphasize that it may necessitate a slightly broader take on
>> the problem of propagation of stream-instance metadata, especially in the face
>> of Gatherers becoming a finalized feature.

> We already have an abstraction for propagating metadata, it's the query part of
> Spliterator (characteristics/estimateSize/comparator etc, technically all
> abstract methods that does not starts with "try").
> For a Gatherer, we need a way to say if a characteristics is preserved or
> removed.
> For a collector, we need a way to have a supplier that takes a Spliterator (a
> synthetic one, not the one that powers the actual stream) so the
> characteristics can be queried.

>> It's great that you started this conversation, Fabian!

>> Cheers,
>> ?

> regards,
> R?mi

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Paul Sandoz
>> <paul.sandoz at oracle.com>
>> Sent: Thursday, 13 February 2025 20:18
>> To: Fabian Meumertzheim <fabian at buildbuddy.io>
>> Cc: core-libs-dev <core-libs-dev at openjdk.org>
>> Subject: Re: JDK-8072840: Presizing for Stream Collectors
>> Hi Fabian,

>> Thanks for sharing and reaching out with the idea before getting too beholden to
>> it.

>> I logged this is quite a while ago. It seemed like a possible good idea at the
>> time, although I never liked the duplication of suppliers. I have become less
>> enthusiastic overtime, especially so as Gatherers have been added. (Gatherer is
>> the underlying primitive we could not find when we were furiously developing
>> streams and meeting the Java 8 deadline.) My sense is if we are going to
>> address we need to think more broadly about Gatherers. And, Viktor being the
>> lead on Gatherers has a good take on where this might head.

>> Paul.

>> > On Feb 12, 2025, at 2:09 AM, Fabian Meumertzheim <fabian at buildbuddy.io> wrote:

>> > As an avid user of Guava's ImmutableCollections, I have been
>> > interested in ways to close the efficiency gap between the built-in
>> > `Stream#toList()` and third-party `Collector` implementations such as
>> > `ImmutableList#toImmutableList()`. I've found the biggest problem to
>> > be the lack of sizing information in `Collector`s, which led to me to
>> > draft a solution to JDK-8072840:
>>> [
>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/23461__;!!ACWV5N9M2RV99hQ!LTEREzHdc6ygpw-3ySfNxSnGgAE_lEgi-NVIohRizUbXqPEDTxxWv25DQMlv_BO37jHevX51iL7Jtzd7YAOB$
>> > |
>> https://github.com/openjdk/jdk/pull/23461 ]

>> > The benchmark shows pretty significant gains for sized streams that
>> > mostly reshape data (e.g. slice records or turn a list into a map by
>> > associating keys), which I've found to be a pretty common use case.

>> > Before I formally send out the PR for review, I would like to gather
>> > feedback on the design aspects of it (rather than the exact
>> > implementation). I will thus leave it in draft mode for now, but
>> > invite anyone to comment on it or on this thread.

>> > Fabian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250219/130f8888/attachment-0001.htm>

From nbenalla at openjdk.org  Wed Feb 19 11:05:59 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 19 Feb 2025 11:05:59 GMT
Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <kkbh1U2d4-82E1OOPq_SBkYolMqLmZz68XcT6ThMjEQ=.0e58b6b4-8e95-412e-8d3f-752e7af1a33e@github.com>
References: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
 <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>
 <kkbh1U2d4-82E1OOPq_SBkYolMqLmZz68XcT6ThMjEQ=.0e58b6b4-8e95-412e-8d3f-752e7af1a33e@github.com>
Message-ID: <HX3zhtWYlzDwcThjfRfh2UiSgtjvxOyz3lHTM4rr3cw=.98597d31-7abe-40a2-b7bf-36b592597b34@github.com>

On Tue, 18 Feb 2025 23:06:42 GMT, Ian Myers <imyers at openjdk.org> wrote:

>> make/common/Modules.gmk line 95:
>> 
>>> 93: SPEC_SUBDIRS += share/specs
>>> 94: 
>>> 95: MAN_SUBDIRS += share/man windows/man
>> 
>> Hm, normally I'd say you should use `$(TARGET_OS)/man`, but we typically generate docs for all platforms at the same time. So I guess this is okay.
>
> Hi @magicus we are seeing build failures because linux builds contain man pages for windows-only tools as reported by https://bugs.openjdk.org/browse/JDK-8350137. Would replacing `windows/man` with `$(TARGET_OS)/man` prevent windows-only tools man pages being generated for linux builds?

I think it will prevent windows-only tools man pages from being generated in linux builds, but it would prevent the man pages from appearing in the generated documentation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23351#discussion_r1961472101

From mullan at openjdk.org  Wed Feb 19 13:20:58 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 19 Feb 2025 13:20:58 GMT
Subject: Integrated: 8347946: Add API note that caller should validate/trust
 signers to the getCertificates and getCodeSigners methods of JarEntry and
 JarURLConnection
In-Reply-To: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
References: <Mcg3FoZUAMgqxn84qBuRXl0NAFsDNU3_6dTOREPUOGA=.0af49ada-9547-49bd-8b7d-6db9fdac37d0@github.com>
Message-ID: <L9ZbBjqGZEKUcIj8_nxo74y42LFwF4Mo-vJ38JfpFtw=.a0092dcb-dae3-40e2-a68a-15700a36845e@github.com>

On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates.
> 
> 2 other smaller changes:
>  - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead
>  - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`)

This pull request has now been integrated.

Changeset: 577ff98a
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/577ff98a6733a99ea49510f15d631beff39c34a5
Stats:     38 lines in 3 files changed: 32 ins; 0 del; 6 mod

8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection

Reviewed-by: lancea, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/23616

From jvernee at openjdk.org  Wed Feb 19 13:37:52 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 19 Feb 2025 13:37:52 GMT
Subject: RFR: 8349653: Clarify the docs for MemorySegment::reinterpret
In-Reply-To: <L94NPSTuSp_-0febenOUpVNuqpoXd91mMReM3sS3INc=.82f12e00-7737-4a35-9585-309ddcb4ecef@github.com>
References: <L94NPSTuSp_-0febenOUpVNuqpoXd91mMReM3sS3INc=.82f12e00-7737-4a35-9585-309ddcb4ecef@github.com>
Message-ID: <b3lC65p_qGPstfiO8luo7Fo3FqjfLQpNuTsCCF3PzVE=.dcfddf4a-ec37-46d4-9b5e-cfa77a4b05a5@github.com>

On Wed, 19 Feb 2025 09:14:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to clarify the documentation for two of the `MemorySegment::reinterpret` overloads.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23688#pullrequestreview-2626820343

From erikj at openjdk.org  Wed Feb 19 13:49:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 19 Feb 2025 13:49:58 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
Message-ID: <y6d6_b60b9nidZHhFWe-z9fErOcE0edW2TriTlORllI=.017268bc-2de1-4ee1-b579-74517baba975@github.com>

On Wed, 19 Feb 2025 03:21:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
>> 
>> After this PR, below JMH tests will run passes.
>> 
>> 
>> org.openjdk.bench.javax.xml.DOM.testBuild
>> org.openjdk.bench.javax.xml.DOM.testModify
>> org.openjdk.bench.javax.xml.DOM.testWalk
>> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
>> org.openjdk.bench.javax.xml.STAX.testParse
>> 
>> 
>> Test command:
>> 
>> 
>> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
>> 
>> 
>> Change has been verified locally, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SetupCopyFiles macro to copy the dependency files

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23625#pullrequestreview-2626861253

From coleenp at openjdk.org  Wed Feb 19 13:54:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Feb 2025 13:54:55 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <o0OOTu12p_xatdRLah4eYogKT3R1je0CKtw-mQVsi2Y=.c16a1780-0e76-4d9d-b9f7-5f9b45695c7d@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <6EpQLprXKfUDUQ6UIl0Vo0M5OPmCJ4SjcnOeprbO40w=.7d6cd0d3-ec59-4935-adb9-484764f0235c@github.com>
 <oIkFtLHt8zVGSYcgzTIiQUarrANFHe2XjVYufDlqKPM=.b8a2516f-1668-44fd-b4b7-16a8f9703167@github.com>
 <S35E5eUCp-oDpwRdgMUzaHEIo8wv16ACZb7iDRzzm0g=.0d482ee0-73cb-494b-a98c-c0aaed5d07f2@github.com>
 <o0OOTu12p_xatdRLah4eYogKT3R1je0CKtw-mQVsi2Y=.c16a1780-0e76-4d9d-b9f7-5f9b45695c7d@github.com>
Message-ID: <g5Gge906h_xfzwqXX8lf1kFyp7nq-NDqfQk8iIdYnNw=.3becf624-1862-46b2-9078-38c8a7163809@github.com>

On Wed, 19 Feb 2025 02:54:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I don't know if we have a style guide that covers this, but I believe the method and field could both be named `isPrimitive`.
>
> I would personally name such a boolean field `primitive`, but I don't have a strong preference on the field naming as long as its references in tests and other locations are correct. In addition, I believe this field may soon be widened to carry more hotspot-specific flags (such as hidden, etc.) so the name is bound to change.

I like 'primitive'.  'hidden' is also a possibility to add to this and give it the same treatment.  I didn't do that one here to limit the changes and I haven't seen all the calls to isHidden so would need to find out how to measure the effects of that change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1961722833

From pminborg at openjdk.org  Wed Feb 19 14:28:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 19 Feb 2025 14:28:39 GMT
Subject: RFR: 8350334: Add final keywords to FFM methods
Message-ID: <6DDqOOkbNVUXgUWn9flY41lfcWIWVOgvBrgxa5njpSg=.b9893567-2543-49c8-bc3f-c3b88e27bcab@github.com>

This PR proposes to add the `final` keyword to some classes and methods in order to simplify compiler devirtualization (e.g. in Graal native image).

Passes `make test TEST=jdk_foreign`

-------------

Commit messages:
 - Make methods and classes final

Changes: https://git.openjdk.org/jdk/pull/23696/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23696&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350334
  Stats: 89 lines in 9 files changed: 5 ins; 0 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/23696.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23696/head:pull/23696

PR: https://git.openjdk.org/jdk/pull/23696

From pminborg at openjdk.org  Wed Feb 19 14:32:57 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 19 Feb 2025 14:32:57 GMT
Subject: RFR: 8349653: Clarify the docs for MemorySegment::reinterpret
In-Reply-To: <b3lC65p_qGPstfiO8luo7Fo3FqjfLQpNuTsCCF3PzVE=.dcfddf4a-ec37-46d4-9b5e-cfa77a4b05a5@github.com>
References: <L94NPSTuSp_-0febenOUpVNuqpoXd91mMReM3sS3INc=.82f12e00-7737-4a35-9585-309ddcb4ecef@github.com>
 <b3lC65p_qGPstfiO8luo7Fo3FqjfLQpNuTsCCF3PzVE=.dcfddf4a-ec37-46d4-9b5e-cfa77a4b05a5@github.com>
Message-ID: <noUnjGSKVCMOcMzrxGlNaDtFG_xTmMnhBEbvIaaYMDY=.ea4e0ed8-6181-4b60-886e-378aeac7e7bd@github.com>

On Wed, 19 Feb 2025 13:35:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR proposes to clarify the documentation for two of the `MemorySegment::reinterpret` overloads.
>
> Marked as reviewed by jvernee (Reviewer).

Thanks for the review @JornVernee! I am going to let this PR sit for an extra day in case there is additional feedback, before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23688#issuecomment-2668823935

From rriggs at openjdk.org  Wed Feb 19 15:12:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Feb 2025 15:12:59 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <ZjAN9VKqYZJ9kEzsFzL2NXtxIEa1Z_DMCA4B1rmWccs=.663c1dd7-b70d-4746-ad80-85446f82f53f@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

Is the change to isInterface and isPrimitive performance neutral?
As @IntrinsicCandidates, there would be some performance gain.

src/hotspot/share/prims/jvm.cpp line 2284:

> 2282: // Please, refer to the description in the jvmtiThreadState.hpp.
> 2283: 
> 2284: JVM_ENTRY(jboolean, JVM_IsInterface(JNIEnv *env, jclass cls))

JVM_IsInteface is deleted in Class.c, what purpose is this?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23572#pullrequestreview-2627122068
PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1961858757

From rriggs at openjdk.org  Wed Feb 19 15:15:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Feb 2025 15:15:57 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <rCOGZidDLYm4-NaaZkkHkw2Yo-OFPhXPy-nn3pWi85Q=.41bd48cb-2410-42ec-9110-edccebfb4c37@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

src/java.base/share/classes/java/lang/Class.java line 807:

> 805:      */
> 806:     public boolean isArray() {
> 807:         return componentType != null;

The componentType declaration should have a comment indicating that == null is the sole indication that the class is an interface.
Perhaps there should be an assert somewhere validating/cross checking that requirement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1961869286

From liach at openjdk.org  Wed Feb 19 15:45:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Feb 2025 15:45:56 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <FrlPjmMb7CgcaoCNXLWwybw-pcHprdWIP8whY8fJU9g=.2564ab5c-9d30-4e5d-95cc-7a85955643b0@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <FrlPjmMb7CgcaoCNXLWwybw-pcHprdWIP8whY8fJU9g=.2564ab5c-9d30-4e5d-95cc-7a85955643b0@github.com>
Message-ID: <2sugnK5bK-SWGVluAWw-UNTKKkErTTNYTxCk7t0mOGo=.3734936f-7a10-48ec-8901-01ece733791f@github.com>

On Wed, 19 Feb 2025 05:08:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> src/java.base/share/classes/java/lang/Class.java line 1009:
> 
>> 1007:     private transient Object classData; // Set by VM
>> 1008:     private transient Object[] signers; // Read by VM, mutable
>> 1009:     private final transient char modifiers;  // Set by the VM
> 
> Why the change of type here?

This is to improve the layout so the introduction of a boolean field does not increase the size of a Class object.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1961925828

From liach at openjdk.org  Wed Feb 19 15:54:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Feb 2025 15:54:52 GMT
Subject: RFR: 8350334: Add final keywords to FFM methods
In-Reply-To: <6DDqOOkbNVUXgUWn9flY41lfcWIWVOgvBrgxa5njpSg=.b9893567-2543-49c8-bc3f-c3b88e27bcab@github.com>
References: <6DDqOOkbNVUXgUWn9flY41lfcWIWVOgvBrgxa5njpSg=.b9893567-2543-49c8-bc3f-c3b88e27bcab@github.com>
Message-ID: <hqtPwcwIUg1r5Hdw0rNPDItjyiZECm7UFMOzw3Aaj8w=.1e57eb29-ef67-49ed-9237-38b4538150b2@github.com>

On Wed, 19 Feb 2025 14:23:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add the `final` keyword to some classes and methods in order to assist compiler devirtualization (e.g. in Graal native image).
> 
> Passes `make test TEST=jdk_foreign`

Looks simple and trivial.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23696#pullrequestreview-2627259944

From liach at openjdk.org  Wed Feb 19 15:59:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Feb 2025 15:59:52 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe
In-Reply-To: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
Message-ID: <bqudOX5XhVqQzu4wxmUE-pVIEvgDKfalk29COgEIJ4Y=.22989ccc-d528-4bbe-ac23-16652dc3cc14@github.com>

On Wed, 19 Feb 2025 07:53:15 GMT, Nicole Xu <duke at openjdk.org> wrote:

> The UnsafeOps JMH benchmark fails with the following error:
> 
>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
> 
> To resolve this, we add the required `--add-opens` flag to grant access for the benchmark.

Yeah, a better fix for this would be to change the import of jdk.internal.misc back to sun.misc, as before JDK-8332744. Unfortunately we will have to accept the "proprietary API" warning, but they are necessary as such APIs are bound for removal for the integrity of the platform.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2669069824

From dl at openjdk.org  Wed Feb 19 16:13:14 2025
From: dl at openjdk.org (Doug Lea)
Date: Wed, 19 Feb 2025 16:13:14 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling
Message-ID: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>

(Copied from https://bugs.openjdk.org/browse/JDK-8319447)

The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.

We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.

A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.

Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for delayed tasks to become enabled and execute, or to cancel them and terminate. The default (to wait) matches default settings of STPE. Also new method getDelayedTaskCount allows monitoring.

We don't expect any compatibility issues: In the unlikely event that someone else has added the four SES methods to a ForkJoinPool subclass, they will continue to work as overrides. It's hard to imagine that anyone has added a form of submitWithTimeout with the same signature (Callable<V> callable, long timeout, TimeUnit unit, Consumer<ForkJoinTask<V>> timeoutAction), or methods with names cancelDelayedTasksOnShutdown or getDelayedTaskCount.

A snag: for reasons that should now be deprecated, ForkJoinPool allow users to externally (via properties) set the commonPool to zero parallelism, disabling worker thread creation, which makes no sense if a DelayScheduler is used. This property setting was made available to JavaEE frameworks so they could ensure that no new threads would be created in service of parallelStream operations (which are structured to be (slowly) executable single-threadedly via caller joins). However, no other async uses would work, which led to workarounds in CompletableFuture (also SubmissionPublisher) to handle this case by generating other threads. It was another arguably wrong decision to do this as well. A better solution that is backward compatible is to internally override commonPool parallelism zero only if known-async methods are used. This preserves original intent, and passes jtreg/tck tests that check for lack of thread creation in parallelStreams and related usages that don't otherwise use a
 ny async j.u.c components (although with some changes in unnecessarily implementation-dependent tests that made assumptions about exactly which threads/pools were used). It does require some changes in the wording of disclaimers in CompletableFuture and elsewhere though. And eventually, all this should go away, although it's not clear know how to deprecate a property setting. For now, the class-level javadoc has been updated to discourage use.

One remaining issue is whether to expose the underlying ScheduledForkJoinTask type. It currently isn't, in part because it would also require exposing currently non-public intervening classes (mainly FJT.InterruptibleTask). The main disadvantage with not exposing is that the schedule methods merely document that the returned ScheduledFuture is a ForkJoinTask rather than include this in signature. This could be revisited in the future without introducing incompatibilities (but with some internal implementation challenges to remove reliance on non-public-ness).

As minor follow-ups, we might expand use of DelaySchedulers internally in j.u.c classes to replace some timed waits.

[Edit](https://bugs.openjdk.org/secure/EditComment!default.jspa?id=5114021&commentId=14754912)
[Delete](https://bugs.openjdk.org/secure/DeleteComment!default.jspa?id=5114021&commentId=14754912)

-------------

Commit messages:
 - Misc minor improvements and renamings for clarity
 - Add optional SubmitWithTimeout action
 - Merge remote-tracking branch 'refs/remotes/origin/JDK-8319447' into JDK-8319447
 - Merge branch 'openjdk:master' into JDK-8319447
 - Reduce garbage retention; use trailing padding; add tests
 - Better accommodate CompletableFuture; use 4-ary heap; add javadocs; other misc
 - Rename DelayedTask to ScheduledForkJoinTask; misc other improvements
 - Simplify policy methods; improve layout
 - Reduce memory accesses
 - Support STPE policy methods
 - ... and 24 more: https://git.openjdk.org/jdk/compare/7d11418c...53516e9d

Changes: https://git.openjdk.org/jdk/pull/23702/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319447
  Stats: 1776 lines in 9 files changed: 1524 ins; 155 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/23702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23702/head:pull/23702

PR: https://git.openjdk.org/jdk/pull/23702

From liach at openjdk.org  Wed Feb 19 16:21:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Feb 2025 16:21:57 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <n1Pm6orA_ufoz5E6FWMNMpfCypAT_q2FyImG4oqpVtM=.2e64b4d5-7805-4f7f-8a5c-0c4dfbc3f6c9@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <n1Pm6orA_ufoz5E6FWMNMpfCypAT_q2FyImG4oqpVtM=.2e64b4d5-7805-4f7f-8a5c-0c4dfbc3f6c9@github.com>
Message-ID: <-rVJ4riSt_UybCT4tvNKCBxGfrHr-xnGx0DNDZyGgsA=.11b43081-86f2-47db-b52c-5f74b8e27960@github.com>

On Wed, 19 Feb 2025 03:30:04 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> src/java.base/share/classes/java/lang/Class.java line 1287:
> 
>> 1285:      */
>> 1286:     public Class<?> getComponentType() {
>> 1287:         // Only return for array types. Storage may be reused for Class for instance types.
> 
> I don't see any changes to componentType related to reuse.  So was this comment and the code below already obsolete?

It was. Before the componentType field was reused for the class initialization monitor int array, and it caused problems with core reflection if a program reflectively accesses this field after a few hundred times. See [JDK-8337622](https://bugs.openjdk.org/browse/JDK-8337622).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1961989175

From liach at openjdk.org  Wed Feb 19 16:25:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Feb 2025 16:25:55 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <Pg84KDXxj5CYgcyMvzcKvDkuZElW6ycoX4JsrGB-ogQ=.29fb4838-4f30-446c-9015-a1e493467efe@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

Re roger's IntrinsicCandidate remark: One behavior that might be affected would be C2's inlining preferences. Some inline-sensitive workloads like FFM API might be affected if some Class attribute access cannot be inlined because the incoming Class object is not constant. See #23460 and #23628.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23572#issuecomment-2669138528

From duke at openjdk.org  Wed Feb 19 17:07:56 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Wed, 19 Feb 2025 17:07:56 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v3]
In-Reply-To: <cFpOX8erhzm1BkIDvun1TkXpj4YCwv3osFT-4NsT9Qw=.44d2ec66-dba4-43ec-b308-13ace56877d8@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Ge-ss9_8u5qA4M_E90pax7oKmmLjgywxVvxLrcUPC1I=.e7ab6efc-118b-469d-8f49-8d5d48bc0478@github.com>
 <nInbF3If8ExPBZM101LA4PscwTpE4WUuFx7GEx2_mL8=.ccc584b6-d75e-4864-a664-6f290402932d@github.com>
 <bfT8EMRk6msqkRF32_vQCfZvirTiWsvg0hrOpThz9i4=.1f6626ed-637e-4ff3-827d-f5dc34094910@github.com>
 <A_C2myp2dclvSO5vDmJD4sl9FMoWFCP-j1P7ihltcKc=.c1cb149b-0e33-4d6d-8399-8d6dfe5dbccc@github.com>
 <dl48ChO5x4futsrtaAjvvlxb4Enekr9S1qFCwQtGVkU=.904d075e-786d-4fe2-980c-f6e9143ba86a@github.com>
 <fcvrEMeNBT-Cp7C5MR_zsON1WDWouU72qVik-DiN4k0=.7b655123-f2ff-4c12-8d94-0845be867d05@github.com>
 <wmIgd_-kflkNtl_HeIq8sAgfBAeDGuYvT9xwsl1TnGc=.4e09a4cf-1f9a-441c-9f86-8f37a682757f@github.com>
 <G0QHgSxgst6mR2wqn6_LdUAb1C5dGfTVcLonEMBbC8Q=.dd75c6a5-9dd4-4605-89c3-fda9b17cd080@github.com>
 <T6tLX_u6tuehydDgOk-Zy90LEIsKMBVHyAtukZgZETo=.dcfd7512-360d-4f51-8b49-7d42199aa6d7@github.com>
 <Cpc_kxrUHuC3Sj2zluPHtPICI63z2swogYe
 c43ycS-I=.b034cc18-7472-4a0c-88d7-2f50eb258692@github.com>
 <HKYrg1nnFMjktEeAAeqF2XE3gy7wQ6-nR7s30Fqecbo=.604a4916-dc31-4bec-a90d-62d5eff16d5b@github.com>
 <cFpOX8erhzm1BkIDvun1TkXpj4YCwv3osFT-4NsT9Qw=.44d2ec66-dba4-43ec-b308-13ace56877d8@github.com>
Message-ID: <6VaLYgZRUSlmtpkbYg6m2s5S7Idrph6FCqK6RpJ3fnE=.b41ce8e0-1569-47ca-91f7-5fe1ffcd571b@github.com>

On Tue, 18 Feb 2025 09:56:21 GMT, David Beaumont <duke at openjdk.org> wrote:

>I'm afraid I don't see how the double-check idea would work...

Yep. I missed that case.

>The other option is to just allow the lock to be dropped.

The other options are many.  Leader-follower pattern would allow FileHandler to not hold the lock during format and retain existing rotate/limit behavior.

Getting back to your earlier question on blocking behavior in Formatter.  Here are some examples I use:
1. ProcessBuilderFormatter. Subclasses include tasklist, netstat, sysinfo, so on which dumps output of those commands to string. Bursts of LogRecords can share a recent result to keep process creation under control.
2. ScreenshotFormatter. Uses java.awt.Robot to grab a screenshot. Then base64 encode the result. This Formatter requires one record per log file. This does the similar burst handling by sharing a recent result. I used this to reopen https://bugs.openjdk.org/browse/JDK-6219960
3. GraphicsFormatter. Paints all frames to an image and base64 encode it.
4. FileFormatter. Returns the contents of a file as a string.  Useful on Linux systems.

All of those formatters I pair with a filter and or attach to a specific logger as I'm listening for a trigger log record.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1960972400

From asemenyuk at openjdk.org  Wed Feb 19 17:11:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 19 Feb 2025 17:11:02 GMT
Subject: Integrated: 8350102: Decouple jpackage test-lib Executor.Result and
 Executor classes
In-Reply-To: <sMoAqlXBM8Xvt3zHIdPVHGfo4UopIxK7kOuIpnMLH-I=.45400301-529d-464e-baa8-144a1d0cc3f1@github.com>
References: <sMoAqlXBM8Xvt3zHIdPVHGfo4UopIxK7kOuIpnMLH-I=.45400301-529d-464e-baa8-144a1d0cc3f1@github.com>
Message-ID: <Cu8z-0UPE79KtShRpa19FPDvy7PbcjMgBnDR9SU-o5I=.89ff7c89-dd4f-4568-b31f-6242ad913198@github.com>

On Fri, 14 Feb 2025 14:52:38 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8350102: Decouple jpackage test-lib Executor.Result and Executor classes

This pull request has now been integrated.

Changeset: 3487f8cb
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3487f8cbd55b06d332d897a010ae8eb371dd4956
Stats:     48 lines in 3 files changed: 15 ins; 7 del; 26 mod

8350102: Decouple jpackage test-lib Executor.Result and Executor classes

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/23636

From coleenp at openjdk.org  Wed Feb 19 17:16:02 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Feb 2025 17:16:02 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <L9_OtZrEExuNr95rU83lgTalaivutLbdTnCgqjT6TkI=.e15ba695-3f5c-433d-9aa7-4db068ce7ce1@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

Thanks for looking at this change.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23572#pullrequestreview-2626906239

From coleenp at openjdk.org  Wed Feb 19 17:16:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Feb 2025 17:16:04 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <FrlPjmMb7CgcaoCNXLWwybw-pcHprdWIP8whY8fJU9g=.2564ab5c-9d30-4e5d-95cc-7a85955643b0@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <FrlPjmMb7CgcaoCNXLWwybw-pcHprdWIP8whY8fJU9g=.2564ab5c-9d30-4e5d-95cc-7a85955643b0@github.com>
Message-ID: <maTemwep0WbKgtihRZGo6LdtkVJAtVi8I-NNP18wvQ8=.34e3da87-46e9-4db4-9d3d-ad73ca8096b2@github.com>

On Wed, 19 Feb 2025 05:01:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> src/hotspot/share/classfile/javaClasses.cpp line 1371:
> 
>> 1369: #endif
>> 1370:   set_modifiers(java_class, JVM_ACC_ABSTRACT | JVM_ACC_FINAL | JVM_ACC_PUBLIC);
>> 1371:   set_is_primitive(java_class);
> 
> Just wondering what the comments at the start of this method are alluding to now that we do have a field at the Java level. ???

I think this comment is talking about java.lang.Class.klass field is null.  Which it still is since there's no Klass pointer for basic types. But no idea what the comment is in ClassFileParser and I don't think introducing a new Klass for primitive types is an improvement.  There are comments elsewhere that the klass is null for primitive types, including the call to java_lang_Class::is_primitive(), so this whole comment is only confusing so I'll remove it.  Or change it to:

  // Mirrors for basic types have a null klass field, which makes them special.

> src/hotspot/share/prims/jvm.cpp line 1262:
> 
>> 1260: JVM_END
>> 1261: 
>> 1262: JVM_ENTRY(jboolean, JVM_IsArrayClass(JNIEnv *env, jclass cls))
> 
> Where are the changes to jvm.h?

Good catch, I also removed getProtectionDomain.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1961739084
PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1961773882

From coleenp at openjdk.org  Wed Feb 19 17:16:05 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Feb 2025 17:16:05 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <E9GPjreqeKFJmZAIjHGQ-1y6FnyqaT94FHUPuK65kmE=.48bd4ecc-ac91-4f7b-895b-a32280d8b437@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <E9GPjreqeKFJmZAIjHGQ-1y6FnyqaT94FHUPuK65kmE=.48bd4ecc-ac91-4f7b-895b-a32280d8b437@github.com>
Message-ID: <_j9Wkg21aBltyVrbO4wxGFKmmLDy0T-eorRL4epfS4k=.5a453b6b-d673-4cc6-b29f-192fa74e290c@github.com>

On Wed, 19 Feb 2025 02:54:05 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> src/hotspot/share/classfile/javaClasses.inline.hpp line 301:
> 
>> 299: #ifdef ASSERT
>> 300:   // The heapwalker walks through Classes that have had their Klass pointers removed, so can't assert this.
>> 301:   // assert(is_primitive == java_class->bool_field(_is_primitive_offset), "must match what we told Java");
> 
> I don't understand this comment about the heapwalker.  It sounds like we could have `is_primitive` set to true incorrectly.  If so, what prevents the asserts below from failing?  And why not use the value from _is_primitive_offset instead?

This is a good question.  The heapwalker walks through dead mirrors so I can't assert that a null klass field matches our boolean setting but I don't know why this never asserts (can't find any instances in the bug database) but it seems like it could.  I'll use the bool field in the mirror in the assert though but not in the return since the caller likely will fetch the klass pointer next.

> src/hotspot/share/prims/jvm.cpp line 2283:
> 
>> 2281: // Otherwise it returns its argument value which is the _the_class Klass*.
>> 2282: // Please, refer to the description in the jvmtiThreadState.hpp.
>> 2283: 
> 
> Does this "RedefineClasses support" comment still belong here?

I think so. The comment in jvmtiThreadState.hpp has details why this is.  We do a mirror switch before verification apparently because of bug 6214132 it says.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1961770573
PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1962059680

From coleenp at openjdk.org  Wed Feb 19 17:16:07 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Feb 2025 17:16:07 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <-rVJ4riSt_UybCT4tvNKCBxGfrHr-xnGx0DNDZyGgsA=.11b43081-86f2-47db-b52c-5f74b8e27960@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <n1Pm6orA_ufoz5E6FWMNMpfCypAT_q2FyImG4oqpVtM=.2e64b4d5-7805-4f7f-8a5c-0c4dfbc3f6c9@github.com>
 <-rVJ4riSt_UybCT4tvNKCBxGfrHr-xnGx0DNDZyGgsA=.11b43081-86f2-47db-b52c-5f74b8e27960@github.com>
Message-ID: <u01Zz75QR4Kvx3ExKJTCnHIKPNVLvekS6fqT5MIZtzk=.5eda33dd-f19d-4549-8216-36c3aa3834cf@github.com>

On Wed, 19 Feb 2025 16:19:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 1287:
>> 
>>> 1285:      */
>>> 1286:     public Class<?> getComponentType() {
>>> 1287:         // Only return for array types. Storage may be reused for Class for instance types.
>> 
>> I don't see any changes to componentType related to reuse.  So was this comment and the code below already obsolete?
>
> It was. Before the componentType field was reused for the class initialization monitor int array, and it caused problems with core reflection if a program reflectively accesses this field after a few hundred times. See [JDK-8337622](https://bugs.openjdk.org/browse/JDK-8337622).

Yes, this comment is obsolete.  We used to share the componentType mirror with an internal 'init-lock' but it caused a bug that was fixed.  If it's not an array the componentType is now always null.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1962069719

From coleenp at openjdk.org  Wed Feb 19 17:16:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Feb 2025 17:16:06 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <2sugnK5bK-SWGVluAWw-UNTKKkErTTNYTxCk7t0mOGo=.3734936f-7a10-48ec-8901-01ece733791f@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <FrlPjmMb7CgcaoCNXLWwybw-pcHprdWIP8whY8fJU9g=.2564ab5c-9d30-4e5d-95cc-7a85955643b0@github.com>
 <2sugnK5bK-SWGVluAWw-UNTKKkErTTNYTxCk7t0mOGo=.3734936f-7a10-48ec-8901-01ece733791f@github.com>
Message-ID: <mXNfXzELMtBeeiwj1ssTg_C3dVzlxbYVD30UH4lYdB0=.81f041c1-0c85-48c8-a658-a30a154157f7@github.com>

On Wed, 19 Feb 2025 15:42:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 1009:
>> 
>>> 1007:     private transient Object classData; // Set by VM
>>> 1008:     private transient Object[] signers; // Read by VM, mutable
>>> 1009:     private final transient char modifiers;  // Set by the VM
>> 
>> Why the change of type here?
>
> This is to improve the layout so the introduction of a boolean field does not increase the size of a Class object.

I changed modifiers to u2 so that we won't have an alignment gap with the bool isPrimitiveType flag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1962060783

From lancea at openjdk.org  Wed Feb 19 17:18:54 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 19 Feb 2025 17:18:54 GMT
Subject: RFR: 8349699: XSL transform fails with certain UTF-8 characters on
 1024 byte boundaries [v3]
In-Reply-To: <1MZGlrgj8IuFnPe_XC8wJw1yBtUtrAMri7DTjEuM8uI=.487e785e-62cd-4d1c-ad0e-98486fa990d7@github.com>
References: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
 <1MZGlrgj8IuFnPe_XC8wJw1yBtUtrAMri7DTjEuM8uI=.487e785e-62cd-4d1c-ad0e-98486fa990d7@github.com>
Message-ID: <9YsGuRu5vrxM4UBqAmO9gy5CdRONIUQqtoxiVZwpgX8=.442bd7ff-25e0-4a7b-bd49-6e8bf966d648@github.com>

On Wed, 19 Feb 2025 00:16:13 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fix an edge case in the patch for JDK-8207760.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add tests verifying invalid sequence; also add tests to verify cases where the pairs are at the edges or anywhere in the text

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23623#pullrequestreview-2627484156

From galder at openjdk.org  Wed Feb 19 17:42:08 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 19 Feb 2025 17:42:08 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
Message-ID: <ONik2I0-4iczocCQOuYDqxjEmIwpJB-FS5CUeyadAqQ=.0ba8687d-3372-4bff-914e-a10464a16a5e@github.com>

On Fri, 7 Feb 2025 12:39:24 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Fix typo
>  - Renaming methods and variables and add docu on algorithms
>  - Fix copyright years
>  - Make sure it runs with cpus with either avx512 or asimd
>  - Test can only run with 256 bit registers or bigger
>    
>    * Remove platform dependant check
>    and use platform independent configuration instead.
>  - Fix license header
>  - Tests should also run on aarch64 asimd=true envs
>  - Added comment around the assertions
>  - Adjust min/max identity IR test expectations after changes
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/75abfbc2...a190ae68

Following our discussion, I've run `MinMaxVector.long` benchmarks with superword disabled and with/without `_maxL` intrinsic in both AVX-512 and AVX2 modes.

The first thing I've observed is that lacking superword, the results with AVX-512 or AVX2 are identical, so I will just focus on AVX-512 results below.


Benchmark                              (probability)  (range)  (seed)  (size)   Mode  Cnt     -maxL     +maxLr   Units
MinMaxVector.longClippingRange                   N/A       90       0    1000  thrpt    4  1012.017  1011.8109  ops/ms
MinMaxVector.longClippingRange                   N/A      100       0    1000  thrpt    4  1012.113  1011.9530  ops/ms
MinMaxVector.longLoopMax                          50      N/A     N/A    2048  thrpt    4   463.946   473.9408  ops/ms
MinMaxVector.longLoopMax                          80      N/A     N/A    2048  thrpt    4   465.391   473.8063  ops/ms
MinMaxVector.longLoopMax                         100      N/A     N/A    2048  thrpt    4   510.992   471.6280  ops/ms (-8%)
MinMaxVector.longLoopMin                          50      N/A     N/A    2048  thrpt    4   496.036   495.3142  ops/ms
MinMaxVector.longLoopMin                          80      N/A     N/A    2048  thrpt    4   495.797   497.1214  ops/ms
MinMaxVector.longLoopMin                         100      N/A     N/A    2048  thrpt    4   495.302   495.1535  ops/ms
MinMaxVector.longReductionMultiplyMax             50      N/A     N/A    2048  thrpt    4   405.495   405.3936  ops/ms
MinMaxVector.longReductionMultiplyMax             80      N/A     N/A    2048  thrpt    4   405.342   405.4505  ops/ms
MinMaxVector.longReductionMultiplyMax            100      N/A     N/A    2048  thrpt    4   846.492   405.4779  ops/ms (-52%)
MinMaxVector.longReductionMultiplyMin             50      N/A     N/A    2048  thrpt    4   414.755   414.7036  ops/ms
MinMaxVector.longReductionMultiplyMin             80      N/A     N/A    2048  thrpt    4   414.705   414.7093  ops/ms
MinMaxVector.longReductionMultiplyMin            100      N/A     N/A    2048  thrpt    4   414.761   414.7150  ops/ms
MinMaxVector.longReductionSimpleMax               50      N/A     N/A    2048  thrpt    4   460.435   460.3764  ops/ms
MinMaxVector.longReductionSimpleMax               80      N/A     N/A    2048  thrpt    4   460.438   460.4718  ops/ms
MinMaxVector.longReductionSimpleMax              100      N/A     N/A    2048  thrpt    4  1023.005   460.5417  ops/ms (-55%)
MinMaxVector.longReductionSimpleMin               50      N/A     N/A    2048  thrpt    4   459.184   459.1662  ops/ms
MinMaxVector.longReductionSimpleMin               80      N/A     N/A    2048  thrpt    4   459.265   459.2588  ops/ms
MinMaxVector.longReductionSimpleMin              100      N/A     N/A    2048  thrpt    4   459.263   459.1304  ops/ms


`longLoopMax at 100%`, `longReductionMultiplyMax at 100%` and `longReductionSimpleMax at 100%` are regressions with the `_maxL` intrinsic. The cause is familiar: without the intrinsic cmp+mov are emitted, while with the intrinsic and conditions above, `cmov` is emitted:

# `longLoopMax` @ 100%

-maxL:

   4.18%  ????  ???   ?           0x00007fb7580f84b2:   cmpq		%r13, %r11
          ????? ???   ?           0x00007fb7580f84b5:   jl		0x7fb7580f84ec      ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ????? ???   ?                                                                     ; - java.lang.Math::max at 11 (line 2038)
          ????? ???   ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longLoopMax at 27 (line 256)
          ????? ???   ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub at 19 (line 124)
   4.23%  ????? ????  ?           0x00007fb7580f84bb:   movq		%r11, 0x10(%rbp, %rsi, 8);*lastore {reexecute=0 rethrow=0 return_oop=0}
          ????? ????  ?                                                                     ; - org.openjdk.bench.java.lang.MinMaxVector::longLoopMax at 30 (line 256)
          ????? ????  ?                                                                     ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub at 19 (line 124)


+maxL:

   1.06%  ???  0x00007fe1b40f5ed1:   movq		0x20(%rbx, %r10, 8), %r14;*laload {reexecute=0 rethrow=0 return_oop=0}
          ???                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longLoopMax at 26 (line 256)
          ???                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub at 19 (line 124)
   1.34%  ???  0x00007fe1b40f5ed6:   cmpq		%r14, %r9
   2.78%  ???  0x00007fe1b40f5ed9:   cmovlq		%r14, %r9
   2.58%  ???  0x00007fe1b40f5edd:   movq		%r9, 0x20(%rax, %r10, 8);*lastore {reexecute=0 rethrow=0 return_oop=0}
          ???                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longLoopMax at 30 (line 256)
          ???                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longLoopMax_jmhTest::longLoopMax_thrpt_jmhStub at 19 (line 124)


# `longReductionMultiplyMax` @ 100%

-maxL:

   6.71%  ??  ???    0x00007f8af40f6278:   imulq		$0xb, 0x18(%r14, %r8, 8), %rdx
          ??  ???                                                              ;*lmul {reexecute=0 rethrow=0 return_oop=0}
          ??  ???                                                              ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMultiplyMax at 24 (line 285)
          ??  ???                                                              ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMultiplyMax_jmhTest::longReductionMultiplyMax_thrpt_jmhStub at 19 (line 124)
   5.28%  ??  ???    0x00007f8af40f627e:   nop
  10.23%  ??  ???    0x00007f8af40f6280:   cmpq		%rdx, %rdi
          ??? ???    0x00007f8af40f6283:   jge		0x7f8af40f62a7      ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ??? ???                                                              ; - java.lang.Math::max at 11 (line 2038)
          ??? ???                                                              ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMultiplyMax at 30 (line 286)
          ??? ???                                                              ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMultiplyMax_jmhTest::longReductionMultiplyMax_thrpt_jmhStub at 19 (line 124)


+maxL:

  11.07%  ??  0x00007f47000f5c4d:   imulq		$0xb, 0x18(%r14, %r11, 8), %rax
          ??                                                            ;*lmul {reexecute=0 rethrow=0 return_oop=0}
          ??                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMultiplyMax at 24 (line 285)
          ??                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMultiplyMax_jmhTest::longReductionMultiplyMax_thrpt_jmhStub at 19 (line 124)
   0.07%  ??  0x00007f47000f5c53:   cmpq		%rdx, %rax
  11.87%  ??  0x00007f47000f5c56:   cmovlq		%rdx, %rax          ;*invokestatic max {reexecute=0 rethrow=0 return_oop=0}
          ??                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMultiplyMax at 30 (line 286)
          ??                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMultiplyMax_jmhTest::longReductionMultiplyMax_thrpt_jmhStub at 19 (line 124)


# `longReductionSimpleMax` @ 100%

-maxL:

   5.71%  ?????     ????      ?             0x00007fc2380f75f9:   movq		0x20(%r14, %r8, 8), %rdi;*laload {reexecute=0 rethrow=0 return_oop=0}
          ?????     ????      ?                                                                       ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionSimpleMax at 20 (line 295)
          ?????     ????      ?                                                                       ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionSimpleMax_jmhTest::longReductionSimpleMax_thrpt_jmhStub at 19 (line 124)
   1.85%  ?????     ????      ?             0x00007fc2380f75fe:   nop
   4.52%  ?????     ????      ?             0x00007fc2380f7600:   cmpq		%rdi, %rdx
          ??????    ????      ?             0x00007fc2380f7603:   jge		0x7fc2380f7667      ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ??????    ????      ?                                                                       ; - java.lang.Math::max at 11 (line 2038)
          ??????    ????      ?                                                                       ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionSimpleMax at 26 (line 296)
          ??????    ????      ?                                                                       ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionSimpleMax_jmhTest::longReductionSimpleMax_thrpt_jmhStub at 19 (line 124)


+maxL:

   3.06%   ??????  0x00007fa6d00f6020:   movq		0x70(%r14, %r11, 8), %r8;*laload {reexecute=0 rethrow=0 return_oop=0}
           ??????                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionSimpleMax at 20 (line 295)
           ??????                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionSimpleMax_jmhTest::longReductionSimpleMax_thrpt_jmhStub at 19 (line 124)
           ??????  0x00007fa6d00f6025:   cmpq		%r8, %r13
   2.88%   ??????  0x00007fa6d00f6028:   cmovlq		%r8, %r13           ;*invokestatic max {reexecute=0 rethrow=0 return_oop=0}
           ??????                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionSimpleMax at 26 (line 296)
           ??????                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionSimpleMax_jmhTest::longReductionSimpleMax_thrpt_jmhStub at 19 (line 124)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2669329851

From galder at openjdk.org  Wed Feb 19 17:47:06 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 19 Feb 2025 17:47:06 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
Message-ID: <xhGVTCK35DjTHkm356ou70rNSmEp9iuRRhOUSso9VfE=.ca03abd8-d954-4727-9556-58365052b311@github.com>

On Fri, 7 Feb 2025 12:39:24 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Fix typo
>  - Renaming methods and variables and add docu on algorithms
>  - Fix copyright years
>  - Make sure it runs with cpus with either avx512 or asimd
>  - Test can only run with 256 bit registers or bigger
>    
>    * Remove platform dependant check
>    and use platform independent configuration instead.
>  - Fix license header
>  - Tests should also run on aarch64 asimd=true envs
>  - Added comment around the assertions
>  - Adjust min/max identity IR test expectations after changes
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/557d790a...a190ae68

I will run a comparison next with the same batch of tests but looking at `int` and see if there are any differences compared with `long` or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2669342758

From lmesnik at openjdk.org  Wed Feb 19 17:49:57 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 19 Feb 2025 17:49:57 GMT
Subject: RFR: 8350151: Support requires property to filter tests
 incompatible with --enable-preview [v2]
In-Reply-To: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
References: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
Message-ID: <AUhzuj3hBXKOC574IAcs7umrmu6ESxzhKzM0Yv2aJJs=.d3def8f8-64ef-4d14-b441-852fe3f726f7@github.com>

> It might be useful to be able to run testing with --enable-preview for feature development. The tests incompatible with this mode must be filtered out.
> 
> I chose name 'java.enablePreview' , because it is more java property than vm or jdk. And 'enablePreview' to be similar with jtreg tag. 
> 
> Tested by running all test suites, and verifying that test is correctly selected.
> There are more tests incompatible with --enable-preview, will mark them in the following bug.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  change other test to exclude

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23653/files
  - new: https://git.openjdk.org/jdk/pull/23653/files/fafdff14..8019bec1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23653&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23653&range=00-01

  Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23653/head:pull/23653

PR: https://git.openjdk.org/jdk/pull/23653

From lmesnik at openjdk.org  Wed Feb 19 17:49:58 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 19 Feb 2025 17:49:58 GMT
Subject: RFR: 8350151: Support requires property to filter tests
 incompatible with --enable-preview [v2]
In-Reply-To: <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com>
References: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
 <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com>
Message-ID: <NGaCT00YtDH9CSv1q-xgfLTB1lPtOTJ_lPTk9nNbVIU=.679690a4-ab9a-4eae-a461-550ace661242@github.com>

On Mon, 17 Feb 2025 08:28:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change other test to exclude
>
> test/jdk/java/lang/System/SecurityManagerWarnings.java line 28:
> 
>> 26:  * @bug 8266459 8268349 8269543 8270380
>> 27:  * @summary check various warnings
>> 28:  * @requires !java.enablePreview
> 
> What is the reason that this test fails with --enable-preview?

Ough, this test puzzled me. It fails with --enable-preview. However, I think I need more time to investigate the issue. So I update PR to exclude test that explicitly says that it shouldn't be executed with --enable-preview.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23653#discussion_r1962116805

From jiangli at openjdk.org  Wed Feb 19 18:29:03 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 19 Feb 2025 18:29:03 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v3]
In-Reply-To: <38QCGfzFNUhE69hUlz5o4H_74wR0lw4sivYa-jGgHXg=.ec9d2a40-e71d-404e-8b8c-2cf284d5b876@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
 <38QCGfzFNUhE69hUlz5o4H_74wR0lw4sivYa-jGgHXg=.ec9d2a40-e71d-404e-8b8c-2cf284d5b876@github.com>
Message-ID: <McP-7ft5xrJ_-4ONm-9vdm-3kz2HeiW9LRYcQ4uHPTI=.236b4aa1-ee23-41fd-bedb-b148e2941e6d@github.com>

On Wed, 19 Feb 2025 06:54:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.
>
> On a more general note, is it a goal to have the static JDK build run against all these tests that are part of the JDK repo? Would that mean that a lot of these will have to start using `@requires` to accomodate this?

@jaikiran, thanks for taking a look!

> Hello Jiangli, the change to introduce a `@requires` property for identifying a static JDK looks OK to me.
> 
> > @requires !jdk.static is added in test/hotspot/jtreg/runtime/modules/ModulesSymLink.java to skip running the test on static JDK. This test uses bin/jlink, which is not provided on static JDK. There are other tests that require tools in bin/. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.
> 
> This part however feels odd. Updating this (and other tests in future) to use the `@requires !jdk.static` to identify the presence or absence of a specific tool in the JDK installation doesn't seem right. Perhaps they should instead rely on a tool-specific property (like maybe `@requires jdk.tool.jlink`)?

Here is some additional context. I picked `ModulesSymLink.java` rather randomly from the hotspot tier1 test failures caused by missing `bin/` tools. I included it in the current change for testing the `@requires !jdk.static` property. There are about 30 test failures in hotspot tier1 due to missing `bin/` tools, those tests execute `bin/jlink`, `bin/jcmd`, `bin/jstat`, `bin/javac`, or etc at runtime. `ModulesSymLink.constructTestJDK()` specifically runs the `jlink` tool  to create a test JDK during test execution. Since the `static-jdk` binary only provides a `bin/java` (and no other executables in `bin`), tests run any other tools at runtime in `bin/` fail. The current main issue with tools is that they require the shared libraries from JDK, for example `libjli.so`. Using a tool-specific property can be appropriate if we decide to support a specific set of tools for `static-jdk`, e.g. create a fully statically linked executable for supported tools, or including the tools required `.
 so` shared libraries in `static-jdk` image. Those details need to be discussed and worked out, we can add more fine grained properties when things are clear.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2669442221

From coleenp at openjdk.org  Wed Feb 19 18:40:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Feb 2025 18:40:36 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v2]
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <dW_0bhxndHftSW3PnLXmEZGsJc4Y16QjUuSA9cChYR4=.a16d0dfc-bbf9-4723-b8f0-5d1abbaae7c8@github.com>

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Code review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23572/files
  - new: https://git.openjdk.org/jdk/pull/23572/files/2d9b9ff5..3e731b9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=00-01

  Stats: 17 lines in 3 files changed: 3 ins; 10 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23572/head:pull/23572

PR: https://git.openjdk.org/jdk/pull/23572

From coleenp at openjdk.org  Wed Feb 19 18:40:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Feb 2025 18:40:37 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v2]
In-Reply-To: <ZjAN9VKqYZJ9kEzsFzL2NXtxIEa1Z_DMCA4B1rmWccs=.663c1dd7-b70d-4746-ad80-85446f82f53f@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <ZjAN9VKqYZJ9kEzsFzL2NXtxIEa1Z_DMCA4B1rmWccs=.663c1dd7-b70d-4746-ad80-85446f82f53f@github.com>
Message-ID: <KzlaP-g90L9MB6Sp11H6FzXt0weIkz8px5IKhP1XF9M=.0027bfea-8105-4a91-9bdd-f837bda8179e@github.com>

On Wed, 19 Feb 2025 15:07:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code review comments.
>
> src/hotspot/share/prims/jvm.cpp line 2284:
> 
>> 2282: // Please, refer to the description in the jvmtiThreadState.hpp.
>> 2283: 
>> 2284: JVM_ENTRY(jboolean, JVM_IsInterface(JNIEnv *env, jclass cls))
> 
> JVM_IsInteface is deleted in Class.c, what purpose is this?

The old classfile verifier uses JVM_IsInterface.

> src/java.base/share/classes/java/lang/Class.java line 807:
> 
>> 805:      */
>> 806:     public boolean isArray() {
>> 807:         return componentType != null;
> 
> The componentType declaration should have a comment indicating that == null is the sole indication that the class is an interface.
> Perhaps there should be an assert somewhere validating/cross checking that requirement.

I added an assert for set_component_mirror() in the vm, but I don't see how to assert it in Java.  Is the comment like:

// The componentType field's null value is the sole indication that the class is an array, see isArray()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1962078501
PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1962186820

From coleenp at openjdk.org  Wed Feb 19 18:40:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Feb 2025 18:40:37 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v2]
In-Reply-To: <u01Zz75QR4Kvx3ExKJTCnHIKPNVLvekS6fqT5MIZtzk=.5eda33dd-f19d-4549-8216-36c3aa3834cf@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <n1Pm6orA_ufoz5E6FWMNMpfCypAT_q2FyImG4oqpVtM=.2e64b4d5-7805-4f7f-8a5c-0c4dfbc3f6c9@github.com>
 <-rVJ4riSt_UybCT4tvNKCBxGfrHr-xnGx0DNDZyGgsA=.11b43081-86f2-47db-b52c-5f74b8e27960@github.com>
 <u01Zz75QR4Kvx3ExKJTCnHIKPNVLvekS6fqT5MIZtzk=.5eda33dd-f19d-4549-8216-36c3aa3834cf@github.com>
Message-ID: <3orjlwIP5PIjb_UBpCUiIV7ZM1U_5BJfZws3PCleKhw=.55438aa0-1c98-476f-b1db-56672a1bbe4a@github.com>

On Wed, 19 Feb 2025 17:10:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> It was. Before the componentType field was reused for the class initialization monitor int array, and it caused problems with core reflection if a program reflectively accesses this field after a few hundred times. See [JDK-8337622](https://bugs.openjdk.org/browse/JDK-8337622).
>
> Yes, this comment is obsolete.  We used to share the componentType mirror with an internal 'init-lock' but it caused a bug that was fixed.  If it's not an array the componentType is now always null.

So for JDK 8 and 21+, the init_lock and componentType are not shared.  In JDK 11 and 17, Hotspot shares the fields, but it's not observable with the older implementation of reflection.  See https://bugs.openjdk.org/browse/JDK-8337622.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1962189932

From coleenp at openjdk.org  Wed Feb 19 18:42:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Feb 2025 18:42:56 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <YKZkZcWYrtvxcqwq8HmKNP1U6DmqztQto_de8aGdv_s=.2bbabcc8-33d4-4219-9d58-e5da44543e2f@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

I ran our standard set of benchmarks on this change with no differences in performance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23572#issuecomment-2669470645

From redestad at openjdk.org  Wed Feb 19 19:16:53 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 19 Feb 2025 19:16:53 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
Message-ID: <EAEam6h8Ud94rHZX9d9iFIBAAeUlvH8bt4dzBuuUsqA=.4738f6fd-29ae-4e68-bd00-99d5ac58d520@github.com>

On Wed, 19 Feb 2025 03:21:37 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
>> 
>> After this PR, below JMH tests will run passes.
>> 
>> 
>> org.openjdk.bench.javax.xml.DOM.testBuild
>> org.openjdk.bench.javax.xml.DOM.testModify
>> org.openjdk.bench.javax.xml.DOM.testWalk
>> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
>> org.openjdk.bench.javax.xml.STAX.testParse
>> 
>> 
>> Test command:
>> 
>> 
>> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
>> 
>> 
>> Change has been verified locally, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SetupCopyFiles macro to copy the dependency files

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23625#pullrequestreview-2627748496

From jiangli at openjdk.org  Wed Feb 19 19:20:54 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 19 Feb 2025 19:20:54 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v3]
In-Reply-To: <38QCGfzFNUhE69hUlz5o4H_74wR0lw4sivYa-jGgHXg=.ec9d2a40-e71d-404e-8b8c-2cf284d5b876@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
 <38QCGfzFNUhE69hUlz5o4H_74wR0lw4sivYa-jGgHXg=.ec9d2a40-e71d-404e-8b8c-2cf284d5b876@github.com>
Message-ID: <4_HIGqls8cQ_WdDbQuZi1vdkW0rrceR0edOzL-FkIhY=.95bd51ab-64ac-49eb-bb38-f0d14453d511@github.com>

On Wed, 19 Feb 2025 06:54:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> On a more general note, is it a goal to have the static JDK build run against all these tests that are part of the JDK repo? Would that mean that a lot of these will have to start using `@requires` to accomodate this?

Running static JDK against all (most of) jtreg tests looks practical, based on what we have learned so far about static support for JDK. I think running against tier1 tests is a good initial minimum goal for now to help building a more solid base for us to work on hermetic support on top of static JDK. 

Following are the tier1 results that I ran a couple of weeks back on static JDK. Overall most tests are passing on static JDK. The `116` failures in hotspot tier1 include gtest failure due to missing `--with-gtest` (I need to fix my test setup to get cleaner results). So overall I think the number of affect tests requiring `@requires` is small.

(linked from https://bugs.openjdk.org/browse/JDK-8348905?focusedId=14745728&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14745728)

==============================
Test summary
==============================
   TEST TOTAL PASS FAIL ERROR
>> jtreg:test/hotspot/jtreg:tier1 2709 2592 116 1 <<
>> jtreg:test/jdk:tier1 2454 2368 86 0 <<
>> jtreg:test/langtools:tier1 4602 4577 25 0 <<
   jtreg:test/jaxp:tier1 0 0 0 0
>> jtreg:test/lib-test:tier1 35 33 2 0 <<
==============================
TEST FAILURE

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2669547916

From joehw at openjdk.org  Wed Feb 19 19:38:57 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 19 Feb 2025 19:38:57 GMT
Subject: Integrated: 8349699: XSL transform fails with certain UTF-8 characters
 on 1024 byte boundaries
In-Reply-To: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
References: <f7A1MBIcp40ixJlP3T3UbWOKOQxei2A21VPKlSLCZyE=.ab8108b3-5b5b-44c1-a878-598fd3e1b02e@github.com>
Message-ID: <piAoq5J5WFHUShwmIsO9YD_Dt2_HXc1YbpUMtYnoJjU=.ce5f4f80-1fbe-493a-909d-aadfc4660937@github.com>

On Fri, 14 Feb 2025 00:56:03 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix an edge case in the patch for JDK-8207760.

This pull request has now been integrated.

Changeset: 4e60c2d9
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e60c2d937fca8170b356f36e72b271104130c40
Stats:     127 lines in 2 files changed: 121 ins; 2 del; 4 mod

8349699: XSL transform fails with certain UTF-8 characters on 1024 byte boundaries

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/23623

From rriggs at openjdk.org  Wed Feb 19 19:39:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Feb 2025 19:39:53 GMT
Subject: RFR: 8350151: Support requires property to filter tests
 incompatible with --enable-preview [v2]
In-Reply-To: <NGaCT00YtDH9CSv1q-xgfLTB1lPtOTJ_lPTk9nNbVIU=.679690a4-ab9a-4eae-a461-550ace661242@github.com>
References: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
 <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com>
 <NGaCT00YtDH9CSv1q-xgfLTB1lPtOTJ_lPTk9nNbVIU=.679690a4-ab9a-4eae-a461-550ace661242@github.com>
Message-ID: <Ol2Z2QCeakdS9FkAIxrzbxxY1v0cLh6h5AeMT90VJbw=.383244fd-9573-4844-a8df-fdae734a4889@github.com>

On Wed, 19 Feb 2025 17:43:10 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/jdk/java/lang/System/SecurityManagerWarnings.java line 28:
>> 
>>> 26:  * @bug 8266459 8268349 8269543 8270380
>>> 27:  * @summary check various warnings
>>> 28:  * @requires !java.enablePreview
>> 
>> What is the reason that this test fails with --enable-preview?
>
> Ough, this test puzzled me. It fails with --enable-preview. However, I think I need more time to investigate the issue. So I update PR to exclude test that explicitly says that it shouldn't be executed with --enable-preview.

It ran ok for me, once I got the command line flags correct.
It ran ok if I added `@enablePreview`.

It also ran ok with an explicit @run command:  (it does not currently have an @run command).

 * @run main/othervm --enable-preview SecurityManagerWarnings
 ```

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23653#discussion_r1962264733

From alanb at openjdk.org  Wed Feb 19 19:45:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Feb 2025 19:45:53 GMT
Subject: RFR: 8350151: Support requires property to filter tests
 incompatible with --enable-preview [v2]
In-Reply-To: <AUhzuj3hBXKOC574IAcs7umrmu6ESxzhKzM0Yv2aJJs=.d3def8f8-64ef-4d14-b441-852fe3f726f7@github.com>
References: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
 <AUhzuj3hBXKOC574IAcs7umrmu6ESxzhKzM0Yv2aJJs=.d3def8f8-64ef-4d14-b441-852fe3f726f7@github.com>
Message-ID: <zuCyFXQb7BUWMS1V3BZkYcpq9kYZkAh5z0wvamN4LSo=.8bfb9f62-cd65-4820-abfd-53d71efa559b@github.com>

On Wed, 19 Feb 2025 17:49:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> It might be useful to be able to run testing with --enable-preview for feature development. The tests incompatible with this mode must be filtered out.
>> 
>> I chose name 'java.enablePreview' , because it is more java property than vm or jdk. And 'enablePreview' to be similar with jtreg tag. 
>> 
>> Tested by running all test suites, and verifying that test is correctly selected.
>> There are more tests incompatible with --enable-preview, will mark them in the following bug.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change other test to exclude

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23653#pullrequestreview-2627805876

From eastigeevich at openjdk.org  Wed Feb 19 19:54:05 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 19 Feb 2025 19:54:05 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <xhGVTCK35DjTHkm356ou70rNSmEp9iuRRhOUSso9VfE=.ca03abd8-d954-4727-9556-58365052b311@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
 <xhGVTCK35DjTHkm356ou70rNSmEp9iuRRhOUSso9VfE=.ca03abd8-d954-4727-9556-58365052b311@github.com>
Message-ID: <gXxBans1yY2lV4CGCGT2-zFYYO2TaX1_M7WRAq6uWIM=.6e862783-8e47-46b8-8a2a-e799e7f946da@github.com>

On Wed, 19 Feb 2025 17:43:54 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into topic.intrinsify-max-min-long
>>  - Fix typo
>>  - Renaming methods and variables and add docu on algorithms
>>  - Fix copyright years
>>  - Make sure it runs with cpus with either avx512 or asimd
>>  - Test can only run with 256 bit registers or bigger
>>    
>>    * Remove platform dependant check
>>    and use platform independent configuration instead.
>>  - Fix license header
>>  - Tests should also run on aarch64 asimd=true envs
>>  - Added comment around the assertions
>>  - Adjust min/max identity IR test expectations after changes
>>  - ... and 34 more: https://git.openjdk.org/jdk/compare/384bab03...a190ae68
>
> I will run a comparison next with the same batch of tests but looking at `int` and see if there are any differences compared with `long` or not.

Hi @galderz,
Results from Graviton 3(Neoverse-V1).
Without the patch:

Benchmark                       (probability)  (range)  (seed)  (size)   Mode  Cnt      Score    Error   Units
MinMaxVector.intClippingRange             N/A       90       0    1000  thrpt    8  12565.427 ? 37.538  ops/ms
MinMaxVector.intClippingRange             N/A      100       0    1000  thrpt    8  12462.072 ? 84.067  ops/ms
MinMaxVector.intLoopMax                    50      N/A     N/A    2048  thrpt    8   5113.090 ? 68.720  ops/ms
MinMaxVector.intLoopMax                    80      N/A     N/A    2048  thrpt    8   5129.857 ? 35.005  ops/ms
MinMaxVector.intLoopMax                   100      N/A     N/A    2048  thrpt    8   5116.081 ?  8.946  ops/ms
MinMaxVector.intLoopMin                    50      N/A     N/A    2048  thrpt    8   6174.544 ? 52.573  ops/ms
MinMaxVector.intLoopMin                    80      N/A     N/A    2048  thrpt    8   6110.884 ? 54.447  ops/ms
MinMaxVector.intLoopMin                   100      N/A     N/A    2048  thrpt    8   6178.661 ? 48.450  ops/ms
MinMaxVector.intReductionMax               50      N/A     N/A    2048  thrpt    8   5109.270 ? 10.525  ops/ms
MinMaxVector.intReductionMax               80      N/A     N/A    2048  thrpt    8   5123.426 ? 28.229  ops/ms
MinMaxVector.intReductionMax              100      N/A     N/A    2048  thrpt    8   5133.799 ?  7.693  ops/ms
MinMaxVector.intReductionMin               50      N/A     N/A    2048  thrpt    8   5130.209 ? 15.491  ops/ms
MinMaxVector.intReductionMin               80      N/A     N/A    2048  thrpt    8   5127.823 ? 27.767  ops/ms
MinMaxVector.intReductionMin              100      N/A     N/A    2048  thrpt    8   5118.217 ? 22.186  ops/ms
MinMaxVector.longClippingRange            N/A       90       0    1000  thrpt    8   1831.026 ? 15.502  ops/ms
MinMaxVector.longClippingRange            N/A      100       0    1000  thrpt    8   1827.194 ? 22.076  ops/ms
MinMaxVector.longLoopMax                   50      N/A     N/A    2048  thrpt    8   2643.383 ?  9.830  ops/ms
MinMaxVector.longLoopMax                   80      N/A     N/A    2048  thrpt    8   2640.417 ?  7.797  ops/ms
MinMaxVector.longLoopMax                  100      N/A     N/A    2048  thrpt    8   1244.321 ?  1.001  ops/ms
MinMaxVector.longLoopMin                   50      N/A     N/A    2048  thrpt    8   3239.234 ?  8.813  ops/ms
MinMaxVector.longLoopMin                   80      N/A     N/A    2048  thrpt    8   3252.713 ?  3.446  ops/ms
MinMaxVector.longLoopMin                  100      N/A     N/A    2048  thrpt    8   1204.370 ? 10.537  ops/ms
MinMaxVector.longReductionMax              50      N/A     N/A    2048  thrpt    8   2536.322 ?  0.127  ops/ms
MinMaxVector.longReductionMax              80      N/A     N/A    2048  thrpt    8   2536.318 ?  0.277  ops/ms
MinMaxVector.longReductionMax             100      N/A     N/A    2048  thrpt    8   1395.273 ? 13.862  ops/ms
MinMaxVector.longReductionMin              50      N/A     N/A    2048  thrpt    8   2536.325 ?  0.146  ops/ms
MinMaxVector.longReductionMin              80      N/A     N/A    2048  thrpt    8   2536.265 ?  0.272  ops/ms
MinMaxVector.longReductionMin             100      N/A     N/A    2048  thrpt    8   1389.982 ?  5.345  ops/ms


With the patch:

Benchmark                       (probability)  (range)  (seed)  (size)   Mode  Cnt      Score    Error   Units
MinMaxVector.intClippingRange             N/A       90       0    1000  thrpt    8  12598.201 ? 52.631  ops/ms
MinMaxVector.intClippingRange             N/A      100       0    1000  thrpt    8  12555.284 ? 62.472  ops/ms
MinMaxVector.intLoopMax                    50      N/A     N/A    2048  thrpt    8   5079.499 ? 16.392  ops/ms
MinMaxVector.intLoopMax                    80      N/A     N/A    2048  thrpt    8   5100.673 ? 30.376  ops/ms
MinMaxVector.intLoopMax                   100      N/A     N/A    2048  thrpt    8   5082.544 ? 23.540  ops/ms
MinMaxVector.intLoopMin                    50      N/A     N/A    2048  thrpt    8   6137.512 ? 30.198  ops/ms
MinMaxVector.intLoopMin                    80      N/A     N/A    2048  thrpt    8   6136.233 ?  7.726  ops/ms
MinMaxVector.intLoopMin                   100      N/A     N/A    2048  thrpt    8   6142.262 ? 96.510  ops/ms
MinMaxVector.intReductionMax               50      N/A     N/A    2048  thrpt    8   5116.055 ? 23.270  ops/ms
MinMaxVector.intReductionMax               80      N/A     N/A    2048  thrpt    8   5111.481 ? 12.236  ops/ms
MinMaxVector.intReductionMax              100      N/A     N/A    2048  thrpt    8   5106.367 ?  9.035  ops/ms
MinMaxVector.intReductionMin               50      N/A     N/A    2048  thrpt    8   5115.666 ? 15.539  ops/ms
MinMaxVector.intReductionMin               80      N/A     N/A    2048  thrpt    8   5133.127 ?  4.918  ops/ms
MinMaxVector.intReductionMin              100      N/A     N/A    2048  thrpt    8   5120.469 ? 24.355  ops/ms
MinMaxVector.longClippingRange            N/A       90       0    1000  thrpt    8   5094.259 ? 14.092  ops/ms
MinMaxVector.longClippingRange            N/A      100       0    1000  thrpt    8   5096.835 ? 16.517  ops/ms
MinMaxVector.longLoopMax                   50      N/A     N/A    2048  thrpt    8   2636.438 ? 18.760  ops/ms
MinMaxVector.longLoopMax                   80      N/A     N/A    2048  thrpt    8   2644.069 ?  3.933  ops/ms
MinMaxVector.longLoopMax                  100      N/A     N/A    2048  thrpt    8   2646.250 ?  2.007  ops/ms
MinMaxVector.longLoopMin                   50      N/A     N/A    2048  thrpt    8   2648.504 ? 18.294  ops/ms
MinMaxVector.longLoopMin                   80      N/A     N/A    2048  thrpt    8   2658.082 ?  3.362  ops/ms
MinMaxVector.longLoopMin                  100      N/A     N/A    2048  thrpt    8   2647.532 ?  5.600  ops/ms
MinMaxVector.longReductionMax              50      N/A     N/A    2048  thrpt    8   2536.254 ?  0.086  ops/ms
MinMaxVector.longReductionMax              80      N/A     N/A    2048  thrpt    8   2536.209 ?  0.129  ops/ms
MinMaxVector.longReductionMax             100      N/A     N/A    2048  thrpt    8   2536.342 ?  0.068  ops/ms
MinMaxVector.longReductionMin              50      N/A     N/A    2048  thrpt    8   2536.271 ?  0.203  ops/ms
MinMaxVector.longReductionMin              80      N/A     N/A    2048  thrpt    8   2536.250 ?  0.343  ops/ms
MinMaxVector.longReductionMin             100      N/A     N/A    2048  thrpt    8   2536.246 ?  0.179  ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2669613497

From joehw at openjdk.org  Wed Feb 19 20:06:52 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 19 Feb 2025 20:06:52 GMT
Subject: RFR: 8349959: Test CR6740048.java passes unexpectedly missing
 CR6740048.xsd
In-Reply-To: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>
References: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>
Message-ID: <fGNGE4wP27oWsCspTsS24OHfqqTnd9oFc_Ki0ctoQE0=.8e28e33b-1167-46c3-870d-792f9693e877@github.com>

On Fri, 14 Feb 2025 07:44:26 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes unexpectedly when missing the depentdent file test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a NULL check after call `getResourceAsStream("CR6740048.xsd")`.
> 
> This PR do not change the original test logic but make test more robustness. Change has been verified locally, test-fix only, no risk.

The schema file is integral to the test, so we assume it will be present. A minor improvement would be to remove the conditional check that verifies its existence. This would allow the test to fail if it can't load the schema file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23627#issuecomment-2669644429

From lmesnik at openjdk.org  Wed Feb 19 20:35:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 19 Feb 2025 20:35:53 GMT
Subject: RFR: 8350151: Support requires property to filter tests
 incompatible with --enable-preview [v2]
In-Reply-To: <Ol2Z2QCeakdS9FkAIxrzbxxY1v0cLh6h5AeMT90VJbw=.383244fd-9573-4844-a8df-fdae734a4889@github.com>
References: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
 <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com>
 <NGaCT00YtDH9CSv1q-xgfLTB1lPtOTJ_lPTk9nNbVIU=.679690a4-ab9a-4eae-a461-550ace661242@github.com>
 <Ol2Z2QCeakdS9FkAIxrzbxxY1v0cLh6h5AeMT90VJbw=.383244fd-9573-4844-a8df-fdae734a4889@github.com>
Message-ID: <d-Z7EZi5HEv8hhUkS7t82ATHuxG-eihiV5ntugZUbUg=.3dd3abe9-75c7-4c3f-838f-13be8d16cc6e@github.com>

On Wed, 19 Feb 2025 19:36:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ough, this test puzzled me. It fails with --enable-preview. However, I think I need more time to investigate the issue. So I update PR to exclude test that explicitly says that it shouldn't be executed with --enable-preview.
>
> It ran ok for me, once I got the command line flags correct.
> It ran ok if I added `@enablePreview`.
> 
> It also ran ok with an explicit @run command:  (it does not currently have an @run command).
> 
>  * @run main/othervm --enable-preview SecurityManagerWarnings
>  ```

For me it fails with
----------System.err:(18/917)----------
 stdout: [];
 stderr: [Error: Unable to initialize main class SecurityManagerWarnings
Caused by: java.lang.NoClassDefFoundError: jdk/test/lib/process/OutputAnalyzer
]
 exitValue = 1
that seems pretty strange, might be test library issue?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23653#discussion_r1962334975

From coleenp at openjdk.org  Wed Feb 19 20:30:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Feb 2025 20:30:34 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v3]
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <9ZTXNeE806c5EDt4Y6QFMqull0_SobjS7mOQGk2wE5s=.81291418-85a7-4826-9ecf-dcdd050ecaf1@github.com>

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Rename isPrimitiveType field to primitive.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23572/files
  - new: https://git.openjdk.org/jdk/pull/23572/files/3e731b9f..d08091ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=01-02

  Stats: 11 lines in 5 files changed: 2 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23572/head:pull/23572

PR: https://git.openjdk.org/jdk/pull/23572

From jiangli at openjdk.org  Wed Feb 19 21:08:52 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 19 Feb 2025 21:08:52 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v3]
In-Reply-To: <c4gZ8K3QMWzK46zOYrMj24MWrnVUGFDUEbqogI2tCDw=.1c802402-bf5d-40b4-881b-932dc2ba9dc1@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
 <7Xbnn-2LkNv3Gsj6nFHXdrdvvPO7vXi3K3MWm33E-jw=.8341aa47-99de-4a67-8339-64b46fa7bb36@github.com>
 <c4gZ8K3QMWzK46zOYrMj24MWrnVUGFDUEbqogI2tCDw=.1c802402-bf5d-40b4-881b-932dc2ba9dc1@github.com>
Message-ID: <VFuf4DsmKMABC1MMPaB6XNreTt5GwJHJTXKedmjFyuM=.9be5f485-467d-4f62-8a3b-dbb8c0a8e1b7@github.com>

On Wed, 19 Feb 2025 07:33:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > This part however feels odd. Updating this (and other tests in future) to use the `@requires !jdk.static` to identify the presence or absence of a specific tool in the JDK installation doesn't seem right. Perhaps they should instead rely on a tool-specific property (like maybe `@requires jdk.tool.jlink`)?
> 
> The property will be useful to select the tests that can or cannot be selected by jtreg when the JDK under test is static image. There are a number of tests that depend on layout or specific files in the modular run-time image so they will need to skipped when the JDK is a static image. So nothing to do with whether specific tools are present or not. The specific test updated here is a bit strange because lib/modules should never be a sym link in the first place and motivation for that is probably a different discussion.

The discussion here made me realize that for the specific ModulesSymLink.java, there are multiple layered issues, including: 

- No `jlink` tool in `static-jdk` when running on static JDK. This is currently observable using the `static-jdk`. 

- No separate `lib/modules` file (and other JDK resource files) if we build a single hermetic Java image for the test. Those JDK files will be built into the single hermetic executable image for runtime access. It would more practical to develop new tests specifically for hermetic image, and not try to run all existing jtreg tests using hermetic package and filtering using @requires property. +1 on @AlanBateman's comment, the second layer is separate discussion which can involve java.home.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2669758714

From dlong at openjdk.org  Wed Feb 19 21:19:58 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 19 Feb 2025 21:19:58 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v3]
In-Reply-To: <_j9Wkg21aBltyVrbO4wxGFKmmLDy0T-eorRL4epfS4k=.5a453b6b-d673-4cc6-b29f-192fa74e290c@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <E9GPjreqeKFJmZAIjHGQ-1y6FnyqaT94FHUPuK65kmE=.48bd4ecc-ac91-4f7b-895b-a32280d8b437@github.com>
 <_j9Wkg21aBltyVrbO4wxGFKmmLDy0T-eorRL4epfS4k=.5a453b6b-d673-4cc6-b29f-192fa74e290c@github.com>
Message-ID: <3qpqR3PC8PFmdgaIoSYA3jDWdl-oon0-AcIzXcI76rY=.38635503-c067-4f6e-a4f1-92c1b6d991d1@github.com>

On Wed, 19 Feb 2025 14:19:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> ... but not in the return since the caller likely will fetch the klass pointer next.

I notice that too.  Callers are using is_primitive() to short-circuit calls to as_Klass(), which means they seem to be aware of this implementation detail when maybe they shouldn't.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1962384926

From mullan at openjdk.org  Wed Feb 19 22:37:51 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 19 Feb 2025 22:37:51 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms [v3]
In-Reply-To: <vJxNHXpG4Phl_yAj3k_WpM4hOwWHfdYIVYG5q-h6tUc=.0a8ccf1b-a622-49cf-bae6-128ae154ced2@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
 <YV-zo5wMDpN1Xbtylo2w6lvx1u3ngHbW89Dthc6o28w=.43cb563d-0857-4488-91dd-eca6a1eb0f66@github.com>
 <btzXCn5chalE5m6W0Yavh6miIYkZj1BtNA3Vx-dHLL8=.d6731282-8f47-4a8a-bab6-086179d9f36d@github.com>
 <vJxNHXpG4Phl_yAj3k_WpM4hOwWHfdYIVYG5q-h6tUc=.0a8ccf1b-a622-49cf-bae6-128ae154ced2@github.com>
Message-ID: <srMcbCUoBSdfZ95aee9zyVrhA2FC3s8IQti16_-10uc=.b690e863-1b06-4091-8cfb-b6e84e90d4b1@github.com>

On Thu, 13 Feb 2025 22:29:46 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Also,  should it be moved to somewhere else like jdk/test/sun/security/provider/certpath?
>
>> Also, should it be moved to somewhere else like jdk/test/sun/security/provider/certpath?
> 
> Hmmm...not sure about that, but maybe an explanation is in order: Because the JDK only implements the client side with OCSP, we rely on CertPathValidator to handle the path validation and that has never been a problem with PQC.  When I did OCSP stapling a long time ago (JDK 9) that was when I wanted a way to build certs (good and malformed ones) and make OCSP servers that didn't need to fork processes outside the jtreg framework or need 3rd party code.  That meant I had to implement the server-side (consumption of requests and generation of responses) and that's where things needed some tuning up.  So it isn't really a CPV problem, it's a testcode problem.  In order to exercise it and ensure that it worked for all the algs we use to sign stuff, I made this test-the-test-code test and at the suggestion of @rhalade I located in the lib-test tree.  Using CPV in the test was mainly a way for me to drive the OCSP request from the JDK code.  That it also validates consumption of the sign
 ed response and the cert chain is a nice freebie.
> 
> Not opposed to making the changes, I just didn't know if it was the right way to go considering that I'm not changing any actual JDK code, just test helper classes so in the future we can do PQC cert chains and OCSP servers for our tests.

No, I take back my comment - your explanation and the location makes sense. I hadn't realized it was a test testing a test server on my initial scan. I think the test summary should be more general and explain what the test is doing. Right now it says "Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms" but that is a side effect of adding this test, and not the main purpose of the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1962465483

From sviswanathan at openjdk.org  Wed Feb 19 23:21:07 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 19 Feb 2025 23:21:07 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v18]
In-Reply-To: <npCqs_ZZsS5MkLbKdkH2HqSrD8KI0loTBdo1DEIMfe4=.ac942c11-d10a-4bc2-a820-396656331758@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <GTm_Er6CT-A4aFdVeWEMCXyJKWWrW56VLe9On4W02fk=.6bb331e3-3a26-4f5e-befb-42e955e4d994@github.com>
 <npCqs_ZZsS5MkLbKdkH2HqSrD8KI0loTBdo1DEIMfe4=.ac942c11-d10a-4bc2-a820-396656331758@github.com>
Message-ID: <2OIYkOt8CJ-CqnQIK8sgMDtvLxJUyD5r_mKj5QT7_a8=.10b1d382-d9ae-40a1-b895-09086c80dee6@github.com>

On Tue, 18 Feb 2025 02:36:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions
>
> Is anyone else getting compile failures after this was integrated? This weirdly seems to only happen on Linux
> 
> * For target hotspot_variant-server_libjvm_objs_mulnode.o:
> /home/runner/work/jdk/jdk/src/hotspot/share/opto/mulnode.cpp: In member function ?virtual const Type* FmaHFNode::Value(PhaseGVN*) const?:
> /home/runner/work/jdk/jdk/src/hotspot/share/opto/mulnode.cpp:1944:37: error: call of overloaded ?make(double)? is ambiguous
>  1944 |   return TypeH::make(fma(f1, f2, f3));
>       |                                     ^
> In file included from /home/runner/work/jdk/jdk/src/hotspot/share/opto/node.hpp:31,
>                  from /home/runner/work/jdk/jdk/src/hotspot/share/opto/addnode.hpp:28,
>                  from /home/runner/work/jdk/jdk/src/hotspot/share/opto/mulnode.cpp:26:
> /home/runner/work/jdk/jdk/src/hotspot/share/opto/type.hpp:544:23: note: candidate: ?static const TypeH* TypeH::make(float)?
>   544 |   static const TypeH* make(float f);
>       |                       ^~~~
> /home/runner/work/jdk/jdk/src/hotspot/share/opto/type.hpp:545:23: note: candidate: ?static const TypeH* TypeH::make(short int)?
>   545 |   static const TypeH* make(short f);
>       |                       ^~~~

@TheShermanTanker I don't see any compile failures on Linux. Both the fastdebug and release build successfully.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2669979058

From jnimeh at openjdk.org  Thu Feb 20 01:12:46 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 20 Feb 2025 01:12:46 GMT
Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test
 utilities to support PQC algorithms [v4]
In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
Message-ID: <Q9DZtqoZUNaC4R45W5tzFJ4t50Qr-ie-2U2FHrfDrF4=.ce343f24-6cba-4bb0-b502-4bb6a5139d87@github.com>

> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).

Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Add more descriptive summary to test
 - Merge with main
 - Remove unnecessary throws declarations
 - Fix JBS ID and summary in test
 - 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23566/files
  - new: https://git.openjdk.org/jdk/pull/23566/files/d0c95035..f39d0e83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=02-03

  Stats: 18126 lines in 881 files changed: 12702 ins; 2531 del; 2893 mod
  Patch: https://git.openjdk.org/jdk/pull/23566.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23566/head:pull/23566

PR: https://git.openjdk.org/jdk/pull/23566

From duke at openjdk.org  Thu Feb 20 01:17:54 2025
From: duke at openjdk.org (Nicole Xu)
Date: Thu, 20 Feb 2025 01:17:54 GMT
Subject: RFR: 8349943: [JMH] Use jvmArgs consistently
In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
Message-ID: <RpA_YEYBoQy64nN70T64Ay3IyvFlqCc2L-L8yTbK5Fc=.88dafdc1-e434-4c3b-a2e7-1320fbe9bf0e@github.com>

On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'.
> 
> All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency.

Hi @cl4es, here is a fellow-up fix of `jvmArgs` flags. Could you please review the changes? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23609#issuecomment-2670146567

From redestad at openjdk.org  Thu Feb 20 01:25:59 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 20 Feb 2025 01:25:59 GMT
Subject: RFR: 8349943: [JMH] Use jvmArgs consistently
In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
Message-ID: <tH8dRcC5CGufP5arOBfWwSzod_P2SM_PEg0oP-xSlI8=.4043508c-7a1c-4bc3-b66f-2d291ba5824e@github.com>

On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'.
> 
> All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency.

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23609#pullrequestreview-2628391999

From duke at openjdk.org  Thu Feb 20 01:30:58 2025
From: duke at openjdk.org (Nicole Xu)
Date: Thu, 20 Feb 2025 01:30:58 GMT
Subject: RFR: 8349943: [JMH] Use jvmArgs consistently
In-Reply-To: <pA_crYq8d4pP02fOMviloSX-9AxrmmZu36Xjk6gszP4=.b2ba01bd-2328-40b5-9286-89b264123cc9@github.com>
References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
 <pA_crYq8d4pP02fOMviloSX-9AxrmmZu36Xjk6gszP4=.b2ba01bd-2328-40b5-9286-89b264123cc9@github.com>
Message-ID: <jBSqUz00zrJ_A04BvVd8wd5sbcrDhZH5uWhm5q4X_NI=.a1b9686a-565e-49b0-bba9-d3ab096ddb3d@github.com>

On Thu, 13 Feb 2025 20:04:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'.
>> 
>> All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency.
>
> The java.lang.foreign arg changes look fine.

@liach @sendaoYan @cl4es Thanks for your review. I'm going to integrate the patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23609#issuecomment-2670174332

From duke at openjdk.org  Thu Feb 20 01:30:58 2025
From: duke at openjdk.org (duke)
Date: Thu, 20 Feb 2025 01:30:58 GMT
Subject: RFR: 8349943: [JMH] Use jvmArgs consistently
In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
Message-ID: <yX55BEDLPXHfnwtd91L0c-TITvW1nZ8fMgJj-m7QKHg=.a15002d1-3381-4d3c-9091-eb51618e9fcc@github.com>

On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'.
> 
> All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency.

@xyyNicole 
Your change (at version 06f874154e22886d7f1522a70dbdccd87fb4d004) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23609#issuecomment-2670175001

From haosun at openjdk.org  Thu Feb 20 01:36:56 2025
From: haosun at openjdk.org (Hao Sun)
Date: Thu, 20 Feb 2025 01:36:56 GMT
Subject: RFR: 8349943: [JMH] Use jvmArgs consistently
In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
Message-ID: <vkh7Ll3y4RZL4bKgX0Hpd-RRuUmVAsJeh5gYEe_jaCI=.3839effc-4ba3-4690-88ae-31893b92e675@github.com>

On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'.
> 
> All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency.

This patch has been reviewed and tested internally.
GHA tests are all green. Let me sponsor it.

-------------

Marked as reviewed by haosun (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23609#pullrequestreview-2628468812

From duke at openjdk.org  Thu Feb 20 01:36:56 2025
From: duke at openjdk.org (Nicole Xu)
Date: Thu, 20 Feb 2025 01:36:56 GMT
Subject: Integrated: 8349943: [JMH] Use jvmArgs consistently
In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com>
Message-ID: <QwDQyYguqtxMJDgiDD7CzSuaZiGDaZuC9gBulUWM3QI=.274feb87-11a5-4c79-ab8d-9d179ad00791@github.com>

On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu <duke at openjdk.org> wrote:

> As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'.
> 
> All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency.

This pull request has now been integrated.

Changeset: 3ebed783
Author:    Nicole Xu <yuyangx at nvidia.com>
Committer: Hao Sun <haosun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ebed78328bd64d2e18369d63d6ea323b87a7b24
Stats:     20 lines in 9 files changed: 2 ins; 0 del; 18 mod

8349943: [JMH] Use jvmArgs consistently

Reviewed-by: syan, redestad, haosun

-------------

PR: https://git.openjdk.org/jdk/pull/23609

From dholmes at openjdk.org  Thu Feb 20 02:52:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Feb 2025 02:52:58 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v3]
In-Reply-To: <9ZTXNeE806c5EDt4Y6QFMqull0_SobjS7mOQGk2wE5s=.81291418-85a7-4826-9ecf-dcdd050ecaf1@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <9ZTXNeE806c5EDt4Y6QFMqull0_SobjS7mOQGk2wE5s=.81291418-85a7-4826-9ecf-dcdd050ecaf1@github.com>
Message-ID: <p18PU3MM6PoNM1H1n6V0NCAYakQZAA5vhnG1_zHT1NU=.fbae280a-8f73-4a0d-819e-0372f9c772fc@github.com>

On Wed, 19 Feb 2025 20:30:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename isPrimitiveType field to primitive.

src/java.base/share/classes/java/lang/Class.java line 1296:

> 1294: 
> 1295:     // The componentType field's null value is the sole indication that the class is an array,
> 1296:     // see isArray().

Suggestion:

    // The componentType field's null value is the sole indication that the class 
    // is an array - see isArray().

src/java.base/share/classes/java/lang/Class.java line 1297:

> 1295:     // The componentType field's null value is the sole indication that the class is an array,
> 1296:     // see isArray().
> 1297:     private transient final Class<?> componentType;

Why the `transient` and how does this impact serialization??

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1962781718
PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1962782083

From syan at openjdk.org  Thu Feb 20 02:53:58 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 20 Feb 2025 02:53:58 GMT
Subject: RFR: 8350051: [JMH] Several tests fails NPE [v2]
In-Reply-To: <OQFh3DTyFqCcNT3Tuo21MV-_-uTGgV_8QUvDvaAtHWs=.16070bd1-8714-44b8-a5c5-843eb50fd03e@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
 <SY1PdOspzEjsQMH_5pdA5S9OTRXzHvsUv07hWMybyys=.448aa31a-c9c1-46a0-9c8f-394405b2fb78@github.com>
 <OQFh3DTyFqCcNT3Tuo21MV-_-uTGgV_8QUvDvaAtHWs=.16070bd1-8714-44b8-a5c5-843eb50fd03e@github.com>
Message-ID: <1YbF0N2tyvKhm0l0X_BJQZogUfuA1ne7Wfs1n3MYP7I=.5ab9a5b3-7342-4fb1-a151-b5d27a67e4bb@github.com>

On Wed, 19 Feb 2025 08:02:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use SetupCopyFiles macro to copy the dependency files
>
> If you have manually verified that the build fails if any of these files are removed then I'm happy. No new tests or documentation needed, really. 
> 
> I could cast my vote towards removing these particular micros. But as the work is done I say let's accept your change, (re-)evaluate their usefulness, and file a RFE to have them removed if they aren't. We have been building out the set of micros we regularly test in nightly / promotion testing, but due to resource constraints only a fraction is run on a regular basis - and javax.xml has not been a priority.

Thanks @cl4es @erikj79 for the suggestions and reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23625#issuecomment-2670335704

From syan at openjdk.org  Thu Feb 20 02:53:59 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 20 Feb 2025 02:53:59 GMT
Subject: Integrated: 8350051: [JMH] Several tests fails NPE
In-Reply-To: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
References: <DosDsCjuMyhPNtME-cGjpayk586UGbLKEMvdF-7RXB0=.775c9e46-d3ea-42cd-a449-91fa01dab9ae@github.com>
Message-ID: <jGmCMSdLG_kmg1XqJ4TR-rJWSNQLxRf9BNYUCDgpBM8=.71901ddd-4992-4576-b8bd-94a5cb99247f@github.com>

On Fri, 14 Feb 2025 07:21:27 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()" because "is" is null', because the file 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing the required xml input file defined by test/micro/org/openjdk/bench/javax/xml/AbstractXMLMicro.java. This PR copy the required xml file to benchmarks.jar, and remove two unexist xml input file.
> 
> After this PR, below JMH tests will run passes.
> 
> 
> org.openjdk.bench.javax.xml.DOM.testBuild
> org.openjdk.bench.javax.xml.DOM.testModify
> org.openjdk.bench.javax.xml.DOM.testWalk
> org.openjdk.bench.javax.xml.SAXUsingJDK.testParse
> org.openjdk.bench.javax.xml.STAX.testParse
> 
> 
> Test command:
> 
> 
> rm -rf build/jmh-result/ ; mkdir -p build/jmh-result/ ; time for test in `cat list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2" CONF=release &> build/jmh-result/$test.log ; done
> 
> 
> Change has been verified locally, no risk.

This pull request has now been integrated.

Changeset: 00d4e4a9
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/00d4e4a9710f89506f36156c24b0f3c5412971fa
Stats:     16 lines in 2 files changed: 11 ins; 2 del; 3 mod

8350051: [JMH] Several tests fails NPE

Reviewed-by: erikj, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/23625

From bpb at openjdk.org  Thu Feb 20 03:15:39 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 20 Feb 2025 03:15:39 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v6]
In-Reply-To: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
Message-ID: <oYBE6rMGvAI-65W_52-f1H8k0R2UghXJTybxOQVcCSc=.097fa2e6-c73c-4f30-a5be-dfe2ce57e534@github.com>

> Update the specification of `java.io.File.exists()` to match its behavior, which seems correct in the context of how the empty abstract pathname is documented elsewhere in the class.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8024695: Extend and clean up test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22821/files
  - new: https://git.openjdk.org/jdk/pull/22821/files/2cde95cb..22d4fb93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22821&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22821&range=04-05

  Stats: 98 lines in 1 file changed: 71 ins; 5 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/22821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22821/head:pull/22821

PR: https://git.openjdk.org/jdk/pull/22821

From syan at openjdk.org  Thu Feb 20 04:02:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 20 Feb 2025 04:02:53 GMT
Subject: RFR: 8349959: Test CR6740048.java passes unexpectedly missing
 CR6740048.xsd
In-Reply-To: <fGNGE4wP27oWsCspTsS24OHfqqTnd9oFc_Ki0ctoQE0=.8e28e33b-1167-46c3-870d-792f9693e877@github.com>
References: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>
 <fGNGE4wP27oWsCspTsS24OHfqqTnd9oFc_Ki0ctoQE0=.8e28e33b-1167-46c3-870d-792f9693e877@github.com>
Message-ID: <9gwtgePvgTRYLX9InspOIGRC63hZBmb94ZcpQCemhNk=.e0f9cb35-8809-4908-8b3e-bf45f03e7bd9@github.com>

On Wed, 19 Feb 2025 20:04:33 GMT, Joe Wang <joehw at openjdk.org> wrote:

> The schema file is integral to the test, so we assume it will be present. A minor improvement would be to remove the conditional check that verifies its existence. This would allow the test to fail if it can't load the schema file.

Do you mean we should change like below


diff --git a/test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java b/test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java
index 077415e3095..fbb515aca70 100644
--- a/test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java
+++ b/test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java
@@ -59,13 +59,9 @@ public final void testReusingDocumentBuilder() {
             DocumentBuilderFactory docBuilderFactory = DocumentBuilderFactory.newInstance();
             docBuilderFactory.setNamespaceAware(true);
 
-            if (xsd != null) {
-                docBuilderFactory.setValidating(true);
-                docBuilderFactory.setAttribute(SCHEMA_LANGUAGE_URL, XML_SCHEMA_URL);
-                docBuilderFactory.setAttribute(SCHEMA_SOURCE_URL, xsd);
-            }
+            docBuilderFactory.setValidating(true);
+            docBuilderFactory.setAttribute(SCHEMA_LANGUAGE_URL, XML_SCHEMA_URL);
+            docBuilderFactory.setAttribute(SCHEMA_SOURCE_URL, xsd);

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23627#issuecomment-2670405905

From liach at openjdk.org  Thu Feb 20 04:31:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Feb 2025 04:31:55 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v3]
In-Reply-To: <p18PU3MM6PoNM1H1n6V0NCAYakQZAA5vhnG1_zHT1NU=.fbae280a-8f73-4a0d-819e-0372f9c772fc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <9ZTXNeE806c5EDt4Y6QFMqull0_SobjS7mOQGk2wE5s=.81291418-85a7-4826-9ecf-dcdd050ecaf1@github.com>
 <p18PU3MM6PoNM1H1n6V0NCAYakQZAA5vhnG1_zHT1NU=.fbae280a-8f73-4a0d-819e-0372f9c772fc@github.com>
Message-ID: <HDfQ6ytPQFhvZcymShEy9Ga8Z3v0TqH-sFHpTqanOOY=.ea3784a6-c54a-4e28-b771-602bbeae9f38@github.com>

On Thu, 20 Feb 2025 02:50:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename isPrimitiveType field to primitive.
>
> src/java.base/share/classes/java/lang/Class.java line 1297:
> 
>> 1295:     // The componentType field's null value is the sole indication that the class is an array,
>> 1296:     // see isArray().
>> 1297:     private transient final Class<?> componentType;
> 
> Why the `transient` and how does this impact serialization??

The fields in `Class` are just inconsistently transient or not. `Class` has special treatment in the serialization specification, so the presence or absence of the `transient` modifier has no effect.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1962841415

From pkumaraswamy at openjdk.org  Thu Feb 20 05:28:57 2025
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Thu, 20 Feb 2025 05:28:57 GMT
Subject: RFR: 8349547: Document jlink and jmods Supported Usage
In-Reply-To: <AexZULgyOat3caRVyoDemL4uokSDwHWWAGkF2CAtvCQ=.81d4b5a2-dff0-49e2-a9ab-0edb991ec48a@github.com>
References: <AexZULgyOat3caRVyoDemL4uokSDwHWWAGkF2CAtvCQ=.81d4b5a2-dff0-49e2-a9ab-0edb991ec48a@github.com>
Message-ID: <TEZHgDB6kQRwr7HWCjwYQbzeD-nW6vDunV23mHLalZ4=.f46df7da-0eca-4ffe-b7d8-a7f40e06bb96@github.com>

On Tue, 18 Feb 2025 09:24:38 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

> Document supported usage of jlink with JDK jmod's
> The document will reflect the future work from JDK-8347831

Closing out this PR, since it will be taken care in JDK-8347831

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23672#issuecomment-2670498543

From pkumaraswamy at openjdk.org  Thu Feb 20 06:15:01 2025
From: pkumaraswamy at openjdk.org (Prajwal Kumaraswamy)
Date: Thu, 20 Feb 2025 06:15:01 GMT
Subject: Withdrawn: 8349547: Document jlink and jmods Supported Usage
In-Reply-To: <AexZULgyOat3caRVyoDemL4uokSDwHWWAGkF2CAtvCQ=.81d4b5a2-dff0-49e2-a9ab-0edb991ec48a@github.com>
References: <AexZULgyOat3caRVyoDemL4uokSDwHWWAGkF2CAtvCQ=.81d4b5a2-dff0-49e2-a9ab-0edb991ec48a@github.com>
Message-ID: <cdKZtqp7tAhuwNa0jfQUsdG7hj4vTS-zpwhjSX60iQg=.faaf43b8-8724-46d7-a76c-4d457326e993@github.com>

On Tue, 18 Feb 2025 09:24:38 GMT, Prajwal Kumaraswamy <pkumaraswamy at openjdk.org> wrote:

> Document supported usage of jlink with JDK jmod's
> The document will reflect the future work from JDK-8347831

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23672

From galder at openjdk.org  Thu Feb 20 06:27:57 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 20 Feb 2025 06:27:57 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <gXxBans1yY2lV4CGCGT2-zFYYO2TaX1_M7WRAq6uWIM=.6e862783-8e47-46b8-8a2a-e799e7f946da@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
 <xhGVTCK35DjTHkm356ou70rNSmEp9iuRRhOUSso9VfE=.ca03abd8-d954-4727-9556-58365052b311@github.com>
 <gXxBans1yY2lV4CGCGT2-zFYYO2TaX1_M7WRAq6uWIM=.6e862783-8e47-46b8-8a2a-e799e7f946da@github.com>
Message-ID: <tTR667Dokfrxx_FadpVxbEaE3Hlr6id5BBYo5Xgo9is=.8288d4e9-904b-4f96-be3c-799e2ae1bb92@github.com>

On Wed, 19 Feb 2025 19:50:50 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> I will run a comparison next with the same batch of tests but looking at `int` and see if there are any differences compared with `long` or not.
>
> Hi @galderz,
> Results from Graviton 3(Neoverse-V1).
> Without the patch:
> 
> Benchmark                       (probability)  (range)  (seed)  (size)   Mode  Cnt      Score    Error   Units
> MinMaxVector.intClippingRange             N/A       90       0    1000  thrpt    8  12565.427 ? 37.538  ops/ms
> MinMaxVector.intClippingRange             N/A      100       0    1000  thrpt    8  12462.072 ? 84.067  ops/ms
> MinMaxVector.intLoopMax                    50      N/A     N/A    2048  thrpt    8   5113.090 ? 68.720  ops/ms
> MinMaxVector.intLoopMax                    80      N/A     N/A    2048  thrpt    8   5129.857 ? 35.005  ops/ms
> MinMaxVector.intLoopMax                   100      N/A     N/A    2048  thrpt    8   5116.081 ?  8.946  ops/ms
> MinMaxVector.intLoopMin                    50      N/A     N/A    2048  thrpt    8   6174.544 ? 52.573  ops/ms
> MinMaxVector.intLoopMin                    80      N/A     N/A    2048  thrpt    8   6110.884 ? 54.447  ops/ms
> MinMaxVector.intLoopMin                   100      N/A     N/A    2048  thrpt    8   6178.661 ? 48.450  ops/ms
> MinMaxVector.intReductionMax               50      N/A     N/A    2048  thrpt    8   5109.270 ? 10.525  ops/ms
> MinMaxVector.intReductionMax               80      N/A     N/A    2048  thrpt    8   5123.426 ? 28.229  ops/ms
> MinMaxVector.intReductionMax              100      N/A     N/A    2048  thrpt    8   5133.799 ?  7.693  ops/ms
> MinMaxVector.intReductionMin               50      N/A     N/A    2048  thrpt    8   5130.209 ? 15.491  ops/ms
> MinMaxVector.intReductionMin               80      N/A     N/A    2048  thrpt    8   5127.823 ? 27.767  ops/ms
> MinMaxVector.intReductionMin              100      N/A     N/A    2048  thrpt    8   5118.217 ? 22.186  ops/ms
> MinMaxVector.longClippingRange            N/A       90       0    1000  thrpt    8   1831.026 ? 15.502  ops/ms
> MinMaxVector.longClippingRange            N/A      100       0    1000  thrpt    8   1827.194 ? 22.076  ops/ms
> MinMaxVector.longLoopMax                   50      N/A     N/A    2048  thrpt    8   2643.383 ?  9.830  ops/ms
> MinMaxVector.longLoopMax                   80      N/A     N/A    2048  thrpt    8   2640.417 ?  7.797  ops/ms
> MinMaxVector.longLoopMax                  100      N/A     N/A    2048  thrpt    8   1244.321 ?  1.001  ops/ms
> MinMaxVector.longLoopMin                   50      N/A     N/A    2048  thrpt    8   3239.234 ?  8.813  ops/ms
> MinMaxVector.longLoopMin                   80      N/A     N/A    2048  thrpt    8   3252.713 ?  3...

Thanks @eastig for the results on Graviton 3. I'm summarising them here:


Benchmark                       (probability)  (range)  (seed)  (size)   Mode  Cnt       Base      Patch   Units
MinMaxVector.longClippingRange            N/A       90       0    1000  thrpt    8   1831.026   5094.259  ops/ms (+178%)
MinMaxVector.longClippingRange            N/A      100       0    1000  thrpt    8   1827.194   5096.835  ops/ms (+180%)
MinMaxVector.longLoopMax                   50      N/A     N/A    2048  thrpt    8   2643.383   2636.438  ops/ms
MinMaxVector.longLoopMax                   80      N/A     N/A    2048  thrpt    8   2640.417   2644.069  ops/ms
MinMaxVector.longLoopMax                  100      N/A     N/A    2048  thrpt    8   1244.321   2646.250  ops/ms (+112%)
MinMaxVector.longLoopMin                   50      N/A     N/A    2048  thrpt    8   3239.234   2648.504  ops/ms (-18%)
MinMaxVector.longLoopMin                   80      N/A     N/A    2048  thrpt    8   3252.713   2658.082  ops/ms (-18%)
MinMaxVector.longLoopMin                  100      N/A     N/A    2048  thrpt    8   1204.370   2647.532  ops/ms (+119%)
MinMaxVector.longReductionMax              50      N/A     N/A    2048  thrpt    8   2536.322   2536.254  ops/ms
MinMaxVector.longReductionMax              80      N/A     N/A    2048  thrpt    8   2536.318   2536.209  ops/ms
MinMaxVector.longReductionMax             100      N/A     N/A    2048  thrpt    8   1395.273   2536.342  ops/ms (+81%)
MinMaxVector.longReductionMin              50      N/A     N/A    2048  thrpt    8   2536.325   2536.271  ops/ms
MinMaxVector.longReductionMin              80      N/A     N/A    2048  thrpt    8   2536.265   2536.250  ops/ms
MinMaxVector.longReductionMin             100      N/A     N/A    2048  thrpt    8   1389.982   2536.246  ops/ms (+82%)


On Graviton 3 there are wide enough registers for vectorization to kick in, so we see similar improvements to x64 AVX-512 in https://github.com/openjdk/jdk/pull/20098#issuecomment-2642788364. There is some variance in the 50/80% probability range, this was also observed slightly there, but on the aarch64 system it looks more pronounced. Interesting that it happened with min but not max but could be variance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2670574593

From galder at openjdk.org  Thu Feb 20 06:53:04 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 20 Feb 2025 06:53:04 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
Message-ID: <NA_X8GyT3wCtXQMpvXjBZB0MsptfiNQ8M66gOaUwh5g=.9f10568a-2599-4711-9d6c-30148465cbdc@github.com>

On Fri, 7 Feb 2025 12:39:24 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Fix typo
>  - Renaming methods and variables and add docu on algorithms
>  - Fix copyright years
>  - Make sure it runs with cpus with either avx512 or asimd
>  - Test can only run with 256 bit registers or bigger
>    
>    * Remove platform dependant check
>    and use platform independent configuration instead.
>  - Fix license header
>  - Tests should also run on aarch64 asimd=true envs
>  - Added comment around the assertions
>  - Adjust min/max identity IR test expectations after changes
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/af7645e5...a190ae68

To follow up https://github.com/openjdk/jdk/pull/20098#issuecomment-2669329851, I've run `MinMaxVector.int` benchmarks with **superword disabled** and with/without `_max`/`_min` intrinsics in both AVX-512 and AVX2 modes.

# AVX-512


Benchmark                             (probability)  (range)  (seed)  (size)   Mode  Cnt  -min/-max  +min/+max   Units
MinMaxVector.intClippingRange                   N/A       90       0    1000  thrpt    4   1067.050   1038.640  ops/ms
MinMaxVector.intClippingRange                   N/A      100       0    1000  thrpt    4   1041.922   1039.004  ops/ms
MinMaxVector.intLoopMax                          50      N/A     N/A    2048  thrpt    4    605.173    604.337  ops/ms
MinMaxVector.intLoopMax                          80      N/A     N/A    2048  thrpt    4    605.106    604.309  ops/ms
MinMaxVector.intLoopMax                         100      N/A     N/A    2048  thrpt    4    604.547    604.432  ops/ms
MinMaxVector.intLoopMin                          50      N/A     N/A    2048  thrpt    4    495.042    605.216  ops/ms (+22%)
MinMaxVector.intLoopMin                          80      N/A     N/A    2048  thrpt    4    495.105    495.217  ops/ms
MinMaxVector.intLoopMin                         100      N/A     N/A    2048  thrpt    4    495.040    495.176  ops/ms
MinMaxVector.intReductionMultiplyMax             50      N/A     N/A    2048  thrpt    4    407.920    407.984  ops/ms
MinMaxVector.intReductionMultiplyMax             80      N/A     N/A    2048  thrpt    4    407.710    407.965  ops/ms
MinMaxVector.intReductionMultiplyMax            100      N/A     N/A    2048  thrpt    4    874.881    407.922  ops/ms (-53%)
MinMaxVector.intReductionMultiplyMin             50      N/A     N/A    2048  thrpt    4    407.911    407.947  ops/ms
MinMaxVector.intReductionMultiplyMin             80      N/A     N/A    2048  thrpt    4    408.015    408.024  ops/ms
MinMaxVector.intReductionMultiplyMin            100      N/A     N/A    2048  thrpt    4    407.978    407.994  ops/ms
MinMaxVector.intReductionSimpleMax               50      N/A     N/A    2048  thrpt    4    460.538    460.439  ops/ms
MinMaxVector.intReductionSimpleMax               80      N/A     N/A    2048  thrpt    4    460.579    460.542  ops/ms
MinMaxVector.intReductionSimpleMax              100      N/A     N/A    2048  thrpt    4    998.211    460.404  ops/ms (-53%)
MinMaxVector.intReductionSimpleMin               50      N/A     N/A    2048  thrpt    4    460.570    460.447  ops/ms
MinMaxVector.intReductionSimpleMin               80      N/A     N/A    2048  thrpt    4    460.552    460.493  ops/ms
MinMaxVector.intReductionSimpleMin              100      N/A     N/A    2048  thrpt    4    460.455    460.485  ops/ms


There is some improvement in `intLoopMin` @ 50% but this didn't materialize in the `perfasm` run, so I don't think it can be strictly be correlated with the use/not-use of the intrinsic.

`intReductionMultiplyMax` and `intReductionSimpleMax` @ 100% regressions with the `max` intrinsic activated are consistent with what the saw with long.

### `intReductionMultiplyMin` and `intReductionSimpleMin` @ 100% same performance

There is something very intriguing happening here, which I don't know it's due to min itself or int vs long. Basically, with or without the `min` intrinsic the performance of these 2 benchmarks is same at 100% branch probability. What is going on? Let's look at one of them:

-min

# VM options: -Djava.library.path=/home/vagrant/1/jdk-intrinsify-max-min-long/build/release-linux-x86_64/images/test/micro/native -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_max,_min -XX:-UseSuperWord
...
   3.04%  ????    ?   0x00007f49280f76e9:   cmpl		%edi, %r10d
   3.14%  ????    ?   0x00007f49280f76ec:   cmovgl		%edi, %r10d         ;*ireturn {reexecute=0 rethrow=0 return_oop=0}
          ????    ?                                                             ; - java.lang.Math::min at 10 (line 2119)
          ????    ?                                                             ; - org.openjdk.bench.java.lang.MinMaxVector::intReductionSimpleMin at 23 (line 212)
          ????    ?                                                             ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_intReductionSimpleMin_jmhTest::intReductionSimpleMin_thrpt_jmhStub at 19 (line 124)


+min

# VM options: -Djava.library.path=/home/vagrant/1/jdk-intrinsify-max-min-long/build/release-linux-x86_64/images/test/micro/native -XX:-UseSuperWord
...
   3.10%  ??      ?   0x00007fbf340f6b97:   cmpl		%edi, %r10d
   3.08%  ??      ?   0x00007fbf340f6b9a:   cmovgl		%edi, %r10d         ;*invokestatic min {reexecute=0 rethrow=0 return_oop=0}
          ??      ?                                                             ; - org.openjdk.bench.java.lang.MinMaxVector::intReductionSimpleMin at 23 (line 212)
          ??      ?                                                             ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_intReductionSimpleMin_jmhTest::intReductionSimpleMin_thrpt_jmhStub at 19 (line 124)


Both are `cmov`. You can see how without the intrinsic the `Math::min` bytecode gets executed and transformed into a `cmov` and the same with the intrinsic.

I will verify this with long shortly to see if this behaviour is specific to `min` operation or something to do with int vs long.

# AVX2

Here are the AVX2 numbers:


Benchmark                             (probability)  (range)  (seed)  (size)   Mode  Cnt  -min/-max  +min/+max   Units
MinMaxVector.intClippingRange                   N/A       90       0    1000  thrpt    4   1068.265   1039.087  ops/ms
MinMaxVector.intClippingRange                   N/A      100       0    1000  thrpt    4   1067.705   1038.760  ops/ms
MinMaxVector.intLoopMax                          50      N/A     N/A    2048  thrpt    4    605.015    604.364  ops/ms
MinMaxVector.intLoopMax                          80      N/A     N/A    2048  thrpt    4    605.169    604.366  ops/ms
MinMaxVector.intLoopMax                         100      N/A     N/A    2048  thrpt    4    604.527    604.494  ops/ms
MinMaxVector.intLoopMin                          50      N/A     N/A    2048  thrpt    4    605.099    605.057  ops/ms
MinMaxVector.intLoopMin                          80      N/A     N/A    2048  thrpt    4    495.071    605.080  ops/ms (+22%)
MinMaxVector.intLoopMin                         100      N/A     N/A    2048  thrpt    4    495.134    495.047  ops/ms
MinMaxVector.intReductionMultiplyMax             50      N/A     N/A    2048  thrpt    4    407.953    407.987  ops/ms
MinMaxVector.intReductionMultiplyMax             80      N/A     N/A    2048  thrpt    4    407.861    408.005  ops/ms
MinMaxVector.intReductionMultiplyMax            100      N/A     N/A    2048  thrpt    4    873.915    407.995  ops/ms (-53%)
MinMaxVector.intReductionMultiplyMin             50      N/A     N/A    2048  thrpt    4    408.019    407.987  ops/ms
MinMaxVector.intReductionMultiplyMin             80      N/A     N/A    2048  thrpt    4    407.971    408.009  ops/ms
MinMaxVector.intReductionMultiplyMin            100      N/A     N/A    2048  thrpt    4    407.970    407.956  ops/ms
MinMaxVector.intReductionSimpleMax               50      N/A     N/A    2048  thrpt    4    460.443    460.514  ops/ms
MinMaxVector.intReductionSimpleMax               80      N/A     N/A    2048  thrpt    4    460.484    460.581  ops/ms
MinMaxVector.intReductionSimpleMax              100      N/A     N/A    2048  thrpt    4   1015.601    460.446  ops/ms (-54%)
MinMaxVector.intReductionSimpleMin               50      N/A     N/A    2048  thrpt    4    460.494    460.532  ops/ms
MinMaxVector.intReductionSimpleMin               80      N/A     N/A    2048  thrpt    4    460.489    460.451  ops/ms
MinMaxVector.intReductionSimpleMin              100      N/A     N/A    2048  thrpt    4   1021.420    460.435  ops/ms (-55%)


This time we see an improvement in `intLoopMin` @ 80% but again it was not observable in the `perfasm` run.

`intReductionMultiplyMax` and `intReductionSimpleMax` @ 100% have regressions, the familiar one of cmp+mov vs cmov. `intReductionMultiplyMin` @ 100% does not have a regression for the same reasons above, both use cmov.

The interesting thing is `intReductionSimpleMin` @ 100%. We see a regression there but I didn't observe it with the `perfasm` run. So, this could be due to variance in the application of `cmov` or not?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2670609470

From alanb at openjdk.org  Thu Feb 20 07:17:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Feb 2025 07:17:57 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v3]
In-Reply-To: <VFuf4DsmKMABC1MMPaB6XNreTt5GwJHJTXKedmjFyuM=.9be5f485-467d-4f62-8a3b-dbb8c0a8e1b7@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
 <7Xbnn-2LkNv3Gsj6nFHXdrdvvPO7vXi3K3MWm33E-jw=.8341aa47-99de-4a67-8339-64b46fa7bb36@github.com>
 <c4gZ8K3QMWzK46zOYrMj24MWrnVUGFDUEbqogI2tCDw=.1c802402-bf5d-40b4-881b-932dc2ba9dc1@github.com>
 <VFuf4DsmKMABC1MMPaB6XNreTt5GwJHJTXKedmjFyuM=.9be5f485-467d-4f62-8a3b-dbb8c0a8e1b7@github.com>
Message-ID: <OP6aeuS8pkiukxpN_wFg5EDO83QtIIKxDha0LE7FX1k=.4672d3bd-f531-492d-b6ba-aed33dfb8f2c@github.com>

On Wed, 19 Feb 2025 21:05:47 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> * No `jlink` tool in `static-jdk` when running on static JDK. This is currently observable using the `static-jdk`.
> * No separate `lib/modules` file (and other JDK resource files) if we build a single hermetic Java image for the test. 

Once the efforts are further along then it will be necessary to ensure that tests that rely on bin/<tool> have the appropriate `@modules jdk.jartool` (or some other tool module) so that jtreg selects the appropriate set of tests to run. ToolProvider should work so tests that use this to run tools "in process" can execute. 

The jdk.static requires properties is slightly different, this is what will be used to select/not-select tests that can only run with a modular run-time image or static image. This includes tests that might rely on files in the JDK conf directory (user editable configuration files, not the same thing as JDK resource files as they will just work).

It's a bit premature to get into jlink here. A static image could include the jdk.jlink module but would only be useful when invoked with ToolProvider and with a module path that contains packaged modules that is can consume, and only if those packaged modules were created from the same src bits. There's a lot more to this for later phases of this effort.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2670648319

From jbhateja at openjdk.org  Thu Feb 20 07:18:01 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 20 Feb 2025 07:18:01 GMT
Subject: RFR: 8350049: [JMH] Float16OperationsBenchmark fails
 java.lang.NoClassDefFoundError [v2]
In-Reply-To: <vjxCfs6qvdqL9zU2jBVoxgV8OgH8zbuboi-7rBJhOWs=.1b8779f3-c9b9-4771-b629-c579965e8a98@github.com>
References: <MAUbF4zfQV2GpI0kgOaRNzNKvFC1sj5FGs49I4PARx0=.436c177b-1061-4e08-8c8c-08c24984faba@github.com>
 <vjxCfs6qvdqL9zU2jBVoxgV8OgH8zbuboi-7rBJhOWs=.1b8779f3-c9b9-4771-b629-c579965e8a98@github.com>
Message-ID: <kACIkVaxiVPPHH6RJtXnEOAGeSPsKvPaOJCjrwr3otw=.790e878b-2463-4b18-9152-cc1db59d4757@github.com>

On Tue, 18 Feb 2025 09:58:50 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The newly added JMH tests 'org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark' fails "java.lang.NoClassDefFoundError: jdk/incubator/vector/Float16" by below test command:
>> 
>> 
>> make test MICRO="FORK=1;WARMUP_ITER=2" TEST="micro:org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark.test_bm_pattern1"
>> 
>> 
>> The `@Fork(jvmArgsPrepend = ..)` in microbenchmarks should replaced as `@Fork(jvmArgs = ..)` since [JDK-8343345](https://bugs.openjdk.org/browse/JDK-8343345). Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the extra whitespace

Thanks LGTM.

-------------

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23624#pullrequestreview-2628899869

From syan at openjdk.org  Thu Feb 20 07:28:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 20 Feb 2025 07:28:01 GMT
Subject: RFR: 8350049: [JMH] Float16OperationsBenchmark fails
 java.lang.NoClassDefFoundError [v2]
In-Reply-To: <vjxCfs6qvdqL9zU2jBVoxgV8OgH8zbuboi-7rBJhOWs=.1b8779f3-c9b9-4771-b629-c579965e8a98@github.com>
References: <MAUbF4zfQV2GpI0kgOaRNzNKvFC1sj5FGs49I4PARx0=.436c177b-1061-4e08-8c8c-08c24984faba@github.com>
 <vjxCfs6qvdqL9zU2jBVoxgV8OgH8zbuboi-7rBJhOWs=.1b8779f3-c9b9-4771-b629-c579965e8a98@github.com>
Message-ID: <1VaSuSg5s5W2Yc2CPIY-LkhPWfeBXRys1yWCMTV8Q5I=.ab7400cc-6c6a-401e-89b7-7021af6191a3@github.com>

On Tue, 18 Feb 2025 09:58:50 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The newly added JMH tests 'org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark' fails "java.lang.NoClassDefFoundError: jdk/incubator/vector/Float16" by below test command:
>> 
>> 
>> make test MICRO="FORK=1;WARMUP_ITER=2" TEST="micro:org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark.test_bm_pattern1"
>> 
>> 
>> The `@Fork(jvmArgsPrepend = ..)` in microbenchmarks should replaced as `@Fork(jvmArgs = ..)` since [JDK-8343345](https://bugs.openjdk.org/browse/JDK-8343345). Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the extra whitespace

Thanks all for the reviews  and approved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23624#issuecomment-2670664854

From syan at openjdk.org  Thu Feb 20 07:28:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 20 Feb 2025 07:28:01 GMT
Subject: Integrated: 8350049: [JMH] Float16OperationsBenchmark fails
 java.lang.NoClassDefFoundError
In-Reply-To: <MAUbF4zfQV2GpI0kgOaRNzNKvFC1sj5FGs49I4PARx0=.436c177b-1061-4e08-8c8c-08c24984faba@github.com>
References: <MAUbF4zfQV2GpI0kgOaRNzNKvFC1sj5FGs49I4PARx0=.436c177b-1061-4e08-8c8c-08c24984faba@github.com>
Message-ID: <iXlPokMLwpSWlBuDsS8qe0nFnxYeetJH3sdb4fJrzVU=.db04b521-841d-4127-95ba-3bd0dc1a6f59@github.com>

On Fri, 14 Feb 2025 02:23:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The newly added JMH tests 'org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark' fails "java.lang.NoClassDefFoundError: jdk/incubator/vector/Float16" by below test command:
> 
> 
> make test MICRO="FORK=1;WARMUP_ITER=2" TEST="micro:org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark.test_bm_pattern1"
> 
> 
> The `@Fork(jvmArgsPrepend = ..)` in microbenchmarks should replaced as `@Fork(jvmArgs = ..)` since [JDK-8343345](https://bugs.openjdk.org/browse/JDK-8343345). Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: 26bf445f
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26bf445f4726f1936a0a4cbaf1424c5235424bfb
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8350049: [JMH] Float16OperationsBenchmark fails java.lang.NoClassDefFoundError

Reviewed-by: jbhateja

-------------

PR: https://git.openjdk.org/jdk/pull/23624

From alanb at openjdk.org  Thu Feb 20 07:56:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Feb 2025 07:56:54 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v6]
In-Reply-To: <oYBE6rMGvAI-65W_52-f1H8k0R2UghXJTybxOQVcCSc=.097fa2e6-c73c-4f30-a5be-dfe2ce57e534@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <oYBE6rMGvAI-65W_52-f1H8k0R2UghXJTybxOQVcCSc=.097fa2e6-c73c-4f30-a5be-dfe2ce57e534@github.com>
Message-ID: <iRHg3erSNNy_gt3QWhc2Yc0hH4z7jDwG_MokSwiTgg0=.c101a1c8-3aac-4ea3-8352-96ea99aed8a3@github.com>

On Thu, 20 Feb 2025 03:15:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Update the specification of `java.io.File.exists()` to match its behavior, which seems correct in the context of how the empty abstract pathname is documented elsewhere in the class.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8024695: Extend and clean up test

src/java.base/share/classes/java/io/File.java line 254:

> 252:     static File getCWD() {
> 253:         return CWD;
> 254:     }

This is a bit icky, have you looked at pushing this down to a holder class in UnixFileSystem and WinNTFileSystem so they they aren't dependent on this.

test/jdk/java/io/File/EmptyPath.java line 67:

> 65: 
> 66:     @Test
> 67:     @Order(1)

What is the reason for use `@Order` in these tests, is there a dependency? Asking because we've usually avoided need to do this and I'm trying to see if how someone might be able to add to this test in the future.

test/jdk/java/io/File/EmptyPath.java line 260:

> 258:         assertFalse(f.canRead());
> 259:         assertTrue(f.setReadable(true));
> 260:         assertTrue(f.canRead());

Need try-finally in the setter tests to ensure that the directory's permissions are restored in the event that the test fails.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1963023613
PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1963021549
PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1963020273

From jbhateja at openjdk.org  Thu Feb 20 09:33:59 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 20 Feb 2025 09:33:59 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <kaboVW6MtayTPC-GSt_U-S8KjPsenaU87af71HBem0U=.d4be0c75-637d-45d7-a291-bf8a3ee8313b@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <kaboVW6MtayTPC-GSt_U-S8KjPsenaU87af71HBem0U=.d4be0c75-637d-45d7-a291-bf8a3ee8313b@github.com>
Message-ID: <mXbBPLqvzMXLMLmsfIhrAwHwrYfmilbqAdNn-_bFDcI=.2e3a4a38-5e67-4f7c-9dc2-3bc060be420a@github.com>

On Tue, 18 Feb 2025 03:50:19 GMT, Nicole Xu <duke at openjdk.org> wrote:

> Sure. Since I am very new to openJDK, I asked my teammate for help to file the follow-up RFE.
> 
> Here is the https://bugs.openjdk.org/browse/JDK-8350215 with description of the discussed issues.

Hi @xyyNicole , 

I have modified the benchmark keeping its essence intact, i.e. to use sufficient number of predicated operations within the vector loop while minimizing the noise due to memory operations.
Modified the index computation logic which can now withstand any ARRAYLEN without resulting in an IOOBE.
Removed redundant vector read/writes to instance fields, thus eliminating significant boxing penalty which translates into throughput gains.

Please feel free to include it along with this patch.
[MaskedLogicOpts.txt](https://github.com/user-attachments/files/18884093/MaskedLogicOpts.txt)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2670932944

From galder at openjdk.org  Thu Feb 20 10:56:58 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 20 Feb 2025 10:56:58 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <NA_X8GyT3wCtXQMpvXjBZB0MsptfiNQ8M66gOaUwh5g=.9f10568a-2599-4711-9d6c-30148465cbdc@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
 <NA_X8GyT3wCtXQMpvXjBZB0MsptfiNQ8M66gOaUwh5g=.9f10568a-2599-4711-9d6c-30148465cbdc@github.com>
Message-ID: <axNKSbry1NhlbWIMgmU9ZxeeHBc_8UjOYp8EtNKxbQM=.89c14b1a-6c67-4752-ae9e-4198a2612c60@github.com>

On Thu, 20 Feb 2025 06:50:07 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> There is something very intriguing happening here, which I don't know it's due to min itself or int vs long.


Benchmark                              (probability)  (size)   Mode  Cnt  -min/-max  +min/+max   Units
MinMaxVector.intReductionMultiplyMax             100    2048  thrpt    4    876.867    407.905  ops/ms (-53%)
MinMaxVector.intReductionMultiplyMin             100    2048  thrpt    4    407.963    407.956  ops/ms (1)
MinMaxVector.longReductionMultiplyMax            100    2048  thrpt    4    838.845    405.371  ops/ms (-51%)
MinMaxVector.longReductionMultiplyMin            100    2048  thrpt    4    825.602    414.757  ops/ms (-49%)
MinMaxVector.intReductionSimpleMax               100    2048  thrpt    4   1032.561    460.486  ops/ms (-55%)
MinMaxVector.intReductionSimpleMin               100    2048  thrpt    4    460.530    460.490  ops/ms (2)
MinMaxVector.longReductionSimpleMax              100    2048  thrpt    4   1017.560    460.436  ops/ms (-54%)
MinMaxVector.longReductionSimpleMin              100    2048  thrpt    4    959.507    459.197  ops/ms (-52%)


 (1) (2) It seems it's a combination of both int AND min reduction operations and disabling the intrinsic. The rest of reduction operations seems to use cmp+mov in that situation but not int+min, which uses cmov. Maybe this is intentional or maybe it's a bug, but it's interesting to notice.

`intReductionMultiplyMin` -min:

# VM options: -Djava.library.path=/home/vagrant/1/jdk-intrinsify-max-min-long/build/release-linux-x86_64/images/test/micro/native -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_min -XX:-UseSuperWord
# Benchmark: org.openjdk.bench.java.lang.MinMaxVector.intReductionMultiplyMin
# Parameters: (probability = 100, size = 2048)
...
   2.29%  ???    ?   0x00007f4aa40f5835:   cmpl		%edi, %r10d
   4.25%  ???    ?   0x00007f4aa40f5838:   cmovgl		%edi, %r10d         ;*ireturn {reexecute=0 rethrow=0 return_oop=0}
          ???    ?                                                             ; - java.lang.Math::min at 10 (line 2119)
          ???    ?                                                             ; - org.openjdk.bench.java.lang.MinMaxVector::intReductionMultiplyMin at 26 (line 202)
          ???    ?                                                             ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_intReductionMultiplyMin_jmhTest::intReductionMultiplyMin_thrpt_jmhStub at 19 (line 124)


`intReductionMultiplyMin` +min:

# VM options: -Djava.library.path=/home/vagrant/1/jdk-intrinsify-max-min-long/build/release-linux-x86_64/images/test/micro/native -XX:-UseSuperWord
# Benchmark: org.openjdk.bench.java.lang.MinMaxVector.intReductionMultiplyMin
# Parameters: (probability = 100, size = 2048)
...
   2.06%  ???    ?   0x00007ff8ec0f4c35:   cmpl		%edi, %r10d
   4.31%  ???    ?   0x00007ff8ec0f4c38:   cmovgl		%edi, %r10d         ;*invokestatic min {reexecute=0 rethrow=0 return_oop=0}
          ???    ?                                                             ; - org.openjdk.bench.java.lang.MinMaxVector::intReductionMultiplyMin at 26 (line 202)
          ???    ?                                                             ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_intReductionMultiplyMin_jmhTest::intReductionMultiplyMin_thrpt_jmhStub at 19 (line 124)


`longReductionMultiplyMin` -min:

# VM options: -Djava.library.path=/home/vagrant/1/jdk-intrinsify-max-min-long/build/release-linux-x86_64/images/test/micro/native -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_minL -XX:-UseSuperWord
# Benchmark: org.openjdk.bench.java.lang.MinMaxVector.longReductionMultiplyMin
# Parameters: (probability = 100, size = 2048)
...
   0.01%  ?            ?   ?? ? ??  0x00007ff9d80f7609:   imulq		$0xb, 0x10(%r12, %r10, 8), %rbp
          ?            ?   ?? ? ??                                                            ;*lmul {reexecute=0 rethrow=0 return_oop=0}
          ?            ?   ?? ? ??                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMultiplyMin at 24 (line 265)
          ?            ?   ?? ? ??                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMultiplyMin_jmhTest::longReductionMultiplyMin_thrpt_jmhStub at 19 (line 124)
          ?            ?   ?? ? ??  0x00007ff9d80f760f:   testq		%rbp, %rbp
          ?            ?   ???? ??  0x00007ff9d80f7612:   jge		0x7ff9d80f7646      ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ?            ?   ???? ??                                                            ; - java.lang.Math::min at 11 (line 2134)
          ?            ?   ???? ??                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMultiplyMin at 30 (line 266)
          ?            ?   ???? ??                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMultiplyMin_jmhTest::longReductionMultiplyMin_thrpt_jmhStub at 19 (line 124)


`longReductionMultiplyMin` +min:

# VM options: -Djava.library.path=/home/vagrant/1/jdk-intrinsify-max-min-long/build/release-linux-x86_64/images/test/micro/native -XX:-UseSuperWord
# Benchmark: org.openjdk.bench.java.lang.MinMaxVector.longReductionMultiplyMin
# Parameters: (probability = 100, size = 2048)
...
   0.01%  ?   ??  0x00007f83400f7d76:   cmpq		%r13, %rdx
   0.12%  ?   ??  0x00007f83400f7d79:   cmovlq		%rdx, %r13          ;*invokestatic min {reexecute=0 rethrow=0 return_oop=0}
          ?   ??                                                            ; - org.openjdk.bench.java.lang.MinMaxVector::longReductionMultiplyMin at 30 (line 266)
          ?   ??                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxVector_longReductionMultiplyMin_jmhTest::longReductionMultiplyMin_thrpt_jmhStub at 19 (line 124)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2671144644

From galder at openjdk.org  Thu Feb 20 11:03:58 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 20 Feb 2025 11:03:58 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <N-faJEFC3vJg5m-H3EyMnAkBg3ecpx_YduxpPyXRz8o=.fee546a6-61d3-4ce7-9939-80a1a9e2748e@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
 <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
 <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
 <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FF
 eVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>
 <ajuhBKoDVKmn_D9vg3O3OVUQVVunAT02KhXcaapMokE=.5b8f2f36-6521-4389-97de-0bf8deeb47dc@github.com>
 <N-faJEFC3vJg5m-H3EyMnAkBg3ecpx_YduxpPyXRz8o=.fee546a6-61d3-4ce7-9939-80a1a9e2748e@github.com>
Message-ID: <tQDhCoMxTDakWM2E5C0jo68nfJnRIsmGYJM6CSje5UU=.132a1a43-4911-4874-b5ac-6610467fd065@github.com>

On Tue, 18 Feb 2025 08:43:38 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> To make it more explicit: implementing long min/max in ad files as cmp will likely remove all the 100% regressions that are observed here. I'm going to repeat the same MinMaxVector int min/max reduction test above with the ad changes @rwestrel suggested to see what effect they have.
>
> @galderz I think we will have the same issue with both `int` and `long`: As far as I know, it is really a difficult problem to decide at compile-time if a `cmove` or `branch` is the better choice. I'm not sure there is any heuristic for which you will not find a micro-benchmark where the heuristic made the wrong choice.
> 
> To my understanding, these are the factors that impact the performance:
> - `cmove` requires all inputs to complete before it can execute, and it has an inherent latency of a cycle or so itself. But you cannot have any branch mispredictions, and hence no branch misprediction penalties (i.e. when the CPU has to flush out the ops from the wrong branch and restart at the branch).
> - `branch` can hide some latencies, because we can already continue with the branch that is speculated on. We do not need to wait for the inputs of the comparison to arrive, and we can already continue with the speculated resulting value. But if the speculation is ever wrong, we have to pay the misprediction penalty.
> 
> In my understanding, there are roughly 3 scenarios:
> - The branch probability is so extreme that the branch predictor would be correct almost always, and so it is profitable to do branching code.
> - The branching probability is somewhere in the middle, and the branch is not predictable. Branch mispredictions are very expensive, and so it is better to use `cmove`.
> - The branching probability is somewhere in the middle, but the branch is predictable (e.g. swapps back and forth). The branch predictor will have almost no mispredictions, and it is faster to use branching code.
> 
> Modeling this precisely is actually a little complex. You would have to know the cost of the `cmove` and the `branching` version of the code. That depends on the latency of the inputs, and the outputs: does the `cmove` dramatically increase the latency on the critical path, and `branching` could hide some of that latency? And you would have to know how good the branch predictor is, which you cannot derive from the branching probability of our profiling (at least not when the probabilities are in the middle, and you don't know if it is a random or predictable pattern).
> 
> If we can find a perfect heuristic - that would be fantastic ;)
> 
> If we cannot find a perfect heuristic, then we should think about what are the most "common" or "relevant" scenarios, I think.
> 
> But let's discuss all of this in a call / offline :)

FYI @eme64 @chhagedorn @rwestrel 

Since we know that vectorization does not always kick in, there was a worry if scalar fallbacks would heavily suffer with the work included in this PR to add long intrinsic for min/max. Looking at the same scenarios with int (read my comments https://github.com/openjdk/jdk/pull/20098#issuecomment-2669329851 and https://github.com/openjdk/jdk/pull/20098#issuecomment-2671144644), it looks clear that the same kind of regressions are also present there. So, if those int scalar regressions were not a problem when int min/max intrinsic was added, I would expect the same to apply to long.

Re: https://github.com/openjdk/jdk/pull/20098#issuecomment-2671144644 - I was trying to think what could be causing this. I thought maybe it's due to the int min/max backend, which is implemented in platform specific way, vs the long min/max backend which relies on platform independent macro expansion. But if that theory was true, I would expect the same behaviour with int max vs long max, but that's not the case. It seems odd to only see this difference with min.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2671163220

From jbhateja at openjdk.org  Thu Feb 20 11:37:08 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 20 Feb 2025 11:37:08 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v18]
In-Reply-To: <npCqs_ZZsS5MkLbKdkH2HqSrD8KI0loTBdo1DEIMfe4=.ac942c11-d10a-4bc2-a820-396656331758@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <GTm_Er6CT-A4aFdVeWEMCXyJKWWrW56VLe9On4W02fk=.6bb331e3-3a26-4f5e-befb-42e955e4d994@github.com>
 <npCqs_ZZsS5MkLbKdkH2HqSrD8KI0loTBdo1DEIMfe4=.ac942c11-d10a-4bc2-a820-396656331758@github.com>
Message-ID: <L2lftStF1cIovnUh2vu6w8D1V3cKM2-ZqlEjdvDDvtg=.03b3c48e-10b5-4f93-950b-8bc48921640a@github.com>

On Tue, 18 Feb 2025 02:36:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Is anyone else getting compile failures after this was integrated? This weirdly seems to only happen on Linux
> 
> ```
> * For target hotspot_variant-server_libjvm_objs_mulnode.o:
> /home/runner/work/jdk/jdk/src/hotspot/share/opto/mulnode.cpp: In member function ?virtual const Type* FmaHFNode::Value(PhaseGVN*) const?:
> /home/runner/work/jdk/jdk/src/hotspot/share/opto/mulnode.cpp:1944:37: error: call of overloaded ?make(double)? is ambiguous
>  1944 |   return TypeH::make(fma(f1, f2, f3));
>       |                                     ^
> In file included from /home/runner/work/jdk/jdk/src/hotspot/share/opto/node.hpp:31,
>                  from /home/runner/work/jdk/jdk/src/hotspot/share/opto/addnode.hpp:28,
>                  from /home/runner/work/jdk/jdk/src/hotspot/share/opto/mulnode.cpp:26:
> /home/runner/work/jdk/jdk/src/hotspot/share/opto/type.hpp:544:23: note: candidate: ?static const TypeH* TypeH::make(float)?
>   544 |   static const TypeH* make(float f);
>       |                       ^~~~
> /home/runner/work/jdk/jdk/src/hotspot/share/opto/type.hpp:545:23: note: candidate: ?static const TypeH* TypeH::make(short int)?
>   545 |   static const TypeH* make(short f);
>       |                       ^~~~
> ```

Hi @TheShermanTanker , 

Please file a separate JBS issue for the errors you are observing with non-standard build options. 
I am also seeing some other build issues with the following configuration
--with-extra-cxxflags=-D__CORRECT_ISO_CPP11_MATH_H_PROTO_FP

Best Regards,
Jatin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2671231948

From coleenp at openjdk.org  Thu Feb 20 13:00:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 20 Feb 2025 13:00:03 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v3]
In-Reply-To: <HDfQ6ytPQFhvZcymShEy9Ga8Z3v0TqH-sFHpTqanOOY=.ea3784a6-c54a-4e28-b771-602bbeae9f38@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <9ZTXNeE806c5EDt4Y6QFMqull0_SobjS7mOQGk2wE5s=.81291418-85a7-4826-9ecf-dcdd050ecaf1@github.com>
 <p18PU3MM6PoNM1H1n6V0NCAYakQZAA5vhnG1_zHT1NU=.fbae280a-8f73-4a0d-819e-0372f9c772fc@github.com>
 <HDfQ6ytPQFhvZcymShEy9Ga8Z3v0TqH-sFHpTqanOOY=.ea3784a6-c54a-4e28-b771-602bbeae9f38@github.com>
Message-ID: <KZoqmh2at9dSUfeAJYZW2w3zQ8zVoWyL2bLkM77OnYU=.40fb703f-99b8-42ee-8c48-c552ce749a75@github.com>

On Thu, 20 Feb 2025 04:29:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 1297:
>> 
>>> 1295:     // The componentType field's null value is the sole indication that the class is an array,
>>> 1296:     // see isArray().
>>> 1297:     private transient final Class<?> componentType;
>> 
>> Why the `transient` and how does this impact serialization??
>
> The fields in `Class` are just inconsistently transient or not. `Class` has special treatment in the serialization specification, so the presence or absence of the `transient` modifier has no effect.

Thanks Chen.  I was wondering why the other JVM installed fields were transient and this one wasn't so I added it to see if someone noticed and could verify whether it's right or not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1963520059

From sgehwolf at openjdk.org  Thu Feb 20 14:22:20 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Feb 2025 14:22:20 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v16]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <u5zEdl0x1vOXu2aa3xhsrfg3FZ58oBT08jvalZU9YW0=.2a829b23-b21b-4ec4-b934-816c56d2952a@github.com>

> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
> 
> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
> 
> This patch addresses this issue by:
> 
> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
> 
> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
> 
> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
> 
> Thoughts?
> 
> Testing:
> 
> - [x] GHA
> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
> - [x] Some manual testing using systemd slices

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Fix missing imports
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Add exclusive access dirs directive for systemd tests
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - ... and 32 more: https://git.openjdk.org/jdk/compare/e1d0a9c8...74abae5b

-------------

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=15
  Stats: 1621 lines in 27 files changed: 1373 ins; 152 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/20280.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280

PR: https://git.openjdk.org/jdk/pull/20280

From alanb at openjdk.org  Thu Feb 20 15:00:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Feb 2025 15:00:55 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling
In-Reply-To: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
Message-ID: <LZLWRwVzynzwSJ2Z951qxEmn7ruD26IPLnpgB-xC0xk=.32fd6208-e290-450e-833b-7caafe5fd48b@github.com>

On Wed, 19 Feb 2025 16:07:56 GMT, Doug Lea <dl at openjdk.org> wrote:

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 142:

> 140:  * <p>Additionally, this class supports {@link
> 141:  * ScheduledExecutorService} methods to delay or periodically execute
> 142:  * tasks, as well as method {#link #submitWithTimeout} to cancel tasks

Broken link here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1963730237

From rriggs at openjdk.org  Thu Feb 20 15:16:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Feb 2025 15:16:56 GMT
Subject: RFR: 8350151: Support requires property to filter tests
 incompatible with --enable-preview [v2]
In-Reply-To: <d-Z7EZi5HEv8hhUkS7t82ATHuxG-eihiV5ntugZUbUg=.3dd3abe9-75c7-4c3f-838f-13be8d16cc6e@github.com>
References: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
 <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com>
 <NGaCT00YtDH9CSv1q-xgfLTB1lPtOTJ_lPTk9nNbVIU=.679690a4-ab9a-4eae-a461-550ace661242@github.com>
 <Ol2Z2QCeakdS9FkAIxrzbxxY1v0cLh6h5AeMT90VJbw=.383244fd-9573-4844-a8df-fdae734a4889@github.com>
 <d-Z7EZi5HEv8hhUkS7t82ATHuxG-eihiV5ntugZUbUg=.3dd3abe9-75c7-4c3f-838f-13be8d16cc6e@github.com>
Message-ID: <SHMiIgKH_cmaVc1XV9ZsUM97nyf4QgQ6kgwYQ77H5u4=.ec351bbb-6894-4921-89f5-5dddd0081302@github.com>

On Wed, 19 Feb 2025 20:32:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> It ran ok for me, once I got the command line flags correct.
>> It ran ok if I added `@enablePreview`.
>> 
>> It also ran ok with an explicit @run command:  (it does not currently have an @run command).
>> 
>>  * @run main/othervm --enable-preview SecurityManagerWarnings
>>  ```
>
> For me it fails with
> ----------System.err:(18/917)----------
>  stdout: [];
>  stderr: [Error: Unable to initialize main class SecurityManagerWarnings
> Caused by: java.lang.NoClassDefFoundError: jdk/test/lib/process/OutputAnalyzer
> ]
>  exitValue = 1
> that seems pretty strange, might be test library issue?

I haven't been able to reproduce that locally. Even with mis-matched compilation of the test library and test code.

I noticed the NoClassDefFoundError message comes from the child process. 
The child is invoked with test.noclasspath=true and no path to the test library.  (intentionally)
The SecurityManagerWarning class explicitly refers to OutputAnalyzer.
There might be a path in which the new VM tries to load the OutputAnalyzer (and throw an error)

Finding a way to reproduce locally might be necessary to track down the cause.
Perhaps adding -Xlog (for the child) might provider more information about the sequence of events.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23653#discussion_r1963767231

From rriggs at openjdk.org  Thu Feb 20 15:20:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Feb 2025 15:20:52 GMT
Subject: RFR: 8350151: Support requires property to filter tests
 incompatible with --enable-preview [v2]
In-Reply-To: <AUhzuj3hBXKOC574IAcs7umrmu6ESxzhKzM0Yv2aJJs=.d3def8f8-64ef-4d14-b441-852fe3f726f7@github.com>
References: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
 <AUhzuj3hBXKOC574IAcs7umrmu6ESxzhKzM0Yv2aJJs=.d3def8f8-64ef-4d14-b441-852fe3f726f7@github.com>
Message-ID: <D0kumdFoW7_VGBsv_8PCAW0i7h_yPdCdzyP0YP3z1lc=.47e3b549-340c-49d7-b71e-7ad95b847bfd@github.com>

On Wed, 19 Feb 2025 17:49:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> It might be useful to be able to run testing with --enable-preview for feature development. The tests incompatible with this mode must be filtered out.
>> 
>> I chose name 'java.enablePreview' , because it is more java property than vm or jdk. And 'enablePreview' to be similar with jtreg tag. 
>> 
>> Tested by running all test suites, and verifying that test is correctly selected.
>> There are more tests incompatible with --enable-preview, will mark them in the following bug.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change other test to exclude

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23653#pullrequestreview-2630226768

From rriggs at openjdk.org  Thu Feb 20 15:20:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Feb 2025 15:20:53 GMT
Subject: RFR: 8350151: Support requires property to filter tests
 incompatible with --enable-preview [v2]
In-Reply-To: <SHMiIgKH_cmaVc1XV9ZsUM97nyf4QgQ6kgwYQ77H5u4=.ec351bbb-6894-4921-89f5-5dddd0081302@github.com>
References: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
 <1iY92LjhRPbtuENrxBQlsCOKx2EHI6leLAfbkorEGzE=.e964726d-cf2c-4715-91fc-c76fc3e6668d@github.com>
 <NGaCT00YtDH9CSv1q-xgfLTB1lPtOTJ_lPTk9nNbVIU=.679690a4-ab9a-4eae-a461-550ace661242@github.com>
 <Ol2Z2QCeakdS9FkAIxrzbxxY1v0cLh6h5AeMT90VJbw=.383244fd-9573-4844-a8df-fdae734a4889@github.com>
 <d-Z7EZi5HEv8hhUkS7t82ATHuxG-eihiV5ntugZUbUg=.3dd3abe9-75c7-4c3f-838f-13be8d16cc6e@github.com>
 <SHMiIgKH_cmaVc1XV9ZsUM97nyf4QgQ6kgwYQ77H5u4=.ec351bbb-6894-4921-89f5-5dddd0081302@github.com>
Message-ID: <pyLegAwNAVqpfU3zxlcT0NEOHdCEzxqzc_N2XeoWkBY=.a0a81185-470a-4840-982d-b15fa5a2c172@github.com>

On Thu, 20 Feb 2025 15:13:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> For me it fails with
>> ----------System.err:(18/917)----------
>>  stdout: [];
>>  stderr: [Error: Unable to initialize main class SecurityManagerWarnings
>> Caused by: java.lang.NoClassDefFoundError: jdk/test/lib/process/OutputAnalyzer
>> ]
>>  exitValue = 1
>> that seems pretty strange, might be test library issue?
>
> I haven't been able to reproduce that locally. Even with mis-matched compilation of the test library and test code.
> 
> I noticed the NoClassDefFoundError message comes from the child process. 
> The child is invoked with test.noclasspath=true and no path to the test library.  (intentionally)
> The SecurityManagerWarning class explicitly refers to OutputAnalyzer.
> There might be a path in which the new VM tries to load the OutputAnalyzer (and throw an error)
> 
> Finding a way to reproduce locally might be necessary to track down the cause.
> Perhaps adding -Xlog (for the child) might provider more information about the sequence of events.

Please file a separate bug for the failure, so further investigation can be done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23653#discussion_r1963775424

From alanb at openjdk.org  Thu Feb 20 15:30:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Feb 2025 15:30:54 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling
In-Reply-To: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
Message-ID: <pBlDCTMraoOpL-uxkXbFvFpMp71mi4SmGTiwyuWm7wo=.1f349028-d27c-441c-a6bb-b442aaddee54@github.com>

On Wed, 19 Feb 2025 16:07:56 GMT, Doug Lea <dl at openjdk.org> wrote:

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3537:

> 3535:      * pool is {@link #shutdownNow}, or is {@link #shutdown} when
> 3536:      * otherwise quiescent and {@link #cancelDelayedTasksOnShutdown}
> 3537:      * is in effect.

In passing, I'm wondering if we should if the term "enabled" should be defined somewhere. SES uses it but it doesn't appear to define it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1963801530

From ihse at openjdk.org  Thu Feb 20 15:52:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Feb 2025 15:52:13 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v3]
In-Reply-To: <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
Message-ID: <WeVPvTHSmdKfo9uS4psVQKxjtyuGpvTbVtQrr3kupkc=.8119672b-4122-492d-818e-f10bcd670209@github.com>

On Tue, 18 Feb 2025 19:29:10 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
>> 
>> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
>> 
>> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

Hi everyone! Sorry for the late reply, I've been ill for a while and have been working through my backlog.

I have independently been working on a solution to get the static JDK image to pass all JTReg tests. I have not created a JBS issue for it yet (before I prototyped this I was not sure it was a feasible way), but my current WIP branch is here: https://github.com/openjdk/jdk/compare/master...magicus:jdk:add-static-relauncher. I was just about to finish the last parts on it prior to falling ill.

In short, what we do in a normal JDK build when we create e.g. the `jar` tool is that we recompiled the `main.c` file making the launcher, but hard-coding the launcher to run the class `sun.tools.jar.Main`, using the JLI interface. In my branch, I instead create a trivial, stand-alone program (I call it a "relauncher") that will just re-execute the real `java` executable with the proper arguments to get it to run the class `sun.tools.jar.Main`. (There are some more subtleties surrounding doing this, but that is the gist of it.)

This way, we can have a single, statically linked `java` binary, but also have these tiny helper tools that just falls back on the static java. This will make a static JDK image behave indistinguishable from a normal JDK image, and thus being able to run all JTreg tests that require a tool to be present. Ideally, I'd like for the static JDK image to be able to pass the JCK, so we can be sure it is fully up to par to a normal JDK image. (But I have not tried doing that yet.)

I cannot really say how my work relates to this PR. My initial reaction is that Jiangli's addition to the whitebox API to let tests know if they are run in a static context or not is sound. Which of the existing tests really will need this annotation in the end is perhaps less clear. But it will allow for tests to explicitly check stuff that might go wrong on a static build.

Oh, and while I was writing that, the PR was committed. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2671902318
PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2671903747

From jiangli at openjdk.org  Thu Feb 20 15:52:13 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Feb 2025 15:52:13 GMT
Subject: Integrated: 8349620: Add VMProps for static JDK
In-Reply-To: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
Message-ID: <FrCbEKz9Az36MoByv54O9jLirEpW09xfWNGGF04Ht5k=.a440507c-f09f-4648-8daf-437c79db643f@github.com>

On Fri, 7 Feb 2025 23:51:41 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
> 
> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
> 
> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.

This pull request has now been integrated.

Changeset: 960ad211
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/960ad211867d65a993b2fc4e6dafa8cea9827b3f
Stats:     19 lines in 6 files changed: 16 ins; 0 del; 3 mod

8349620: Add VMProps for static JDK

Reviewed-by: alanb, manc

-------------

PR: https://git.openjdk.org/jdk/pull/23528

From bpb at openjdk.org  Thu Feb 20 16:23:59 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 20 Feb 2025 16:23:59 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v6]
In-Reply-To: <iRHg3erSNNy_gt3QWhc2Yc0hH4z7jDwG_MokSwiTgg0=.c101a1c8-3aac-4ea3-8352-96ea99aed8a3@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <oYBE6rMGvAI-65W_52-f1H8k0R2UghXJTybxOQVcCSc=.097fa2e6-c73c-4f30-a5be-dfe2ce57e534@github.com>
 <iRHg3erSNNy_gt3QWhc2Yc0hH4z7jDwG_MokSwiTgg0=.c101a1c8-3aac-4ea3-8352-96ea99aed8a3@github.com>
Message-ID: <7ZGZ5fNRQKq4B6Tzao_RlQDscNjfDxlAgtCfnhpVp7c=.555f08b8-0f5d-400a-beb7-5a0635cdd619@github.com>

On Thu, 20 Feb 2025 07:52:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8024695: Extend and clean up test
>
> test/jdk/java/io/File/EmptyPath.java line 67:
> 
>> 65: 
>> 66:     @Test
>> 67:     @Order(1)
> 
> What is the reason for use `@Order` in these tests, is there a dependency? Asking because we've usually avoided need to do this and I'm trying to see if how someone might be able to add to this test in the future.

Early on I had some concern about the state being affected in a way that would make some tests spuriously fail if they were not performed before others. I think with careful handling of resetting the state as suggested above ("Need try-finally in the setter tests") then the `Order` annotations can be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1963925038

From schernyshev at openjdk.org  Thu Feb 20 17:16:56 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 20 Feb 2025 17:16:56 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <odVIQQDcyKJtY-WCiVhkFgwVDn_BwD0PLMqz6sEscHw=.19efc5b7-a33a-4e10-b624-037b5cba6e98@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <odVIQQDcyKJtY-WCiVhkFgwVDn_BwD0PLMqz6sEscHw=.19efc5b7-a33a-4e10-b624-037b5cba6e98@github.com>
Message-ID: <kcAMTV-WogoDKxJJl-G5RlveHsMmRgHD8-ruClXQLRQ=.11dcd8e3-50a3-4648-8cf0-79bbcceb4795@github.com>

On Mon, 17 Feb 2025 15:48:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added details in the log message
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2SubsystemController.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2024, Red Hat Inc.
> 
> You did not touch the test but change the COPYRIGHT year, why ?

Hi Matthias, thanks for spotting this. This is the leftover from the previous version of the patch. I'll remove it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1964037810

From alanb at openjdk.org  Thu Feb 20 17:24:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Feb 2025 17:24:58 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v6]
In-Reply-To: <-b9My_gexK8dEW6DgLgy3u5Nwisx6V0CU_pxOQk0AAM=.13d28836-1eb6-42ea-bcda-87d4d734c7a2@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <oYBE6rMGvAI-65W_52-f1H8k0R2UghXJTybxOQVcCSc=.097fa2e6-c73c-4f30-a5be-dfe2ce57e534@github.com>
 <iRHg3erSNNy_gt3QWhc2Yc0hH4z7jDwG_MokSwiTgg0=.c101a1c8-3aac-4ea3-8352-96ea99aed8a3@github.com>
 <-b9My_gexK8dEW6DgLgy3u5Nwisx6V0CU_pxOQk0AAM=.13d28836-1eb6-42ea-bcda-87d4d734c7a2@github.com>
Message-ID: <IQNCL17WDjGTj2keKo4KlhZPPdsg2hHdBQx7pU20n3Q=.51ad0e6c-781a-409a-8bc8-19b3151ec222@github.com>

On Thu, 20 Feb 2025 17:19:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/File.java line 254:
>> 
>>> 252:     static File getCWD() {
>>> 253:         return CWD;
>>> 254:     }
>> 
>> This is a bit icky, have you looked at pushing this down to a holder class in UnixFileSystem and WinNTFileSystem so they they aren't dependent on this.
>
> Why not just down into `FileSystem`? It's not OS-dependent.

That would be okay too, just need to avoid circular initialization.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1964048936

From schernyshev at openjdk.org  Thu Feb 20 17:29:37 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 20 Feb 2025 17:29:37 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v12]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <pCE3R1bagrzvun1a0BwoJ2DBo0GsHHUAIXgDKcFVY6Q=.ec8dc9cc-0dfb-4fda-b11b-787a4d664e14@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/a3002a92..39f44e92

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=10-11

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From alanb at openjdk.org  Thu Feb 20 17:29:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 20 Feb 2025 17:29:54 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling
In-Reply-To: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
Message-ID: <ONTlw86kpqOpkyvxBug2JWjBLR12ae_hV85U_r-zfwI=.7a93e455-4957-4896-a569-03e5359ba795@github.com>

On Wed, 19 Feb 2025 16:07:56 GMT, Doug Lea <dl at openjdk.org> wrote:

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3720:

> 3718:     /**
> 3719:      * Submits a task executing the given function, cancelling or
> 3720:      * performing a given timeoutAction if not completed within the

"cancelling or performance a given timeoutAction" could be misread to mean that it cancels the timeoutAction. It might be clear to say "cancelling the task or ...".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1964057274

From bpb at openjdk.org  Thu Feb 20 17:24:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 20 Feb 2025 17:24:57 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v6]
In-Reply-To: <iRHg3erSNNy_gt3QWhc2Yc0hH4z7jDwG_MokSwiTgg0=.c101a1c8-3aac-4ea3-8352-96ea99aed8a3@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <oYBE6rMGvAI-65W_52-f1H8k0R2UghXJTybxOQVcCSc=.097fa2e6-c73c-4f30-a5be-dfe2ce57e534@github.com>
 <iRHg3erSNNy_gt3QWhc2Yc0hH4z7jDwG_MokSwiTgg0=.c101a1c8-3aac-4ea3-8352-96ea99aed8a3@github.com>
Message-ID: <-b9My_gexK8dEW6DgLgy3u5Nwisx6V0CU_pxOQk0AAM=.13d28836-1eb6-42ea-bcda-87d4d734c7a2@github.com>

On Thu, 20 Feb 2025 07:54:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8024695: Extend and clean up test
>
> src/java.base/share/classes/java/io/File.java line 254:
> 
>> 252:     static File getCWD() {
>> 253:         return CWD;
>> 254:     }
> 
> This is a bit icky, have you looked at pushing this down to a holder class in UnixFileSystem and WinNTFileSystem so they they aren't dependent on this.

Why not just down into `FileSystem`? It's not OS-dependent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1964046284

From schernyshev at openjdk.org  Thu Feb 20 17:32:32 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 20 Feb 2025 17:32:32 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v13]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <_60M7CyqmgwYG1XOgkI-IGVqFCv9ZKW3oHFnwLiKUGA=.53db28b3-5c41-45f8-a198-f93bd03d8e85@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  revert header change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/39f44e92..8e8ab869

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From joehw at openjdk.org  Thu Feb 20 17:34:56 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 20 Feb 2025 17:34:56 GMT
Subject: RFR: 8349959: Test CR6740048.java passes unexpectedly missing
 CR6740048.xsd
In-Reply-To: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>
References: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>
Message-ID: <XsTwcaRhAtNHvnfUgqmqvxo0s9HcE6zU4u8Z_LFJO5M=.4a89cb53-e88a-4aac-86d7-8249f7f7ea94@github.com>

On Fri, 14 Feb 2025 07:44:26 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes unexpectedly when missing the depentdent file test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a NULL check after call `getResourceAsStream("CR6740048.xsd")`.
> 
> This PR do not change the original test logic but make test more robustness. Change has been verified locally, test-fix only, no risk.

Yes, that would do.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23627#issuecomment-2672198652

From schernyshev at openjdk.org  Thu Feb 20 17:36:04 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 20 Feb 2025 17:36:04 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
Message-ID: <OObfj4QWk_Q3Fk2-mDJbpfeFNhOAbgEmDB-IBehjR4c=.672abfeb-fc3f-4c68-ad0d-693ac0eb7bcd@github.com>

On Mon, 17 Feb 2025 11:09:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added details in the log message
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 73:
> 
>> 71:                                 break;
>> 72:                             }
>> 73:                             cgp = (cgp.getNameCount() > 1) ? cgp.subpath(1, cgp.getNameCount()) : Path.of("");
> 
> Suggestion:
> 
>                             cgp = (nameCount > 1) ? cgp.subpath(1, nameCount) : Path.of("");

Good catch, but as long as cgp#nameCount may change in the loop, this exact patch i cannot take.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1964064662

From duke at openjdk.org  Thu Feb 20 17:38:21 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 20 Feb 2025 17:38:21 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v4]
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <T87Ln19qgOny6fnXDb0hxUTYeLgejd_VgyBcKLLZfGE=.793ab490-912f-471f-bfe3-a8ff227565ae@github.com>

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Updating code and tests according to feedback and discussions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23491/files
  - new: https://git.openjdk.org/jdk/pull/23491/files/0c6ec9ae..01157cb9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=02-03

  Stats: 236 lines in 9 files changed: 218 ins; 11 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491

PR: https://git.openjdk.org/jdk/pull/23491

From lmesnik at openjdk.org  Thu Feb 20 18:02:59 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 20 Feb 2025 18:02:59 GMT
Subject: Integrated: 8350151: Support requires property to filter tests
 incompatible with --enable-preview
In-Reply-To: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
References: <j5V2HNnnA8tKcpg0IztsUNVL90cIPo5sjtbiUHm4zh4=.dc74fe18-c96a-420f-951f-0bf4fd9659c8@github.com>
Message-ID: <RJHCHDOIg5-Vg80M6XOeKHdcFwGuIfLluHIX5qRDQwg=.dabaf187-1130-4ea8-b027-cc08e709ec4c@github.com>

On Sat, 15 Feb 2025 19:43:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> It might be useful to be able to run testing with --enable-preview for feature development. The tests incompatible with this mode must be filtered out.
> 
> I chose name 'java.enablePreview' , because it is more java property than vm or jdk. And 'enablePreview' to be similar with jtreg tag. 
> 
> Tested by running all test suites, and verifying that test is correctly selected.
> There are more tests incompatible with --enable-preview, will mark them in the following bug.

This pull request has now been integrated.

Changeset: 1eb0db37
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1eb0db37608ae1dd05accc1e22c57d76fa2c72ce
Stats:     27 lines in 5 files changed: 19 ins; 0 del; 8 mod

8350151: Support requires property to filter tests incompatible with --enable-preview

Reviewed-by: alanb, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/23653

From coleenp at openjdk.org  Thu Feb 20 20:11:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 20 Feb 2025 20:11:11 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v4]
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <SXu4wiwyAqFFkV5mBhqBKKWv03q7fBHRx1HTlMCt3x8=.c135d8ff-aeda-425a-88e6-55b04bbb59c5@github.com>

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/Class.java
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23572/files
  - new: https://git.openjdk.org/jdk/pull/23572/files/d08091ac..7a4c595b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23572/head:pull/23572

PR: https://git.openjdk.org/jdk/pull/23572

From coleenp at openjdk.org  Thu Feb 20 20:19:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 20 Feb 2025 20:19:15 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v5]
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23572/files
  - new: https://git.openjdk.org/jdk/pull/23572/files/7a4c595b..02347433

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23572/head:pull/23572

PR: https://git.openjdk.org/jdk/pull/23572

From acobbs at openjdk.org  Thu Feb 20 21:05:22 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 20 Feb 2025 21:05:22 GMT
Subject: RFR: 8261669: Add lint warning for widening primitive conversions that
 lose information
Message-ID: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>

This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss.

I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks!

Currently, we generate this warning, but only for assignment operators, e.g.:

int x = 0;
x += 1.0f;   // warning here


This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.:

void method(float f) { }
...
float a = 0x10000001;   // warning here
method(0x10000001);     // warning here


It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.:

float f1 = 0x10000000;     // no warning here

The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not.

As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast:


float a = (float)0x10000001;   // no warning here

-------------

Commit messages:
 - Warn for more widening primitive conversions that lose information.

Changes: https://git.openjdk.org/jdk/pull/23718/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23718&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8261669
  Stats: 187 lines in 15 files changed: 149 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/23718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23718/head:pull/23718

PR: https://git.openjdk.org/jdk/pull/23718

From vlivanov at openjdk.org  Thu Feb 20 21:56:55 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 20 Feb 2025 21:56:55 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v5]
In-Reply-To: <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>
Message-ID: <LI--MPBmyj6QB6202JJV1iLAWY-friLYZ-yWm5t0vvg=.474dcd0d-6ef2-4312-8cff-5496e2a6c5d9@github.com>

On Thu, 20 Feb 2025 20:19:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace

Looks good!

Regarding @IntrinsicCandidate and its effects on JIT-compiler inlining decisions, @ForceInline could be added, but IMO it's not necessary since new implementations are small.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23572#pullrequestreview-2631244815

From bpb at openjdk.org  Thu Feb 20 22:20:04 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 20 Feb 2025 22:20:04 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v7]
In-Reply-To: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
Message-ID: <BZTFWp9edoLszrHqicbGRyKKANYwmNG8CCmug53YEXs=.7adcdfc7-1df4-44c1-aad9-477afd6ef4bf@github.com>

> Update the specification of `java.io.File.exists()` to match its behavior, which seems correct in the context of how the empty abstract pathname is documented elsewhere in the class.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - 8024695: Move getCWD to holder; remove Order from test
 - Merge
 - 8024695: Extend and clean up test
 - 8024695: Fix merge error; improve get*Space tests
 - Merge
 - 8024695: Add test of length()
 - 8024695: Change implementation to work for empty path
 - 8024695: new File("").exists() returns false whereas it is the current working directory

-------------

Changes: https://git.openjdk.org/jdk/pull/22821/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22821&range=06
  Stats: 306 lines in 4 files changed: 263 ins; 1 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/22821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22821/head:pull/22821

PR: https://git.openjdk.org/jdk/pull/22821

From bpb at openjdk.org  Thu Feb 20 22:20:05 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 20 Feb 2025 22:20:05 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v6]
In-Reply-To: <IQNCL17WDjGTj2keKo4KlhZPPdsg2hHdBQx7pU20n3Q=.51ad0e6c-781a-409a-8bc8-19b3151ec222@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <oYBE6rMGvAI-65W_52-f1H8k0R2UghXJTybxOQVcCSc=.097fa2e6-c73c-4f30-a5be-dfe2ce57e534@github.com>
 <iRHg3erSNNy_gt3QWhc2Yc0hH4z7jDwG_MokSwiTgg0=.c101a1c8-3aac-4ea3-8352-96ea99aed8a3@github.com>
 <-b9My_gexK8dEW6DgLgy3u5Nwisx6V0CU_pxOQk0AAM=.13d28836-1eb6-42ea-bcda-87d4d734c7a2@github.com>
 <IQNCL17WDjGTj2keKo4KlhZPPdsg2hHdBQx7pU20n3Q=.51ad0e6c-781a-409a-8bc8-19b3151ec222@github.com>
Message-ID: <plWS3JZRg4XXJF4FbldH0qa0ulq_0kHoX6iw6dPMvgM=.515f8a95-57d4-4ee0-abdb-cd9189d4c71b@github.com>

On Thu, 20 Feb 2025 17:21:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Why not just down into `FileSystem`? It's not OS-dependent.
>
> That would be okay too, just need to avoid circular initialization.

So changed in a3b7977.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1964415464

From bpb at openjdk.org  Thu Feb 20 22:20:05 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 20 Feb 2025 22:20:05 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v6]
In-Reply-To: <7ZGZ5fNRQKq4B6Tzao_RlQDscNjfDxlAgtCfnhpVp7c=.555f08b8-0f5d-400a-beb7-5a0635cdd619@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <oYBE6rMGvAI-65W_52-f1H8k0R2UghXJTybxOQVcCSc=.097fa2e6-c73c-4f30-a5be-dfe2ce57e534@github.com>
 <iRHg3erSNNy_gt3QWhc2Yc0hH4z7jDwG_MokSwiTgg0=.c101a1c8-3aac-4ea3-8352-96ea99aed8a3@github.com>
 <7ZGZ5fNRQKq4B6Tzao_RlQDscNjfDxlAgtCfnhpVp7c=.555f08b8-0f5d-400a-beb7-5a0635cdd619@github.com>
Message-ID: <Kw6XEVraBvn-FDnyLpOMLKPvbNsMc8c38uwA3PjxLMI=.e14859f6-17c0-4838-b746-a296e56c47b3@github.com>

On Thu, 20 Feb 2025 16:21:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/io/File/EmptyPath.java line 67:
>> 
>>> 65: 
>>> 66:     @Test
>>> 67:     @Order(1)
>> 
>> What is the reason for use `@Order` in these tests, is there a dependency? Asking because we've usually avoided need to do this and I'm trying to see if how someone might be able to add to this test in the future.
>
> Early on I had some concern about the state being affected in a way that would make some tests spuriously fail if they were not performed before others. I think with careful handling of resetting the state as suggested above ("Need try-finally in the setter tests") then the `Order` annotations can be removed.

`Order` removed in a3b7977; no effect on results.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1964415314

From bpb at openjdk.org  Thu Feb 20 22:20:06 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 20 Feb 2025 22:20:06 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v6]
In-Reply-To: <iRHg3erSNNy_gt3QWhc2Yc0hH4z7jDwG_MokSwiTgg0=.c101a1c8-3aac-4ea3-8352-96ea99aed8a3@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <oYBE6rMGvAI-65W_52-f1H8k0R2UghXJTybxOQVcCSc=.097fa2e6-c73c-4f30-a5be-dfe2ce57e534@github.com>
 <iRHg3erSNNy_gt3QWhc2Yc0hH4z7jDwG_MokSwiTgg0=.c101a1c8-3aac-4ea3-8352-96ea99aed8a3@github.com>
Message-ID: <GTuDYq9w6Xg9OVZY-vidSrRkooYDN457C46ngRR5pNQ=.e9c06c7b-6fb3-4371-9590-f854d5c8293d@github.com>

On Thu, 20 Feb 2025 07:51:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8024695: Extend and clean up test
>
> test/jdk/java/io/File/EmptyPath.java line 260:
> 
>> 258:         assertFalse(f.canRead());
>> 259:         assertTrue(f.setReadable(true));
>> 260:         assertTrue(f.canRead());
> 
> Need try-finally in the setter tests to ensure that the directory's permissions are restored in the event that the test fails.

So changed in a3b7977.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1964415260

From jiangli at openjdk.org  Thu Feb 20 22:37:06 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Feb 2025 22:37:06 GMT
Subject: RFR: 8349620: Add VMProps for static JDK [v3]
In-Reply-To: <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
References: <BUzYMvuP7WZSlghwPvrOKpVL7gnl8sgMNzMUmbsJy3U=.d223b8b7-48ef-4286-8224-ec0cb4bdf101@github.com>
 <ey88p_YVk1Xb9W18artjGTzHg9AjfiEGSOcmLfXJIv0=.c5ec3a1d-d853-4aee-bbd5-68d11504d6a6@github.com>
Message-ID: <hPp2RzA1Ya5SzhiYG9qPpgkJAOBUvXfHEK5pFjRdDXE=.4a8270db-ed4c-4bcb-b926-1da0b6c0ee47@github.com>

On Tue, 18 Feb 2025 19:29:10 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that adds the `jdk.static` VMProps. It can be used to skip tests not for running on static JDK.
>> 
>> This also adds a new WhiteBox native method, `jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine if it's static at runtime. 
>> 
>> `@requires !jdk.static` is added in `test/hotspot/jtreg/runtime/modules/ModulesSymLink.java` to skip running the test on static JDK. This test uses `bin/jlink`, which is not provided on static JDK. There are other tests that require tools in `bin/`. Those are not modified by the current PR to skip running on static JDK. Those can be done after the current change is fully discussed and reviewed/approved.
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

> Hi everyone! Sorry for the late reply, I've been ill for a while and have been working through my backlog.
> 
> I have independently been working on a solution to get the static JDK image to pass all JTReg tests. I have not created a JBS issue for it yet (before I prototyped this I was not sure it was a feasible way), but my current WIP branch is here: [master...magicus:jdk:add-static-relauncher](https://github.com/openjdk/jdk/compare/master...magicus:jdk:add-static-relauncher). I was just about to finish the last parts on it prior to falling ill.
> 
> In short, what we do in a normal JDK build when we create e.g. the `jar` tool is that we recompiled the `main.c` file making the launcher, but hard-coding the launcher to run the class `sun.tools.jar.Main`, using the JLI interface. In my branch, I instead create a trivial, stand-alone program (I call it a "relauncher") that will just re-execute the real `java` executable with the proper arguments to get it to run the class `sun.tools.jar.Main`. (There are some more subtleties surrounding doing this, but that is the gist of it.)
> 
> This way, we can have a single, statically linked `java` binary, but also have these tiny helper tools that just falls back on the static java. This will make a static JDK image behave indistinguishable from a normal JDK image, and thus being able to run all JTreg tests that require a tool to be present. Ideally, I'd like for the static JDK image to be able to pass the JCK, so we can be sure it is fully up to par to a normal JDK image. (But I have not tried doing that yet.)
> 
> I cannot really say how my work relates to this PR. My initial reaction is that Jiangli's addition to the whitebox API to let tests know if they are run in a static context or not is sound. Which of the existing tests really will need this annotation in the end is perhaps less clear. But it will allow for tests to explicitly check stuff that might go wrong on a static build.

@magicus Thanks for the thoughts and looking into the jtreg testing as well. IIUC, you want to make the required tools (perhaps a selected set of tools) usable for the static JDK at runtime, so any tests using tools at runtime can still be tested on static JDK. That seems to be a good goal and worth investigation. Your approach with re-executing the `java` executable sounds very interesting.

Really like your thoughts on making the static JDK image to pass the JCK!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2672843741

From duke at openjdk.org  Thu Feb 20 22:37:52 2025
From: duke at openjdk.org (Sunmisc Unsafe)
Date: Thu, 20 Feb 2025 22:37:52 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling
In-Reply-To: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
Message-ID: <rsvIPXG0q5KZJY8svll6a78ZEJwIjAZx0MxwFgd04DU=.32ebadf4-182e-47c5-b804-92028b40fc29@github.com>

On Wed, 19 Feb 2025 16:07:56 GMT, Doug Lea <dl at openjdk.org> wrote:

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

Is it possible to use getAndSet instead of cas-loop on #pend?

final Task t = tail.getAndSet(task);
t.next = task;

but that would require a new head field to bypass, probably not worth the gamble if the footprint increases a lot

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23702#issuecomment-2672844363

From coleenp at openjdk.org  Thu Feb 20 23:25:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 20 Feb 2025 23:25:57 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v5]
In-Reply-To: <3qpqR3PC8PFmdgaIoSYA3jDWdl-oon0-AcIzXcI76rY=.38635503-c067-4f6e-a4f1-92c1b6d991d1@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <E9GPjreqeKFJmZAIjHGQ-1y6FnyqaT94FHUPuK65kmE=.48bd4ecc-ac91-4f7b-895b-a32280d8b437@github.com>
 <_j9Wkg21aBltyVrbO4wxGFKmmLDy0T-eorRL4epfS4k=.5a453b6b-d673-4cc6-b29f-192fa74e290c@github.com>
 <3qpqR3PC8PFmdgaIoSYA3jDWdl-oon0-AcIzXcI76rY=.38635503-c067-4f6e-a4f1-92c1b6d991d1@github.com>
Message-ID: <dOZIsMeRy34Anbe2OORtfWN6eJHD2zPhIHF_vtuqDCo=.956c37b8-e682-475a-90f0-5818e7168044@github.com>

On Wed, 19 Feb 2025 21:16:51 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is a good question.  The heapwalker walks through dead mirrors so I can't assert that a null klass field matches our boolean setting but I don't know why this never asserts (can't find any instances in the bug database) but it seems like it could.  I'll use the bool field in the mirror in the assert though but not in the return since the caller likely will fetch the klass pointer next.
>
>> ... but not in the return since the caller likely will fetch the klass pointer next.
> 
> I notice that too.  Callers are using is_primitive() to short-circuit calls to as_Klass(), which means they seem to be aware of this implementation detail when maybe they shouldn't.

There are 136 callers so yes, it might be something that shouldn't be known in this many places.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1964492501

From coleenp at openjdk.org  Thu Feb 20 23:31:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 20 Feb 2025 23:31:55 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v5]
In-Reply-To: <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>
Message-ID: <J-2mk_b36BGlhDo7eRbyuERg0jr8lZmYfJKTtOcRGp4=.b0a93e8f-0006-472d-9221-f04315d89254@github.com>

On Thu, 20 Feb 2025 20:19:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace

Thanks Vladimir for review and for answering my earlier questions on this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23572#issuecomment-2672941007

From liach at openjdk.org  Thu Feb 20 23:40:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Feb 2025 23:40:55 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v5]
In-Reply-To: <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>
Message-ID: <beP3eW57na8hjpPFM27Zbhg3i4iZm_htJAhn7LZiwHg=.876cec03-2f47-468c-8197-fa59e590e435@github.com>

On Thu, 20 Feb 2025 20:19:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace

You are right, using the field directly is indeed better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1964502825

From jiangli at openjdk.org  Thu Feb 20 23:47:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Feb 2025 23:47:10 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK [v2]
In-Reply-To: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
Message-ID: <7T4TxxbN8RmIWkFPp0UNjlXhs07kmaWTEiepZG77vtE=.02c46b3f-eb18-4a82-811a-a5ed1a87592f@github.com>

> Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 
> 
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
> - Link with `-ldl` explicitly
> 
> The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224

Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Skip test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java for static JDK.
 - Revert make/test/JtregNativeJdk.gmk and test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c changes.
 - Merge branch 'master' into JDK-8350041
 - Remove 'lib' prefix from 'java.dll'.
 - Update copyright header year.
 - - Change to call JNU_GetStringPlatformChars, JNU_ClassString and JNU_NewStringPlatform
     using the function addresses obtained from lookup. This allows building libstringPlatformChars
     without explicitly linking with libjava.so (or libjava.dll).
   - Remove #include "jni_util.h".
   - Add BUILD_JDK_JTREG_LIBRARIES_LDFLAGS_libstringPlatformChars := -ldl. It's needed to
     avoid build failure if the build is configured to not allow undefined symbols in shared
     library.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23646/files
  - new: https://git.openjdk.org/jdk/pull/23646/files/013b391b..1de95b89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23646&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23646&range=00-01

  Stats: 7588 lines in 309 files changed: 3962 ins; 2555 del; 1071 mod
  Patch: https://git.openjdk.org/jdk/pull/23646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23646/head:pull/23646

PR: https://git.openjdk.org/jdk/pull/23646

From jiangli at openjdk.org  Thu Feb 20 23:47:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Feb 2025 23:47:10 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK
In-Reply-To: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
Message-ID: <9ssLntcEm-TOvy3i4JQLTiYflakzo-Yb9mTbNi3-y0c=.c7addb52-0979-4d1a-a36f-5833289c2c5b@github.com>

On Fri, 14 Feb 2025 18:31:52 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 
> 
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
> - Link with `-ldl` explicitly
> 
> The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224

> > I don't object to changing this test but it might be simpler to just skip this test, once we can use `@requires !jdk.static`.
> 
> Thanks, @AlanBateman. I think skipping this test for static JDK sounds reasonable to me, since this test seems to explicitly test these JNU_ functions. Changing to do dynamic lookup may alter the original intention. I'll update after #23528.

Updated to skipping `java/lang/String/nativeEncoding/StringPlatformChars.java` on static JDK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23646#issuecomment-2672961034

From liach at openjdk.org  Fri Feb 21 00:06:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 00:06:02 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
Message-ID: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>

Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.

Reduces the instructions to execute this code in a simple main by 47%:

long[] arr = new long[8];
var ms = MemorySegment.ofArray(arr);
ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);


Main overheads in FFM are identified to be:
1. Eager initialization of direct MethodHandle; can be CDS archived
2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead

Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.

Tests: tier 1-3 running

-------------

Commit messages:
 - More cleanup
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline
 - Make sure the form impl class is initialized
 - Reduce MT initialization work
 - MH linkToStatic stall
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline
 - Enhance cache for basic value layouts
 - More stuff
 - VH inline stuff stage

Changes: https://git.openjdk.org/jdk/pull/23720/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350118
  Stats: 1869 lines in 16 files changed: 1056 ins; 215 del; 598 mod
  Patch: https://git.openjdk.org/jdk/pull/23720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23720/head:pull/23720

PR: https://git.openjdk.org/jdk/pull/23720

From jperkins at redhat.com  Fri Feb 21 01:08:45 2025
From: jperkins at redhat.com (James Perkins)
Date: Thu, 20 Feb 2025 17:08:45 -0800
Subject: Integrated: 8344011: Remove usage of security manager from Class
 and reflective APIs
In-Reply-To: <aTe0NwDudHsBnKTUSomoER8v8m_5tLkBM2UVH5ru63k=.ae2f2a37-726b-4096-bfde-0f6506dd712b@github.com>
References: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
 <aTe0NwDudHsBnKTUSomoER8v8m_5tLkBM2UVH5ru63k=.ae2f2a37-726b-4096-bfde-0f6506dd712b@github.com>
Message-ID: <CADGwLpjuD=2xy=LfbOFaxcQ4NRtN+x9Ma2U_5-O5g5UVT7+84g@mail.gmail.com>

Please forgive me if this is the wrong medium to report this.

I've found an issue with the change in the ServiceLoader. Specifically, the
getConstructor()[1] method. Previously, the method caught Throwable and
then fail which would throw a java.util.ServiceConfigurationError
exception. With the changes, only a catches a NoSuchMethodException and
throws a ServiceConfigurationError then. Is this change in behavior
expected?

For some background on how I found this. I had a legitimate classpath issue
missing a CDI dependency. However, the constructor was throwing a
NoClassDefFoundException because of the missing required class. In versions
less than Java 24 this was okay because Throwable was caught. In Java 24
and 25 early access, this is an issue because the NoClassDefFoundException
is thrown instead of it being wrapped in a ServiceConfigurationError.

[1]:
https://github.com/openjdk/jdk/commit/abacece8265996aaec888c8f109f2e476ec7a8e3#diff-32ee5f2b2ad157956f95f404ef7001d8a1ca597ff07f4eb88181309a606af199L647-L668


James R. Perkins

Principal Software Engineer

Red Hat <https://www.redhat.com/>
<https://www.redhat.com/>


On Wed, Nov 13, 2024 at 11:44?PM Alan Bateman <alanb at openjdk.org> wrote:

> On Wed, 13 Nov 2024 10:32:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>
> > Remove code required for the now defunct SecurityManager execution mode
> from java.lang.Class, friends, and reflection APIs. Careful review is
> required so I've set Reviewer to 2. I've tried to keep the changes as easy
> to review as possible and not go over board with cleanup.
> >
> > sun.reflect.misc.ReflectUtil are been hollowed out. A future pass will
> remove empty methods and qualified exports once the changes in "far away"
> code and modules is done.
> >
> > In Lookup's class description, the removal of the sentence "avoid
> package access checks for classes accessible to the lookup class"  and the
> link to the removed "Security manager interactions" section is in
> discussion/non-normative text, just missed in the JEP 486 update that
> remove the linked section.
> >
> > runtime/cds/appcds/StaticArchiveWithLambda.java is updated as creating
> the archive no longer skips a generated class.
> >
> > Testing: tier1-5
>
> This pull request has now been integrated.
>
> Changeset: abacece8
> Author:    Alan Bateman <alanb at openjdk.org>
> URL:
> https://git.openjdk.org/jdk/commit/abacece8265996aaec888c8f109f2e476ec7a8e3
> Stats:     1254 lines in 26 files changed: 6 ins; 1094 del; 154 mod
>
> 8344011: Remove usage of security manager from Class and reflective APIs
>
> Reviewed-by: liach, yzheng, rriggs
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/22063
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250220/951e6c6e/attachment-0001.htm>

From syan at openjdk.org  Fri Feb 21 01:38:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Feb 2025 01:38:34 GMT
Subject: RFR: 8349959: Test CR6740048.java passes unexpectedly missing
 CR6740048.xsd [v2]
In-Reply-To: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>
References: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>
Message-ID: <2X5YTyjpXVjeK5ddgSBxOpkcTMODfdUshupcn7Jkwjg=.0162eefd-9b16-440b-8a63-9bf3d8834415@github.com>

> Hi all,
> 
> Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes unexpectedly when missing the depentdent file test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a NULL check after call `getResourceAsStream("CR6740048.xsd")`.
> 
> This PR do not change the original test logic but make test more robustness. Change has been verified locally, test-fix only, no risk.

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove the conditional check that verifies its existence

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23627/files
  - new: https://git.openjdk.org/jdk/pull/23627/files/699c6371..c0cf0d11

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23627&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23627&range=00-01

  Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23627/head:pull/23627

PR: https://git.openjdk.org/jdk/pull/23627

From syan at openjdk.org  Fri Feb 21 01:38:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 21 Feb 2025 01:38:34 GMT
Subject: RFR: 8349959: Test CR6740048.java passes unexpectedly missing
 CR6740048.xsd
In-Reply-To: <XsTwcaRhAtNHvnfUgqmqvxo0s9HcE6zU4u8Z_LFJO5M=.4a89cb53-e88a-4aac-86d7-8249f7f7ea94@github.com>
References: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>
 <XsTwcaRhAtNHvnfUgqmqvxo0s9HcE6zU4u8Z_LFJO5M=.4a89cb53-e88a-4aac-86d7-8249f7f7ea94@github.com>
Message-ID: <z4hfWT_Ge4bnpAkPXwx1S94rbIkvuH1PldYWJCFRtW0=.9f7b8189-9204-402a-bd36-db36372d65ae@github.com>

On Thu, 20 Feb 2025 17:32:06 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Yes, that would do.

Thanks, PR has been updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23627#issuecomment-2673138446

From jvernee at openjdk.org  Fri Feb 21 02:28:03 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 21 Feb 2025 02:28:03 GMT
Subject: RFR: 8287788: Implement a better allocator for downcalls [v18]
In-Reply-To: <Ycfo32fkfmcX332ag1BKYatxVVdLtiyHQSzmW82GuiY=.dc58a535-ba78-4ce6-a059-76af5df8e5c8@github.com>
References: <lGAHUKO5rriFO4hwvI2udJxslv2RB_YVDb3qdPmm0PU=.056a498a-8fc5-450c-ab51-6ddf1abe8fa2@github.com>
 <IZlZEhyy67aCP5VIumH2t9aF-yUWNlxT3-QyG39A3AU=.176bf64d-bee3-4e56-b0ab-9619db86ff24@github.com>
 <Ycfo32fkfmcX332ag1BKYatxVVdLtiyHQSzmW82GuiY=.dc58a535-ba78-4ce6-a059-76af5df8e5c8@github.com>
Message-ID: <b9aM7cFEbZcCCY2L-mMyxdUWte67moqupsenKjE0Iyo=.cab5da2e-0833-43ea-83cd-e3124840d739@github.com>

On Sat, 1 Feb 2025 11:18:18 GMT, Matthias Ernst <duke at openjdk.org> wrote:

>> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix test under VThread factory
>
> Tried for a few hours to repro with various approaches, to no avail.

@mernst-github We have investigated this issue further, and have narrowed it down to an issue with malloc/free. See: https://bugs.openjdk.org/browse/JDK-8350455

At this point, I think it's safe to try and re-integrate this patch, but the `stress` test should be separated out into a separate jtreg test, and then added to the problem list, with a reference to the above issue. 

Note that we already have an issue to redo this patch: https://bugs.openjdk.org/browse/JDK-8349146 Is that something you'd be interested in taking on?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2673194510

From alan.bateman at oracle.com  Fri Feb 21 06:44:11 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 21 Feb 2025 06:44:11 +0000
Subject: Integrated: 8344011: Remove usage of security manager from Class
 and reflective APIs
In-Reply-To: <CADGwLpjuD=2xy=LfbOFaxcQ4NRtN+x9Ma2U_5-O5g5UVT7+84g@mail.gmail.com>
References: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
 <aTe0NwDudHsBnKTUSomoER8v8m_5tLkBM2UVH5ru63k=.ae2f2a37-726b-4096-bfde-0f6506dd712b@github.com>
 <CADGwLpjuD=2xy=LfbOFaxcQ4NRtN+x9Ma2U_5-O5g5UVT7+84g@mail.gmail.com>
Message-ID: <e0f863fc-c0c2-4d95-9e63-c2b0c9f4ad0d@oracle.com>

On 21/02/2025 01:08, James Perkins wrote:
> Please forgive me if this is the wrong medium to report this.
>
> I've found an issue with the change in the ServiceLoader. 
> Specifically, the getConstructor()[1] method. Previously, the method 
> caught Throwable and then fail which would throw a 
> java.util.ServiceConfigurationError exception. With the changes, only 
> a catches a?NoSuchMethodException and throws a 
> ServiceConfigurationError then. Is this change in behavior expected?
>
> For some background on how I found this. I had a legitimate?classpath 
> issue missing a CDI dependency. However, the constructor was throwing 
> a NoClassDefFoundException because of the missing required class. In 
> versions less than Java 24 this was okay because Throwable was caught. 
> In Java 24 and 25 early access, this is an issue because the 
> NoClassDefFoundException is thrown instead of it being wrapped in a 
> ServiceConfigurationError.
>
Thanks for the bug report. Yes, this is a change in behavior that was 
not intended, and a reminder that there aren't enough tests for NCDFE 
and other linkage errors. Note that there are other cases, that date 
back to JDK 6, where linkage errors aren't wrapped so is other work to 
do in this area. I've created JDK-8350481 to track the behavior change.

-Alan

[1] https://bugs.openjdk.org/browse/JDK-8350481

From alanb at openjdk.org  Fri Feb 21 06:59:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Feb 2025 06:59:52 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK
In-Reply-To: <9ssLntcEm-TOvy3i4JQLTiYflakzo-Yb9mTbNi3-y0c=.c7addb52-0979-4d1a-a36f-5833289c2c5b@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
 <9ssLntcEm-TOvy3i4JQLTiYflakzo-Yb9mTbNi3-y0c=.c7addb52-0979-4d1a-a36f-5833289c2c5b@github.com>
Message-ID: <qxmE4GhVi7isIA3WFANbECNuEuTDVX7dVv5L4_4IhEQ=.92cba780-d49c-4769-bd8c-f0e81fcdb920@github.com>

On Thu, 20 Feb 2025 23:44:44 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Updated to skipping `java/lang/String/nativeEncoding/StringPlatformChars.java` on static JDK.

Thanks. If you can bump the copyright header date then I think we are done with this one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23646#issuecomment-2673693612

From duke at openjdk.org  Fri Feb 21 07:01:42 2025
From: duke at openjdk.org (Nicole Xu)
Date: Fri, 21 Feb 2025 07:01:42 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
Message-ID: <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>

> The UnsafeOps JMH benchmark fails with the following error:
> 
>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
> 
> To resolve this, we add the required `--add-opens` flag to grant access for the benchmark.

Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:

 - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
   
   The UnsafeOps JMH benchmark fails with the following error:
   
         ```
         java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
         ```
   
   Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
   `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
   
   Note that even it will raise "proprietary API" warnings after this
   patch, it is acceptable because the relevant APIs are bound for removal
   for the integrity of the platform.
   
   Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c
 - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe"
   
   This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23686/files
  - new: https://git.openjdk.org/jdk/pull/23686/files/ebc32ae2..b2bbc24e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23686&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23686&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23686.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23686/head:pull/23686

PR: https://git.openjdk.org/jdk/pull/23686

From alanb at openjdk.org  Fri Feb 21 07:12:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Feb 2025 07:12:53 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
 <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
Message-ID: <v596TlVCfNtjrGUEXtFItD4xTol9OIECCs2ABgsKUAw=.2ac68717-ed86-4700-afdd-b66e8c46fae1@github.com>

On Fri, 21 Feb 2025 07:01:42 GMT, Nicole Xu <duke at openjdk.org> wrote:

>> The UnsafeOps JMH benchmark fails with the following error:
>> 
>>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>> 
>> To resolve this, we add the required `--add-opens` flag to grant access for the benchmark.
>
> Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
>    
>    The UnsafeOps JMH benchmark fails with the following error:
>    
>          ```
>          java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>          ```
>    
>    Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>    `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>    
>    Note that even it will raise "proprietary API" warnings after this
>    patch, it is acceptable because the relevant APIs are bound for removal
>    for the integrity of the platform.
>    
>    Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c
>  - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe"
>    
>    This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b.

Thanks for restoring, this micro was specifically for sun.misc.Unsafe. I'm not wondering about the FFM micros that were also changed by JDK-8332744. Might not matter there but I think the original motive was to compare against sun.misc.Unsafe usage.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2673759459

From duke at openjdk.org  Fri Feb 21 07:22:52 2025
From: duke at openjdk.org (Nicole Xu)
Date: Fri, 21 Feb 2025 07:22:52 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <v596TlVCfNtjrGUEXtFItD4xTol9OIECCs2ABgsKUAw=.2ac68717-ed86-4700-afdd-b66e8c46fae1@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
 <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
 <v596TlVCfNtjrGUEXtFItD4xTol9OIECCs2ABgsKUAw=.2ac68717-ed86-4700-afdd-b66e8c46fae1@github.com>
Message-ID: <xEpCh4Kx3i6OCq5uoG0HXCPWZrIhZDp76VitTBHKfX0=.10601dfd-d094-4e3b-9313-7d6a924fe5e7@github.com>

On Fri, 21 Feb 2025 07:10:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thanks for restoring, this micro was specifically for sun.misc.Unsafe. I'm not wondering about the FFM micros that were also changed by JDK-8332744. Might not matter there but I think the original motive was to compare against sun.misc.Unsafe usage.

Yeah. I have updated and only changed `Unsafe` back as you and @liach suggested, so that the runtime error here could be fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2673776382

From alanb at openjdk.org  Fri Feb 21 07:44:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Feb 2025 07:44:53 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v6]
In-Reply-To: <plWS3JZRg4XXJF4FbldH0qa0ulq_0kHoX6iw6dPMvgM=.515f8a95-57d4-4ee0-abdb-cd9189d4c71b@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <oYBE6rMGvAI-65W_52-f1H8k0R2UghXJTybxOQVcCSc=.097fa2e6-c73c-4f30-a5be-dfe2ce57e534@github.com>
 <iRHg3erSNNy_gt3QWhc2Yc0hH4z7jDwG_MokSwiTgg0=.c101a1c8-3aac-4ea3-8352-96ea99aed8a3@github.com>
 <-b9My_gexK8dEW6DgLgy3u5Nwisx6V0CU_pxOQk0AAM=.13d28836-1eb6-42ea-bcda-87d4d734c7a2@github.com>
 <IQNCL17WDjGTj2keKo4KlhZPPdsg2hHdBQx7pU20n3Q=.51ad0e6c-781a-409a-8bc8-19b3151ec222@github.com>
 <plWS3JZRg4XXJF4FbldH0qa0ulq_0kHoX6iw6dPMvgM=.515f8a95-57d4-4ee0-abdb-cd9189d4c71b@github.com>
Message-ID: <y1SuyN-sDLk3KKK_eDkZzxmnxpuseBPd3T1W9aMz85Q=.8dbd5b18-720f-4356-a82a-e8a3b3ea0319@github.com>

On Thu, 20 Feb 2025 22:17:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> That would be okay too, just need to avoid circular initialization.
>
> So changed in a3b7977.

Thanks, that is better replace for this. In time it may be a good candidate to be a stable value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1965014862

From alanb at openjdk.org  Fri Feb 21 07:44:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Feb 2025 07:44:56 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v7]
In-Reply-To: <BZTFWp9edoLszrHqicbGRyKKANYwmNG8CCmug53YEXs=.7adcdfc7-1df4-44c1-aad9-477afd6ef4bf@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <BZTFWp9edoLszrHqicbGRyKKANYwmNG8CCmug53YEXs=.7adcdfc7-1df4-44c1-aad9-477afd6ef4bf@github.com>
Message-ID: <_I2SmeK1d6-aTF-mozF-kNHNX89CNN6ssiiTsUeKvYo=.addb41f3-019a-45af-b4ab-cc7d480485d7@github.com>

On Thu, 20 Feb 2025 22:20:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Update the specification of `java.io.File.exists()` to match its behavior, which seems correct in the context of how the empty abstract pathname is documented elsewhere in the class.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - 8024695: Move getCWD to holder; remove Order from test
>  - Merge
>  - 8024695: Extend and clean up test
>  - 8024695: Fix merge error; improve get*Space tests
>  - Merge
>  - 8024695: Add test of length()
>  - 8024695: Change implementation to work for empty path
>  - 8024695: new File("").exists() returns false whereas it is the current working directory

test/jdk/java/io/File/EmptyPath.java line 121:

> 119:             assertTrue(actual > 0);
> 120:             long ds = Math.abs(expected - actual);
> 121:             assertTrue((double)ds/expected < 0.05);

Are you confident that this tolerance is enough? Every test that has checked space available/used has taken a long time to bed in. For this test then I don't think we need to assert any relationship between the allocated and free space, it really just needs to check that it returns some value for the current directory.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1965013880

From epeter at openjdk.org  Fri Feb 21 08:22:59 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 21 Feb 2025 08:22:59 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <tQDhCoMxTDakWM2E5C0jo68nfJnRIsmGYJM6CSje5UU=.132a1a43-4911-4874-b5ac-6610467fd065@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
 <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
 <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
 <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FF
 eVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>
 <ajuhBKoDVKmn_D9vg3O3OVUQVVunAT02KhXcaapMokE=.5b8f2f36-6521-4389-97de-0bf8deeb47dc@github.com>
 <N-faJEFC3vJg5m-H3EyMnAkBg3ecpx_YduxpPyXRz8o=.fee546a6-61d3-4ce7-9939-80a1a9e2748e@github.com>
 <tQDhCoMxTDakWM2E5C0jo68nfJnRIsmGYJM6CSje5UU=.132a1a43-4911-4874-b5ac-6610467fd065@github.com>
Message-ID: <ugxcwW3OuUA372UYiQzEdzUW6zJxog-Bc_YD8ALzovI=.d92b16d0-af53-4935-90fa-65af126c978f@github.com>

On Thu, 20 Feb 2025 11:00:59 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> So, if those int scalar regressions were not a problem when int min/max intrinsic was added, I would expect the same to apply to long.

Do you know when they were added? If that was a long time ago, we might not have noticed back then, but we might notice now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2673875104

From epeter at openjdk.org  Fri Feb 21 08:23:00 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 21 Feb 2025 08:23:00 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <NA_X8GyT3wCtXQMpvXjBZB0MsptfiNQ8M66gOaUwh5g=.9f10568a-2599-4711-9d6c-30148465cbdc@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
 <NA_X8GyT3wCtXQMpvXjBZB0MsptfiNQ8M66gOaUwh5g=.9f10568a-2599-4711-9d6c-30148465cbdc@github.com>
Message-ID: <UtVPWMSN4Gkta0QNlEUoBSAckHZqc0b_XaCTBRSiQdE=.2d3ef926-b052-4040-8c65-9d1e493bfba1@github.com>

On Thu, 20 Feb 2025 06:50:07 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> The interesting thing is intReductionSimpleMin @ 100%. We see a regression there but I didn't observe it with the perfasm run. So, this could be due to variance in the application of cmov or not?

I don't see the error / variance in the results you posted. Often I look at those, and if it is anywhere above 10% of the average, then I'm suspicious ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2673879859

From epeter at openjdk.org  Fri Feb 21 08:30:00 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 21 Feb 2025 08:30:00 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <tQDhCoMxTDakWM2E5C0jo68nfJnRIsmGYJM6CSje5UU=.132a1a43-4911-4874-b5ac-6610467fd065@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>
 <Mci8jQuT-MquLYeikUrrdzKo9dJJuQa3ejdc7tlYQyI=.e0007de8-08b2-4a42-950c-f8e1225777fc@github.com>
 <RHL_g49_BCZQzsQJU-T88fkAOoSKpNvEC2Xx-QxdpRk=.4fbc0037-ba55-40e1-a091-4c16d7e8ee99@github.com>
 <MAcSY0Kc9JFrv5ueJDNkDH9I9LpIsYcRjiJ7RtQt090=.03b107fd-8879-41de-a0a4-b6202a9da369@github.com>
 <OxF5Va_n5CdxRW2uSTQQzMe6JSSNqnfs4qd3pAwSAEo=.d33d96b2-0d11-4d67-91cc-5ae94e78c580@github.com>
 <S-e2FYgJy02RfywN3A6WTPaepdkK6ly8KYNnX6tHCig=.a38238e5-7d3b-412b-a78e-9def776179ff@github.com>
 <T8VJwIaK1x-G60XsQNIUB9wcHQeYP1bkYB98Am9c8KM=.56412af0-9471-4619-9e14-03ba5f5cfde2@github.com>
 <msxoTDkFVjqA2xbPwhboyul7Oal6uQAQcig5RdkeiyY=.7d5bd096-0906-45fa-a3db-0ace9b629fcb@github.com>
 <5oGMaD5b87inAMkco6l5ODRvWv7FRsHGJiu_UMrGrTc=.0be44429-d322-4a6f-b91d-b64a146fad05@github.com>
 <3ArmrOQcUoj8DhHTq1a40Oz3GE8bCDDy3FF
 eVgbladg=.b8e0e13b-39f3-41a6-8a1b-5ca4febb4a41@github.com>
 <ajuhBKoDVKmn_D9vg3O3OVUQVVunAT02KhXcaapMokE=.5b8f2f36-6521-4389-97de-0bf8deeb47dc@github.com>
 <N-faJEFC3vJg5m-H3EyMnAkBg3ecpx_YduxpPyXRz8o=.fee546a6-61d3-4ce7-9939-80a1a9e2748e@github.com>
 <tQDhCoMxTDakWM2E5C0jo68nfJnRIsmGYJM6CSje5UU=.132a1a43-4911-4874-b5ac-6610467fd065@github.com>
Message-ID: <tts6bHpI9Z29U4XwPBLqAWkhE2XG9qccCkkCLI_M0Nw=.52ccbcfe-1910-4cba-9ed4-a30b0f90f696@github.com>

On Thu, 20 Feb 2025 11:00:59 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> Re: https://github.com/openjdk/jdk/pull/20098#issuecomment-2671144644 - I was trying to think what could be causing this.

Maybe it is an issue with probabilities? Do you know at what point (if at all) the `MinI` node appears/disappears in that example?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2673892612

From mcimadamore at openjdk.org  Fri Feb 21 10:03:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 10:03:58 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 45:

> 43:   $1_Type := $2
> 44: 
> 45:   ifeq ($$($1_Type), Boolean)

These changes in ScopedMemoryAccess are not strictly required -- but I imagine they simplify your implementation of the var handle impl methods. So, it's ok to leave them in.

make/modules/java.base/gensrc/GensrcVarHandles.gmk line 171:

> 169: # Param 1 - Variable declaration prefix
> 170: # Param 2 - Type with first letter capitalized
> 171: # TODO decide if CAS/Bitwise/AtomicAdd should be enabled for subints

Exactly - let's keep this out for now (they seem to be currently enabled -- and I'd prefer to do that separately, after some discussion)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965204113
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965202095

From mcimadamore at openjdk.org  Fri Feb 21 10:07:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 10:07:52 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <iog0kKFr_ePoJsQUo36J0soxHEf2-a0Ac7abgZ5Ys1M=.e67b1aa5-c695-4ba2-8831-71043242df49@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1556:

> 1554: 
> 1555:             @Override
> 1556:             public VarHandle memorySegmentViewHandle(Class<?> carrier, MemoryLayout enclosing, long alignmentMask, ByteOrder order, boolean fixedOffset, long offset) {

When I was playing with the code I kept being confused by the `fixedOffset` parameter name. The reason being that no var handle is really "fixed offset" (all VH take a "base" offset -- and this doesn't change that). What this "fixedOffset" means is really "there's no other (dynamic) offset on top of the base offset". I think calling it "stridedAccess" seems subjectively more evocative (or something like that).

src/java.base/share/classes/java/lang/invoke/VarForm.java line 70:

> 68:     VarForm(Class<?> implClass, VarForm methodTypeSource) {
> 69:         this.implClass = implClass;
> 70:         // methodTypeSource already called initMethodTypes

can we turn this comment into an assertion?

src/java.base/share/classes/java/lang/invoke/VarForm.java line 150:

> 148:         String methodName = value.methodName();
> 149:         MethodType type = methodType_table[value.at.ordinal()].insertParameterTypes(0, VarHandle.class);
> 150:         assert !UNSAFE.shouldBeInitialized(implClass) : implClass;

Thanks - took a long time to figure this one out -- hopefully it will save time in the future ;-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965208913
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965210069
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965211558

From mcimadamore at openjdk.org  Fri Feb 21 10:18:02 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 10:18:02 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

src/java.base/share/classes/java/lang/invoke/VarHandleSegmentViewBase.java line 34:

> 32:  * Base class for memory segment var handle view implementations.
> 33:  */
> 34: final class VarHandleSegmentViewBase extends VarHandle {

Should the name of this class change so that we drop `Base` ? It's no longer extended by anything.

src/java.base/share/classes/java/lang/invoke/VarHandles.java line 767:

> 765: //                    new HandleType(Object.class, long.class),
> 766: //
> 767: //                    // MS[base][offset]->T

I like how you programmatically generate all guards for all the shapes we care about.

On `MS[base][offset]` I wonder if generating a guard matters (for now) given that such a var handle will be indirect?

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 77:

> 75:         }
> 76: 
> 77:         @ForceInline

Question: can this and the `offset` method go in the `VarHandleSegmentViewBase` class? They don't seem to depend on anything in these classes - so it seems mostly duplicated code?

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 85:

> 83: 
> 84:         @ForceInline
> 85:         static $type$ get(VarHandle ob, Object obb, long base) {

I like this: a fast path for non-strided access, while, at the same time, reusing the impl.
In the future we can also add another variant for when there's only one index (which is by far the most common case).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965223737
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965218844
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965222924
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965226302

From mcimadamore at openjdk.org  Fri Feb 21 10:27:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 10:27:58 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <xLnepF4ybHY2H0J72WNtKFIjg_eBYAKYO-SttMpLgEI=.be7d1a89-227f-496e-9eff-0fdf2a177f1b@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 210:

> 208: 
> 209:         // (MS, long, long) if has strides, (MS, long) if no stride
> 210:         VarHandle handle = Utils.makeRawSegmentViewVarHandle(rootLayout(), valueLayout, strides.length == 0, offset);

Super! To make the code clearer - I would assign `strides.length == 0` to a local variable, and then reuse that variable both here and in the branch below (to make it more explicit that the two things are connected -- e.g. no stride, no need for adaptation)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965239357

From mcimadamore at openjdk.org  Fri Feb 21 10:30:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 10:30:52 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <etkFO6pJadhT4JbyJnZZSUaG6YqqQLmxOo38FFHzyws=.26406444-4738-4fdd-b4a4-63f960cc5def@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 77:

> 75: 
> 76:     private static MethodHandle computeFilterHandle(int index) {
> 77:         MethodHandles.Lookup lookup = MethodHandles.lookup();

please break this big conditional up!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965244316

From dfuchs at openjdk.org  Fri Feb 21 10:43:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Feb 2025 10:43:56 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v4]
In-Reply-To: <T87Ln19qgOny6fnXDb0hxUTYeLgejd_VgyBcKLLZfGE=.793ab490-912f-471f-bfe3-a8ff227565ae@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <T87Ln19qgOny6fnXDb0hxUTYeLgejd_VgyBcKLLZfGE=.793ab490-912f-471f-bfe3-a8ff227565ae@github.com>
Message-ID: <yJcbneFY6PA1KM1FENfnpJnTWld7-ijWZUIavF4b7nU=.cfc75ae1-385f-466e-8762-0654ca9b96b8@github.com>

On Thu, 20 Feb 2025 17:38:21 GMT, David Beaumont <duke at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating code and tests according to feedback and discussions.

src/java.logging/share/classes/java/util/logging/FileHandler.java line 747:

> 745: 
> 746:     @Override
> 747:     void synchronousPostWriteHook() {

I would add:

assert Thread.holdsLock(this);

here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1965264917

From mcimadamore at openjdk.org  Fri Feb 21 11:04:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 11:04:58 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <iQEdcnbJgEIJParqw13U1TRp_mPWkUpAOkn8mGOLM5w=.552276ad-c626-47c4-a649-783c12d47745@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java line 164:

> 162:         @ForceInline
> 163:         public final VarHandle varHandle() {
> 164:             record VarHandleCache() implements Function<AbstractValueLayout<?>, VarHandle> {

Can this cache be removed? The var handles created here should be "direct" -- meaning that we don't expect LayoutPath to add any adaptations on top of what's already done in the "raw" var handle returned by `Utils:makeRawSegmentViewVarHandle`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965294264

From mcimadamore at openjdk.org  Fri Feb 21 11:08:55 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 11:08:55 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <du6cAeDwexZcn1xFM5WPlC8PFN8USzV7QZMBamLVmcY=.84d6a694-0c13-4e80-8dd0-c873bde3e9f8@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

Overall, this is a great cleanup and consolidation of the memory segment VH code. I left various comments -- but this is already in a great shape. Thanks!

-------------

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2632727514

From mcimadamore at openjdk.org  Fri Feb 21 11:08:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 11:08:56 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <du6cAeDwexZcn1xFM5WPlC8PFN8USzV7QZMBamLVmcY=.84d6a694-0c13-4e80-8dd0-c873bde3e9f8@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <du6cAeDwexZcn1xFM5WPlC8PFN8USzV7QZMBamLVmcY=.84d6a694-0c13-4e80-8dd0-c873bde3e9f8@github.com>
Message-ID: <xHrSIGoarEAIgYesTWOdf2MY2IwphxKHk3jDFzZNUo4=.462ec623-5a77-44ca-bb1b-5e241be12e43@github.com>

On Fri, 21 Feb 2025 11:05:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Overall, this is a great cleanup and consolidation of the memory segment VH code. I left various comments -- but this is already in a great shape. Thanks!

It would be useful to run some micro benchmarks before/after -- especially those starting with "LoopOver*" and see if anything jumps out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2674259763

From mcimadamore at openjdk.org  Fri Feb 21 11:12:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 11:12:54 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <Hcss2BTOqMfZp2_jSnbGCKTxoXvmE5tNtUAbhgSEhnA=.a9c324b2-6bea-4f7d-a390-66c0f3df722b@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

I wonder if the changes affecting `isAccessModeSupported` should warrant a small CSR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2674266390

From dfuchs at openjdk.org  Fri Feb 21 11:12:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Feb 2025 11:12:55 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v7]
In-Reply-To: <BZTFWp9edoLszrHqicbGRyKKANYwmNG8CCmug53YEXs=.7adcdfc7-1df4-44c1-aad9-477afd6ef4bf@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <BZTFWp9edoLszrHqicbGRyKKANYwmNG8CCmug53YEXs=.7adcdfc7-1df4-44c1-aad9-477afd6ef4bf@github.com>
Message-ID: <-tnkrHlvQMgfJTqF6nFSYWMJDD6MwoKJ3q1tCqd3XfQ=.37f8d859-aefc-4a73-b9cb-ab52ab242285@github.com>

On Thu, 20 Feb 2025 22:20:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Update the specification of `java.io.File.exists()` to match its behavior, which seems correct in the context of how the empty abstract pathname is documented elsewhere in the class.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - 8024695: Move getCWD to holder; remove Order from test
>  - Merge
>  - 8024695: Extend and clean up test
>  - 8024695: Fix merge error; improve get*Space tests
>  - Merge
>  - 8024695: Add test of length()
>  - 8024695: Change implementation to work for empty path
>  - 8024695: new File("").exists() returns false whereas it is the current working directory

Looks like the [description of the PR](https://github.com/openjdk/jdk/pull/22821#issue-2749006501) should be updated now - we're no longer updating the specification to match the existing behaviour?

src/java.base/unix/classes/java/io/UnixFileSystem.java line 37:

> 35: 
> 36:     private String getPathForSysCalls(String path) {
> 37:         return path.isEmpty() ? getCWD().getPath() : path;

The Windows implementation has a guard for path == null. Is it superfluous there, or should it be added here?

    private String getPathForWin32Calls(String path) {
        return (path != null && path.isEmpty()) ? getCWD().getPath() : path;
    }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22821#issuecomment-2674268301
PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1965296464

From yzheng at openjdk.org  Fri Feb 21 12:14:57 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Fri, 21 Feb 2025 12:14:57 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v5]
In-Reply-To: <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>
Message-ID: <PAvrHsKnYAx1187SXemNFstJdKD2JZJq4S6sWt-NAhs=.fb8a0ca2-d4e2-4f94-bf3a-6b4f7238a7e0@github.com>

On Thu, 20 Feb 2025 20:19:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace

LGTM! As @iwanowww said, not inlining such trivial methods seems more like an inliner bug/enhancement opportunity.

-------------

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23572#pullrequestreview-2632877796

From duke at openjdk.org  Fri Feb 21 12:30:57 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 21 Feb 2025 12:30:57 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v4]
In-Reply-To: <yJcbneFY6PA1KM1FENfnpJnTWld7-ijWZUIavF4b7nU=.cfc75ae1-385f-466e-8762-0654ca9b96b8@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <T87Ln19qgOny6fnXDb0hxUTYeLgejd_VgyBcKLLZfGE=.793ab490-912f-471f-bfe3-a8ff227565ae@github.com>
 <yJcbneFY6PA1KM1FENfnpJnTWld7-ijWZUIavF4b7nU=.cfc75ae1-385f-466e-8762-0654ca9b96b8@github.com>
Message-ID: <NmW-IY47dzgufdI1mOW-H5-xiHZ2OGzyc9BeEWl6i9E=.60c89896-2a3a-474b-92f3-11a7b506a829@github.com>

On Fri, 21 Feb 2025 10:41:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating code and tests according to feedback and discussions.
>
> src/java.logging/share/classes/java/util/logging/FileHandler.java line 747:
> 
>> 745: 
>> 746:     @Override
>> 747:     void synchronousPostWriteHook() {
> 
> I would add:
> 
> assert Thread.holdsLock(this);
> 
> here

I decided against doing that because it's tested for in the unit test, and it adds "work" for every `publish()` method of every `StreamHandler` subclass run with assertions enabled, which feels unwanted to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1965400125

From coleenp at openjdk.org  Fri Feb 21 12:31:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 21 Feb 2025 12:31:46 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v6]
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <hOLDDibFVRsNY46cNYYY_J_QcBPABSHF2IeCZdpVV-c=.4ae5e382-51e4-4f6f-98ad-16540ced161f@github.com>

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Remove JVM_GetClassModifiers from jvm.h too.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23572/files
  - new: https://git.openjdk.org/jdk/pull/23572/files/02347433..c23718b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23572/head:pull/23572

PR: https://git.openjdk.org/jdk/pull/23572

From coleenp at openjdk.org  Fri Feb 21 12:31:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 21 Feb 2025 12:31:48 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v6]
In-Reply-To: <maTemwep0WbKgtihRZGo6LdtkVJAtVi8I-NNP18wvQ8=.34e3da87-46e9-4db4-9d3d-ad73ca8096b2@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <FrlPjmMb7CgcaoCNXLWwybw-pcHprdWIP8whY8fJU9g=.2564ab5c-9d30-4e5d-95cc-7a85955643b0@github.com>
 <maTemwep0WbKgtihRZGo6LdtkVJAtVi8I-NNP18wvQ8=.34e3da87-46e9-4db4-9d3d-ad73ca8096b2@github.com>
Message-ID: <w0inKFB0-c2_QmfFAqTQ9fVqy5wMyQ69sdROl19NrP0=.335d827a-1820-4bdd-83ed-f00e6ab37370@github.com>

On Wed, 19 Feb 2025 14:21:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 1262:
>> 
>>> 1260: JVM_END
>>> 1261: 
>>> 1262: JVM_ENTRY(jboolean, JVM_IsArrayClass(JNIEnv *env, jclass cls))
>> 
>> Where are the changes to jvm.h?
>
> Good catch, I also removed JVM_GetProtectionDomain.

and JVM_GetClassModifiers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1965401052

From coleenp at openjdk.org  Fri Feb 21 12:31:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 21 Feb 2025 12:31:49 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v5]
In-Reply-To: <beP3eW57na8hjpPFM27Zbhg3i4iZm_htJAhn7LZiwHg=.876cec03-2f47-468c-8197-fa59e590e435@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>
 <beP3eW57na8hjpPFM27Zbhg3i4iZm_htJAhn7LZiwHg=.876cec03-2f47-468c-8197-fa59e590e435@github.com>
Message-ID: <3jNPEzaXa0Ncf8eu3vct6a_jyH7k4tH_mbRBaKmbMc0=.d3a86a0f-1bed-4084-af92-959f4dbd52f4@github.com>

On Thu, 20 Feb 2025 23:38:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix whitespace
>
> You are right, using the field directly is indeed better.

I don't use the field directly because the field is a short and getModifiers makes it into Modifier.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1965399996

From dl at openjdk.org  Fri Feb 21 12:51:52 2025
From: dl at openjdk.org (Doug Lea)
Date: Fri, 21 Feb 2025 12:51:52 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling
In-Reply-To: <ONTlw86kpqOpkyvxBug2JWjBLR12ae_hV85U_r-zfwI=.7a93e455-4957-4896-a569-03e5359ba795@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <ONTlw86kpqOpkyvxBug2JWjBLR12ae_hV85U_r-zfwI=.7a93e455-4957-4896-a569-03e5359ba795@github.com>
Message-ID: <9vSV4psFMWDjCzDx3fMRJj6kUlX5LufrfaLTOORNVXY=.e62ea9fd-2dcc-4482-8dfa-533374f651aa@github.com>

On Thu, 20 Feb 2025 17:27:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3720:
> 
>> 3718:     /**
>> 3719:      * Submits a task executing the given function, cancelling or
>> 3720:      * performing a given timeoutAction if not completed within the
> 
> "cancelling or performance a given timeoutAction" could be misread to mean that it cancels the timeoutAction. It might be clear to say "cancelling the task or ...".

Added:
Delayed
 * actions become <em>enabled</em> and behave as ordinary submitted
 * tasks when their delays elapse.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965424702

From dl at openjdk.org  Fri Feb 21 12:54:53 2025
From: dl at openjdk.org (Doug Lea)
Date: Fri, 21 Feb 2025 12:54:53 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling
In-Reply-To: <pBlDCTMraoOpL-uxkXbFvFpMp71mi4SmGTiwyuWm7wo=.1f349028-d27c-441c-a6bb-b442aaddee54@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <pBlDCTMraoOpL-uxkXbFvFpMp71mi4SmGTiwyuWm7wo=.1f349028-d27c-441c-a6bb-b442aaddee54@github.com>
Message-ID: <lCPKGelsDQSXMw44DwMLaYIlY1WPDcVMd83UEBfs1Bs=.8f1ba3bc-2a09-4202-a906-eb5e4e06dbe9@github.com>

On Thu, 20 Feb 2025 15:28:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3537:
> 
>> 3535:      * pool is {@link #shutdownNow}, or is {@link #shutdown} when
>> 3536:      * otherwise quiescent and {@link #cancelDelayedTasksOnShutdown}
>> 3537:      * is in effect.
> 
> In passing, I'm wondering if we should if the term "enabled" should be defined somewhere. SES uses it but it doesn't appear to define it.

Added: 
 Delayed actions become <em>enabled</em> and behave as ordinary submitted tasks when their delays elapse.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965429003

From dl at openjdk.org  Fri Feb 21 13:16:10 2025
From: dl at openjdk.org (Doug Lea)
Date: Fri, 21 Feb 2025 13:16:10 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
Message-ID: <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Address feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23702/files
  - new: https://git.openjdk.org/jdk/pull/23702/files/53516e9d..16815cc0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=00-01

  Stats: 46 lines in 2 files changed: 6 ins; 1 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/23702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23702/head:pull/23702

PR: https://git.openjdk.org/jdk/pull/23702

From dl at openjdk.org  Fri Feb 21 13:16:10 2025
From: dl at openjdk.org (Doug Lea)
Date: Fri, 21 Feb 2025 13:16:10 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling
In-Reply-To: <rsvIPXG0q5KZJY8svll6a78ZEJwIjAZx0MxwFgd04DU=.32ebadf4-182e-47c5-b804-92028b40fc29@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <rsvIPXG0q5KZJY8svll6a78ZEJwIjAZx0MxwFgd04DU=.32ebadf4-182e-47c5-b804-92028b40fc29@github.com>
Message-ID: <rr2vE2DO2Yz1b2-oyXd2HMcMfRMBBBd80KA_vCf7uug=.dfd6635e-264f-44cb-98f1-cd73cbf0a4f2@github.com>

On Thu, 20 Feb 2025 22:35:07 GMT, Sunmisc Unsafe <duke at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Is it possible to use getAndSet instead of cas-loop on #pend?
> 
> final Task t = tail.getAndSet(task);
> t.next = task;
> 
> but that would require a new head field to bypass, probably not worth the gamble if the footprint increases a lot

@sunmisc You are right that it would be nice if there were a way to efficiently use getAndSet here because a failed reference CAS hits slow paths that vary across GCs. But all of the ways I know to do this are much worse.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23702#issuecomment-2674519257

From liach at openjdk.org  Fri Feb 21 13:56:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 13:56:53 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
Message-ID: <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>

On Fri, 21 Feb 2025 09:59:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> make/modules/java.base/gensrc/GensrcVarHandles.gmk line 171:
> 
>> 169: # Param 1 - Variable declaration prefix
>> 170: # Param 2 - Type with first letter capitalized
>> 171: # TODO decide if CAS/Bitwise/AtomicAdd should be enabled for subints
> 
> Exactly - let's keep this out for now (they seem to be currently enabled -- and I'd prefer to do that separately, after some discussion)

I have disabled them with #, and the status is confirmed by test for access modes. I kept the infra to make future reenabling easy.

> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1556:
> 
>> 1554: 
>> 1555:             @Override
>> 1556:             public VarHandle memorySegmentViewHandle(Class<?> carrier, MemoryLayout enclosing, long alignmentMask, ByteOrder order, boolean fixedOffset, long offset) {
> 
> When I was playing with the code I kept being confused by the `fixedOffset` parameter name. The reason being that no var handle is really "fixed offset" (all VH take a "base" offset -- and this doesn't change that). What this "fixedOffset" means is really "there's no other (dynamic) offset on top of the base offset". I think calling it "stridedAccess" seems subjectively more evocative (or something like that).

Shouldn't this be called noStride then?

> src/java.base/share/classes/java/lang/invoke/VarHandles.java line 767:
> 
>> 765: //                    new HandleType(Object.class, long.class),
>> 766: //
>> 767: //                    // MS[base][offset]->T
> 
> I like how you programmatically generate all guards for all the shapes we care about.
> 
> On `MS[base][offset]` I wonder if generating a guard matters (for now) given that such a var handle will be indirect?

Yes, it avoids the extra generation of vh linker lambda forms.

> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 77:
> 
>> 75: 
>> 76:     private static MethodHandle computeFilterHandle(int index) {
>> 77:         MethodHandles.Lookup lookup = MethodHandles.lookup();
> 
> please break this big conditional up!

This is a one-time cold path initializer so I did not care too much about its size. How should I break it up?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965506674
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965508406
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965504398
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965512480

From liach at openjdk.org  Fri Feb 21 14:04:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 14:04:02 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v5]
In-Reply-To: <3jNPEzaXa0Ncf8eu3vct6a_jyH7k4tH_mbRBaKmbMc0=.d3a86a0f-1bed-4084-af92-959f4dbd52f4@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>
 <beP3eW57na8hjpPFM27Zbhg3i4iZm_htJAhn7LZiwHg=.876cec03-2f47-468c-8197-fa59e590e435@github.com>
 <3jNPEzaXa0Ncf8eu3vct6a_jyH7k4tH_mbRBaKmbMc0=.d3a86a0f-1bed-4084-af92-959f4dbd52f4@github.com>
Message-ID: <VyoHvDMpugJg1-XWZE_gKFwBkWc-7of8qIfdcuDB2jE=.b0d9bdb7-7480-4ae1-afec-e48cbf94c188@github.com>

On Fri, 21 Feb 2025 12:27:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> You are right, using the field directly is indeed better.
>
> I don't use the field directly because the field is a short and getModifiers makes it into Modifier.

Indeed, even though this checks for the specific bit so widening has no effect, it is better to be cautious here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1965522767

From mcimadamore at openjdk.org  Fri Feb 21 14:46:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 14:46:52 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
 <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
Message-ID: <RW0eXeCodO55Qy8C5HLrB-kCp8jlqfVRFo6ELAO3OTs=.c85c04d1-4792-4bb0-aad3-f8a8c3be4695@github.com>

On Fri, 21 Feb 2025 13:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> I have disabled them with #, and the status is confirmed by test for access modes. I kept the infra to make future reenabling easy.

Doh - I missed the `#` -- maybe add few more to make that more explicit? (I agree with the approach)

>> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1556:
>> 
>>> 1554: 
>>> 1555:             @Override
>>> 1556:             public VarHandle memorySegmentViewHandle(Class<?> carrier, MemoryLayout enclosing, long alignmentMask, ByteOrder order, boolean fixedOffset, long offset) {
>> 
>> When I was playing with the code I kept being confused by the `fixedOffset` parameter name. The reason being that no var handle is really "fixed offset" (all VH take a "base" offset -- and this doesn't change that). What this "fixedOffset" means is really "there's no other (dynamic) offset on top of the base offset". I think calling it "stridedAccess" seems subjectively more evocative (or something like that).
>
> Shouldn't this be called noStride then?

noStride works (I was mostly suggesting that appealing to the concept of "there's a stride or not" might be more useful)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965596079
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965598874

From mcimadamore at openjdk.org  Fri Feb 21 14:53:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 14:53:57 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
 <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
Message-ID: <_HjEh41bJQXpl2my0adypBMQou6-51j9TGg9nXEHBvc=.248ba429-a846-4045-af59-fc186026dd42@github.com>

On Fri, 21 Feb 2025 13:53:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 77:
>> 
>>> 75: 
>>> 76:     private static MethodHandle computeFilterHandle(int index) {
>>> 77:         MethodHandles.Lookup lookup = MethodHandles.lookup();
>> 
>> please break this big conditional up!
>
> This is a one-time cold path initializer so I did not care too much about its size. How should I break it up?

I mean - using a single expression which is a conditional with two big switches seems quite unreadable.I suggest to move the `VH_FILTERS[index] = ` assignment out of the `computeFilterHandle` method. Then, rewrite `computeFilterHandle` as:


if (addressSize != 4) {
    return switch ...
} else {
    return switch ...
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965609458

From mcimadamore at openjdk.org  Fri Feb 21 14:57:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 14:57:52 GMT
Subject: RFR: 8349653: Clarify the docs for MemorySegment::reinterpret
In-Reply-To: <L94NPSTuSp_-0febenOUpVNuqpoXd91mMReM3sS3INc=.82f12e00-7737-4a35-9585-309ddcb4ecef@github.com>
References: <L94NPSTuSp_-0febenOUpVNuqpoXd91mMReM3sS3INc=.82f12e00-7737-4a35-9585-309ddcb4ecef@github.com>
Message-ID: <dMx_Z42bGd6Q4EmReKspi4F0KPEcf2DGBmr0fkYnavQ=.5ceaf17b-1834-48c1-bb77-020a5ca93fcb@github.com>

On Wed, 19 Feb 2025 09:14:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to clarify the documentation for two of the `MemorySegment::reinterpret` overloads.

Looks good!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23688#pullrequestreview-2633298651

From mcimadamore at openjdk.org  Fri Feb 21 15:02:12 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 15:02:12 GMT
Subject: RFR: 8350334: Add final keywords to FFM methods
In-Reply-To: <6DDqOOkbNVUXgUWn9flY41lfcWIWVOgvBrgxa5njpSg=.b9893567-2543-49c8-bc3f-c3b88e27bcab@github.com>
References: <6DDqOOkbNVUXgUWn9flY41lfcWIWVOgvBrgxa5njpSg=.b9893567-2543-49c8-bc3f-c3b88e27bcab@github.com>
Message-ID: <ElOOtzlOp3B_ek-1QePEs3DSq-Ofg9Bw8MtQMNjw0z0=.650dafa5-5b0d-4d9f-8a7e-e3605c5fd550@github.com>

On Wed, 19 Feb 2025 14:23:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add the `final` keyword to some classes and methods in order to assist compiler devirtualization (e.g. in Graal native image).
> 
> Passes `make test TEST=jdk_foreign`

I have no objection with this -- but I do think that before we embark on such changes we should somehow have some evidence that making such changes would be beneficial performance-wise. In terms of making the code clearer, I guess I'd prefer to see `final` only where it really matters -- for instance, we in `MemorySessionImpl::checkValidStateRaw` -- because in that case we truly care for the impl not to be split across multiple implementations. In other cases, IMHO adding `final` everywhere just makes refactoring harder -- so I'm a bit on the fence.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23696#pullrequestreview-2633312389

From liach at openjdk.org  Fri Feb 21 16:08:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 16:08:58 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
Message-ID: <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>

On Fri, 21 Feb 2025 10:12:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 77:
> 
>> 75:         }
>> 76: 
>> 77:         @ForceInline
> 
> Question: can this and the `offset` method go in the `VarHandleSegmentViewBase` class? They don't seem to depend on anything in these classes - so it seems mostly duplicated code?

Now this will require code update to static import `offset` from `VarHandleSegmentViewBase`. Is that acceptable?

> src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java line 164:
> 
>> 162:         @ForceInline
>> 163:         public final VarHandle varHandle() {
>> 164:             record VarHandleCache() implements Function<AbstractValueLayout<?>, VarHandle> {
> 
> Can this cache be removed? The var handles created here should be "direct" -- meaning that we don't expect LayoutPath to add any adaptations on top of what's already done in the "raw" var handle returned by `Utils:makeRawSegmentViewVarHandle`?

We have two caches, one in `ValueLayouts` and another in `Utils`. Should we remove both?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965763775
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965771047

From vklang at openjdk.org  Fri Feb 21 16:26:57 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 21 Feb 2025 16:26:57 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
Message-ID: <iuOedRj9wuXEY0ZZW0HyQPUwtGdQ0-vdvYsFLfIH9JA=.fa172c04-48da-48f1-b0a4-3ef9e710c2c7@github.com>

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 2812:

> 2810:     public CompletableFuture<T> completeOnTimeout(T value, long timeout,
> 2811:                                                   TimeUnit unit) {
> 2812:         arrangeTimeout(unit.toNanos(timeout),

Suggestion:

        arrangeTimeout(unit.toNanos(timeout), // Implicit null-check of unit

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965811672

From vklang at openjdk.org  Fri Feb 21 16:33:55 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 21 Feb 2025 16:33:55 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
Message-ID: <Kag2Nig3EtyolwmBmM5IeiG7evVY5r7bSwDHgJcMm5s=.47db8ec3-e293-4018-9fdb-426e66636885@github.com>

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 2840:

> 2838:         Canceller(Future<?> f) { this.f = f; }
> 2839:         public void accept(Object ignore, Throwable ex) {
> 2840:             if (f != null)

@DougLea Does it make sense to create a Canceller with a `null` `f`-parameter?

src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 2874:

> 2872:     public static Executor delayedExecutor(long delay, TimeUnit unit,
> 2873:                                            Executor executor) {
> 2874:         return new DelayedExecutor(unit.toNanos(delay),

Suggestion:

        return new DelayedExecutor(unit.toNanos(delay), // Implicit null-check of unit

src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 2891:

> 2889:      */
> 2890:     public static Executor delayedExecutor(long delay, TimeUnit unit) {
> 2891:         return new DelayedExecutor(unit.toNanos(delay), ASYNC_POOL);

Suggestion:

        return new DelayedExecutor(unit.toNanos(delay), ASYNC_POOL); // Implicit null-check of unit

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965819083
PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965822241
PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965822660

From david at dgregory.dev  Fri Feb 21 16:34:05 2025
From: david at dgregory.dev (David Gregory)
Date: Fri, 21 Feb 2025 16:34:05 +0000
Subject: New candidate JEP: 502: Stable Values (Preview)
In-Reply-To: <4eb86dce-e930-4f1a-a46f-3c142af672c7@oracle.com>
References: <4eb86dce-e930-4f1a-a46f-3c142af672c7@oracle.com>
Message-ID: <f3a89c36-3a5d-4dab-b9e7-5a3cc52408dc@dgregory.dev>

> While we started working on this for MH/VH-related use cases (for 
> instance, FFM's jextract will be a big user of stable values), we also 
> realized that this abstraction is actually quite useful in other cases 
> too.

This is really exciting! Stable values open the door to some really exciting language features, especially in functional languages.

For example, something similar is used to implement the tail-recursion modulo cons transformation in the OCaml compiler: https://ocaml.org/manual/5.3/tail_mod_cons.html#sec:details

This could enable languages hosted on the JVM to make all kinds of not-quite-tail-recursive programs stack safe without using explicit stacks to store the intermediate values.

Is it possible that the informal rules for record components will be adjusted to allow stable fields in addition to final ones?

Thanks,
   David Gregory


From vklang at openjdk.org  Fri Feb 21 16:38:57 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 21 Feb 2025 16:38:57 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
Message-ID: <8WSFK0WtY1PaOPeuLRZrSDqvkt0Fd0kVSeVPUx2B4no=.cb5fd759-ea88-452d-ad1a-c142c110b982@github.com>

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 2947:

> 2945:             e.scheduleDelayedTask(
> 2946:                 new ScheduledForkJoinTask<Void>(
> 2947:                     nanoDelay, 0L, true,

@DougLea Doesn't this mean that anyone can submit tasks which will be executed on the DelayedScheduler scheduling thread? If so, there's a big risk that things end up there which shouldn't be there, and could even compromise the liveness of said thread? ?

src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 336:

> 334:         if ((s = status) >= 0 &&
> 335:             (s = getAndBitwiseOrStatus(DONE | ABNORMAL)) >= 0)
> 336:             signalWaiters();

Nice simplification

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965830171
PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965836907

From vklang at openjdk.org  Fri Feb 21 16:54:56 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 21 Feb 2025 16:54:56 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
Message-ID: <LVC9_kIjU5rwELw6uKilGFu6lxZsQNxBm_76qisHrX8=.71560102-5f4b-47b6-8649-be28553b5afc@github.com>

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 1668:

> 1666:                      t.interrupt();
> 1667:                  } catch (Throwable ignore) {
> 1668:                  }

@DougLea This is just for peace of mind, I presume?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965872447

From vklang at openjdk.org  Fri Feb 21 17:05:56 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 21 Feb 2025 17:05:56 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
Message-ID: <Ug2AKx-o37K3dHCKHvOSxNvmxInSf3P9_rq3ZA7s4BE=.c4be5b3d-6bc3-4c77-ad9f-865b96418d71@github.com>

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 50:

> 48:         var future = new CompletableFuture<>().orTimeout(12, TimeUnit.HOURS);
> 49:         future.completeExceptionally(new RuntimeException("This is fine"));
> 50:         while (delayer.getDelayedTaskCount() != 0) {

Might be good to start the test case asserting that the delayed task count is 0 (so there's no interference).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965886235

From bpb at openjdk.org  Fri Feb 21 17:08:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 21 Feb 2025 17:08:53 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v6]
In-Reply-To: <y1SuyN-sDLk3KKK_eDkZzxmnxpuseBPd3T1W9aMz85Q=.8dbd5b18-720f-4356-a82a-e8a3b3ea0319@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <oYBE6rMGvAI-65W_52-f1H8k0R2UghXJTybxOQVcCSc=.097fa2e6-c73c-4f30-a5be-dfe2ce57e534@github.com>
 <iRHg3erSNNy_gt3QWhc2Yc0hH4z7jDwG_MokSwiTgg0=.c101a1c8-3aac-4ea3-8352-96ea99aed8a3@github.com>
 <-b9My_gexK8dEW6DgLgy3u5Nwisx6V0CU_pxOQk0AAM=.13d28836-1eb6-42ea-bcda-87d4d734c7a2@github.com>
 <IQNCL17WDjGTj2keKo4KlhZPPdsg2hHdBQx7pU20n3Q=.51ad0e6c-781a-409a-8bc8-19b3151ec222@github.com>
 <plWS3JZRg4XXJF4FbldH0qa0ulq_0kHoX6iw6dPMvgM=.515f8a95-57d4-4ee0-abdb-cd9189d4c71b@github.com>
 <y1SuyN-sDLk3KKK_eDkZzxmnxpuseBPd3T1W9aMz85Q=.8dbd5b18-720f-4356-a82a-e8a3b3ea0319@github.com>
Message-ID: <2h9Nr5_VYsDhqZwkdKqptbvl4GwfO62i8DGPHm3dAio=.051fb5e2-6a13-40fd-a0d3-5fb8cb08f36c@github.com>

On Fri, 21 Feb 2025 07:42:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> So changed in a3b7977.
>
> Thanks, that is better replace for this. In time it may be a good candidate to be a stable value.

It was a bad idea in the first place that I put that in `File` itself. I also thought of this being a stable value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1965889959

From bpb at openjdk.org  Fri Feb 21 17:08:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 21 Feb 2025 17:08:53 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v7]
In-Reply-To: <-tnkrHlvQMgfJTqF6nFSYWMJDD6MwoKJ3q1tCqd3XfQ=.37f8d859-aefc-4a73-b9cb-ab52ab242285@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <BZTFWp9edoLszrHqicbGRyKKANYwmNG8CCmug53YEXs=.7adcdfc7-1df4-44c1-aad9-477afd6ef4bf@github.com>
 <-tnkrHlvQMgfJTqF6nFSYWMJDD6MwoKJ3q1tCqd3XfQ=.37f8d859-aefc-4a73-b9cb-ab52ab242285@github.com>
Message-ID: <XZT4aTSOvNC5NBYXFqangP967BS9buHnhZll7zCWaRQ=.aed7ca96-c4d9-482e-aa63-dc47ecafecb5@github.com>

On Fri, 21 Feb 2025 11:10:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Looks like the [description of the PR](https://github.com/openjdk/jdk/pull/22821#issue-2749006501) should be updated now

You are correct, thanks: I have updated it. Note that I still need to change the CSR similarly.

> src/java.base/unix/classes/java/io/UnixFileSystem.java line 37:
> 
>> 35: 
>> 36:     private String getPathForSysCalls(String path) {
>> 37:         return path.isEmpty() ? getCWD().getPath() : path;
> 
> The Windows implementation has a guard for path == null. Is it superfluous there, or should it be added here?
> 
>     private String getPathForWin32Calls(String path) {
>         return (path != null && path.isEmpty()) ? getCWD().getPath() : path;
>     }

Without the `null` check on Windows there were test failures which I do not see on Unix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22821#issuecomment-2675093494
PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1965887504

From bpb at openjdk.org  Fri Feb 21 17:08:56 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 21 Feb 2025 17:08:56 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v7]
In-Reply-To: <_I2SmeK1d6-aTF-mozF-kNHNX89CNN6ssiiTsUeKvYo=.addb41f3-019a-45af-b4ab-cc7d480485d7@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <BZTFWp9edoLszrHqicbGRyKKANYwmNG8CCmug53YEXs=.7adcdfc7-1df4-44c1-aad9-477afd6ef4bf@github.com>
 <_I2SmeK1d6-aTF-mozF-kNHNX89CNN6ssiiTsUeKvYo=.addb41f3-019a-45af-b4ab-cc7d480485d7@github.com>
Message-ID: <xXJzfIqRJfM9ir8AXGFtO9n4ZsEue93dLsvwauFZxaQ=.a13a8a2a-af61-4c41-9567-e0f0ec5309c3@github.com>

On Fri, 21 Feb 2025 07:41:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - 8024695: Move getCWD to holder; remove Order from test
>>  - Merge
>>  - 8024695: Extend and clean up test
>>  - 8024695: Fix merge error; improve get*Space tests
>>  - Merge
>>  - 8024695: Add test of length()
>>  - 8024695: Change implementation to work for empty path
>>  - 8024695: new File("").exists() returns false whereas it is the current working directory
>
> test/jdk/java/io/File/EmptyPath.java line 121:
> 
>> 119:             assertTrue(actual > 0);
>> 120:             long ds = Math.abs(expected - actual);
>> 121:             assertTrue((double)ds/expected < 0.05);
> 
> Are you confident that this tolerance is enough? Every test that has checked space available/used has taken a long time to bed in. For this test then I don't think we need to assert any relationship between the allocated and free space, it really just needs to check that it returns some value for the current directory.

I don't recall asserting any relationship between the allocated and free space. Initially I had this simply checking that each returned space value was positive. Do you think that that is enough?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1965886696

From vklang at openjdk.org  Fri Feb 21 17:13:54 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 21 Feb 2025 17:13:54 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
Message-ID: <xXK-JdCtw7G0WpVjqZTwDSdF3i1hVzK50os_knF8p8Q=.7234155d-ec77-4c18-a764-71411b2cc521@github.com>

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 146:

> 144:  * and invoke other {@linkplain ForkJoinTask ForkJoinTasks}. Delayed
> 145:  * actions become <em>enabled</em> and behave as ordinary submitted
> 146:  * tasks when their delays elapse.  schedule methods return

Suggestion:

 * tasks when their delays elapse. Scheduling methods return

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 160:

> 158:  * do not include scheduled tasks that are not yet ready to execute,
> 159:  * whcih are reported separately by method {@link
> 160:  * getDelayedTaskCount}.

Suggestion:

 * which are reported separately by method {@link getDelayedTaskCount}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965895255
PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965896730

From vklang at openjdk.org  Fri Feb 21 17:19:59 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 21 Feb 2025 17:19:59 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
Message-ID: <dIxwveIw4666uGfaxsfLVF22w4HpT5QKi1WQlhNTCrg=.6faa36a1-a03b-4347-b43e-2cddce7175dc@github.com>

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 187:

> 185:  * are used. It is possible to disable use of threads by using a
> 186:  * factory that may return {@code null}, in which case some tasks may
> 187:  * never execute. It is also possible but strongly discouraged to set

Suggestion:

 * never execute. While possible, it is strongly discouraged to set

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965903204

From alanb at openjdk.org  Fri Feb 21 17:20:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Feb 2025 17:20:53 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v7]
In-Reply-To: <xXJzfIqRJfM9ir8AXGFtO9n4ZsEue93dLsvwauFZxaQ=.a13a8a2a-af61-4c41-9567-e0f0ec5309c3@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <BZTFWp9edoLszrHqicbGRyKKANYwmNG8CCmug53YEXs=.7adcdfc7-1df4-44c1-aad9-477afd6ef4bf@github.com>
 <_I2SmeK1d6-aTF-mozF-kNHNX89CNN6ssiiTsUeKvYo=.addb41f3-019a-45af-b4ab-cc7d480485d7@github.com>
 <xXJzfIqRJfM9ir8AXGFtO9n4ZsEue93dLsvwauFZxaQ=.a13a8a2a-af61-4c41-9567-e0f0ec5309c3@github.com>
Message-ID: <WwOCUDZH7fv-9wTK2mHSQ9zobnInTzm19tTbXPYWuWM=.afade94f-ef36-4b4c-8944-43492ff64a42@github.com>

On Fri, 21 Feb 2025 17:03:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/io/File/EmptyPath.java line 121:
>> 
>>> 119:             assertTrue(actual > 0);
>>> 120:             long ds = Math.abs(expected - actual);
>>> 121:             assertTrue((double)ds/expected < 0.05);
>> 
>> Are you confident that this tolerance is enough? Every test that has checked space available/used has taken a long time to bed in. For this test then I don't think we need to assert any relationship between the allocated and free space, it really just needs to check that it returns some value for the current directory.
>
> I don't recall asserting any relationship between the allocated and free space. Initially I had this simply checking that each returned space value was positive. Do you think that that is enough?

My comment is about the tests getTotalSpace/getFreeSpace/getUsableSpace as they check that the results are close to the FIleStore equivalent. My concern is how stable this is with other tests running in other agent VMs as the file usage will change while the test runs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1965900240

From bpb at openjdk.org  Fri Feb 21 17:20:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 21 Feb 2025 17:20:53 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v7]
In-Reply-To: <WwOCUDZH7fv-9wTK2mHSQ9zobnInTzm19tTbXPYWuWM=.afade94f-ef36-4b4c-8944-43492ff64a42@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <BZTFWp9edoLszrHqicbGRyKKANYwmNG8CCmug53YEXs=.7adcdfc7-1df4-44c1-aad9-477afd6ef4bf@github.com>
 <_I2SmeK1d6-aTF-mozF-kNHNX89CNN6ssiiTsUeKvYo=.addb41f3-019a-45af-b4ab-cc7d480485d7@github.com>
 <xXJzfIqRJfM9ir8AXGFtO9n4ZsEue93dLsvwauFZxaQ=.a13a8a2a-af61-4c41-9567-e0f0ec5309c3@github.com>
 <WwOCUDZH7fv-9wTK2mHSQ9zobnInTzm19tTbXPYWuWM=.afade94f-ef36-4b4c-8944-43492ff64a42@github.com>
Message-ID: <sgBjzMRIRQ-b5XbE3eTqC04Zb7PCoyDgbA3y76t_OAQ=.ee799634-f1ef-4a84-9ceb-c163c6097a74@github.com>

On Fri, 21 Feb 2025 17:14:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I don't recall asserting any relationship between the allocated and free space. Initially I had this simply checking that each returned space value was positive. Do you think that that is enough?
>
> My comment is about the tests getTotalSpace/getFreeSpace/getUsableSpace as they check that the results are close to the FIleStore equivalent. My concern is how stable this is with other tests running in other agent VMs as the file usage will change while the test runs.

Understood. Do you think that checking for a positive value is sufficient?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1965902445

From alanb at openjdk.org  Fri Feb 21 17:20:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Feb 2025 17:20:54 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v7]
In-Reply-To: <sgBjzMRIRQ-b5XbE3eTqC04Zb7PCoyDgbA3y76t_OAQ=.ee799634-f1ef-4a84-9ceb-c163c6097a74@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <BZTFWp9edoLszrHqicbGRyKKANYwmNG8CCmug53YEXs=.7adcdfc7-1df4-44c1-aad9-477afd6ef4bf@github.com>
 <_I2SmeK1d6-aTF-mozF-kNHNX89CNN6ssiiTsUeKvYo=.addb41f3-019a-45af-b4ab-cc7d480485d7@github.com>
 <xXJzfIqRJfM9ir8AXGFtO9n4ZsEue93dLsvwauFZxaQ=.a13a8a2a-af61-4c41-9567-e0f0ec5309c3@github.com>
 <WwOCUDZH7fv-9wTK2mHSQ9zobnInTzm19tTbXPYWuWM=.afade94f-ef36-4b4c-8944-43492ff64a42@github.com>
 <sgBjzMRIRQ-b5XbE3eTqC04Zb7PCoyDgbA3y76t_OAQ=.ee799634-f1ef-4a84-9ceb-c163c6097a74@github.com>
Message-ID: <2HHwFvEEv0PxCDbOE_fi0moxRHhBkmfERQMl0Ec0wuU=.d7f42c9e-c821-49ba-b563-58fff4603057@github.com>

On Fri, 21 Feb 2025 17:16:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> My comment is about the tests getTotalSpace/getFreeSpace/getUsableSpace as they check that the results are close to the FIleStore equivalent. My concern is how stable this is with other tests running in other agent VMs as the file usage will change while the test runs.
>
> Understood. Do you think that checking for a positive value is sufficient?

That should be okay here as this test is about empty paths, there are other tests for file space (and as you know, they've been troubleshooting over the years so just trying to avoid extending the noise to this test).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1965905251

From vklang at openjdk.org  Fri Feb 21 17:25:57 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 21 Feb 2025 17:25:57 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
Message-ID: <0kh2k7xJtPVfBtDOm8bGlv5BvHzs5x3u5dqUxjlpa1Y=.4a29c6a5-e7d0-4c72-b739-879f66a9b907@github.com>

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2585:

> 2583:      * throws RejectedExecutionException if shutdown or terminating.
> 2584:      * @param r current ThreadLocalRandom.getProbe() value
> 2585:      * @param rejectOnShutdown true if throw RJE when shutdown

Suggestion:

     * @param rejectOnShutdown true if to throw RejectedExecutionException when shutdown

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965911166

From joehw at openjdk.org  Fri Feb 21 17:27:52 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 21 Feb 2025 17:27:52 GMT
Subject: RFR: 8349959: Test CR6740048.java passes unexpectedly missing
 CR6740048.xsd [v2]
In-Reply-To: <2X5YTyjpXVjeK5ddgSBxOpkcTMODfdUshupcn7Jkwjg=.0162eefd-9b16-440b-8a63-9bf3d8834415@github.com>
References: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>
 <2X5YTyjpXVjeK5ddgSBxOpkcTMODfdUshupcn7Jkwjg=.0162eefd-9b16-440b-8a63-9bf3d8834415@github.com>
Message-ID: <ftqcL4qBAFM5dpqzJXFFynYZ9yPbUBco1FsbEln_fMs=.b3982522-9a46-4c74-a5c5-3fdc8f814dc2@github.com>

On Fri, 21 Feb 2025 01:38:34 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes unexpectedly when missing the depentdent file test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a NULL check after call `getResourceAsStream("CR6740048.xsd")`.
>> 
>> This PR do not change the original test logic but make test more robustness. Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the conditional check that verifies its existence

Thanks.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23627#pullrequestreview-2633771314

From alanb at openjdk.org  Fri Feb 21 17:33:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 21 Feb 2025 17:33:53 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <lCPKGelsDQSXMw44DwMLaYIlY1WPDcVMd83UEBfs1Bs=.8f1ba3bc-2a09-4202-a906-eb5e4e06dbe9@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <pBlDCTMraoOpL-uxkXbFvFpMp71mi4SmGTiwyuWm7wo=.1f349028-d27c-441c-a6bb-b442aaddee54@github.com>
 <lCPKGelsDQSXMw44DwMLaYIlY1WPDcVMd83UEBfs1Bs=.8f1ba3bc-2a09-4202-a906-eb5e4e06dbe9@github.com>
Message-ID: <MgOr9vpLJe5lK-kRi36BsyLd5PogT50bR3Lc9-It47M=.b655d4da-0ad9-4081-9f35-e965d8098db8@github.com>

On Fri, 21 Feb 2025 12:52:10 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3537:
>> 
>>> 3535:      * pool is {@link #shutdownNow}, or is {@link #shutdown} when
>>> 3536:      * otherwise quiescent and {@link #cancelDelayedTasksOnShutdown}
>>> 3537:      * is in effect.
>> 
>> In passing, I'm wondering if we should if the term "enabled" should be defined somewhere. SES uses it but it doesn't appear to define it.
>
> Added: 
>  Delayed actions become <em>enabled</em> and behave as ordinary submitted tasks when their delays elapse.

Thanks. Also here we have ".. after the given delay, At which" so need to smooth that out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965919783

From bpb at openjdk.org  Fri Feb 21 17:38:30 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 21 Feb 2025 17:38:30 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v8]
In-Reply-To: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
Message-ID: <5J1AVvpAM4bzLRDFIcFgCxNcPbHBvh-_-boP7cCvkB4=.089f35d2-70d0-4699-b163-60dc30a46d3f@github.com>

> Modify the implementation of `java.io.File` so that it correctly handles the empty path `""`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8024695: Check only that space is positive

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22821/files
  - new: https://git.openjdk.org/jdk/pull/22821/files/a3b7977e..689480f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22821&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22821&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22821/head:pull/22821

PR: https://git.openjdk.org/jdk/pull/22821

From vklang at openjdk.org  Fri Feb 21 17:41:55 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 21 Feb 2025 17:41:55 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
Message-ID: <6g-1DgWFaIf6NCEijtD143S1N77MYA2s3kzAHg4vohk=.ca29514a-bc90-4355-83fc-ec025f204857@github.com>

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3526:

> 3524:         if (((ds = delayScheduler) == null &&
> 3525:              (ds = startDelayScheduler()) == null) ||
> 3526:             task == null || (runState & SHUTDOWN) != 0L)

Might not make sense to start the delay scheduler if the task is null.

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3534:

> 3532:     /**
> 3533:      * Submits a one-shot task that becomes enabled after the given
> 3534:      * delay, At which point it will execute unless explicitly

Suggestion:

     * delay, at which point it will execute unless explicitly

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3557:

> 3555:         return scheduleDelayedTask(
> 3556:             new ScheduledForkJoinTask<Void>(
> 3557:                 unit.toNanos(delay), 0L, false, command, null, this));

Suggestion:

                unit.toNanos(delay), 0L, false, command, null, this)); // Implicit null-check of unit

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965928320
PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965928717
PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1965929483

From mcimadamore at openjdk.org  Fri Feb 21 18:40:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 18:40:53 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
 <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>
Message-ID: <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>

On Fri, 21 Feb 2025 16:04:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 77:
>> 
>>> 75:         }
>>> 76: 
>>> 77:         @ForceInline
>> 
>> Question: can this and the `offset` method go in the `VarHandleSegmentViewBase` class? They don't seem to depend on anything in these classes - so it seems mostly duplicated code?
>
> Now this will require code update to static import `offset` from `VarHandleSegmentViewBase`. Is that acceptable?

Maybe let's leave it, at least in this round

>> src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java line 164:
>> 
>>> 162:         @ForceInline
>>> 163:         public final VarHandle varHandle() {
>>> 164:             record VarHandleCache() implements Function<AbstractValueLayout<?>, VarHandle> {
>> 
>> Can this cache be removed? The var handles created here should be "direct" -- meaning that we don't expect LayoutPath to add any adaptations on top of what's already done in the "raw" var handle returned by `Utils:makeRawSegmentViewVarHandle`?
>
> We have two caches, one in `ValueLayouts` and another in `Utils`. Should we remove both?

I'm not convinced about the one in ValueLayouts *e.g. where this comment was added) -- if you agree that the other cache should already handle this -- then maybe we can only keep one

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1966002718
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1965999335

From maurizio.cimadamore at oracle.com  Fri Feb 21 18:42:41 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 18:42:41 +0000
Subject: New candidate JEP: 502: Stable Values (Preview)
In-Reply-To: <f3a89c36-3a5d-4dab-b9e7-5a3cc52408dc@dgregory.dev>
References: <4eb86dce-e930-4f1a-a46f-3c142af672c7@oracle.com>
 <f3a89c36-3a5d-4dab-b9e7-5a3cc52408dc@dgregory.dev>
Message-ID: <da1f77a2-fed8-4439-a83d-bc286234e963@oracle.com>

Hi David,
thanks for reaching out -- answser inline below

On 21/02/2025 16:34, David Gregory wrote:
>> While we started working on this for MH/VH-related use cases (for 
>> instance, FFM's jextract will be a big user of stable values), we 
>> also realized that this abstraction is actually quite useful in other 
>> cases too.
>
> This is really exciting! Stable values open the door to some really 
> exciting language features, especially in functional languages.
>
> For example, something similar is used to implement the tail-recursion 
> modulo cons transformation in the OCaml compiler: 
> https://ocaml.org/manual/5.3/tail_mod_cons.html#sec:details
>
> This could enable languages hosted on the JVM to make all kinds of 
> not-quite-tail-recursive programs stack safe without using explicit 
> stacks to store the intermediate values.
>
> Is it possible that the informal rules for record components will be 
> adjusted to allow stable fields in addition to final ones?

There's different meaning for the word "trusted". If, by that, you mean 
that fields of type StableValue<X> should be trusted the same way that 
record components are trusted (e.g. where "final" really means "final"), 
this is something we can do. I believe the prototype we have today does 
that to some extent -- but we don't know yet whether that "hack" will be 
made official :-)

In a way this problem of "trust" is an orthogonal issue -- and it would 
be better to wait for better support for trusting _all_ final fields 
(not just those inside records, or those whose type is StableValue).

Cheers
Maurizio



From liach at openjdk.org  Fri Feb 21 18:56:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 18:56:52 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle
In-Reply-To: <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
 <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>
 <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>
Message-ID: <KksIB9BPE7W3JaDYgUYSspfkMn-KYT9r-a6_VwDcPOY=.5d08fdba-fbb2-4c05-aefc-09d27e4e1b41@github.com>

On Fri, 21 Feb 2025 18:34:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> We have two caches, one in `ValueLayouts` and another in `Utils`. Should we remove both?
>
> I'm not convinced about the one in ValueLayouts *e.g. where this comment was added) -- if you agree that the other cache should already handle this -- then maybe we can only keep one

Indeed, the other cache already handles this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1966022359

From jiangli at openjdk.org  Fri Feb 21 19:04:31 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Feb 2025 19:04:31 GMT
Subject: RFR: 8350041: Make libstringPlatformChars support static JDK [v3]
In-Reply-To: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
Message-ID: <WMCISBl2MCFjkzH-A__7B1agpJqpROWetFcFQ-Dh0OM=.a0a31dd9-c92f-4815-8dcf-3858854245ae@github.com>

> Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 
> 
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
> - Link with `-ldl` explicitly
> 
> The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23646/files
  - new: https://git.openjdk.org/jdk/pull/23646/files/1de95b89..1a51b701

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23646&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23646&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23646/head:pull/23646

PR: https://git.openjdk.org/jdk/pull/23646

From jiangli at openjdk.org  Fri Feb 21 19:07:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 21 Feb 2025 19:07:56 GMT
Subject: RFR: 8350041: Skip
 test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java on static
 JDK
In-Reply-To: <qxmE4GhVi7isIA3WFANbECNuEuTDVX7dVv5L4_4IhEQ=.92cba780-d49c-4769-bd8c-f0e81fcdb920@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
 <9ssLntcEm-TOvy3i4JQLTiYflakzo-Yb9mTbNi3-y0c=.c7addb52-0979-4d1a-a36f-5833289c2c5b@github.com>
 <qxmE4GhVi7isIA3WFANbECNuEuTDVX7dVv5L4_4IhEQ=.92cba780-d49c-4769-bd8c-f0e81fcdb920@github.com>
Message-ID: <0jmPQX54MjO0zkvR3rL6Wu-UgJM5y9k5jp65oMBYlbs=.b9fb1c5d-4bc8-4f1d-a2ee-ce3d7027ad1a@github.com>

On Fri, 21 Feb 2025 06:57:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Updated to skipping `java/lang/String/nativeEncoding/StringPlatformChars.java` on static JDK.
> 
> Thanks. If you can bump the copyright header date then I think we are done with this one.

Done, thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23646#issuecomment-2675329710

From mullan at openjdk.org  Fri Feb 21 19:55:57 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 21 Feb 2025 19:55:57 GMT
Subject: RFR: 8349759: Add unit test for CertificateBuilder and
 SimpleOCSPServer test utilities [v4]
In-Reply-To: <Q9DZtqoZUNaC4R45W5tzFJ4t50Qr-ie-2U2FHrfDrF4=.ce343f24-6cba-4bb0-b502-4bb6a5139d87@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
 <Q9DZtqoZUNaC4R45W5tzFJ4t50Qr-ie-2U2FHrfDrF4=.ce343f24-6cba-4bb0-b502-4bb6a5139d87@github.com>
Message-ID: <S5u6UbVmVFQZTxsyXcXYXqcHKLmrfcN28ZXtn76TLBg=.f71ea310-a4c6-4702-b9a2-51c05976768f@github.com>

On Thu, 20 Feb 2025 01:12:46 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).
>
> Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Add more descriptive summary to test
>  - Merge with main
>  - Remove unnecessary throws declarations
>  - Fix JBS ID and summary in test
>  - 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms

Looks good.

-------------

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23566#pullrequestreview-2634091549

From schernyshev at openjdk.org  Fri Feb 21 19:56:16 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 21 Feb 2025 19:56:16 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v14]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <wA6p1_QAZNYebosD6c32cGb5MisP3UOxLub-gnSo4-w=.12387827-c8ca-4c09-be08-370f1d758c7c@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  fix the tests to address the review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/8e8ab869..28122ff9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=12-13

  Stats: 27 lines in 2 files changed: 5 ins; 6 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From schernyshev at openjdk.org  Fri Feb 21 19:56:17 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 21 Feb 2025 19:56:17 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
Message-ID: <Q-hAI75CokWDYr2bdgBE5Ud-9xdFBMs57eRqYkASvcE=.2c9fd89a-1a24-4b0a-93e4-6c7f5e40414e@github.com>

On Mon, 17 Feb 2025 11:28:38 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added details in the log message
>
> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 60:
> 
>> 58: 
>> 59:             Common.prepareWhiteBox();
>> 60:             DockerTestUtils.buildJdkContainerImage(imageName);
> 
> This can be moved out of the condition. It's there in both cases.

Done

> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 85:
> 
>> 83:         } else {
>> 84:             System.out.println("Metrics are from neither cgroup v1 nor v2, skipped for now.");
>> 85:         }
> 
> Suggestion:
> 
>         throw new RuntimeException("cgroup version not known? was: " + metrics.getProvider());

I made it with `jtreg.SkippedException`

> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 98:
> 
>> 96:         opts.addDockerOpts("--privileged")
>> 97:             .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host"))
>> 98:             .addDockerOpts("--memory", "1g");
> 
> Please extract this "larger" memory limit out of this function. The expectation is to have:
> 
> 
> Container memory limit => X
> Some lower limit in a moved path => Y
> 
> Expect that the lower limit of Y is being detected.
> 
> 
> For example:
> 
> 
> testMemoryLimitSubgroupV1("1g", "100m", "104857600", false);

done.

> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 118:
> 
>> 116:         opts.addDockerOpts("--privileged")
>> 117:             .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host"))
>> 118:             .addDockerOpts("--memory", "1g");
> 
> Same here with the `1g` container memory limit. Move it to a parameter.

done. extracted the parameter.

> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 72:
> 
>> 70:         } else {
>> 71:             System.out.println("Metrics are from neither cgroup v1 nor v2, skipped for now.");
>> 72:         }
> 
> Please `throw` here.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966094564
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966094301
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966093295
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966092984
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966092288

From bpb at openjdk.org  Fri Feb 21 20:03:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 21 Feb 2025 20:03:55 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v9]
In-Reply-To: <NwTJelNPGLUFAP_qE7hQu_xs2aNfwcKvOj2ORS-ZKMw=.9e7c8874-ae1a-464a-bbfa-201c9d218656@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <NwTJelNPGLUFAP_qE7hQu_xs2aNfwcKvOj2ORS-ZKMw=.9e7c8874-ae1a-464a-bbfa-201c9d218656@github.com>
Message-ID: <dJE1E8NjYMI7DJPXs7hcMuTiUDCcWoiLm2phCNzG05U=.79c29011-36fd-4ecb-9058-3418d8cd1e27@github.com>

On Fri, 21 Feb 2025 19:00:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify the implementation of `java.io.File` so that it correctly handles the empty path `""`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8024695: Add sentence to clarify empty File behavior

I have updated the CSR to match this PR as of commit 473ccae.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22821#issuecomment-2675433839

From schernyshev at openjdk.org  Fri Feb 21 20:07:58 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 21 Feb 2025 20:07:58 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <OObfj4QWk_Q3Fk2-mDJbpfeFNhOAbgEmDB-IBehjR4c=.672abfeb-fc3f-4c68-ad0d-693ac0eb7bcd@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
 <OObfj4QWk_Q3Fk2-mDJbpfeFNhOAbgEmDB-IBehjR4c=.672abfeb-fc3f-4c68-ad0d-693ac0eb7bcd@github.com>
Message-ID: <E4B7c1WLUyhHGmEaox71qVNbypKMw_Hdo1dKU_RQcMY=.db21dfe9-e676-4ac6-b954-19bc40b64268@github.com>

On Thu, 20 Feb 2025 17:32:54 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 73:
>> 
>>> 71:                                 break;
>>> 72:                             }
>>> 73:                             cgp = (cgp.getNameCount() > 1) ? cgp.subpath(1, cgp.getNameCount()) : Path.of("");
>> 
>> Suggestion:
>> 
>>                             cgp = (nameCount > 1) ? cgp.subpath(1, nameCount) : Path.of("");
>
> Good catch, but as long as cgp#nameCount may change in the loop, this exact patch i cannot take.

How about this?

int currentNameCount = cgp.getNameCount();
cgp = (currentNameCount > 1) ? cgp.subpath(1, currentNameCount) : Path.of("");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966107031

From liach at openjdk.org  Fri Feb 21 20:14:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 20:14:19 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Review remarks, dates, some more simplifications

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23720/files
  - new: https://git.openjdk.org/jdk/pull/23720/files/02c6faa1..c4af6ebf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=00-01

  Stats: 427 lines in 13 files changed: 136 ins; 113 del; 178 mod
  Patch: https://git.openjdk.org/jdk/pull/23720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23720/head:pull/23720

PR: https://git.openjdk.org/jdk/pull/23720

From liach at openjdk.org  Fri Feb 21 20:19:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 20:19:52 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <RW0eXeCodO55Qy8C5HLrB-kCp8jlqfVRFo6ELAO3OTs=.c85c04d1-4792-4bb0-aad3-f8a8c3be4695@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
 <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
 <RW0eXeCodO55Qy8C5HLrB-kCp8jlqfVRFo6ELAO3OTs=.c85c04d1-4792-4bb0-aad3-f8a8c3be4695@github.com>
Message-ID: <a6GcFgRP6Mmghgl8tuOWhXNwtSSN1999BDg8SH2nyFg=.74bd0ae7-1d27-4b6a-a798-1eafbc9977c2@github.com>

On Fri, 21 Feb 2025 14:43:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I have disabled them with #, and the status is confirmed by test for access modes. I kept the infra to make future reenabling easy.
>
>> I have disabled them with #, and the status is confirmed by test for access modes. I kept the infra to make future reenabling easy.
> 
> Doh - I missed the `#` -- maybe add few more to make that more explicit? (I agree with the approach)

Left a space and an extra note to make the comment hash more obvious.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1966119784

From jnimeh at openjdk.org  Fri Feb 21 20:32:58 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 21 Feb 2025 20:32:58 GMT
Subject: Integrated: 8349759: Add unit test for CertificateBuilder and
 SimpleOCSPServer test utilities
In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com>
Message-ID: <k77X72wTjBMxim4nFlacpUft349F9jgW408mKmD7zyc=.464c3e1b-c993-46cd-9b8c-0be6ccec63ca@github.com>

On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes.  They would break when ML-DSA was selected as key and signing algorithms.  Also RSASSA-PSS works better now with these changes.  I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature).

This pull request has now been integrated.

Changeset: 9d9d7a17
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d9d7a17d3d1a8971712ef1b22e919012350db6f
Stats:     329 lines in 3 files changed: 270 ins; 21 del; 38 mod

8349759: Add unit test for CertificateBuilder and SimpleOCSPServer test utilities

Reviewed-by: mullan

-------------

PR: https://git.openjdk.org/jdk/pull/23566

From dlong at openjdk.org  Fri Feb 21 21:10:58 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 21 Feb 2025 21:10:58 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v5]
In-Reply-To: <VyoHvDMpugJg1-XWZE_gKFwBkWc-7of8qIfdcuDB2jE=.b0d9bdb7-7480-4ae1-afec-e48cbf94c188@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>
 <beP3eW57na8hjpPFM27Zbhg3i4iZm_htJAhn7LZiwHg=.876cec03-2f47-468c-8197-fa59e590e435@github.com>
 <3jNPEzaXa0Ncf8eu3vct6a_jyH7k4tH_mbRBaKmbMc0=.d3a86a0f-1bed-4084-af92-959f4dbd52f4@github.com>
 <VyoHvDMpugJg1-XWZE_gKFwBkWc-7of8qIfdcuDB2jE=.b0d9bdb7-7480-4ae1-afec-e48cbf94c188@github.com>
Message-ID: <LrjguT4-f7V_Wotxu2zb87fAUEoCtFnuPqr442jiEpc=.0bb754fa-51ce-479d-b1de-fbea5f9f2017@github.com>

On Fri, 21 Feb 2025 14:01:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I don't use the field directly because the field is a short and getModifiers makes it into Modifier.
>
> Indeed, even though this checks for the specific bit so widening has no effect, it is better to be cautious here.

> I don't use the field directly because the field is a short and getModifiers makes it into Modifier.

But getModifiers() returns `int`, not `Modifier` (which is all static).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1966170358

From mcimadamore at openjdk.org  Fri Feb 21 22:15:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 21 Feb 2025 22:15:54 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <7WL6BoPaoO9F7HqJfaLFqskMQLhzp_NdTBRzcApkR_0=.c47ece0a-ec3d-48c7-994f-d73a0208f5fa@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 120:

> 118:      * with a {@link ValueLayout#varHandle()} call is cached inside a stable field of the value layout implementation.
> 119:      * This optimizes common code idioms like {@code JAVA_INT.varHandle().getInt(...)}. A second layer of caching
> 120:      * is then provided by this method, so different value layouts with same effects can reuse var handle instances.

I believe this comment is now out of sync? (It talks about two levels of caching --- but there's only one now)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1966264372

From liach at openjdk.org  Fri Feb 21 22:15:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 22:15:54 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <7WL6BoPaoO9F7HqJfaLFqskMQLhzp_NdTBRzcApkR_0=.c47ece0a-ec3d-48c7-994f-d73a0208f5fa@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <7WL6BoPaoO9F7HqJfaLFqskMQLhzp_NdTBRzcApkR_0=.c47ece0a-ec3d-48c7-994f-d73a0208f5fa@github.com>
Message-ID: <5YIov6L2WD1Strf0NJMZpOl4ouicJ8JhzVY3-gW16Is=.7acd9289-897b-4dec-91a9-d17989ee91dd@github.com>

On Fri, 21 Feb 2025 22:11:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 120:
> 
>> 118:      * with a {@link ValueLayout#varHandle()} call is cached inside a stable field of the value layout implementation.
>> 119:      * This optimizes common code idioms like {@code JAVA_INT.varHandle().getInt(...)}. A second layer of caching
>> 120:      * is then provided by this method, so different value layouts with same effects can reuse var handle instances.
> 
> I believe this comment is now out of sync? (It talks about two levels of caching --- but there's only one now)

The first level is right, it is the instance field AbstractValueLayout.handle. The static final CHM over there was not mentioned and is now removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1966265626

From liach at openjdk.org  Fri Feb 21 22:21:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 22:21:53 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <3yhXZNAbPb_sRC_CXmKGzUNsvhl1rOfIvtdGfUCsvq4=.66ca9688-2bf1-4eec-9a38-c499a8390fcc@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

Benchmark results for the latest revision appears performance neutral. bytestacks same as last revision. 11 jobs left in tier 1-3, no failure so far. Also created CSR for this minor behavioral change.

Benchmark                                                (polluteProfile)  Mode  Cnt  Score   Error  Units
LoopOverNonConstantHeap.BB_get                                      false  avgt   30  0.934 ? 0.027  ns/op
LoopOverNonConstantHeap.BB_get                                       true  avgt   30  0.946 ? 0.028  ns/op
LoopOverNonConstantHeap.BB_loop                                     false  avgt   30  0.208 ? 0.004  ms/op
LoopOverNonConstantHeap.BB_loop                                      true  avgt   30  0.211 ? 0.003  ms/op
LoopOverNonConstantHeap.segment_get                                 false  avgt   30  1.123 ? 0.040  ns/op
LoopOverNonConstantHeap.segment_get                                  true  avgt   30  1.120 ? 0.040  ns/op
LoopOverNonConstantHeap.segment_loop                                false  avgt   30  0.205 ? 0.004  ms/op
LoopOverNonConstantHeap.segment_loop                                 true  avgt   30  0.202 ? 0.003  ms/op
LoopOverNonConstantHeap.segment_loop_instance                       false  avgt   30  0.209 ? 0.005  ms/op
LoopOverNonConstantHeap.segment_loop_instance                        true  avgt   30  0.202 ? 0.003  ms/op
LoopOverNonConstantHeap.segment_loop_instance_unaligned             false  avgt   30  0.209 ? 0.004  ms/op
LoopOverNonConstantHeap.segment_loop_instance_unaligned              true  avgt   30  0.210 ? 0.004  ms/op
LoopOverNonConstantHeap.segment_loop_readonly                       false  avgt   30  0.206 ? 0.004  ms/op
LoopOverNonConstantHeap.segment_loop_readonly                        true  avgt   30  0.206 ? 0.005  ms/op
LoopOverNonConstantHeap.segment_loop_slice                          false  avgt   30  0.203 ? 0.002  ms/op
LoopOverNonConstantHeap.segment_loop_slice                           true  avgt   30  0.207 ? 0.004  ms/op
LoopOverNonConstantHeap.segment_loop_unaligned                      false  avgt   30  0.206 ? 0.004  ms/op
LoopOverNonConstantHeap.segment_loop_unaligned                       true  avgt   30  0.209 ? 0.003  ms/op
LoopOverNonConstantHeap.unsafe_get                                  false  avgt   30  0.386 ? 0.017  ns/op
LoopOverNonConstantHeap.unsafe_get                                   true  avgt   30  0.381 ? 0.017  ns/op
LoopOverNonConstantHeap.unsafe_loop                                 false  avgt   30  0.205 ? 0.004  ms/op
LoopOverNonConstantHeap.unsafe_loop                                  true  avgt   30  0.204 ? 0.004  ms/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2675734830

From jperkins at redhat.com  Fri Feb 21 22:57:27 2025
From: jperkins at redhat.com (James Perkins)
Date: Fri, 21 Feb 2025 14:57:27 -0800
Subject: Integrated: 8344011: Remove usage of security manager from Class
 and reflective APIs
In-Reply-To: <e0f863fc-c0c2-4d95-9e63-c2b0c9f4ad0d@oracle.com>
References: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
 <aTe0NwDudHsBnKTUSomoER8v8m_5tLkBM2UVH5ru63k=.ae2f2a37-726b-4096-bfde-0f6506dd712b@github.com>
 <CADGwLpjuD=2xy=LfbOFaxcQ4NRtN+x9Ma2U_5-O5g5UVT7+84g@mail.gmail.com>
 <e0f863fc-c0c2-4d95-9e63-c2b0c9f4ad0d@oracle.com>
Message-ID: <CADGwLpiCxwGwRtdSyxojC7bw+j2OhpjsC+YTW+eB=EjCcTZT9A@mail.gmail.com>

Perfect. Thank you so much Alan.


James R. Perkins

Principal Software Engineer

Red Hat <https://www.redhat.com/>
<https://www.redhat.com/>


On Thu, Feb 20, 2025 at 10:44?PM Alan Bateman <alan.bateman at oracle.com>
wrote:

> On 21/02/2025 01:08, James Perkins wrote:
> > Please forgive me if this is the wrong medium to report this.
> >
> > I've found an issue with the change in the ServiceLoader.
> > Specifically, the getConstructor()[1] method. Previously, the method
> > caught Throwable and then fail which would throw a
> > java.util.ServiceConfigurationError exception. With the changes, only
> > a catches a NoSuchMethodException and throws a
> > ServiceConfigurationError then. Is this change in behavior expected?
> >
> > For some background on how I found this. I had a legitimate classpath
> > issue missing a CDI dependency. However, the constructor was throwing
> > a NoClassDefFoundException because of the missing required class. In
> > versions less than Java 24 this was okay because Throwable was caught.
> > In Java 24 and 25 early access, this is an issue because the
> > NoClassDefFoundException is thrown instead of it being wrapped in a
> > ServiceConfigurationError.
> >
> Thanks for the bug report. Yes, this is a change in behavior that was
> not intended, and a reminder that there aren't enough tests for NCDFE
> and other linkage errors. Note that there are other cases, that date
> back to JDK 6, where linkage errors aren't wrapped so is other work to
> do in this area. I've created JDK-8350481 to track the behavior change.
>
> -Alan
>
> [1] https://bugs.openjdk.org/browse/JDK-8350481
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250221/12e4fa77/attachment.htm>

From asemenyuk at openjdk.org  Sat Feb 22 00:25:31 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 22 Feb 2025 00:25:31 GMT
Subject: RFR: 8326447: jpackage creates Windows installers that cannot be
 signed
Message-ID: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>

Support the use of a custom msi wrapper executable when building an exe installer.

Put `installer.exe` file in the resource directory and jpackage will use it instead of the default `msiwrapper.exe` resource for exe installer.

To test this feature created a test that builds exe installer with a custom icon. The result installer exe is used as a custom msi wrapper executable in the second jpackage command that builds exe installer with the default icon. The installer exe produced by the second jackage command should have the same icon as the exe installer created in the first jpackage run.

Moved code verifying icons in executables from `LauncherIconVerifier.WinIconVerifier` class into `WinExecutableIconVerifier` class to make it available for tests. Replaced inline powershell script extracting icons from executables with standalone `read-executable-icon.ps1` powershell script. The script uses `ExtractIcon` instead of `ExtractAssociatedIcon`. It extracts icon from the executable's resources and will not fall back to anything if there is no icon resource.

-------------

Commit messages:
 - Fix modifier order
 - Update copyright year
 - 8326447: jpackage creates Windows installers that cannot be signed

Changes: https://git.openjdk.org/jdk/pull/23732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23732&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326447
  Stats: 652 lines in 7 files changed: 453 ins; 193 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23732/head:pull/23732

PR: https://git.openjdk.org/jdk/pull/23732

From asemenyuk at openjdk.org  Sat Feb 22 01:05:45 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 22 Feb 2025 01:05:45 GMT
Subject: RFR: 8326447: jpackage creates Windows installers that cannot be
 signed [v2]
In-Reply-To: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
References: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
Message-ID: <MSL093tHmx2AjlYAg4AX9c5ZDb4Ib10naqD1CEOp8fQ=.c310c5eb-7b3d-4e15-868f-1a97007227d4@github.com>

> Support the use of a custom msi wrapper executable when building an exe installer.
> 
> Put `installer.exe` file in the resource directory and jpackage will use it instead of the default `msiwrapper.exe` resource for exe installer.
> 
> To test this feature created a test that builds exe installer with a custom icon. The result installer exe is used as a custom msi wrapper executable in the second jpackage command that builds exe installer with the default icon. The installer exe produced by the second jackage command should have the same icon as the exe installer created in the first jpackage run.
> 
> Moved code verifying icons in executables from `LauncherIconVerifier.WinIconVerifier` class into `WinExecutableIconVerifier` class to make it available for tests. Replaced inline powershell script extracting icons from executables with standalone `read-executable-icon.ps1` powershell script. The script uses `ExtractIcon` instead of `ExtractAssociatedIcon`. It extracts icon from the executable's resources and will not fall back to anything if there is no icon resource.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Use ExtractIconEx() WinAPI to extract icons from executables, as it doesn't rely on GetLastError() to deliver error information to the caller. GetLastError() is not reliable in managed code.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23732/files
  - new: https://git.openjdk.org/jdk/pull/23732/files/32a8a696..31ebde0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23732&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23732&range=00-01

  Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23732/head:pull/23732

PR: https://git.openjdk.org/jdk/pull/23732

From asemenyuk at openjdk.org  Sat Feb 22 01:19:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 22 Feb 2025 01:19:57 GMT
Subject: RFR: 8326447: jpackage creates Windows installers that cannot be
 signed [v2]
In-Reply-To: <MSL093tHmx2AjlYAg4AX9c5ZDb4Ib10naqD1CEOp8fQ=.c310c5eb-7b3d-4e15-868f-1a97007227d4@github.com>
References: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
 <MSL093tHmx2AjlYAg4AX9c5ZDb4Ib10naqD1CEOp8fQ=.c310c5eb-7b3d-4e15-868f-1a97007227d4@github.com>
Message-ID: <7g433SN6ZMgesqKedNM946oqBJFHcvqmklVcDTaWpA8=.fd0d2c72-18b5-4362-97cb-619b6e86e646@github.com>

On Sat, 22 Feb 2025 01:05:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Support the use of a custom msi wrapper executable when building an exe installer.
>> 
>> Put `installer.exe` file in the resource directory and jpackage will use it instead of the default `msiwrapper.exe` resource for exe installer.
>> 
>> To test this feature created a test that builds exe installer with a custom icon. The result installer exe is used as a custom msi wrapper executable in the second jpackage command that builds exe installer with the default icon. The installer exe produced by the second jackage command should have the same icon as the exe installer created in the first jpackage run.
>> 
>> Moved code verifying icons in executables from `LauncherIconVerifier.WinIconVerifier` class into `WinExecutableIconVerifier` class to make it available for tests. Replaced inline powershell script extracting icons from executables with standalone `read-executable-icon.ps1` powershell script. The script uses `ExtractIcon` instead of `ExtractAssociatedIcon`. It extracts icon from the executable's resources and will not fall back to anything if there is no icon resource.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ExtractIconEx() WinAPI to extract icons from executables, as it doesn't rely on GetLastError() to deliver error information to the caller. GetLastError() is not reliable in managed code.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23732#issuecomment-2675911301

From almatvee at openjdk.org  Sat Feb 22 02:19:58 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 22 Feb 2025 02:19:58 GMT
Subject: RFR: 8326447: jpackage creates Windows installers that cannot be
 signed [v2]
In-Reply-To: <MSL093tHmx2AjlYAg4AX9c5ZDb4Ib10naqD1CEOp8fQ=.c310c5eb-7b3d-4e15-868f-1a97007227d4@github.com>
References: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
 <MSL093tHmx2AjlYAg4AX9c5ZDb4Ib10naqD1CEOp8fQ=.c310c5eb-7b3d-4e15-868f-1a97007227d4@github.com>
Message-ID: <81fTLCm_fBu0AetaL9k0z6XiWdQYYwBxD1mhf1YbU04=.c4c15742-d895-4c9f-8a2b-338fbb88200a@github.com>

On Sat, 22 Feb 2025 01:05:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Support the use of a custom msi wrapper executable when building an exe installer.
>> 
>> Put `installer.exe` file in the resource directory and jpackage will use it instead of the default `msiwrapper.exe` resource for exe installer.
>> 
>> To test this feature created a test that builds exe installer with a custom icon. The result installer exe is used as a custom msi wrapper executable in the second jpackage command that builds exe installer with the default icon. The installer exe produced by the second jackage command should have the same icon as the exe installer created in the first jpackage run.
>> 
>> Moved code verifying icons in executables from `LauncherIconVerifier.WinIconVerifier` class into `WinExecutableIconVerifier` class to make it available for tests. Replaced inline powershell script extracting icons from executables with standalone `read-executable-icon.ps1` powershell script. The script uses `ExtractIcon` instead of `ExtractAssociatedIcon`. It extracts icon from the executable's resources and will not fall back to anything if there is no icon resource.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ExtractIconEx() WinAPI to extract icons from executables, as it doesn't rely on GetLastError() to deliver error information to the caller. GetLastError() is not reliable in managed code.

How user should figure out what `installer.exe` suppose to do? Should user just take it from another JDK which works? It does not look like a solution to this issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23732#issuecomment-2675947409

From almatvee at openjdk.org  Sat Feb 22 02:23:51 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 22 Feb 2025 02:23:51 GMT
Subject: RFR: 8326447: jpackage creates Windows installers that cannot be
 signed [v2]
In-Reply-To: <MSL093tHmx2AjlYAg4AX9c5ZDb4Ib10naqD1CEOp8fQ=.c310c5eb-7b3d-4e15-868f-1a97007227d4@github.com>
References: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
 <MSL093tHmx2AjlYAg4AX9c5ZDb4Ib10naqD1CEOp8fQ=.c310c5eb-7b3d-4e15-868f-1a97007227d4@github.com>
Message-ID: <cOuAPAnzi5bg4m8GZmQJWhHHAe9tAObr6kH_Y0oIt1Q=.941bb392-c9ef-4a2c-ae29-384645105a4f@github.com>

On Sat, 22 Feb 2025 01:05:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Support the use of a custom msi wrapper executable when building an exe installer.
>> 
>> Put `installer.exe` file in the resource directory and jpackage will use it instead of the default `msiwrapper.exe` resource for exe installer.
>> 
>> To test this feature created a test that builds exe installer with a custom icon. The result installer exe is used as a custom msi wrapper executable in the second jpackage command that builds exe installer with the default icon. The installer exe produced by the second jackage command should have the same icon as the exe installer created in the first jpackage run.
>> 
>> Moved code verifying icons in executables from `LauncherIconVerifier.WinIconVerifier` class into `WinExecutableIconVerifier` class to make it available for tests. Replaced inline powershell script extracting icons from executables with standalone `read-executable-icon.ps1` powershell script. The script uses `ExtractIcon` instead of `ExtractAssociatedIcon`. It extracts icon from the executable's resources and will not fall back to anything if there is no icon resource.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ExtractIconEx() WinAPI to extract icons from executables, as it doesn't rely on GetLastError() to deliver error information to the caller. GetLastError() is not reliable in managed code.

Can we add test which will use `SignTool` to sign produced .exe installer? This test can be similar to our macOS signing tests which require additional system configuration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23732#issuecomment-2675948907

From asemenyuk at openjdk.org  Sat Feb 22 02:35:53 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 22 Feb 2025 02:35:53 GMT
Subject: RFR: 8326447: jpackage creates Windows installers that cannot be
 signed [v2]
In-Reply-To: <81fTLCm_fBu0AetaL9k0z6XiWdQYYwBxD1mhf1YbU04=.c4c15742-d895-4c9f-8a2b-338fbb88200a@github.com>
References: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
 <MSL093tHmx2AjlYAg4AX9c5ZDb4Ib10naqD1CEOp8fQ=.c310c5eb-7b3d-4e15-868f-1a97007227d4@github.com>
 <81fTLCm_fBu0AetaL9k0z6XiWdQYYwBxD1mhf1YbU04=.c4c15742-d895-4c9f-8a2b-338fbb88200a@github.com>
Message-ID: <6WV36Wql8_nh-2P3EDVJx6VfoWx-YhnHFS141AKei-A=.fe85363a-5fb7-4180-b6ef-ea8ae78eac05@github.com>

On Sat, 22 Feb 2025 02:17:32 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Should user just take it from another JDK which works?

Yes

>  It does not look like a solution to this issue.

Do you have a better idea?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23732#issuecomment-2675954065

From asemenyuk at openjdk.org  Sat Feb 22 02:39:01 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 22 Feb 2025 02:39:01 GMT
Subject: RFR: 8326447: jpackage creates Windows installers that cannot be
 signed [v2]
In-Reply-To: <cOuAPAnzi5bg4m8GZmQJWhHHAe9tAObr6kH_Y0oIt1Q=.941bb392-c9ef-4a2c-ae29-384645105a4f@github.com>
References: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
 <MSL093tHmx2AjlYAg4AX9c5ZDb4Ib10naqD1CEOp8fQ=.c310c5eb-7b3d-4e15-868f-1a97007227d4@github.com>
 <cOuAPAnzi5bg4m8GZmQJWhHHAe9tAObr6kH_Y0oIt1Q=.941bb392-c9ef-4a2c-ae29-384645105a4f@github.com>
Message-ID: <MgJUnWgzNNfnHUgt71hNNqkACHtZ1LFsNT7fKJDzcGM=.581666d3-c4eb-4378-9e04-e6e1cacca3b3@github.com>

On Sat, 22 Feb 2025 02:21:14 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Can we add test which will use SignTool to sign produced .exe installer?

What would be the action if the test fails?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23732#issuecomment-2675957416

From syan at openjdk.org  Sat Feb 22 03:13:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Feb 2025 03:13:56 GMT
Subject: RFR: 8349959: Test CR6740048.java passes unexpectedly missing
 CR6740048.xsd
In-Reply-To: <XsTwcaRhAtNHvnfUgqmqvxo0s9HcE6zU4u8Z_LFJO5M=.4a89cb53-e88a-4aac-86d7-8249f7f7ea94@github.com>
References: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>
 <XsTwcaRhAtNHvnfUgqmqvxo0s9HcE6zU4u8Z_LFJO5M=.4a89cb53-e88a-4aac-86d7-8249f7f7ea94@github.com>
Message-ID: <l4YMWtK1bMQEQJUWWxOywtwEZh0tRWtnSQbiETcULqg=.7aa462d1-9c5c-4785-9f88-07d119366ca7@github.com>

On Thu, 20 Feb 2025 17:32:06 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Hi all,
>> 
>> Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes unexpectedly when missing the depentdent file test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a NULL check after call `getResourceAsStream("CR6740048.xsd")`.
>> 
>> This PR do not change the original test logic but make test more robustness. Change has been verified locally, test-fix only, no risk.
>
> Yes, that would do.

Thanks @JoeWang-Java for the suggestion and review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23627#issuecomment-2675975261

From syan at openjdk.org  Sat Feb 22 03:13:57 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 22 Feb 2025 03:13:57 GMT
Subject: Integrated: 8349959: Test CR6740048.java passes unexpectedly missing
 CR6740048.xsd
In-Reply-To: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>
References: <RHkoaFCZ6SJmpVOTXa0W1Olrj-mvuk2YnRFqAYY4o-k=.a946eb1a-1425-438c-8478-2039199bbc28@github.com>
Message-ID: <9G92IwOpITO0_7_IndjiwIxRO2AhHhjkPIam6TVCvWo=.f4e35b97-da41-4efb-b097-b2a2a8713ea0@github.com>

On Fri, 14 Feb 2025 07:44:26 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes unexpectedly when missing the depentdent file test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a NULL check after call `getResourceAsStream("CR6740048.xsd")`.
> 
> This PR do not change the original test logic but make test more robustness. Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: 5cbd9d1f
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cbd9d1fe19b6d9516233cd1ed8d3ba340b7a1e6
Stats:     6 lines in 1 file changed: 0 ins; 2 del; 4 mod

8349959: Test CR6740048.java passes unexpectedly missing CR6740048.xsd

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/23627

From almatvee at openjdk.org  Sat Feb 22 04:12:54 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 22 Feb 2025 04:12:54 GMT
Subject: RFR: 8326447: jpackage creates Windows installers that cannot be
 signed [v2]
In-Reply-To: <6WV36Wql8_nh-2P3EDVJx6VfoWx-YhnHFS141AKei-A=.fe85363a-5fb7-4180-b6ef-ea8ae78eac05@github.com>
References: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
 <MSL093tHmx2AjlYAg4AX9c5ZDb4Ib10naqD1CEOp8fQ=.c310c5eb-7b3d-4e15-868f-1a97007227d4@github.com>
 <81fTLCm_fBu0AetaL9k0z6XiWdQYYwBxD1mhf1YbU04=.c4c15742-d895-4c9f-8a2b-338fbb88200a@github.com>
 <6WV36Wql8_nh-2P3EDVJx6VfoWx-YhnHFS141AKei-A=.fe85363a-5fb7-4180-b6ef-ea8ae78eac05@github.com>
Message-ID: <e_Eqn9z5b_fBVreu0D4MFpNd68VUij-yB_lZcUQHyK8=.c71152e3-9643-4ea6-ac0a-7ec2e02f3fda@github.com>

On Sat, 22 Feb 2025 02:32:29 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Do you have a better idea?

Can we sign `msiwrapper.exe` which does not have any embedded msi? `jmod.exe` can be used to extract it from `resources`. If it works maybe bug in our embed code. If it does not work do we know when it was introduced and figure out root cause?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23732#issuecomment-2675998971

From asemenyuk at openjdk.org  Sat Feb 22 05:39:58 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 22 Feb 2025 05:39:58 GMT
Subject: RFR: 8326447: jpackage creates Windows installers that cannot be
 signed [v2]
In-Reply-To: <e_Eqn9z5b_fBVreu0D4MFpNd68VUij-yB_lZcUQHyK8=.c71152e3-9643-4ea6-ac0a-7ec2e02f3fda@github.com>
References: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
 <MSL093tHmx2AjlYAg4AX9c5ZDb4Ib10naqD1CEOp8fQ=.c310c5eb-7b3d-4e15-868f-1a97007227d4@github.com>
 <81fTLCm_fBu0AetaL9k0z6XiWdQYYwBxD1mhf1YbU04=.c4c15742-d895-4c9f-8a2b-338fbb88200a@github.com>
 <6WV36Wql8_nh-2P3EDVJx6VfoWx-YhnHFS141AKei-A=.fe85363a-5fb7-4180-b6ef-ea8ae78eac05@github.com>
 <e_Eqn9z5b_fBVreu0D4MFpNd68VUij-yB_lZcUQHyK8=.c71152e3-9643-4ea6-ac0a-7ec2e02f3fda@github.com>
Message-ID: <w7ik-RZa4xAQdj2blTUXiHW3rmo6M8l1Vu5yy76DJrg=.388eaa3c-b83c-4cc8-badd-982719268122@github.com>

On Sat, 22 Feb 2025 04:10:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> maybe bug in our embed code

The code has been the same since the first release of jpackage.

> do we know when it was introduced and figure out root cause

Quote from the bug description:

> JDK 21.0.2 (Temurin)
>
> A DESCRIPTION OF THE PROBLEM :
> I have recently upgraded from Java 18 to Java 21, and noticed that there has been a change in jpackage which is causing signtool (the Microsoft code signing tool) to fail when signing the installer. Even though the installer .exe can be run on the system, the signtool command fails with:
> 
> SignTool Error: SignedCode::Sign returned error: 0x800700C1
> 
> This rather cryptic message refers to ERROR_BAD_EXE_FORMAT. Note that the same build run with Java 18 produces an .exe installer which does not have this problem.
> 
> If I compare the .exe produced by Java 21 with that produced by Java 18 with dumpfile and pestudio, I notice two differences:
> 
> 1. There is a 'version' section containing application name and version information in the Java 18 installer which is no longer present
> 2. The linker version has changed from 1.27 to 1.37

Maybe something is off with the toolchain used to assemble Temurin JDK 21.

I used pestudio to inspect the value of the linker's version in PE headers of Open JDK binaries from Oracle. A few releases I inspected have something like "Microsoft Linker 14.36".
I did the same for `msiwrapper.exe` from Temurin JDK21 (OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip). The linker version is "Microsoft Linker 14.37". For Temurin JDK18 (OpenJDK18U-jdk_x64_windows_hotspot_18.0.2.1_1.zip) the linker version is "Microsoft Linker 14.27".

> 2. The linker version has changed from 1.27 to 1.37

Maybe the submitter meant the linker version changed from 14.27 to 14.37?

Anyway, they didn't complain about the Oracle variant of OpenJDK. If this is linker version-specific issue SignTool test may pass with Oracle OpenJDK and fail with other variants built with different toolchains.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23732#issuecomment-2676030459

From alanb at openjdk.org  Sat Feb 22 07:35:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 22 Feb 2025 07:35:52 GMT
Subject: RFR: 8350041: Skip
 test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java on static
 JDK [v3]
In-Reply-To: <WMCISBl2MCFjkzH-A__7B1agpJqpROWetFcFQ-Dh0OM=.a0a31dd9-c92f-4815-8dcf-3858854245ae@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
 <WMCISBl2MCFjkzH-A__7B1agpJqpROWetFcFQ-Dh0OM=.a0a31dd9-c92f-4815-8dcf-3858854245ae@github.com>
Message-ID: <FPczF-3BT_PgnN8d-d7hR-OgeI8NGS9OzBzAYIm5FqU=.d05c9ef2-bb35-403d-8eff-06ae0b47dbd1@github.com>

On Fri, 21 Feb 2025 19:04:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 
>> 
>> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
>> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
>> - Link with `-ldl` explicitly
>> 
>> The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23646#pullrequestreview-2634741045

From dl at openjdk.org  Sat Feb 22 11:53:54 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 22 Feb 2025 11:53:54 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <MgOr9vpLJe5lK-kRi36BsyLd5PogT50bR3Lc9-It47M=.b655d4da-0ad9-4081-9f35-e965d8098db8@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <pBlDCTMraoOpL-uxkXbFvFpMp71mi4SmGTiwyuWm7wo=.1f349028-d27c-441c-a6bb-b442aaddee54@github.com>
 <lCPKGelsDQSXMw44DwMLaYIlY1WPDcVMd83UEBfs1Bs=.8f1ba3bc-2a09-4202-a906-eb5e4e06dbe9@github.com>
 <MgOr9vpLJe5lK-kRi36BsyLd5PogT50bR3Lc9-It47M=.b655d4da-0ad9-4081-9f35-e965d8098db8@github.com>
Message-ID: <rIIJN_lk2SEOTw0OjYbYJ9CpFcb9PbUiirF_fH_YkN4=.ae9a03f2-17ab-4caf-9893-8c6c7f4303b4@github.com>

On Fri, 21 Feb 2025 17:30:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Added: 
>>  Delayed actions become <em>enabled</em> and behave as ordinary submitted tasks when their delays elapse.
>
> Thanks. Also here we have ".. after the given delay, At which" so need to smooth that out.

OK. I also renamed executeReadyScheduledTask to executeEnabledScheduledTask and checked consistency of usages elsewhere.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1966501150

From dl at openjdk.org  Sat Feb 22 11:59:52 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 22 Feb 2025 11:59:52 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <Kag2Nig3EtyolwmBmM5IeiG7evVY5r7bSwDHgJcMm5s=.47db8ec3-e293-4018-9fdb-426e66636885@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
 <Kag2Nig3EtyolwmBmM5IeiG7evVY5r7bSwDHgJcMm5s=.47db8ec3-e293-4018-9fdb-426e66636885@github.com>
Message-ID: <EM1JF3VdRhXAicC-MBnYMfXKUU--tpxFTo13vnlOrws=.64ac5d79-e35f-4eff-b7d2-0edfb0b53371@github.com>

On Fri, 21 Feb 2025 16:28:15 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address feedback
>
> src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 2840:
> 
>> 2838:         Canceller(Future<?> f) { this.f = f; }
>> 2839:         public void accept(Object ignore, Throwable ex) {
>> 2840:             if (f != null)
> 
> @DougLea Does it make sense to create a Canceller with a `null` `f`-parameter?

The usual j.u.c answer: it is never null now, but if there were ever a case in which it were, it's a no-op.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1966502091

From dl at openjdk.org  Sat Feb 22 12:19:53 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 22 Feb 2025 12:19:53 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <8WSFK0WtY1PaOPeuLRZrSDqvkt0Fd0kVSeVPUx2B4no=.cb5fd759-ea88-452d-ad1a-c142c110b982@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
 <8WSFK0WtY1PaOPeuLRZrSDqvkt0Fd0kVSeVPUx2B4no=.cb5fd759-ea88-452d-ad1a-c142c110b982@github.com>
Message-ID: <br72MAE21IhkNJygkgVycDo486sSweEqPPgeCgMir6Q=.17221903-451b-4463-bda6-a2739b9daa4c@github.com>

On Fri, 21 Feb 2025 16:34:32 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address feedback
>
> src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 2947:
> 
>> 2945:             e.scheduleDelayedTask(
>> 2946:                 new ScheduledForkJoinTask<Void>(
>> 2947:                     nanoDelay, 0L, true,
> 
> @DougLea Doesn't this mean that anyone can submit tasks which will be executed on the DelayedScheduler scheduling thread? If so, there's a big risk that things end up there which shouldn't be there, and could even compromise the liveness of said thread? ?

The task here is just TaskSubmitter's { executor.execute(action); }, which is assumed here (and in every other async  CF method) not to indefinitely block or loop. The class-level javadoc doesn't (and can't) strictly mandate this though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1966505042

From dl at openjdk.org  Sat Feb 22 12:23:00 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 22 Feb 2025 12:23:00 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <LVC9_kIjU5rwELw6uKilGFu6lxZsQNxBm_76qisHrX8=.71560102-5f4b-47b6-8649-be28553b5afc@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
 <LVC9_kIjU5rwELw6uKilGFu6lxZsQNxBm_76qisHrX8=.71560102-5f4b-47b6-8649-be28553b5afc@github.com>
Message-ID: <1HNOIcH8340KCE5xqS4PAvwptXxgzk3wCtR7l2KFSjI=.45ff5f87-2c2a-4da1-aecb-70955e51b373@github.com>

On Fri, 21 Feb 2025 16:52:41 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address feedback
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 1668:
> 
>> 1666:                      t.interrupt();
>> 1667:                  } catch (Throwable ignore) {
>> 1668:                  }
> 
> @DougLea This is just for peace of mind, I presume?

Yes. We don't think there are any cases left where interrupt can throw a VM error, but still can't strictly rule it out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1966505505

From dl at openjdk.org  Sat Feb 22 12:30:54 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 22 Feb 2025 12:30:54 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <xXK-JdCtw7G0WpVjqZTwDSdF3i1hVzK50os_knF8p8Q=.7234155d-ec77-4c18-a764-71411b2cc521@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
 <xXK-JdCtw7G0WpVjqZTwDSdF3i1hVzK50os_knF8p8Q=.7234155d-ec77-4c18-a764-71411b2cc521@github.com>
Message-ID: <8pGiV5TUGE0AJo5-hEx46aPvarck176P6tsBBHka1l0=.ba1dbed9-0788-4c4b-a8bc-7c5e380a1651@github.com>

On Fri, 21 Feb 2025 17:10:24 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address feedback
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 146:
> 
>> 144:  * and invoke other {@linkplain ForkJoinTask ForkJoinTasks}. Delayed
>> 145:  * actions become <em>enabled</em> and behave as ordinary submitted
>> 146:  * tasks when their delays elapse.  schedule methods return
> 
> Suggestion:
> 
>  * tasks when their delays elapse. Scheduling methods return

done

> test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java line 50:
> 
>> 48:         var future = new CompletableFuture<>().orTimeout(12, TimeUnit.HOURS);
>> 49:         future.completeExceptionally(new RuntimeException("This is fine"));
>> 50:         while (delayer.getDelayedTaskCount() != 0) {
> 
> Might be good to start the test case asserting that the delayed task count is 0 (so there's no interference).

Thanks, done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1966506690
PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1966506368

From dl at openjdk.org  Sat Feb 22 12:41:53 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 22 Feb 2025 12:41:53 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <xXK-JdCtw7G0WpVjqZTwDSdF3i1hVzK50os_knF8p8Q=.7234155d-ec77-4c18-a764-71411b2cc521@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
 <xXK-JdCtw7G0WpVjqZTwDSdF3i1hVzK50os_knF8p8Q=.7234155d-ec77-4c18-a764-71411b2cc521@github.com>
Message-ID: <4AlOpx7MA7bkuSGqSADTLQiIWNh4gcg7EDsUhRlXF94=.712b861c-9d98-45e3-9c14-cd6a062408df@github.com>

On Fri, 21 Feb 2025 17:11:31 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address feedback
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 160:
> 
>> 158:  * do not include scheduled tasks that are not yet ready to execute,
>> 159:  * whcih are reported separately by method {@link
>> 160:  * getDelayedTaskCount}.
> 
> Suggestion:
> 
>  * which are reported separately by method {@link getDelayedTaskCount}.

Done. also checked for a fixed other cases of missing "#"  in method links

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1966508666

From dl at openjdk.org  Sat Feb 22 12:45:53 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 22 Feb 2025 12:45:53 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <0kh2k7xJtPVfBtDOm8bGlv5BvHzs5x3u5dqUxjlpa1Y=.4a29c6a5-e7d0-4c72-b739-879f66a9b907@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
 <0kh2k7xJtPVfBtDOm8bGlv5BvHzs5x3u5dqUxjlpa1Y=.4a29c6a5-e7d0-4c72-b739-879f66a9b907@github.com>
Message-ID: <zy1qp9JVpxxjUaneQy1WiujPjiFbWDJpFbTpobQchKo=.b2799c17-92cf-4299-a156-cdda1d20f539@github.com>

On Fri, 21 Feb 2025 17:23:23 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address feedback
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2585:
> 
>> 2583:      * throws RejectedExecutionException if shutdown or terminating.
>> 2584:      * @param r current ThreadLocalRandom.getProbe() value
>> 2585:      * @param rejectOnShutdown true if throw RJE when shutdown
> 
> Suggestion:
> 
>      * @param rejectOnShutdown true if to throw RejectedExecutionException when shutdown

done.

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3534:
> 
>> 3532:     /**
>> 3533:      * Submits a one-shot task that becomes enabled after the given
>> 3534:      * delay, At which point it will execute unless explicitly
> 
> Suggestion:
> 
>      * delay, at which point it will execute unless explicitly

Reworded

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1966509464
PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1966509509

From dl at openjdk.org  Sat Feb 22 12:50:55 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 22 Feb 2025 12:50:55 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <6g-1DgWFaIf6NCEijtD143S1N77MYA2s3kzAHg4vohk=.ca29514a-bc90-4355-83fc-ec025f204857@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
 <6g-1DgWFaIf6NCEijtD143S1N77MYA2s3kzAHg4vohk=.ca29514a-bc90-4355-83fc-ec025f204857@github.com>
Message-ID: <n0WirPl32HPTa94Bp_0L2wCW-6fzLds2AFoUBhHJGvU=.3402b2a9-85e3-4410-b1a1-2737d51c9d08@github.com>

On Fri, 21 Feb 2025 17:38:00 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address feedback
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3526:
> 
>> 3524:         if (((ds = delayScheduler) == null &&
>> 3525:              (ds = startDelayScheduler()) == null) ||
>> 3526:             task == null || (runState & SHUTDOWN) != 0L)
> 
> Might not make sense to start the delay scheduler if the task is null.

There's no longer need or value of that null check (there was in some trial version), so removed.

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3557:
> 
>> 3555:         return scheduleDelayedTask(
>> 3556:             new ScheduledForkJoinTask<Void>(
>> 3557:                 unit.toNanos(delay), 0L, false, command, null, this));
> 
> Suggestion:
> 
>                 unit.toNanos(delay), 0L, false, command, null, this)); // Implicit null-check of unit

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1966510207
PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1966509890

From dl at openjdk.org  Sat Feb 22 12:53:54 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 22 Feb 2025 12:53:54 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v2]
In-Reply-To: <dIxwveIw4666uGfaxsfLVF22w4HpT5QKi1WQlhNTCrg=.6faa36a1-a03b-4347-b43e-2cddce7175dc@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <EMlMgKNAo2TwawXcj2gWDGcy_6g5ElDsGYUTBoGFe90=.d0ee28f0-463a-4516-a9dd-eea78b5957fc@github.com>
 <dIxwveIw4666uGfaxsfLVF22w4HpT5QKi1WQlhNTCrg=.6faa36a1-a03b-4347-b43e-2cddce7175dc@github.com>
Message-ID: <nBEFcZZN4TTWKBrkHm5Jl0Dgx25VpFjDleHleiz9Rug=.4df5ad47-87b2-4e37-a5b3-3113d543476a@github.com>

On Fri, 21 Feb 2025 17:16:55 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address feedback
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 187:
> 
>> 185:  * are used. It is possible to disable use of threads by using a
>> 186:  * factory that may return {@code null}, in which case some tasks may
>> 187:  * never execute. It is also possible but strongly discouraged to set
> 
> Suggestion:
> 
>  * never execute. While possible, it is strongly discouraged to set

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1966510556

From alanb at openjdk.org  Sat Feb 22 13:54:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 22 Feb 2025 13:54:53 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v9]
In-Reply-To: <NwTJelNPGLUFAP_qE7hQu_xs2aNfwcKvOj2ORS-ZKMw=.9e7c8874-ae1a-464a-bbfa-201c9d218656@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <NwTJelNPGLUFAP_qE7hQu_xs2aNfwcKvOj2ORS-ZKMw=.9e7c8874-ae1a-464a-bbfa-201c9d218656@github.com>
Message-ID: <61zMkO1r0cBrjnz9aa2-3ThDIvD0lTtF3wNRz3zHicE=.8b3704fd-5fac-4db7-8f52-65cc73d720e3@github.com>

On Fri, 21 Feb 2025 19:00:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify the implementation of `java.io.File` so that it correctly handles the empty path `""`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8024695: Add sentence to clarify empty File behavior

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22821#pullrequestreview-2634808665

From dl at openjdk.org  Sat Feb 22 14:30:11 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 22 Feb 2025 14:30:11 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v3]
In-Reply-To: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
Message-ID: <YEAZz3j4mW7nIz0Iq0BEJ9OW5-Fqo1DSnMBkYkQaOUI=.ecce1ad9-ed24-4a11-8642-4f73aef274c0@github.com>

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments; ensure new internal methods can't clash with subclasses

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23702/files
  - new: https://git.openjdk.org/jdk/pull/23702/files/16815cc0..84eaab05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=01-02

  Stats: 95 lines in 5 files changed: 25 ins; 19 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/23702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23702/head:pull/23702

PR: https://git.openjdk.org/jdk/pull/23702

From asemenyuk at openjdk.org  Sat Feb 22 14:40:39 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 22 Feb 2025 14:40:39 GMT
Subject: RFR: 8326447: jpackage creates Windows installers that cannot be
 signed [v3]
In-Reply-To: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
References: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
Message-ID: <XjISAKVpiB7S0DpTYiCjC2xbY5oXiZemnzFhy4zqDqA=.4f8b16e8-87d1-4181-9f98-5e356691f597@github.com>

> Support the use of a custom msi wrapper executable when building an exe installer.
> 
> Put `installer.exe` file in the resource directory and jpackage will use it instead of the default `msiwrapper.exe` resource for exe installer.
> 
> To test this feature created a test that builds exe installer with a custom icon. The result installer exe is used as a custom msi wrapper executable in the second jpackage command that builds exe installer with the default icon. The installer exe produced by the second jackage command should have the same icon as the exe installer created in the first jpackage run.
> 
> Moved code verifying icons in executables from `LauncherIconVerifier.WinIconVerifier` class into `WinExecutableIconVerifier` class to make it available for tests. Replaced inline powershell script extracting icons from executables with standalone `read-executable-icon.ps1` powershell script. The script uses `ExtractIcon` instead of `ExtractAssociatedIcon`. It extracts icon from the executable's resources and will not fall back to anything if there is no icon resource.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Keep bundles produces by the test in the test work directory

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23732/files
  - new: https://git.openjdk.org/jdk/pull/23732/files/31ebde0c..d5827daa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23732&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23732&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23732/head:pull/23732

PR: https://git.openjdk.org/jdk/pull/23732

From coleenp at openjdk.org  Sat Feb 22 14:49:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 22 Feb 2025 14:49:38 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v7]
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <Y4xsaQoNZ448-1w0-OjJvAi5NidyaI5bLHAtRx_2Ovk=.2b5fc86b-ad1d-4b75-b51a-459fa5fd88e3@github.com>

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Use modifiers field directly in isInterface.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23572/files
  - new: https://git.openjdk.org/jdk/pull/23572/files/c23718b3..db7c9782

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23572/head:pull/23572

PR: https://git.openjdk.org/jdk/pull/23572

From coleenp at openjdk.org  Sat Feb 22 14:49:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 22 Feb 2025 14:49:38 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v5]
In-Reply-To: <LrjguT4-f7V_Wotxu2zb87fAUEoCtFnuPqr442jiEpc=.0bb754fa-51ce-479d-b1de-fbea5f9f2017@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <PM65jBoMpUpFNVH-ZcJWCDJl1IavmTdNU-2DnS9j22c=.7d4fdd41-5ed0-4785-b37f-c7f4b0c1e9e9@github.com>
 <beP3eW57na8hjpPFM27Zbhg3i4iZm_htJAhn7LZiwHg=.876cec03-2f47-468c-8197-fa59e590e435@github.com>
 <3jNPEzaXa0Ncf8eu3vct6a_jyH7k4tH_mbRBaKmbMc0=.d3a86a0f-1bed-4084-af92-959f4dbd52f4@github.com>
 <VyoHvDMpugJg1-XWZE_gKFwBkWc-7of8qIfdcuDB2jE=.b0d9bdb7-7480-4ae1-afec-e48cbf94c188@github.com>
 <LrjguT4-f7V_Wotxu2zb87fAUEoCtFnuPqr442jiEpc=.0bb754fa-51ce-479d-b1de-fbea5f9f2017@github.com>
Message-ID: <lVKXy7KXi77A5PNSsqH5M4z_PXRaHBuBheQSm3t4gic=.76f5d72f-00f7-4f0c-bbce-08f6f7146a8a@github.com>

On Fri, 21 Feb 2025 21:08:33 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Indeed, even though this checks for the specific bit so widening has no effect, it is better to be cautious here.
>
>> I don't use the field directly because the field is a short and getModifiers makes it into Modifier.
> 
> But getModifiers() returns `int`, not `Modifier` (which is all static).

I mis-remembered why I called getModifiers(), maybe because all the other calls to getModifiers() in Class.java which used be needed, but I did want to call Modifier.isInterface().  If using the 'modifiers' field directly is better, I'll change it to that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1966527692

From jiangli at openjdk.org  Sun Feb 23 02:38:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sun, 23 Feb 2025 02:38:57 GMT
Subject: Integrated: 8350041: Skip
 test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java on static
 JDK
In-Reply-To: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
References: <58P7DlZ9Q-wpR-sFu4MdR1znmlYMNrGMzHE-PTQmWLE=.6c81b32a-cf61-4bdc-9b60-868adce9972a@github.com>
Message-ID: <ONy-QY43H0jq-ZlRjZu3dzpXNWilDW0ecRbvvX0TK44=.1bd18613-1b61-456a-86f9-cef4195b6e8e@github.com>

On Fri, 14 Feb 2025 18:31:52 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix to make `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: 
> 
> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and `JNU_NewStringPlatform` dynamically
> - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` with `libjava.so`
> - Link with `-ldl` explicitly
> 
> The test passed on Linux, macos and Windows in GHA testing, https://github.com/jianglizhou/jdk/actions/runs/13320840902/job/37206171224

This pull request has now been integrated.

Changeset: 05b48129
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05b481294cbf2ad7c8d917b8e039e7aebcf91104
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8350041: Skip test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java on static JDK

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/23646

From kbarrett at openjdk.org  Sun Feb 23 10:23:05 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 23 Feb 2025 10:23:05 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
Message-ID: <LcZtUjCXWicin-NhFBQKKcXSiCj5SivVMRDDf96dFO0=.5b46ddbe-959a-44a6-b689-8325770f4cad@github.com>

On Tue, 18 Feb 2025 14:33:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
>> 
>> We can migrate DBBs to use `java.lang.ref.Cleaner`.
>> 
>> There are two pecularities during this rewrite.
>> 
>> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
>> 
>> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
>> 
>> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit more comments

I've made a prototype that adds Cleaner.waitForCleaning() and changes
Bits.reserveMemory() to use it.

https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:wait-for-cleaning?expand=1

It's based on the shipilev commits 1-19, for ease of comparison and
prototyping. There are also some shortcuts (like making some things public
that likely shouldn't be), again for ease of prototyping.

I ran the DirectBufferAllocTest test a few hundred times without any
problems.  I also ran it directly, configured with a 1/2 hour runtime, again
without problems.  I ran the two new micros against baseline, the shipilev
changes only, and the waitForCleaning changes.  Results below.

DirectByteBufferGC
baseline
Benchmark                (count)  Mode  Cnt    Score    Error  Units
DirectByteBufferGC.test    16384  avgt    9    4.036 ?  0.244  ms/op
DirectByteBufferGC.test    65536  avgt    9    7.117 ?  0.184  ms/op
DirectByteBufferGC.test   262144  avgt    9   18.482 ?  1.064  ms/op
DirectByteBufferGC.test  1048576  avgt    9  194.590 ? 17.639  ms/op
DirectByteBufferGC.test  4194304  avgt    9  802.354 ? 57.576  ms/op

shipilev
Benchmark                (count)  Mode  Cnt    Score    Error  Units
DirectByteBufferGC.test    16384  avgt    9    4.104 ?  0.045  ms/op
DirectByteBufferGC.test    65536  avgt    9    6.875 ?  0.244  ms/op
DirectByteBufferGC.test   262144  avgt    9   17.943 ?  0.446  ms/op
DirectByteBufferGC.test  1048576  avgt    9   59.002 ?  3.616  ms/op
DirectByteBufferGC.test  4194304  avgt    9  331.328 ? 36.580  ms/op

waitForCleaning
Benchmark                (count)  Mode  Cnt    Score    Error  Units
DirectByteBufferGC.test    16384  avgt    9    4.058 ?  0.167  ms/op
DirectByteBufferGC.test    65536  avgt    9    6.775 ?  0.281  ms/op
DirectByteBufferGC.test   262144  avgt    9   17.724 ?  0.602  ms/op
DirectByteBufferGC.test  1048576  avgt    9   57.284 ?  2.679  ms/op
DirectByteBufferGC.test  4194304  avgt    9  330.002 ? 44.200  ms/op

DirectByteBufferChurn
baseline
Benchmark                   (recipFreq)  Mode  Cnt   Score   Error  Units
DirectByteBufferChurn.test          128  avgt    9  15.693 ? 0.991  ns/op
DirectByteBufferChurn.test          256  avgt    9  11.255 ? 0.369  ns/op
DirectByteBufferChurn.test          512  avgt    9   9.422 ? 0.382  ns/op
DirectByteBufferChurn.test         1024  avgt    9   8.529 ? 0.311  ns/op
DirectByteBufferChurn.test         2048  avgt    9   7.833 ? 0.287  ns/op

shipilev
Benchmark                   (recipFreq)  Mode  Cnt   Score   Error  Units
DirectByteBufferChurn.test          128  avgt    9  12.524 ? 0.476  ns/op
DirectByteBufferChurn.test          256  avgt    9   9.248 ? 0.175  ns/op
DirectByteBufferChurn.test          512  avgt    9   8.583 ? 0.197  ns/op
DirectByteBufferChurn.test         1024  avgt    9   8.227 ? 0.274  ns/op
DirectByteBufferChurn.test         2048  avgt    9   7.526 ? 0.394  ns/op

waitForCleaning
Benchmark                   (recipFreq)  Mode  Cnt   Score   Error  Units
DirectByteBufferChurn.test          128  avgt    9  11.235 ? 1.998  ns/op
DirectByteBufferChurn.test          256  avgt    9   9.129 ? 0.324  ns/op
DirectByteBufferChurn.test          512  avgt    9   8.446 ? 0.115  ns/op
DirectByteBufferChurn.test         1024  avgt    9   7.786 ? 0.425  ns/op
DirectByteBufferChurn.test         2048  avgt    9   7.477 ? 0.150  ns/op

The baseline DirectByteBufferGC suffers significantly at higher counts,
probably because of the long doubly-linked list of registered
jdk.internal.ref.Cleaner objects.

By eye the performance of both shipilev and waitForCleaning on the DBBChurn
benchmark seem to be consistently slightly better than baseline, and within
the noise of each other for both benchmarks.

This waitForCleaning approach raises several questions.

(1) Is the improved reliability of this approach worth the additional effort?
My inclination is to say yes.  But note that it should perhaps be different
effort - see item (2).

(2) Should Cleaner be responsible for providing the additional functionality?
An alternative is to have Bits implement it's own cleaning, directly using a
private PhantomReference derivative, ReferenceQueue, and Thread.

If there were multiple (potential) clients for this sort of thing then putting
it in Cleaner may makes sense, so long as their requirements are similar.  But
we're kind of fighting with it, esp. with the canary approach, but even with
the waitForCleaning approach.  I think things could be simpler and easier to
understand with a direct implementation.  And Cleaner was not intended to be
the last word in the area of reference-based cleanup.  Rather, it's a
convenient package for addressing some common patterns (esp. with
finalization).  It provides some useful infrastructure that would need to be
replaced in a bespoke implementation, but I don't think there's anything all
that large or complicated there, and some streamlining is possible.

Note that I haven't done any work in that direction yet.

(3) Do we need the retry stuff, and how should it be done?  I did some
monitoring of the retries, and waitForCleaning DBBA does need the retries
(though rarely more than 1, and I never saw more than 2).  I kind of feel like
the retries are a kludgy workaround for what seems like an unreasonable test,
but oh well.

The point of the retries is to allow other threads to drop some DBBs that can
become reclaimable during the associated wait, giving the waiting thread an
opportunity to make use of that now available memory.

I experimented with a retry-style more similar to the current code, where each
thread on the slow path will do at most one GC and then go into a wait/sleep
loop if reservation continues to fail.  (I added some locking to avoid the
concurrent requests for GC issue with the current code.) That didn't seem to
make any difference compared to something like the proposed serialized GC and
sleep loop.  I can construct theoretical cases that seem to favor either, but
the style in the proposal seems simpler.

Of course, the question of when to do GCs and how many to do is moot if
-XX:+DisableExplicitGC is used.  (The default for that option is false.)

src/java.base/share/classes/java/nio/Bits.java line 149:

> 147:         //   1. GC needs to discover dead references and hand them over to Reference
> 148:         //      processing thread. This activity can be asynchronous and can complete after
> 149:         //      we unblock from System.gc().

Adding cleared references to the pending list is always completed before the
GC invocation completes.  Doing otherwise would break or significantly
complicate Reference.waitForReferenceProcessing(), and to no good purpose.
That function should only return false when all references cleared by a prior
GC have been enqueued in their respective queues.  There are tests that depend
on that.  (I looked, and so far as I can tell, none of the extant GCs violate
this.)

src/java.base/share/classes/java/nio/Bits.java line 166:

> 164:         // install the canary, call System.gc(), wait for canary to get processed (dead). This
> 165:         // signals that since our last call to System.gc(), steps (1) and (2) have finished, and
> 166:         // step (3) is currently in progress.

The canary having been processed doesn't tell us anything definitive about
step (2), because steps (2) and (3) occur concurrently.  The reference
processing thread transfers references to their respective queues, and the
cleaner thread processes references that have been placed in its queue, both
running at the same time.  All we know is that the canary got transferred and
cleaned.  There may or many not have been other references similarly
transferred and cleaned.  There may or may not be more references in the
pending list, in the cleaner queue, or both.  That the canary has been cleaned
doesn't give us any information about either the pending list or the cleaner
queue.

src/java.base/share/classes/java/nio/Bits.java line 172:

> 170:         // corner case would be handled with a normal retry attempt, after trying to allocate.
> 171:         // If allocation succeeds even after partial cleanup, we are done. If it does not, we get
> 172:         // to try again, this time reliably getting the results of the first cleanup run. Not

After trying again, all we know is that both the previous and the new canary
have been processed.  We don't know anything about other references, either
from the latest or preceeding GCs.  Consider this unfortunate scenario.  The
first canary ended up at the head of the pending list.  The reference
processing thread transfered it to the cleaner queue and then stalled.  The
cleaner thread processed the first canary.  The waiting thread noted that,
retried and failed the reservation, and retried the GC and wait for the
canary.  The retry canary also happened to end up at the front of the updated
pending list.  The reference processor transferred it and again stalled.  The
cleaner thread processed the retry canary.  No real cleaning has happened,
i.e. we have not reliably gotten the results of the first cleanup run.

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22165#pullrequestreview-2635485651
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1966720234
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1966720361
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1966720509

From rstupp at openjdk.org  Sun Feb 23 15:15:44 2025
From: rstupp at openjdk.org (Robert Stupp)
Date: Sun, 23 Feb 2025 15:15:44 GMT
Subject: RFR: 8349545: ClassLoader.definePackage() throws
 IllegalArgumentException if package already defined
Message-ID: <nPvgVf0OlU00h6YkrG0OXwiAqjc9_Eu7qBdUmTSSUYg=.1de24d04-2a4b-45a7-999d-529658b4d497@github.com>

Concurent calls to `ClassLoader.definePackage()` can yield `IllegalArgumentException`s if the package is already defined. Some built-in class loaders, like `URLClassLoader`, already handle this case, but custom class loaders (would) have to handle this case.

This change updates the logic of `CL.definePackage` to not throw an IAE if the "redefined" package is equal to the already defined one.

Tests added in `jdk/java/lang/Package/PackageDefineTest.java` (+ pulling up the `TestClassLoader` from `PackageDefineTest`).

-------------

Commit messages:
 - spec (javadoc)
 - move checks to CL + hoist IAE checks from URL/BuiltinClassLoaders
 - 8349545: ClassLoader.definePackage() throws IllegalArgumentException if package already defined

Changes: https://git.openjdk.org/jdk/pull/23737/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23737&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349545
  Stats: 260 lines in 6 files changed: 218 ins; 29 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/23737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23737/head:pull/23737

PR: https://git.openjdk.org/jdk/pull/23737

From rstupp at openjdk.org  Sun Feb 23 15:15:44 2025
From: rstupp at openjdk.org (Robert Stupp)
Date: Sun, 23 Feb 2025 15:15:44 GMT
Subject: RFR: 8349545: ClassLoader.definePackage() throws
 IllegalArgumentException if package already defined
In-Reply-To: <nPvgVf0OlU00h6YkrG0OXwiAqjc9_Eu7qBdUmTSSUYg=.1de24d04-2a4b-45a7-999d-529658b4d497@github.com>
References: <nPvgVf0OlU00h6YkrG0OXwiAqjc9_Eu7qBdUmTSSUYg=.1de24d04-2a4b-45a7-999d-529658b4d497@github.com>
Message-ID: <mHqpaiGN-v5xnbUly1yK0nvhFWUhx7JmaD-00iqCUys=.4df8a28c-d2ae-40b9-b019-923316df97d9@github.com>

On Sun, 23 Feb 2025 11:32:41 GMT, Robert Stupp <rstupp at openjdk.org> wrote:

> Concurent calls to `ClassLoader.definePackage()` can yield `IllegalArgumentException`s if the package is already defined. Some built-in class loaders, like `URLClassLoader`, already handle this case, but custom class loaders (would) have to handle this case.
> 
> This change updates the logic of `CL.definePackage` to not throw an IAE if the "redefined" package is equal to the already defined one.
> 
> Tests added in `jdk/java/lang/Package/PackageDefineTest.java` (+ pulling up the `TestClassLoader` from `PackageDefineTest`).

Should the "sealing checks" be moved from URLClassLoader to ClassLoader?

I've reverted the changes to `[Named]Package.java` and added the "compatible" checks directly to `CL.definePackage()`, using the existing `isSealed` checks.

Unrelated to this change, I wonder whether `java.lang.Package#isSealed(java.net.URL)` should be changed to prevent involving `URLStreamHandler` via `URL.equals`. WDYT?

src/java.base/share/classes/java/lang/NamedPackage.java line 94:

> 92:         return (o instanceof NamedPackage other)
> 93:                 && name.equals(other.name)
> 94:                 && module == other.module;

I'm not sure about the object-equality check here wrt module-layers.

src/java.base/share/classes/java/lang/NamedPackage.java line 99:

> 97:     @Override
> 98:     public int hashCode() {
> 99:         return name.hashCode();

I might be wrong, but IIRC object-identity-hash-code got/gets is treated in a special way w/ Lilliput, so I omitted `module` here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23737#issuecomment-2676805462
PR Comment: https://git.openjdk.org/jdk/pull/23737#issuecomment-2676915966
PR Review Comment: https://git.openjdk.org/jdk/pull/23737#discussion_r1966750832
PR Review Comment: https://git.openjdk.org/jdk/pull/23737#discussion_r1966750746

From dl at openjdk.org  Sun Feb 23 15:26:48 2025
From: dl at openjdk.org (Doug Lea)
Date: Sun, 23 Feb 2025 15:26:48 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
Message-ID: <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Standardize parameter checking

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23702/files
  - new: https://git.openjdk.org/jdk/pull/23702/files/84eaab05..c9bc41ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=02-03

  Stats: 115 lines in 3 files changed: 30 ins; 29 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/23702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23702/head:pull/23702

PR: https://git.openjdk.org/jdk/pull/23702

From dl at openjdk.org  Sun Feb 23 15:26:48 2025
From: dl at openjdk.org (Doug Lea)
Date: Sun, 23 Feb 2025 15:26:48 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v3]
In-Reply-To: <YEAZz3j4mW7nIz0Iq0BEJ9OW5-Fqo1DSnMBkYkQaOUI=.ecce1ad9-ed24-4a11-8642-4f73aef274c0@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <YEAZz3j4mW7nIz0Iq0BEJ9OW5-Fqo1DSnMBkYkQaOUI=.ecce1ad9-ed24-4a11-8642-4f73aef274c0@github.com>
Message-ID: <lnqQUlXXda3VNqW1XNRlRhvHyJCvdV9WQn_MVv_RHIk=.7ac4ed0b-3171-46a8-a96e-1f186a3afe1e@github.com>

On Sat, 22 Feb 2025 14:30:11 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments; ensure new internal methods can't clash with subclasses

As a bit of cleanup, I updated to regularize parameter checking (mainly null checks) in ForkJoin classes, not just those  directly impacted when adding scheduling methods. Sorry to add so many boring diffs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23702#issuecomment-2676921846

From alanb at openjdk.org  Sun Feb 23 16:56:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 23 Feb 2025 16:56:54 GMT
Subject: RFR: 8349545: ClassLoader.definePackage() throws
 IllegalArgumentException if package already defined
In-Reply-To: <nPvgVf0OlU00h6YkrG0OXwiAqjc9_Eu7qBdUmTSSUYg=.1de24d04-2a4b-45a7-999d-529658b4d497@github.com>
References: <nPvgVf0OlU00h6YkrG0OXwiAqjc9_Eu7qBdUmTSSUYg=.1de24d04-2a4b-45a7-999d-529658b4d497@github.com>
Message-ID: <ufZKomLA7dBQzprjfyFE4Js23bhfbD34RSD-wRLymSw=.3b66e656-8a58-4bec-8387-25655d09f1a8@github.com>

On Sun, 23 Feb 2025 11:32:41 GMT, Robert Stupp <rstupp at openjdk.org> wrote:

> Concurent calls to `ClassLoader.definePackage()` can yield `IllegalArgumentException`s if the package is already defined. Some built-in class loaders, like `URLClassLoader`, already handle this case, but custom class loaders (would) have to handle this case.
> 
> This change updates the logic of `CL.definePackage` to not throw an IAE if the "redefined" package is equal to the already defined one.
> 
> Tests added in `jdk/java/lang/Package/PackageDefineTest.java` (+ pulling up the `TestClassLoader` from `PackageDefineTest`).

It's a bug for a custom ClassLoader implementation to attempt to define the same Package more than once, so JDK-8349545 is really an issue that should be fixed in the custom class loader. The proposal here effectively changes definePackage to be "definePackageIfNotDefined" so that custom class loaders don't need to coordinate concurrent attempts to define a Package. This is a significant change in behavior to a JDK 1.2 era API so caution is needed, and will require effort to work through the implications. So I think more thinking required to decide if JDK-8349545 should be closed or whether the inconvenience for subclasses is worth introducing a new API rather changing the behavior of definePackage.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23737#issuecomment-2676985791

From jpai at openjdk.org  Mon Feb 24 05:55:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Feb 2025 05:55:05 GMT
Subject: RFR: 8204868: java/util/zip/ZipFile/TestCleaner.java still fails with
 "cleaner failed to clean zipfile."
Message-ID: <SagoNViasiREITln_earADUSLDTN9stD2UAJotnE1d4=.b9f76665-937c-4d7d-b33e-5e304cfce189@github.com>

Can I please get a review of this test-only change which proposes to address an intermittent failure in the `test/jdk/java/util/zip/ZipFile/TestCleaner.java` test?

This test does operations on Inflater/Deflater/ZipFile and  closes those instances and then waits for GC to kick in. After wait for a second, it then checks that the underlying resources held by these instances have been cleaned (by the Cleaner).

Once in a while, we have noticed that this test fails because the resources haven't been cleaned. I suspect this is because within the (fixed) 1 second wait time, the Cleaner hasn't yet invoked the cleaning action for these instances.

The commit in this PR updates the test to run it in `othervm` so that the Cleaner actions aren't delayed by any other test or code that might have previously run on the `agentvm`. Furthermore, the test is also updated to the use the `ForceGC` test util which takes into account the jtreg test timeout factor for deciding how long to wait for the Cleaner to initiate the cleaning action. Our CI is configured with a timeout factor of 4, so with this change, instead of a fixed maximum 1 second wait time, the test will now wait a maximum of 4 seconds for the cleaner action to be invoked.

The test continues to pass with this change, even with a repeat execution of 50 runs.

-------------

Commit messages:
 - 8204868: java/util/zip/ZipFile/TestCleaner.java still fails with "cleaner failed to clean zipfile."

Changes: https://git.openjdk.org/jdk/pull/23742/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23742&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8204868
  Stats: 44 lines in 1 file changed: 21 ins; 11 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/23742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23742/head:pull/23742

PR: https://git.openjdk.org/jdk/pull/23742

From kbarrett at openjdk.org  Mon Feb 24 06:13:04 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 24 Feb 2025 06:13:04 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
Message-ID: <DRXDXe1c8hZO3rSKBDQHratQJnS4_L2eO_H_QYuIEHk=.ef10672c-f741-4987-9c59-67de4e76b7b0@github.com>

On Tue, 18 Feb 2025 14:33:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
>> 
>> We can migrate DBBs to use `java.lang.ref.Cleaner`.
>> 
>> There are two pecularities during this rewrite.
>> 
>> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
>> 
>> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
>> 
>> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit more comments

> (2) Should Cleaner be responsible for providing the additional functionality?
> [...]
> If there were multiple (potential) clients for this sort of thing then putting
> it in Cleaner may makes sense [...]

And here is a bug and recently opened PR that would benefit from having
Cleaner.waitForCleaning.
https://bugs.openjdk.org/browse/JDK-8204868
java/util/zip/ZipFile/TestCleaner.java still fails with "cleaner failed to clean zipfile."
https://github.com/openjdk/jdk/pull/23742

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2677514285

From kbarrett at openjdk.org  Mon Feb 24 06:15:51 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 24 Feb 2025 06:15:51 GMT
Subject: RFR: 8204868: java/util/zip/ZipFile/TestCleaner.java still fails
 with "cleaner failed to clean zipfile."
In-Reply-To: <SagoNViasiREITln_earADUSLDTN9stD2UAJotnE1d4=.b9f76665-937c-4d7d-b33e-5e304cfce189@github.com>
References: <SagoNViasiREITln_earADUSLDTN9stD2UAJotnE1d4=.b9f76665-937c-4d7d-b33e-5e304cfce189@github.com>
Message-ID: <hPmv3gXNMl8KJSYcDay45unE7sHqS3FFbNaSVooI0jc=.d96353e6-b53a-4e3e-85ff-9efdab1b4670@github.com>

On Mon, 24 Feb 2025 05:50:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address an intermittent failure in the `test/jdk/java/util/zip/ZipFile/TestCleaner.java` test?
> 
> This test does operations on Inflater/Deflater/ZipFile and  closes those instances and then waits for GC to kick in. After wait for a second, it then checks that the underlying resources held by these instances have been cleaned (by the Cleaner).
> 
> Once in a while, we have noticed that this test fails because the resources haven't been cleaned. I suspect this is because within the (fixed) 1 second wait time, the Cleaner hasn't yet invoked the cleaning action for these instances.
> 
> The commit in this PR updates the test to run it in `othervm` so that the Cleaner actions aren't delayed by any other test or code that might have previously run on the `agentvm`. Furthermore, the test is also updated to the use the `ForceGC` test util which takes into account the jtreg test timeout factor for deciding how long to wait for the Cleaner to initiate the cleaning action. Our CI is configured with a timeout factor of 4, so with this change, instead of a fixed maximum 1 second wait time, the test will now wait a maximum of 4 seconds for the cleaner action to be invoked.
> 
> The test continues to pass with this change, even with a repeat execution of 50 runs.

Not a review, just a drive-by comment.
There is discussion happening in https://github.com/openjdk/jdk/pull/22165
about perhaps adding a facility that would also provide a reliable solution to
this problem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23742#issuecomment-2677516771

From alanb at openjdk.org  Mon Feb 24 07:28:08 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Feb 2025 07:28:08 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <DRXDXe1c8hZO3rSKBDQHratQJnS4_L2eO_H_QYuIEHk=.ef10672c-f741-4987-9c59-67de4e76b7b0@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
 <DRXDXe1c8hZO3rSKBDQHratQJnS4_L2eO_H_QYuIEHk=.ef10672c-f741-4987-9c59-67de4e76b7b0@github.com>
Message-ID: <DpBtmZ54p8xyOHEfef89_tjdHc8amOboFsmaWXLOEzs=.a504dac1-f087-4ef2-b8e5-cf42cbba47b1@github.com>

On Mon, 24 Feb 2025 06:10:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> And here is a bug and recently opened PR that would benefit from having Cleaner.waitForCleaning. 

If you are suggesting exposing this as a public API then I don't think we should do this, I actually think it's time to consider deprecating Cleaner but that is a bigger discussion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2677612532

From pminborg at openjdk.org  Mon Feb 24 07:41:04 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 24 Feb 2025 07:41:04 GMT
Subject: Integrated: 8349653: Clarify the docs for MemorySegment::reinterpret
In-Reply-To: <L94NPSTuSp_-0febenOUpVNuqpoXd91mMReM3sS3INc=.82f12e00-7737-4a35-9585-309ddcb4ecef@github.com>
References: <L94NPSTuSp_-0febenOUpVNuqpoXd91mMReM3sS3INc=.82f12e00-7737-4a35-9585-309ddcb4ecef@github.com>
Message-ID: <6UaS9CFWkMEjVFeICw3oOTyK0zMjd3jiN6Idx0gj96c=.979ca27e-7062-4f86-a050-a07c55b6f791@github.com>

On Wed, 19 Feb 2025 09:14:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to clarify the documentation for two of the `MemorySegment::reinterpret` overloads.

This pull request has now been integrated.

Changeset: f755fadc
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f755fadc3d7fd1e09cdc2442531fa724ebb77dce
Stats:     18 lines in 1 file changed: 0 ins; 0 del; 18 mod

8349653: Clarify the docs for MemorySegment::reinterpret

Reviewed-by: jvernee, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/23688

From asotona at openjdk.org  Mon Feb 24 08:14:32 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 24 Feb 2025 08:14:32 GMT
Subject: RFR: 8350548: java.lang.classfile package javadoc has errors
Message-ID: <hn1StpIZRkCqK75GKcI-4xOjYKVUdc3W0tHIfYi-T5o=.70cca0e2-be53-4019-9e4f-6e01dcd66c1b@github.com>

j.l.classfile package-summary contains many code snippets.
Some of the shorter snippets are embedded in the javadoc and therefore are not validated by the tests.
One embedded code snippet contains a typo, and two snippets do not reflect the actual API method name.

This patch fixes the code snippets.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8350548: java.lang.classfile package javadoc has errors

Changes: https://git.openjdk.org/jdk/pull/23743/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23743&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350548
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23743.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23743/head:pull/23743

PR: https://git.openjdk.org/jdk/pull/23743

From tvaleev at openjdk.org  Mon Feb 24 08:49:25 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 24 Feb 2025 08:49:25 GMT
Subject: RFR: 8350518: org.openjdk.bench.java.util.TreeMapUpdate.compute fails
 with  "java.lang.IllegalArgumentException: key out of range"
Message-ID: <sUX5c-b5uzJ7biA1mOTwB_DuXU9kJwU1CZwA26NZysM=.67ea4b42-ebd6-44ad-a344-d8b06806c21f@github.com>

It appears that the benchmark was erroneous. The combination of "tailMap" mode and comparator = true didn't work correctly, as the comparator is descending. This PR changes the benchmark to use headMap instead of tailMap in comparator mode. The "tailMap" mode is renamed to "subMap". Now, all parameter combinations work correctly.

-------------

Commit messages:
 - Fix tailMap mode

Changes: https://git.openjdk.org/jdk/pull/23744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350518
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23744/head:pull/23744

PR: https://git.openjdk.org/jdk/pull/23744

From kbarrett at openjdk.org  Mon Feb 24 09:33:06 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 24 Feb 2025 09:33:06 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <DpBtmZ54p8xyOHEfef89_tjdHc8amOboFsmaWXLOEzs=.a504dac1-f087-4ef2-b8e5-cf42cbba47b1@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
 <DRXDXe1c8hZO3rSKBDQHratQJnS4_L2eO_H_QYuIEHk=.ef10672c-f741-4987-9c59-67de4e76b7b0@github.com>
 <DpBtmZ54p8xyOHEfef89_tjdHc8amOboFsmaWXLOEzs=.a504dac1-f087-4ef2-b8e5-cf42cbba47b1@github.com>
Message-ID: <iBjBZlFeeD5TSntjrxUryLhycKbm9CldiL32kMTRiEw=.4acb6c2a-d165-4795-bd73-b07cc455b6f3@github.com>

On Mon, 24 Feb 2025 07:25:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If you are suggesting exposing this as a public API then I don't think we should do this,

Not at this time, quite possibly never.  As mentioned, I made some things public for ease of prototyping.
I even commented it as such.

> I actually think it's time to consider deprecating Cleaner but that is a bigger discussion.

Which "Cleaner" are you referring to?  If jdk.internal.ref.Cleaner, this PR proposes to remove it.
If java.lang.ref.Cleaner, then why?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2677851956

From jpai at openjdk.org  Mon Feb 24 09:46:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Feb 2025 09:46:29 GMT
Subject: RFR: 8341184: Clean up the interaction between the launcher native
 code and the LauncherHelper [v16]
In-Reply-To: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
References: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
Message-ID: <JHBC_-2uIDzTy40hi2OfmFH2-eh_XXtZrgpgiQIxd3U=.5e271baf-04ca-4eaf-b51c-c85b9248fd40@github.com>

> Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? 
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. 
> 
> Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code.
> 
> No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - ... and 6 more: https://git.openjdk.org/jdk/compare/e410af00...d1ac5174

-------------

Changes: https://git.openjdk.org/jdk/pull/21256/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=15
  Stats: 367 lines in 2 files changed: 105 ins; 172 del; 90 mod
  Patch: https://git.openjdk.org/jdk/pull/21256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21256/head:pull/21256

PR: https://git.openjdk.org/jdk/pull/21256

From jpai at openjdk.org  Mon Feb 24 09:46:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Feb 2025 09:46:30 GMT
Subject: RFR: 8341184: Clean up the interaction between the launcher native
 code and the LauncherHelper [v15]
In-Reply-To: <-DhsoE0MTAqPvYYzRvNf2T06RmZk0tJCHy8vOQnUIgc=.ea3c6f9d-2650-40b4-88dc-e505182e2871@github.com>
References: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
 <-DhsoE0MTAqPvYYzRvNf2T06RmZk0tJCHy8vOQnUIgc=.ea3c6f9d-2650-40b4-88dc-e505182e2871@github.com>
Message-ID: <SDVTPfMg4tZDpPa9rWqxMLznSJubl7NQeJVIJiTKaNE=.f50ba3f8-7eeb-49de-b2a4-742be606eb87@github.com>

On Thu, 30 Jan 2025 14:20:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? 
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. 
>> 
>> Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code.
>> 
>> No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/2efb6aaa...73152bbf

keep open

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21256#issuecomment-2677883766

From dfuchs at openjdk.org  Mon Feb 24 10:16:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Feb 2025 10:16:52 GMT
Subject: RFR: 8024695: new File("").exists() returns false whereas it is
 the current working directory [v7]
In-Reply-To: <XZT4aTSOvNC5NBYXFqangP967BS9buHnhZll7zCWaRQ=.aed7ca96-c4d9-482e-aa63-dc47ecafecb5@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
 <BZTFWp9edoLszrHqicbGRyKKANYwmNG8CCmug53YEXs=.7adcdfc7-1df4-44c1-aad9-477afd6ef4bf@github.com>
 <-tnkrHlvQMgfJTqF6nFSYWMJDD6MwoKJ3q1tCqd3XfQ=.37f8d859-aefc-4a73-b9cb-ab52ab242285@github.com>
 <XZT4aTSOvNC5NBYXFqangP967BS9buHnhZll7zCWaRQ=.aed7ca96-c4d9-482e-aa63-dc47ecafecb5@github.com>
Message-ID: <rdY1LVy6m27iExXKJZJoGvTKXsP1e-RmjXMEH5ova_U=.59087cb1-5f7b-486e-98fb-296c160e3ca0@github.com>

On Fri, 21 Feb 2025 17:04:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/classes/java/io/UnixFileSystem.java line 37:
>> 
>>> 35: 
>>> 36:     private String getPathForSysCalls(String path) {
>>> 37:         return path.isEmpty() ? getCWD().getPath() : path;
>> 
>> The Windows implementation has a guard for path == null. Is it superfluous there, or should it be added here?
>> 
>>     private String getPathForWin32Calls(String path) {
>>         return (path != null && path.isEmpty()) ? getCWD().getPath() : path;
>>     }
>
> Without the `null` check on Windows there were test failures which I do not see on Unix.

OK - let's not poke the beast ;-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22821#discussion_r1967346641

From vklang at openjdk.org  Mon Feb 24 10:44:56 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 24 Feb 2025 10:44:56 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
Message-ID: <OwbK12nA076DrZdxTdFwnsHVFFt8zex4btWJW98rajQ=.8848d411-d81d-4263-ab65-16927a9c7acb@github.com>

On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Standardize parameter checking

src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 1803:

> 1801:                 for (Callable<T> c : tasks) {
> 1802:                     if (c == null)
> 1803:                         throw new NullPointerException();

Is there a test for this condition?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1967389547

From mcimadamore at openjdk.org  Mon Feb 24 11:31:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Feb 2025 11:31:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <5YIov6L2WD1Strf0NJMZpOl4ouicJ8JhzVY3-gW16Is=.7acd9289-897b-4dec-91a9-d17989ee91dd@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <7WL6BoPaoO9F7HqJfaLFqskMQLhzp_NdTBRzcApkR_0=.c47ece0a-ec3d-48c7-994f-d73a0208f5fa@github.com>
 <5YIov6L2WD1Strf0NJMZpOl4ouicJ8JhzVY3-gW16Is=.7acd9289-897b-4dec-91a9-d17989ee91dd@github.com>
Message-ID: <gN0tmKgAlcrnaMkrz1o8q0m9T609CRIP3VqxDSpjvJk=.b1660524-0ccb-4e7f-8f11-38f2276abc04@github.com>

On Fri, 21 Feb 2025 22:12:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 120:
>> 
>>> 118:      * with a {@link ValueLayout#varHandle()} call is cached inside a stable field of the value layout implementation.
>>> 119:      * This optimizes common code idioms like {@code JAVA_INT.varHandle().getInt(...)}. A second layer of caching
>>> 120:      * is then provided by this method, so different value layouts with same effects can reuse var handle instances.
>> 
>> I believe this comment is now out of sync? (It talks about two levels of caching --- but there's only one now)
>
> The first level is right, it is the instance field AbstractValueLayout.handle. The static final CHM over there was not mentioned and is now removed

I've re-read this, and I see how `cached inside a stable field` doesn't really imply use of map or something else. So yes, this text is still ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1967464555

From mcimadamore at openjdk.org  Mon Feb 24 11:36:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 24 Feb 2025 11:36:54 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <8JTFy-f-rYCzlLbpHImCvEbWG7VCSnlUDG4MkAAHaa0=.cfb825a4-0124-4022-a1c8-15cb4d4b0697@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

Marked as reviewed by mcimadamore (Reviewer).

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 130:

> 128:      */
> 129:     public static VarHandle makeRawSegmentViewVarHandle(MemoryLayout enclosing, ValueLayout layout, boolean noStride, long offset) {
> 130:         if (enclosing instanceof ValueLayout direct) {

For now the caching is ok. Moving forrward, I wonder if we shouldn't add more reuse between field var handles in cases like these:


struct Point {
   int x; int y;
}



struct Tuple {
   int u; int v;
}


E.g. if I access the first field in these two structs, then the var handle will be identical? In a way, we use the enclosing layout for two reasons:

* to determine the size `S` of the accessed memory region
* to determine the alignment `A` of the accessed memory region

So, if the static `offset`, accessed `layout`, `S` and `A` are the same for two accesses, we should probably reuse the same var handle instance? E.g. whether we access `x` in a `Point`, or `u` in a `Tuple` makes little difference.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2636794415
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1967472774

From duke at openjdk.org  Mon Feb 24 11:58:11 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 24 Feb 2025 11:58:11 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v5]
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <vZc1-hha520B7-DQDt_mwe6WSyJvCcLqWzUk5htPvPY=.39186436-1b4b-49cb-be65-3a080d68d693@github.com>

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Adding @implNote to new JavaDoc.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23491/files
  - new: https://git.openjdk.org/jdk/pull/23491/files/01157cb9..f425f3fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=03-04

  Stats: 17 lines in 2 files changed: 2 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/23491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491

PR: https://git.openjdk.org/jdk/pull/23491

From dfuchs at openjdk.org  Mon Feb 24 12:21:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Feb 2025 12:21:54 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v5]
In-Reply-To: <vZc1-hha520B7-DQDt_mwe6WSyJvCcLqWzUk5htPvPY=.39186436-1b4b-49cb-be65-3a080d68d693@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <vZc1-hha520B7-DQDt_mwe6WSyJvCcLqWzUk5htPvPY=.39186436-1b4b-49cb-be65-3a080d68d693@github.com>
Message-ID: <Oc7I2MAVvFqtEBlJo32NDW0Zxg_rqRKD2Nxa2Baa5jI=.21251055-3bc8-4846-ac1f-2200dfa78d63@github.com>

On Mon, 24 Feb 2025 11:58:11 GMT, David Beaumont <duke at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding @implNote to new JavaDoc.

src/java.logging/share/classes/java/util/logging/Handler.java line 47:

> 45:  *
> 46:  * <h2>Subclass Implementation Notes</h2>
> 47:  *

Have you looked at how this is rendered in the generated API documentation when loaded up in the browser?

I mean `@implNote` is usually a section on its own, so I am unsure whether lines 46-47 above should be moved inside the `@implNote` section or simply removed. Or maybe it's OK to leave them there - but I am afraid it would appear as an empty subsection in the normative API documentation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1967540935

From duke at openjdk.org  Mon Feb 24 13:08:49 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 24 Feb 2025 13:08:49 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v6]
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <1_MYqF28HW1ASAglx6I3PhgIff6ZLN_mcCqOWQSSIxg=.942bd5e5-56a4-4cbe-b551-536c714297f7@github.com>

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Tweaking @implNote for better rendering.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23491/files
  - new: https://git.openjdk.org/jdk/pull/23491/files/f425f3fb..19e84728

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=04-05

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491

PR: https://git.openjdk.org/jdk/pull/23491

From duke at openjdk.org  Mon Feb 24 13:08:50 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 24 Feb 2025 13:08:50 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v5]
In-Reply-To: <Oc7I2MAVvFqtEBlJo32NDW0Zxg_rqRKD2Nxa2Baa5jI=.21251055-3bc8-4846-ac1f-2200dfa78d63@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <vZc1-hha520B7-DQDt_mwe6WSyJvCcLqWzUk5htPvPY=.39186436-1b4b-49cb-be65-3a080d68d693@github.com>
 <Oc7I2MAVvFqtEBlJo32NDW0Zxg_rqRKD2Nxa2Baa5jI=.21251055-3bc8-4846-ac1f-2200dfa78d63@github.com>
Message-ID: <wz9z1e5wkb-eDPnxOGFu-U2qSOfbrSwtMtnp2bQa7N0=.0f2f7b1e-ed82-44bc-94b8-c72d856dcef4@github.com>

On Mon, 24 Feb 2025 12:19:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding @implNote to new JavaDoc.
>
> src/java.logging/share/classes/java/util/logging/Handler.java line 47:
> 
>> 45:  *
>> 46:  * <h2>Subclass Implementation Notes</h2>
>> 47:  *
> 
> Have you looked at how this is rendered in the generated API documentation when loaded up in the browser?
> 
> I mean `@implNote` is usually a section on its own, so I am unsure whether lines 46-47 above should be moved inside the `@implNote` section or simply removed. Or maybe it's OK to leave them there - but I am afraid it would appear as an empty subsection in the normative API documentation.

You're right, it looks wrong with the `<h2>` and the @implNote. I'll just remove the `<h2>`.
I hadn't appreciated that the note would have its own section. Thanks for spotting.
It also seems that you can only add one annotation per JavaDoc entry, so I removed the 2nd.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1967604106

From duke at openjdk.org  Mon Feb 24 13:08:51 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 24 Feb 2025 13:08:51 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v5]
In-Reply-To: <wz9z1e5wkb-eDPnxOGFu-U2qSOfbrSwtMtnp2bQa7N0=.0f2f7b1e-ed82-44bc-94b8-c72d856dcef4@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <vZc1-hha520B7-DQDt_mwe6WSyJvCcLqWzUk5htPvPY=.39186436-1b4b-49cb-be65-3a080d68d693@github.com>
 <Oc7I2MAVvFqtEBlJo32NDW0Zxg_rqRKD2Nxa2Baa5jI=.21251055-3bc8-4846-ac1f-2200dfa78d63@github.com>
 <wz9z1e5wkb-eDPnxOGFu-U2qSOfbrSwtMtnp2bQa7N0=.0f2f7b1e-ed82-44bc-94b8-c72d856dcef4@github.com>
Message-ID: <ZvkO8f7M47mVW5rq9GvmCyDvhq_GN8SZiF6YObC2YF0=.2fc14752-55ed-4e68-b29b-46747f35c2ff@github.com>

On Mon, 24 Feb 2025 13:03:38 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.logging/share/classes/java/util/logging/Handler.java line 47:
>> 
>>> 45:  *
>>> 46:  * <h2>Subclass Implementation Notes</h2>
>>> 47:  *
>> 
>> Have you looked at how this is rendered in the generated API documentation when loaded up in the browser?
>> 
>> I mean `@implNote` is usually a section on its own, so I am unsure whether lines 46-47 above should be moved inside the `@implNote` section or simply removed. Or maybe it's OK to leave them there - but I am afraid it would appear as an empty subsection in the normative API documentation.
>
> You're right, it looks wrong with the `<h2>` and the @implNote. I'll just remove the `<h2>`.
> I hadn't appreciated that the note would have its own section. Thanks for spotting.
> It also seems that you can only add one annotation per JavaDoc entry, so I removed the 2nd.

I've asked on the CSR if this should be @implNote or @implSpec.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1967607215

From liach at openjdk.org  Mon Feb 24 14:51:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 14:51:56 GMT
Subject: RFR: 8350548: java.lang.classfile package javadoc has errors
In-Reply-To: <hn1StpIZRkCqK75GKcI-4xOjYKVUdc3W0tHIfYi-T5o=.70cca0e2-be53-4019-9e4f-6e01dcd66c1b@github.com>
References: <hn1StpIZRkCqK75GKcI-4xOjYKVUdc3W0tHIfYi-T5o=.70cca0e2-be53-4019-9e4f-6e01dcd66c1b@github.com>
Message-ID: <3CemGmHJXmVzlN_IAi5sQgAKKm-5aTh6_ATGL8349xA=.f22715fd-1fbf-4aa7-bf99-59b5ab6b170b@github.com>

On Mon, 24 Feb 2025 08:09:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> j.l.classfile package-summary contains many code snippets.
> Some of the shorter snippets are embedded in the javadoc and therefore are not validated by the tests.
> One embedded code snippet contains a typo, and two snippets do not reflect the actual API method name.
> 
> This patch fixes the code snippets.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23743#pullrequestreview-2637386965

From rriggs at openjdk.org  Mon Feb 24 15:22:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 24 Feb 2025 15:22:56 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v5]
In-Reply-To: <ZvkO8f7M47mVW5rq9GvmCyDvhq_GN8SZiF6YObC2YF0=.2fc14752-55ed-4e68-b29b-46747f35c2ff@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <vZc1-hha520B7-DQDt_mwe6WSyJvCcLqWzUk5htPvPY=.39186436-1b4b-49cb-be65-3a080d68d693@github.com>
 <Oc7I2MAVvFqtEBlJo32NDW0Zxg_rqRKD2Nxa2Baa5jI=.21251055-3bc8-4846-ac1f-2200dfa78d63@github.com>
 <wz9z1e5wkb-eDPnxOGFu-U2qSOfbrSwtMtnp2bQa7N0=.0f2f7b1e-ed82-44bc-94b8-c72d856dcef4@github.com>
 <ZvkO8f7M47mVW5rq9GvmCyDvhq_GN8SZiF6YObC2YF0=.2fc14752-55ed-4e68-b29b-46747f35c2ff@github.com>
Message-ID: <xu7btviwlSp29qHVzlKb0kQvIskPjjnyVBEfXcw7SrI=.27ec6027-af39-48f6-95fd-c116df09cec2@github.com>

On Mon, 24 Feb 2025 13:05:57 GMT, David Beaumont <duke at openjdk.org> wrote:

>> You're right, it looks wrong with the `<h2>` and the @implNote. I'll just remove the `<h2>`.
>> I hadn't appreciated that the note would have its own section. Thanks for spotting.
>> It also seems that you can only add one annotation per JavaDoc entry, so I removed the 2nd.
>
> I've asked on the CSR if this should be @implNote or @implSpec.

Those read more like an @ApiNote, advice on how to use the API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1967859202

From dfuchs at openjdk.org  Mon Feb 24 15:39:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Feb 2025 15:39:54 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v5]
In-Reply-To: <xu7btviwlSp29qHVzlKb0kQvIskPjjnyVBEfXcw7SrI=.27ec6027-af39-48f6-95fd-c116df09cec2@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <vZc1-hha520B7-DQDt_mwe6WSyJvCcLqWzUk5htPvPY=.39186436-1b4b-49cb-be65-3a080d68d693@github.com>
 <Oc7I2MAVvFqtEBlJo32NDW0Zxg_rqRKD2Nxa2Baa5jI=.21251055-3bc8-4846-ac1f-2200dfa78d63@github.com>
 <wz9z1e5wkb-eDPnxOGFu-U2qSOfbrSwtMtnp2bQa7N0=.0f2f7b1e-ed82-44bc-94b8-c72d856dcef4@github.com>
 <ZvkO8f7M47mVW5rq9GvmCyDvhq_GN8SZiF6YObC2YF0=.2fc14752-55ed-4e68-b29b-46747f35c2ff@github.com>
 <xu7btviwlSp29qHVzlKb0kQvIskPjjnyVBEfXcw7SrI=.27ec6027-af39-48f6-95fd-c116df09cec2@github.com>
Message-ID: <PPQFrU3yEH7Wmczr0MaDKOH3FPS9u-StaxnV039bgRQ=.7ee055bc-cda2-4a06-b963-9fded638d48c@github.com>

On Mon, 24 Feb 2025 15:20:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I've asked on the CSR if this should be @implNote or @implSpec.
>
> Those read more like an @ApiNote, advice on how to use the API.

@RogerRiggs - Is overriding a method and calling `super` considered a use of the API? Because these notes are only useful for people implemeting custom subclasses of Handler...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1967897581

From coleenp at openjdk.org  Mon Feb 24 15:59:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Feb 2025 15:59:58 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v7]
In-Reply-To: <FrlPjmMb7CgcaoCNXLWwybw-pcHprdWIP8whY8fJU9g=.2564ab5c-9d30-4e5d-95cc-7a85955643b0@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <FrlPjmMb7CgcaoCNXLWwybw-pcHprdWIP8whY8fJU9g=.2564ab5c-9d30-4e5d-95cc-7a85955643b0@github.com>
Message-ID: <PougFcuJq00aqVSqW2EhQ9xOiQw_QhOy04xbXQDb4ak=.bfc9d18a-d756-4b21-8aba-e91b3dfe28df@github.com>

On Wed, 19 Feb 2025 05:12:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Does the SA not need any updates in relation to this?

No, the SA doesn't know about these compiler intrinsics.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23572#issuecomment-2678913119

From coleenp at openjdk.org  Mon Feb 24 15:59:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Feb 2025 15:59:59 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v7]
In-Reply-To: <dOZIsMeRy34Anbe2OORtfWN6eJHD2zPhIHF_vtuqDCo=.956c37b8-e682-475a-90f0-5818e7168044@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <E9GPjreqeKFJmZAIjHGQ-1y6FnyqaT94FHUPuK65kmE=.48bd4ecc-ac91-4f7b-895b-a32280d8b437@github.com>
 <_j9Wkg21aBltyVrbO4wxGFKmmLDy0T-eorRL4epfS4k=.5a453b6b-d673-4cc6-b29f-192fa74e290c@github.com>
 <3qpqR3PC8PFmdgaIoSYA3jDWdl-oon0-AcIzXcI76rY=.38635503-c067-4f6e-a4f1-92c1b6d991d1@github.com>
 <dOZIsMeRy34Anbe2OORtfWN6eJHD2zPhIHF_vtuqDCo=.956c37b8-e682-475a-90f0-5818e7168044@github.com>
Message-ID: <4eQr952WCBhGqlLqX0q2TCDLuFrwh_UmxgJcb2BOs_s=.8e7f55a7-60ec-4cc8-9a8b-cca84ccbba10@github.com>

On Thu, 20 Feb 2025 23:23:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>>> ... but not in the return since the caller likely will fetch the klass pointer next.
>> 
>> I notice that too.  Callers are using is_primitive() to short-circuit calls to as_Klass(), which means they seem to be aware of this implementation detail when maybe they shouldn't.
>
> There are 70 callers so yes, it might be something that shouldn't be known in this many places.

Definitely out of the scope of this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1967943222

From duke at openjdk.org  Mon Feb 24 16:21:33 2025
From: duke at openjdk.org (He-Pin (kerr))
Date: Mon, 24 Feb 2025 16:21:33 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v2]
In-Reply-To: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
Message-ID: <ENJYX5JbrLeyXN2uoSJgrntY6mW_0bZsre6CEQEeDDg=.a2078d52-ebf7-4f8b-bfad-a86bedfeea1b@github.com>

> Motivation:
> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
> 
> Modification:
> Add detail error messages.
> 
> Result:
> Helpful messages.

He-Pin(kerr) has updated the pull request incrementally with one additional commit since the last revision:

  chore: update tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23050/files
  - new: https://git.openjdk.org/jdk/pull/23050/files/c1b48462..dfc2cee7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23050&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23050&range=00-01

  Stats: 151 lines in 4 files changed: 64 ins; 12 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/23050.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23050/head:pull/23050

PR: https://git.openjdk.org/jdk/pull/23050

From asemenyuk at openjdk.org  Mon Feb 24 17:02:28 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 24 Feb 2025 17:02:28 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG packaging
Message-ID: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>

8350594: Misleading warning about install dir for DMG packaging

-------------

Commit messages:
 - Update copyright year
 - Remove redundant import changes
 - Added tests for DMG install dir. Fixed DMG bundler to report warning only when custom install dir differs from the default install dir.

Changes: https://git.openjdk.org/jdk/pull/23752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23752&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350594
  Stats: 182 lines in 5 files changed: 153 ins; 18 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/23752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23752/head:pull/23752

PR: https://git.openjdk.org/jdk/pull/23752

From asemenyuk at openjdk.org  Mon Feb 24 17:06:56 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 24 Feb 2025 17:06:56 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
Message-ID: <JoOkh7Tc5y-G07oSk_oyUHeqQm91nlv4qKUmj_roOwI=.6c4fc556-9466-4047-b040-b1b358ae1ef7@github.com>

On Mon, 24 Feb 2025 16:54:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Fix the warning message about the custom installation directory location jpackage issues for DMG runtime packaging.
>  - Don't issue the warning when the `-install-dir` value equals the default installation directory location.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23752#issuecomment-2679112228

From skuksenko at openjdk.org  Mon Feb 24 17:32:58 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Mon, 24 Feb 2025 17:32:58 GMT
Subject: RFR: 8350518: org.openjdk.bench.java.util.TreeMapUpdate.compute
 fails with  "java.lang.IllegalArgumentException: key out of range"
In-Reply-To: <sUX5c-b5uzJ7biA1mOTwB_DuXU9kJwU1CZwA26NZysM=.67ea4b42-ebd6-44ad-a344-d8b06806c21f@github.com>
References: <sUX5c-b5uzJ7biA1mOTwB_DuXU9kJwU1CZwA26NZysM=.67ea4b42-ebd6-44ad-a344-d8b06806c21f@github.com>
Message-ID: <G8IkVmeLR1Ek6YsYTBwXOgVhZDT_dp8zydxvxkSSru8=.baa3626b-07a3-4a06-9a61-22e3e6944369@github.com>

On Mon, 24 Feb 2025 08:44:00 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> It appears that the benchmark was erroneous. The combination of "tailMap" mode and comparator = true didn't work correctly, as the comparator is descending. This PR changes the benchmark to use headMap instead of tailMap in comparator mode. The "tailMap" mode is renamed to "subMap". Now, all parameter combinations work correctly.

Marked as reviewed by skuksenko (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23744#pullrequestreview-2637919424

From liach at openjdk.org  Mon Feb 24 17:52:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 17:52:00 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v7]
In-Reply-To: <Y4xsaQoNZ448-1w0-OjJvAi5NidyaI5bLHAtRx_2Ovk=.2b5fc86b-ad1d-4b75-b51a-459fa5fd88e3@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <Y4xsaQoNZ448-1w0-OjJvAi5NidyaI5bLHAtRx_2Ovk=.2b5fc86b-ad1d-4b75-b51a-459fa5fd88e3@github.com>
Message-ID: <IbaGy3rmKAt4_B3oPMB_K-3rprF0qY036ISs84VPwLo=.4be6bc1a-c26e-4e6d-9d35-e0d97e7e1512@github.com>

On Sat, 22 Feb 2025 14:49:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use modifiers field directly in isInterface.

The limited changes to the Java codebase looks reasonable. We should probably get a double check from Alan or some other architect.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23572#pullrequestreview-2637961573

From liach at openjdk.org  Mon Feb 24 17:57:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 17:57:05 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
 <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>
 <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>
Message-ID: <iN-WtpFC1zxkX6fcLHMlvWb816k8dhk2l6LpOYB1pRY=.01a3ed67-1bfc-43df-aff8-def1e1ed4f4f@github.com>

On Fri, 21 Feb 2025 18:37:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Now this will require code update to static import `offset` from `VarHandleSegmentViewBase`. Is that acceptable?
>
> Maybe let's leave it, at least in this round

Done in latest update.

>> This is a one-time cold path initializer so I did not care too much about its size. How should I break it up?
>
> I mean - using a single expression which is a conditional with two big switches seems quite unreadable.I suggest to move the `VH_FILTERS[index] = ` assignment out of the `computeFilterHandle` method. Then, rewrite `computeFilterHandle` as:
> 
> 
> if (addressSize != 4) {
>     return switch ...
> } else {
>     return switch ...
> }

Done in latest update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1968136129
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1968134480

From liach at openjdk.org  Mon Feb 24 17:57:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 17:57:07 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
Message-ID: <EI0Eph45u6__pwU8cytpsa2JVp90WtUpuo5XJtGioOs=.efa80f00-5fea-4c08-a424-478e41018099@github.com>

On Fri, 21 Feb 2025 10:15:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 85:
> 
>> 83: 
>> 84:         @ForceInline
>> 85:         static $type$ get(VarHandle ob, Object obb, long base) {
> 
> I like this: a fast path for non-strided access, while, at the same time, reusing the impl.
> In the future we can also add another variant for when there's only one index (which is by far the most common case).

I think that would require new impl classes, as there may be invocation type clash with the existing one-offset version. And the new offset will require extra checks too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1968135651

From liach at openjdk.org  Mon Feb 24 17:57:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 17:57:07 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <KksIB9BPE7W3JaDYgUYSspfkMn-KYT9r-a6_VwDcPOY=.5d08fdba-fbb2-4c05-aefc-09d27e4e1b41@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
 <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>
 <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>
 <KksIB9BPE7W3JaDYgUYSspfkMn-KYT9r-a6_VwDcPOY=.5d08fdba-fbb2-4c05-aefc-09d27e4e1b41@github.com>
Message-ID: <NNmU6UiiOQucVWSTEnjfdWOlXhh3OZlpsJMLYGhQrio=.ff688775-3a0a-4077-913c-b29d4ea18456@github.com>

On Fri, 21 Feb 2025 18:54:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I'm not convinced about the one in ValueLayouts *e.g. where this comment was added) -- if you agree that the other cache should already handle this -- then maybe we can only keep one
>
> Indeed, the other cache already handles this.

Done in latest update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1968136574

From asemenyuk at openjdk.org  Mon Feb 24 18:19:12 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 24 Feb 2025 18:19:12 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging [v2]
In-Reply-To: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
Message-ID: <YMOglLxAdTtYM1xCYTBOhgm6lu7rFl1ajvPNud9iCNk=.b9a7921e-85d6-41b7-ae16-6ae2ae07ebf3@github.com>

> - Fix the warning message about the custom installation directory location jpackage issues for DMG runtime packaging.
>  - Don't issue the warning when the `-install-dir` value equals the default installation directory location.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Fix bug with not running testDmg() tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23752/files
  - new: https://git.openjdk.org/jdk/pull/23752/files/bf4268da..afc341c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23752&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23752&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23752/head:pull/23752

PR: https://git.openjdk.org/jdk/pull/23752

From almatvee at openjdk.org  Mon Feb 24 18:20:54 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 24 Feb 2025 18:20:54 GMT
Subject: RFR: 8326447: jpackage creates Windows installers that cannot be
 signed [v3]
In-Reply-To: <XjISAKVpiB7S0DpTYiCjC2xbY5oXiZemnzFhy4zqDqA=.4f8b16e8-87d1-4181-9f98-5e356691f597@github.com>
References: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
 <XjISAKVpiB7S0DpTYiCjC2xbY5oXiZemnzFhy4zqDqA=.4f8b16e8-87d1-4181-9f98-5e356691f597@github.com>
Message-ID: <DizqNnex0uEjaqAibo3Y00lKKBTHXJXq8oDwZUN2lsc=.16eb02b7-8876-4e0c-98aa-2e84c6d5dbca@github.com>

On Sat, 22 Feb 2025 14:40:39 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Support the use of a custom msi wrapper executable when building an exe installer.
>> 
>> Put `installer.exe` file in the resource directory and jpackage will use it instead of the default `msiwrapper.exe` resource for exe installer.
>> 
>> To test this feature created a test that builds exe installer with a custom icon. The result installer exe is used as a custom msi wrapper executable in the second jpackage command that builds exe installer with the default icon. The installer exe produced by the second jackage command should have the same icon as the exe installer created in the first jpackage run.
>> 
>> Moved code verifying icons in executables from `LauncherIconVerifier.WinIconVerifier` class into `WinExecutableIconVerifier` class to make it available for tests. Replaced inline powershell script extracting icons from executables with standalone `read-executable-icon.ps1` powershell script. The script uses `ExtractIcon` instead of `ExtractAssociatedIcon`. It extracts icon from the executable's resources and will not fall back to anything if there is no icon resource.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep bundles produces by the test in the test work directory

Thanks for explanation. It makes sense now and fix is just to provide workaround for such cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23732#issuecomment-2679293267

From almatvee at openjdk.org  Mon Feb 24 18:26:00 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 24 Feb 2025 18:26:00 GMT
Subject: RFR: 8326447: jpackage creates Windows installers that cannot be
 signed [v3]
In-Reply-To: <XjISAKVpiB7S0DpTYiCjC2xbY5oXiZemnzFhy4zqDqA=.4f8b16e8-87d1-4181-9f98-5e356691f597@github.com>
References: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
 <XjISAKVpiB7S0DpTYiCjC2xbY5oXiZemnzFhy4zqDqA=.4f8b16e8-87d1-4181-9f98-5e356691f597@github.com>
Message-ID: <PyMBcgCxY8d9gPGycExurWoA2E9X8MjRPtUyI7WQjt0=.b3fd0ed1-1e80-4d8e-9905-a41fb67d06c4@github.com>

On Sat, 22 Feb 2025 14:40:39 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Support the use of a custom msi wrapper executable when building an exe installer.
>> 
>> Put `installer.exe` file in the resource directory and jpackage will use it instead of the default `msiwrapper.exe` resource for exe installer.
>> 
>> To test this feature created a test that builds exe installer with a custom icon. The result installer exe is used as a custom msi wrapper executable in the second jpackage command that builds exe installer with the default icon. The installer exe produced by the second jackage command should have the same icon as the exe installer created in the first jpackage run.
>> 
>> Moved code verifying icons in executables from `LauncherIconVerifier.WinIconVerifier` class into `WinExecutableIconVerifier` class to make it available for tests. Replaced inline powershell script extracting icons from executables with standalone `read-executable-icon.ps1` powershell script. The script uses `ExtractIcon` instead of `ExtractAssociatedIcon`. It extracts icon from the executable's resources and will not fall back to anything if there is no icon resource.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep bundles produces by the test in the test work directory

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23732#pullrequestreview-2638063655

From rriggs at openjdk.org  Mon Feb 24 19:10:02 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 24 Feb 2025 19:10:02 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v7]
In-Reply-To: <Y4xsaQoNZ448-1w0-OjJvAi5NidyaI5bLHAtRx_2Ovk=.2b5fc86b-ad1d-4b75-b51a-459fa5fd88e3@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <Y4xsaQoNZ448-1w0-OjJvAi5NidyaI5bLHAtRx_2Ovk=.2b5fc86b-ad1d-4b75-b51a-459fa5fd88e3@github.com>
Message-ID: <zbniE_PgMPvG0iCQWIN6hgMZj7vcpLTqIB_DSDP6Upc=.211ac7ec-ea4a-43b6-b712-d267ad049412@github.com>

On Sat, 22 Feb 2025 14:49:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use modifiers field directly in isInterface.

A nice simplification.

src/java.base/share/classes/java/lang/Class.java line 241:

> 239:     private Class(ClassLoader loader, Class<?> arrayComponentType, char mods, ProtectionDomain pd, boolean isPrim) {
> 240:         // Initialize final field for classLoader.  The initialization value of non-null
> 241:         // prevents future JIT optimizations from assuming this final field is null.

To add a bit more depth to this comment, I'd add.

"The following assignments are done directly by the VM without calling this constructor."
Or something to that effect.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23572#pullrequestreview-2638174546
PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1968254793

From liach at openjdk.org  Mon Feb 24 19:12:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 19:12:56 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v5]
In-Reply-To: <PPQFrU3yEH7Wmczr0MaDKOH3FPS9u-StaxnV039bgRQ=.7ee055bc-cda2-4a06-b963-9fded638d48c@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <vZc1-hha520B7-DQDt_mwe6WSyJvCcLqWzUk5htPvPY=.39186436-1b4b-49cb-be65-3a080d68d693@github.com>
 <Oc7I2MAVvFqtEBlJo32NDW0Zxg_rqRKD2Nxa2Baa5jI=.21251055-3bc8-4846-ac1f-2200dfa78d63@github.com>
 <wz9z1e5wkb-eDPnxOGFu-U2qSOfbrSwtMtnp2bQa7N0=.0f2f7b1e-ed82-44bc-94b8-c72d856dcef4@github.com>
 <ZvkO8f7M47mVW5rq9GvmCyDvhq_GN8SZiF6YObC2YF0=.2fc14752-55ed-4e68-b29b-46747f35c2ff@github.com>
 <xu7btviwlSp29qHVzlKb0kQvIskPjjnyVBEfXcw7SrI=.27ec6027-af39-48f6-95fd-c116df09cec2@github.com>
 <PPQFrU3yEH7Wmczr0MaDKOH3FPS9u-StaxnV039bgRQ=.7ee055bc-cda2-4a06-b963-9fded638d48c@github.com>
Message-ID: <cIIMBAIOznZq81h_SY8yiO8wgJILoLm8qNaNmyAOffU=.a5bcc287-163d-44cb-9526-b38c1b9f27aa@github.com>

On Mon, 24 Feb 2025 15:37:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Those read more like an @ApiNote, advice on how to use the API.
>
> @RogerRiggs - Is overriding a method and calling `super` considered a use of the API? Because these notes are only useful for people implemeting custom subclasses of Handler...

Yep, I think overriding methods are considered usages of API. Implementation applies to the exact method implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1968261372

From liach at openjdk.org  Mon Feb 24 19:13:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 19:13:54 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <8JTFy-f-rYCzlLbpHImCvEbWG7VCSnlUDG4MkAAHaa0=.cfb825a4-0124-4022-a1c8-15cb4d4b0697@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <8JTFy-f-rYCzlLbpHImCvEbWG7VCSnlUDG4MkAAHaa0=.cfb825a4-0124-4022-a1c8-15cb4d4b0697@github.com>
Message-ID: <EJJGa5hbTu2Cgl9gwSnCZEnSkxj5N2pHV3ALhqI6TPs=.0b1fb59c-5a71-43ef-b759-cc0e384a55a9@github.com>

On Mon, 24 Feb 2025 11:34:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 130:
> 
>> 128:      */
>> 129:     public static VarHandle makeRawSegmentViewVarHandle(MemoryLayout enclosing, ValueLayout layout, boolean noStride, long offset) {
>> 130:         if (enclosing instanceof ValueLayout direct) {
> 
> For now the caching is ok. Moving forrward, I wonder if we shouldn't add more reuse between field var handles in cases like these:
> 
> 
> struct Point {
>    int x; int y;
> }
> 
> 
> 
> struct Tuple {
>    int u; int v;
> }
> 
> 
> E.g. if I access the first field in these two structs, then the var handle will be identical? In a way, we use the enclosing layout for two reasons:
> 
> * to determine the size `S` of the accessed memory region
> * to determine the alignment `A` of the accessed memory region
> 
> So, if the static `offset`, accessed `layout`, `S` and `A` are the same for two accesses, we should probably reuse the same var handle instance? E.g. whether we access `x` in a `Point`, or `u` in a `Tuple` makes little difference.

I think direct var handles are quite cheap already and don't really need caching. What really worth caching should be the combinators and the VH derived from those combinators.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1968262515

From asemenyuk at openjdk.org  Mon Feb 24 19:25:04 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 24 Feb 2025 19:25:04 GMT
Subject: RFR: 8350601: Miscellaneous updates to jpackage test lib
Message-ID: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>

- Unify TKit.createTempDirectory() and TKit.createTempFile() functions. Remove `throws IOexception` from their signatures. Add relevant tests.
 - JPackageCommand.java: remove try/catch(IOexception) around `TKit.createTempDirectory()` call.
 - AppImagePackageTest.java: replace `TKit.createTempDirectory(null)` with `TKit.createTempDirectory("appimage")` to fix NPE.
 - Make `TKit.assertDirectoryExists(Path, Optional<Boolean>)` private. This is internal and shouldn't be exposed.
 - add `TKit.assertEquals(boolean, boolean)` and `TKit.assertNotEquals(boolean, boolean)` with tests.
 - AdditionalLauncher.java: remove redundant code duplicating functionality of `TKit.createTempFile()` (should have been cleaned long ago).
 - JPackageCommand.java: add a check for the main jar in the app image if the main jar was specified. Missing part of [JDK-8325089](https://bugs.openjdk.org/browse/JDK-8325089).

-------------

Commit messages:
 - Better test description and add tests for roles with dots
 - Merge branch 'master' into decouple-tkit
 - Test if the main jar is in the app image if specified.
 - Merge branch 'decouple-executor-result' into decouple-tkit
 - Merge branch 'decouple-fix-annotations' into decouple-executor-result
 - Fix javac error
 - Merge branch 'decouple-junit' into decouple-fix-annotations
 - Merge branch 'master' into decouple-junit
 - Remove redundant "return"
 - Fix merge
 - ... and 23 more: https://git.openjdk.org/jdk/compare/dfcd0df6...01fa2528

Changes: https://git.openjdk.org/jdk/pull/23754/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23754&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350601
  Stats: 251 lines in 5 files changed: 199 ins; 26 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/23754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23754/head:pull/23754

PR: https://git.openjdk.org/jdk/pull/23754

From rriggs at openjdk.org  Mon Feb 24 19:26:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 24 Feb 2025 19:26:58 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v5]
In-Reply-To: <cIIMBAIOznZq81h_SY8yiO8wgJILoLm8qNaNmyAOffU=.a5bcc287-163d-44cb-9526-b38c1b9f27aa@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <vZc1-hha520B7-DQDt_mwe6WSyJvCcLqWzUk5htPvPY=.39186436-1b4b-49cb-be65-3a080d68d693@github.com>
 <Oc7I2MAVvFqtEBlJo32NDW0Zxg_rqRKD2Nxa2Baa5jI=.21251055-3bc8-4846-ac1f-2200dfa78d63@github.com>
 <wz9z1e5wkb-eDPnxOGFu-U2qSOfbrSwtMtnp2bQa7N0=.0f2f7b1e-ed82-44bc-94b8-c72d856dcef4@github.com>
 <ZvkO8f7M47mVW5rq9GvmCyDvhq_GN8SZiF6YObC2YF0=.2fc14752-55ed-4e68-b29b-46747f35c2ff@github.com>
 <xu7btviwlSp29qHVzlKb0kQvIskPjjnyVBEfXcw7SrI=.27ec6027-af39-48f6-95fd-c116df09cec2@github.com>
 <PPQFrU3yEH7Wmczr0MaDKOH3FPS9u-StaxnV039bgRQ=.7ee055bc-cda2-4a06-b963-9fded638d48c@github.com>
 <cIIMBAIOznZq81h_SY8yiO8wgJILoLm8qNaNmyAOffU=.a5bcc287-163d-44cb-9526-b38c1b9f27aa@github.com>
Message-ID: <Ci0NqGJ1Gj5nx2ICSz-wzs4rhWZfOlvg-Mmrt4AYwQA=.8dfcf39b-8fef-4ead-a4e4-05f5cdbba114@github.com>

On Mon, 24 Feb 2025 19:10:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @RogerRiggs - Is overriding a method and calling `super` considered a use of the API? Because these notes are only useful for people implemeting custom subclasses of Handler...
>
> Yep, I think overriding methods are considered usages of API. Implementation applies to the exact method implementation.

There are elements of both implNote and ApiNote, maybe there is clarity in separating the descriptions into two notes. ImplNote says what it does and ApiNote says how to subclass. If both cases, the language of the prose is written to describe in one case and to recommend in the other. My observation was on the mixing of the two. I'm aware the version as written covering difficult to describe behaviors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1968295565

From asemenyuk at openjdk.org  Mon Feb 24 19:29:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 24 Feb 2025 19:29:57 GMT
Subject: RFR: 8350601: Miscellaneous updates to jpackage test lib
In-Reply-To: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
References: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
Message-ID: <yIxppSxuU9VS1BFRN9cugzh3PfyXWkISeUxW2c3gupg=.4393e032-eb6e-4fbb-9338-a8266a218005@github.com>

On Mon, 24 Feb 2025 19:18:27 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Unify TKit.createTempDirectory() and TKit.createTempFile() functions. Remove `throws IOexception` from their signatures. Add relevant tests.
>  - JPackageCommand.java: remove try/catch(IOexception) around `TKit.createTempDirectory()` call.
>  - AppImagePackageTest.java: replace `TKit.createTempDirectory(null)` with `TKit.createTempDirectory("appimage")` to fix NPE.
>  - Make `TKit.assertDirectoryExists(Path, Optional<Boolean>)` private. This is internal and shouldn't be exposed.
>  - add `TKit.assertEquals(boolean, boolean)` and `TKit.assertNotEquals(boolean, boolean)` with tests.
>  - AdditionalLauncher.java: remove redundant code duplicating functionality of `TKit.createTempFile()` (should have been cleaned long ago).
>  - JPackageCommand.java: add a check for the main jar in the app image if the main jar was specified. Missing part of [JDK-8325089](https://bugs.openjdk.org/browse/JDK-8325089).

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23754#issuecomment-2679446041

From coleenp at openjdk.org  Mon Feb 24 19:30:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Feb 2025 19:30:41 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v7]
In-Reply-To: <Y4xsaQoNZ448-1w0-OjJvAi5NidyaI5bLHAtRx_2Ovk=.2b5fc86b-ad1d-4b75-b51a-459fa5fd88e3@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <Y4xsaQoNZ448-1w0-OjJvAi5NidyaI5bLHAtRx_2Ovk=.2b5fc86b-ad1d-4b75-b51a-459fa5fd88e3@github.com>
Message-ID: <5i_vwoj0oivW08tMAX5Bp2m7yK_pgQOy0b7_MizQ-uM=.0f54046e-8972-4d05-89d6-aee42b079b48@github.com>

On Sat, 22 Feb 2025 14:49:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use modifiers field directly in isInterface.

Thanks for reviewing Roger.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23572#issuecomment-2679447427

From coleenp at openjdk.org  Mon Feb 24 19:30:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Feb 2025 19:30:41 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v8]
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <Da5eRkoxdxdezyjWC7_XfLct1aDhjd1ZtP6WPEZ5yis=.e4954c0d-91d7-47f3-a5f6-ec0afc0e8be2@github.com>

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add a comment about Class constructor.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23572/files
  - new: https://git.openjdk.org/jdk/pull/23572/files/db7c9782..591abdda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23572&range=06-07

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23572/head:pull/23572

PR: https://git.openjdk.org/jdk/pull/23572

From coleenp at openjdk.org  Mon Feb 24 19:30:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Feb 2025 19:30:41 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v7]
In-Reply-To: <zbniE_PgMPvG0iCQWIN6hgMZj7vcpLTqIB_DSDP6Upc=.211ac7ec-ea4a-43b6-b712-d267ad049412@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <Y4xsaQoNZ448-1w0-OjJvAi5NidyaI5bLHAtRx_2Ovk=.2b5fc86b-ad1d-4b75-b51a-459fa5fd88e3@github.com>
 <zbniE_PgMPvG0iCQWIN6hgMZj7vcpLTqIB_DSDP6Upc=.211ac7ec-ea4a-43b6-b712-d267ad049412@github.com>
Message-ID: <BBoia7Fs_qyBD_fYBoKdNLX7__DobS7vj7QWX_Dnyv0=.be23fc10-bf38-4d37-b623-6ed30ae59a62@github.com>

On Mon, 24 Feb 2025 19:06:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use modifiers field directly in isInterface.
>
> src/java.base/share/classes/java/lang/Class.java line 241:
> 
>> 239:     private Class(ClassLoader loader, Class<?> arrayComponentType, char mods, ProtectionDomain pd, boolean isPrim) {
>> 240:         // Initialize final field for classLoader.  The initialization value of non-null
>> 241:         // prevents future JIT optimizations from assuming this final field is null.
> 
> To add a bit more depth to this comment, I'd add.
> 
> "The following assignments are done directly by the VM without calling this constructor."
> Or something to that effect.

Okay, that's a good comment.  I'll add it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23572#discussion_r1968297499

From liach at openjdk.org  Mon Feb 24 19:31:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 19:31:56 GMT
Subject: RFR: 8350518: org.openjdk.bench.java.util.TreeMapUpdate.compute
 fails with  "java.lang.IllegalArgumentException: key out of range"
In-Reply-To: <sUX5c-b5uzJ7biA1mOTwB_DuXU9kJwU1CZwA26NZysM=.67ea4b42-ebd6-44ad-a344-d8b06806c21f@github.com>
References: <sUX5c-b5uzJ7biA1mOTwB_DuXU9kJwU1CZwA26NZysM=.67ea4b42-ebd6-44ad-a344-d8b06806c21f@github.com>
Message-ID: <sYU-1DkqTcl0D1vp4INiAA0W20XJSZORhRJ-6qC0Xuo=.7b091bd3-26e1-4f4b-941c-18e9c79797a7@github.com>

On Mon, 24 Feb 2025 08:44:00 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> It appears that the benchmark was erroneous. The combination of "tailMap" mode and comparator = true didn't work correctly, as the comparator is descending. This PR changes the benchmark to use headMap instead of tailMap in comparator mode. The "tailMap" mode is renamed to "subMap". Now, all parameter combinations work correctly.

This file needs a copyright year update, from `(c) 2020, Oracle` to `(c) 2020, 2025, Oracle`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23744#pullrequestreview-2638249150

From naoto at openjdk.org  Mon Feb 24 19:52:32 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Feb 2025 19:52:32 GMT
Subject: RFR: 8345213: JVM Prefers /etc/timezone Over /etc/localtime on Debian
 12
Message-ID: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>

Removing the support for /etc/timezone file that is Debian distro specific. The file is no longer considered authoritative (https://wiki.debian.org/TimeZoneChanges#Check_Configured_Timezone), and in fact, it is now out of sync as the bug reports. The fix was confirmed manually on a Ubuntu 25.04.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/23755/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23755&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345213
  Stats: 30 lines in 1 file changed: 0 ins; 28 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23755.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23755/head:pull/23755

PR: https://git.openjdk.org/jdk/pull/23755

From asemenyuk at openjdk.org  Mon Feb 24 19:58:25 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 24 Feb 2025 19:58:25 GMT
Subject: RFR: 8350601: Miscellaneous updates to jpackage test lib [v2]
In-Reply-To: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
References: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
Message-ID: <PUhkCVNFPWLOzV6_jkuUtX3Wkfi5qBnzeYotGigCXPA=.8ac7a114-55e4-4928-8627-df641ca64a4a@github.com>

> - Unify TKit.createTempDirectory() and TKit.createTempFile() functions. Remove `throws IOexception` from their signatures. Add relevant tests.
>  - JPackageCommand.java: remove try/catch(IOexception) around `TKit.createTempDirectory()` call.
>  - AppImagePackageTest.java: replace `TKit.createTempDirectory(null)` with `TKit.createTempDirectory("appimage")` to fix NPE.
>  - Make `TKit.assertDirectoryExists(Path, Optional<Boolean>)` private. This is internal and shouldn't be exposed.
>  - add `TKit.assertEquals(boolean, boolean)` and `TKit.assertNotEquals(boolean, boolean)` with tests.
>  - AdditionalLauncher.java: remove redundant code duplicating functionality of `TKit.createTempFile()` (should have been cleaned long ago).
>  - JPackageCommand.java: add a check for the main jar in the app image if the main jar was specified. Missing part of [JDK-8325089](https://bugs.openjdk.org/browse/JDK-8325089).

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Better log message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23754/files
  - new: https://git.openjdk.org/jdk/pull/23754/files/01fa2528..e1a7d43c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23754&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23754&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23754/head:pull/23754

PR: https://git.openjdk.org/jdk/pull/23754

From dfuchs at openjdk.org  Mon Feb 24 20:10:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Feb 2025 20:10:54 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v5]
In-Reply-To: <Ci0NqGJ1Gj5nx2ICSz-wzs4rhWZfOlvg-Mmrt4AYwQA=.8dfcf39b-8fef-4ead-a4e4-05f5cdbba114@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <vZc1-hha520B7-DQDt_mwe6WSyJvCcLqWzUk5htPvPY=.39186436-1b4b-49cb-be65-3a080d68d693@github.com>
 <Oc7I2MAVvFqtEBlJo32NDW0Zxg_rqRKD2Nxa2Baa5jI=.21251055-3bc8-4846-ac1f-2200dfa78d63@github.com>
 <wz9z1e5wkb-eDPnxOGFu-U2qSOfbrSwtMtnp2bQa7N0=.0f2f7b1e-ed82-44bc-94b8-c72d856dcef4@github.com>
 <ZvkO8f7M47mVW5rq9GvmCyDvhq_GN8SZiF6YObC2YF0=.2fc14752-55ed-4e68-b29b-46747f35c2ff@github.com>
 <xu7btviwlSp29qHVzlKb0kQvIskPjjnyVBEfXcw7SrI=.27ec6027-af39-48f6-95fd-c116df09cec2@github.com>
 <PPQFrU3yEH7Wmczr0MaDKOH3FPS9u-StaxnV039bgRQ=.7ee055bc-cda2-4a06-b963-9fded638d48c@github.com>
 <cIIMBAIOznZq81h_SY8yiO8wgJILoLm8qNaNmyAOffU=.a5bcc287-163d-44cb-9526-b38c1b9f27aa@github.com>
 <Ci0NqGJ1Gj5nx2ICSz-wzs4rhWZfOlvg-Mmrt4AYwQA=.8dfcf39b-8fef-4ead-a4e4-05f5cdbba114@github.com>
Message-ID: <7E1jL9QojzMY2KbzEzjcH9w692axor_UFGSI83kH2dQ=.d18d62a1-8734-49bb-bdf2-55e43d355f77@github.com>

On Mon, 24 Feb 2025 19:24:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Yep, I think overriding methods are considered usages of API. Implementation applies to the exact method implementation.
>
> There are elements of both implNote and ApiNote, maybe there is clarity in separating the descriptions into two notes. ImplNote says what it does and ApiNote says how to subclass. If both cases, the language of the prose is written to describe in one case and to recommend in the other. My observation was on the mixing of the two. I'm aware the version as written covering difficult to describe behaviors.

I am not sure whether splitting would bring clarity or would make it harder to read. `@apiNote` and `@implNote` are separate sections in the API documentation, so at the minimum a split may require adding some links in both directions. I have the feeling that having the text in a single section might be preferable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1968346862

From asemenyuk at openjdk.org  Mon Feb 24 20:29:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 24 Feb 2025 20:29:09 GMT
Subject: RFR: 8350601: Miscellaneous updates to jpackage test lib [v3]
In-Reply-To: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
References: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
Message-ID: <0FwuZfTqsEtFdRbEtS3OSpdFtUgx5Q6ky3PiRN1EYXY=.a4617553-a64e-4d0f-8b9a-5b6c819dab37@github.com>

> - Unify TKit.createTempDirectory() and TKit.createTempFile() functions. Remove `throws IOexception` from their signatures. Add relevant tests.
>  - JPackageCommand.java: remove try/catch(IOexception) around `TKit.createTempDirectory()` call.
>  - AppImagePackageTest.java: replace `TKit.createTempDirectory(null)` with `TKit.createTempDirectory("appimage")` to fix NPE.
>  - Make `TKit.assertDirectoryExists(Path, Optional<Boolean>)` private. This is internal and shouldn't be exposed.
>  - add `TKit.assertEquals(boolean, boolean)` and `TKit.assertNotEquals(boolean, boolean)` with tests.
>  - AdditionalLauncher.java: remove redundant code duplicating functionality of `TKit.createTempFile()` (should have been cleaned long ago).
>  - JPackageCommand.java: add a check for the main jar in the app image if the main jar was specified. Missing part of [JDK-8325089](https://bugs.openjdk.org/browse/JDK-8325089).

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Copyright year update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23754/files
  - new: https://git.openjdk.org/jdk/pull/23754/files/e1a7d43c..71072247

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23754&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23754&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23754/head:pull/23754

PR: https://git.openjdk.org/jdk/pull/23754

From dlong at openjdk.org  Mon Feb 24 21:09:57 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 24 Feb 2025 21:09:57 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v8]
In-Reply-To: <Da5eRkoxdxdezyjWC7_XfLct1aDhjd1ZtP6WPEZ5yis=.e4954c0d-91d7-47f3-a5f6-ec0afc0e8be2@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <Da5eRkoxdxdezyjWC7_XfLct1aDhjd1ZtP6WPEZ5yis=.e4954c0d-91d7-47f3-a5f6-ec0afc0e8be2@github.com>
Message-ID: <bLz8_HfrtBGMU5bk3p1wWEdYslpHx1kS4pYEtgfSrTw=.8842f20c-1b14-427e-b026-f4c3420ce45b@github.com>

On Mon, 24 Feb 2025 19:30:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment about Class constructor.

Marked as reviewed by dlong (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23572#pullrequestreview-2638441924

From schernyshev at openjdk.org  Mon Feb 24 21:20:49 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 24 Feb 2025 21:20:49 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
Message-ID: <QV8_TSQ8Ym5RE65TyC3cIlyTsB-vNxO5oRpnCvkRCwU=.cb32334b-6d40-4801-9a4b-1521756cbadf@github.com>

On Mon, 17 Feb 2025 14:04:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> `CgroupV1Controller::set_subsystem_path` needs high level comment update to describe the logic happening.
> 

Done, added

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2679664923

From schernyshev at openjdk.org  Mon Feb 24 21:20:49 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 24 Feb 2025 21:20:49 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v15]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <jPiUQFkkA_7ELb36w5iT9aI0SZyW67azvVcO_Y6kpmA=.43bd87a6-8e61-40a3-ac47-938ef992784d@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:

 - added high level comment to CgroupV1Controller::set_subsystem_path
 - fix minor issue calling .getNameCount() twice

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/28122ff9..3568c138

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=13-14

  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From schernyshev at openjdk.org  Mon Feb 24 21:20:50 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 24 Feb 2025 21:20:50 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <E4B7c1WLUyhHGmEaox71qVNbypKMw_Hdo1dKU_RQcMY=.db21dfe9-e676-4ac6-b954-19bc40b64268@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
 <OObfj4QWk_Q3Fk2-mDJbpfeFNhOAbgEmDB-IBehjR4c=.672abfeb-fc3f-4c68-ad0d-693ac0eb7bcd@github.com>
 <E4B7c1WLUyhHGmEaox71qVNbypKMw_Hdo1dKU_RQcMY=.db21dfe9-e676-4ac6-b954-19bc40b64268@github.com>
Message-ID: <V7oEjruvb8foydYDCIvuupWtILQUk2S13hK5y5FWqys=.b32faff6-fb66-44eb-be04-656edf02f7ae@github.com>

On Fri, 21 Feb 2025 20:05:07 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Good catch, but as long as cgp#nameCount may change in the loop, this exact patch i cannot take.
>
> How about this?
> 
> int currentNameCount = cgp.getNameCount();
> cgp = (currentNameCount > 1) ? cgp.subpath(1, currentNameCount) : Path.of("");

I tested the builds with the above change. It seems to be doing the thing. Please see the updated PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1968429793

From joehw at openjdk.org  Mon Feb 24 21:33:58 2025
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 24 Feb 2025 21:33:58 GMT
Subject: RFR: 8345213: JVM Prefers /etc/timezone Over /etc/localtime on
 Debian 12
In-Reply-To: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
References: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
Message-ID: <EQTl43doHUcISlA4Ixf1S-wnjbM0pdnE37GP5bWFamo=.0dbae38f-0f94-49cb-bac9-928f726cc8e3@github.com>

On Mon, 24 Feb 2025 19:46:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the support for /etc/timezone file that is Debian distro specific. The file is no longer considered authoritative (https://wiki.debian.org/TimeZoneChanges#Check_Configured_Timezone), and in fact, it is now out of sync as the bug reports. The fix was confirmed manually on a Ubuntu 25.04.

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23755#pullrequestreview-2638486942

From almatvee at openjdk.org  Mon Feb 24 22:38:55 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 24 Feb 2025 22:38:55 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging [v2]
In-Reply-To: <YMOglLxAdTtYM1xCYTBOhgm6lu7rFl1ajvPNud9iCNk=.b9a7921e-85d6-41b7-ae16-6ae2ae07ebf3@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <YMOglLxAdTtYM1xCYTBOhgm6lu7rFl1ajvPNud9iCNk=.b9a7921e-85d6-41b7-ae16-6ae2ae07ebf3@github.com>
Message-ID: <oRWVWBdi3kSQRqK4dGm7dQiBlvN6SCoe97zc2_1Pjgg=.e409ad86-5cb2-45bc-9189-f52e0854042b@github.com>

On Mon, 24 Feb 2025 18:19:12 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Fix the warning message about the custom installation directory location jpackage issues for DMG runtime packaging.
>>  - Don't issue the warning when the `-install-dir` value equals the default installation directory location.
>>  - Add relevant tests.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug with not running testDmg() tests

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 94:

> 92: message.signing.pkg=Warning: For signing PKG, you might need to set "Always Trust" for your certificate using "Keychain Access" tool.
> 93: message.setfile.dmg=Setting custom icon on DMG file skipped because 'SetFile' utility was not found. Installing Xcode with Command Line Tools should resolve this issue.
> 94: message.install-dir-ignored=Warning: "--install-dir" is not supported by DMG and will be default to {0}.

I think it is better to change message to "Warning: "--install-dir" value "{0}" is not supported by DMG and will be default to {1}." Currently it sounds that CLI option "--install-dir" is not supported, but it will work if it points to default location.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23752#discussion_r1968497236

From liach at openjdk.org  Mon Feb 24 22:56:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 22:56:03 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant
Message-ID: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>

LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.

There may need to be additional intrinsic work for MH combinator lf bytecode generation.

-------------

Commit messages:
 - Years, roll back unrelated changes
 - Simplify constant making
 - Years
 - Eliminate zero form
 - Special LF treatment for MHs.constant

Changes: https://git.openjdk.org/jdk/pull/23706/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23706&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350607
  Stats: 260 lines in 9 files changed: 86 ins; 116 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/23706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23706/head:pull/23706

PR: https://git.openjdk.org/jdk/pull/23706

From jrose at openjdk.org  Mon Feb 24 22:56:04 2025
From: jrose at openjdk.org (John R Rose)
Date: Mon, 24 Feb 2025 22:56:04 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant
In-Reply-To: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
Message-ID: <6w803Bt-p9pjcWwrgqxGZ8g9-1re_n8h21cL-VFagsw=.90fff225-ee93-4ee7-9059-b945b9e9a6ce@github.com>

On Thu, 20 Feb 2025 02:33:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.
> 
> There may need to be additional intrinsic work for MH combinator lf bytecode generation.

You are on the right track.  Some of the details don?t look right to me, so I left comments on the PR.

 I realize it is tricky to get this stuff bootstrapped, and sometimes it helps to copy initialization code to avoid hitting a common path too soon.  But I think the right answer here is probably to lean hard on common paths in BMH, for both the zero and the constant cases.

Another matter:  The intrinsicData thingy bothers me.  Do we really need to use it?  Why not just have a clean identity NF, and then call NF(mycon) in a LF?

It looks like intrinsicData is under-used, and perhaps can be removed completely.  It only carries the length of a lookup table, before this PR??  If so, I?d support lazily making N different NFs for table lookup, for each table arity in N. (I.e., N names, not one name, and no side-data.)  But maybe that would be equally bad.

Anyway, those are my first reactions.  Thanks!

src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1653:

> 1651:     }
> 1652: 
> 1653:     private static LambdaForm computeConstantForm(BasicType type) {

I think the word "create" is more conventional, at this point, than "compute".
When you are finding some lazily computed resource, you create it if not present.
There is "computeInvoker" and "computeValueConversions" elsewhere, but I think "create" is more frequent.

src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1665:

> 1663:         if (cached != null)
> 1664:             return cached;
> 1665:         return BASIC_SPECIES[ord] = SimpleMethodHandle.BMH_SPECIES.extendWith(type);

It's not clear to me what `BASIC_SPECIES` means here.  BMH species exist which correspond to all non-empty tuples of bound types.  So maybe what you are caching here is unary BMH species?  In that case `UNARY_BMH_SPECIES` might be more to the point.  Even better, place that array in BMH.java itself, call it `BoundMethodHandle.UNARY_SPECIES`, and give it a name `BoundMethodHandle.unarySpeciesData(BasicType)`.

src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1691:

> 1689: 
> 1690:             // Look up symbolic names.  It might not be necessary to have these,
> 1691:             // but if we need to emit direct references to bytecodes, it helps.

Rename `createFormsFor` to `createIdentityForm`, since it now only creates that one thing (plus its NF).

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1347:

> 1345:         IDENTITY,
> 1346:         CONSTANT,
> 1347:         NONE // no intrinsic associated

I notice you are using the `intrinsicData` property to keep track of the constant, which is a good call.

A little below here, around line 1400, there is a possible bug in the handling of `intrinsicData`.

Possible fix:


--- a/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
@@ -1409,7 +1409,8 @@ static MethodHandle makeIntrinsic(MethodHandle target, Intrinsic intrinsicName)
     }
 
     static MethodHandle makeIntrinsic(MethodHandle target, Intrinsic intrinsicName, Object intrinsicData) {
-        if (intrinsicName == target.intrinsicName())
+        if (intrinsicName == target.intrinsicName() &&
+            intrinsicData == target.intrinsicData())
             return target;
         return new IntrinsicMethodHandle(target, intrinsicName, intrinsicData);
     }


It should be added to this PR, lest constants get confused somehow.

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 2307:

> 2305:     }
> 2306: 
> 2307:     static MethodHandle makeConstantI(Wrapper type, int value) {

After going over the rest of the patch, I don't think these new factories pull their weight.

They just duplicate what the BMH species factories do when adding the first bound value.

If the BMH factories don't do this job, they should be changed so they can handle it.

In other words, the details of BMH factory invocation should be kept inside the BMH files (or SMH, which is the null case of BMH).

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4946:

> 4944:         } else if (bt == BasicType.D_TYPE) {
> 4945:             return MethodHandleImpl.makeConstantD(0.0D);
> 4946:         }

This if/then/else over basic types is unpleasantly messy, just to handle one-time creation for a cached zero MH.

I suggest using `bt.basicTypeWrapper().zero()` to get the zero value generically, and then use generic binding logic such as `MHs::insertArguments` or `insertArgumentPrimitive`, just like `MHs::constant` does.  Calling `makeConstantJ` and siblings seems like a code smell.  Is there a way to get rub of `makeConstantX` and instead generalize the `insertArguments` protocols which creates BMHs?

src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java line 75:

> 73:             LF_INVINTERFACE            =  4,
> 74:             LF_INVSTATIC_INIT          =  5,  // DMH invokeStatic with <clinit> barrier
> 75:             LF_INTERPRET               =  6,  // LF interpreter, only its vmentry is used

Unrelated change here?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23706#pullrequestreview-2634451086
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1966311674
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1966322804
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1966326986
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1966306954
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1966339208
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1966337750
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1966338094

From liach at openjdk.org  Mon Feb 24 22:56:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 22:56:04 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant
In-Reply-To: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
Message-ID: <8ak-I_zY-QoTQwBsaynxZ88e0SZQOJ98ojwtrXQEP8E=.db4e1df6-43d2-4e37-8aeb-ce67162a98e5@github.com>

On Thu, 20 Feb 2025 02:33:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.
> 
> There may need to be additional intrinsic work for MH combinator lf bytecode generation.

I think this version should be fine: Perfstartup-LambdaNoop's `MethodHandle.constant` instructions have decreased from 99032 to 48507 by eliding the generation of a LF via LambdaFormEditor. Tests seem to be fine too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23706#issuecomment-2679834729

From liach at openjdk.org  Mon Feb 24 22:56:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 22:56:05 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant
In-Reply-To: <6w803Bt-p9pjcWwrgqxGZ8g9-1re_n8h21cL-VFagsw=.90fff225-ee93-4ee7-9059-b945b9e9a6ce@github.com>
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 <6w803Bt-p9pjcWwrgqxGZ8g9-1re_n8h21cL-VFagsw=.90fff225-ee93-4ee7-9059-b945b9e9a6ce@github.com>
Message-ID: <cLEffDad1CuNGyHo5cfI86E5-CrzGQz7WSBaLazVhCU=.0cba62ea-c42d-464c-8a67-3e73b827b5b0@github.com>

On Fri, 21 Feb 2025 23:17:50 GMT, John R Rose <jrose at openjdk.org> wrote:

>> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.
>> 
>> There may need to be additional intrinsic work for MH combinator lf bytecode generation.
>
> src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1653:
> 
>> 1651:     }
>> 1652: 
>> 1653:     private static LambdaForm computeConstantForm(BasicType type) {
> 
> I think the word "create" is more conventional, at this point, than "compute".
> When you are finding some lazily computed resource, you create it if not present.
> There is "computeInvoker" and "computeValueConversions" elsewhere, but I think "create" is more frequent.

Renamed to `createConstantForm`.

> src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1665:
> 
>> 1663:         if (cached != null)
>> 1664:             return cached;
>> 1665:         return BASIC_SPECIES[ord] = SimpleMethodHandle.BMH_SPECIES.extendWith(type);
> 
> It's not clear to me what `BASIC_SPECIES` means here.  BMH species exist which correspond to all non-empty tuples of bound types.  So maybe what you are caching here is unary BMH species?  In that case `UNARY_BMH_SPECIES` might be more to the point.  Even better, place that array in BMH.java itself, call it `BoundMethodHandle.UNARY_SPECIES`, and give it a name `BoundMethodHandle.unarySpeciesData(BasicType)`.

I just noticed `BMH$SpeciesData.extensions` is a stable array, so we can just query `SimpleMethodHandle.BMH_SPECIES` (aka `BMH.SPECIALIZER.topSpecies`)'s `extendWith` and use that stable array instead.

> src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1691:
> 
>> 1689: 
>> 1690:             // Look up symbolic names.  It might not be necessary to have these,
>> 1691:             // but if we need to emit direct references to bytecodes, it helps.
> 
> Rename `createFormsFor` to `createIdentityForm`, since it now only creates that one thing (plus its NF).

Done.

> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1347:
> 
>> 1345:         IDENTITY,
>> 1346:         CONSTANT,
>> 1347:         NONE // no intrinsic associated
> 
> I notice you are using the `intrinsicData` property to keep track of the constant, which is a good call.
> 
> A little below here, around line 1400, there is a possible bug in the handling of `intrinsicData`.
> 
> Possible fix:
> 
> 
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
> @@ -1409,7 +1409,8 @@ static MethodHandle makeIntrinsic(MethodHandle target, Intrinsic intrinsicName)
>      }
>  
>      static MethodHandle makeIntrinsic(MethodHandle target, Intrinsic intrinsicName, Object intrinsicData) {
> -        if (intrinsicName == target.intrinsicName())
> +        if (intrinsicName == target.intrinsicName() &&
> +            intrinsicData == target.intrinsicData())
>              return target;
>          return new IntrinsicMethodHandle(target, intrinsicName, intrinsicData);
>      }
> 
> 
> It should be added to this PR, lest constants get confused somehow.

I reviewed the other use of `intrinsicData`, `tableSwitch`. I believe the intrinsic is actually a regression by growing the bytecode size - we should just select a MH via hash table lookup and invoke that MH, given all MHs in that list have the same type. I have removed the use of intrinsic data here and we can move on to remove it later.

I noticed that intrinsics are useful really only as part of named functions. And named functions only reuse arbitrary MHs for the invoker form. Is my understanding here correct?

> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 2307:
> 
>> 2305:     }
>> 2306: 
>> 2307:     static MethodHandle makeConstantI(Wrapper type, int value) {
> 
> After going over the rest of the patch, I don't think these new factories pull their weight.
> 
> They just duplicate what the BMH species factories do when adding the first bound value.
> 
> If the BMH factories don't do this job, they should be changed so they can handle it.
> 
> In other words, the details of BMH factory invocation should be kept inside the BMH files (or SMH, which is the null case of BMH).

Addressed in the same way as for https://github.com/openjdk/jdk/pull/23706#discussion_r1968478226

> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4946:
> 
>> 4944:         } else if (bt == BasicType.D_TYPE) {
>> 4945:             return MethodHandleImpl.makeConstantD(0.0D);
>> 4946:         }
> 
> This if/then/else over basic types is unpleasantly messy, just to handle one-time creation for a cached zero MH.
> 
> I suggest using `bt.basicTypeWrapper().zero()` to get the zero value generically, and then use generic binding logic such as `MHs::insertArguments` or `insertArgumentPrimitive`, just like `MHs::constant` does.  Calling `makeConstantJ` and siblings seems like a code smell.  Is there a way to get rub of `makeConstantX` and instead generalize the `insertArguments` protocols which creates BMHs?

I moved the binding logic to be with `BMH::bindSingle` and renamed the original bindSingle to be bindSingleL. It should reduce code smell a little bit; will push soon ?

> src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java line 75:
> 
>> 73:             LF_INVINTERFACE            =  4,
>> 74:             LF_INVSTATIC_INIT          =  5,  // DMH invokeStatic with <clinit> barrier
>> 75:             LF_INTERPRET               =  6,  // LF interpreter, only its vmentry is used
> 
> Unrelated change here?

Indeed, however its dummy LF used the zero NF and required some updates :( Wish we can just cache it as a MemberName

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1968532132
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1968472249
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1968500456
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1968485136
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1968479670
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1968478226
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1968479177

From almatvee at openjdk.org  Mon Feb 24 23:03:52 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 24 Feb 2025 23:03:52 GMT
Subject: RFR: 8350601: Miscellaneous updates to jpackage test lib [v3]
In-Reply-To: <0FwuZfTqsEtFdRbEtS3OSpdFtUgx5Q6ky3PiRN1EYXY=.a4617553-a64e-4d0f-8b9a-5b6c819dab37@github.com>
References: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
 <0FwuZfTqsEtFdRbEtS3OSpdFtUgx5Q6ky3PiRN1EYXY=.a4617553-a64e-4d0f-8b9a-5b6c819dab37@github.com>
Message-ID: <2pIkTcwmKLSzk1fFtX2wdnEUtCox2YgK9lXTbexfy_0=.157ff385-01ae-4950-b2d7-7f0200a7dace@github.com>

On Mon, 24 Feb 2025 20:29:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Unify TKit.createTempDirectory() and TKit.createTempFile() functions. Remove `throws IOexception` from their signatures. Add relevant tests.
>>  - JPackageCommand.java: remove try/catch(IOexception) around `TKit.createTempDirectory()` call.
>>  - AppImagePackageTest.java: replace `TKit.createTempDirectory(null)` with `TKit.createTempDirectory("appimage")` to fix NPE.
>>  - Make `TKit.assertDirectoryExists(Path, Optional<Boolean>)` private. This is internal and shouldn't be exposed.
>>  - add `TKit.assertEquals(boolean, boolean)` and `TKit.assertNotEquals(boolean, boolean)` with tests.
>>  - AdditionalLauncher.java: remove redundant code duplicating functionality of `TKit.createTempFile()` (should have been cleaned long ago).
>>  - JPackageCommand.java: add a check for the main jar in the app image if the main jar was specified. Missing part of [JDK-8325089](https://bugs.openjdk.org/browse/JDK-8325089).
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year update

Looks fine overall. I left one comment.

test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/TKitTest.java line 232:

> 230:             if ((expectedExceptionClass == null) == (expectedPath == null)) {
> 231:                 throw new IllegalArgumentException("Only one of `expectedPath` and `expectedExceptionClass` can be null");
> 232:             }

This one is confusing. It will evaluate to true if both != null. Did you mean "&&" instead of "=="?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23754#pullrequestreview-2638639705
PR Review Comment: https://git.openjdk.org/jdk/pull/23754#discussion_r1968536523

From schernyshev at openjdk.org  Mon Feb 24 23:35:58 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 24 Feb 2025 23:35:58 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
Message-ID: <tJ3zjnmJ1lKiQR8c6dhE_kGUR9qr75rWZmvsnMh-_8w=.5a75cd5c-fd8d-4336-a0e6-7d98fe69c0ae@github.com>

On Mon, 17 Feb 2025 14:04:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those.

The subgroup path reduction is covered by `TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` (it wouldn't be possible in gtests as it requires touching cgroup tree on a host system). It actually checks that the subgroup directory exists and skips non-existent directories, that is reflected in the test log below. The bottom line comes from `CgroupV1Controller::set_subsystem_path`.

========== NEW TEST CASE:      Cgroup V1 subgroup memory limit: 100m
[COMMAND]
docker run --tty=true --rm --privileged --cgroupns=host --memory 200m jdk-internal:test-containers-docker-TestMemoryWithSubgroups-subgroup sh -c mkdir -p /sys/fs/cgroup/memory/test ; echo 100m > /sys/fs/cgroup/memory/test/memory.limit_in_bytes ; echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs ; /jdk/bin/java -Xlog:os+container=trace -version
[2025-02-24T22:33:28.049656218Z] Gathering output for process 23369
[ELAPSED: 5385 ms]
[STDERR]

[STDOUT]
[0.002s][trace][os,container] OSContainer::init: Initializing Container Support
[0.003s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
[0.004s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
[0.004s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test.

With additional logging added before line 77, this could be looking like

[STDOUT]
[0.002s][trace][os,container] OSContainer::init: Initializing Container Support
[0.002s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
[0.003s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
[0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test.
[0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test.
[0.005s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test.

Before the fix, the current path adjustment scheme would produce the following order:

/sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test
/sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370
/sys/fs/cgroup/memory/docker
/sys/fs/cgroup/memory

Only the last path is valid in the container, others are non-existent. The result will be 200m, while the correct is 100m.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2679936058

From liach at openjdk.org  Mon Feb 24 23:45:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 23:45:37 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
Message-ID: <fc3PZJ4V4V5SHyLJVfRYzRL6AhHiI7yJUMeM7bgoZhI=.5b31249a-b4d4-42e3-8204-fea187c1aff5@github.com>

> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.
> 
> There may need to be additional intrinsic work for MH combinator lf bytecode generation.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  We no longer load DelegateMH as we no longer rebind

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23706/files
  - new: https://git.openjdk.org/jdk/pull/23706/files/6f5c8873..beee1ad6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23706&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23706&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23706/head:pull/23706

PR: https://git.openjdk.org/jdk/pull/23706

From liach at openjdk.org  Mon Feb 24 23:51:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 23:51:04 GMT
Subject: RFR: 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe
Message-ID: <NLQLZm3c6l5ympapbv_5zWH8rNo8zhGchZrvq7hie9k=.e5e8b256-1a9c-42c0-ac58-8b6416937f39@github.com>

Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.

-------------

Commit messages:
 - 8350549: MethodHandleProxies.WRAPPER_TYPES is not thread-safe

Changes: https://git.openjdk.org/jdk/pull/23757/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23757&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350549
  Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23757/head:pull/23757

PR: https://git.openjdk.org/jdk/pull/23757

From psandoz at openjdk.org  Tue Feb 25 00:02:53 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 25 Feb 2025 00:02:53 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <Zzk64psydzXMRGpewo7BcvKmqBOwFL5cT0kgkXvY6GI=.b0def6d9-53ec-4be7-af67-d91354135546@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <x9ETYwOSiE2ZfaP4xus4S6WppTevakAr0hHsRlA7YF8=.a22172e1-e5b5-42f9-9d92-2df2e09fdb05@github.com>
 <52HO_iL9asn1huCdJj82R1AwF1w8ON9HZetrdc9rQyQ=.28e137e0-a7f7-4839-a3e7-eda4f8a6c4f5@github.com>
 <Zzk64psydzXMRGpewo7BcvKmqBOwFL5cT0kgkXvY6GI=.b0def6d9-53ec-4be7-af67-d91354135546@github.com>
Message-ID: <xWPOEnpk0__054Vd9w7LnkBpHvWdwKtjhjE69b3rwoY=.420231ab-1323-45ef-bcb8-179af701583d@github.com>

On Mon, 17 Feb 2025 06:40:11 GMT, Nicole Xu <duke at openjdk.org> wrote:

>> Please try with following command line
>> `java -jar target/benchmarks.jar -f 1 -i 2 -wi 1 -w 30 -p ARRAYLEN=30 MaskedLogic`
>
> Thanks for pointing that out. Typically, ARRAYLEN is almost always a POT value, which is also assumed by many other benchmarks. Are we realistically going to test with an ARRAYLEN of 30? 
> 
> I think the POT assumption is reasonable for our purposes.

It's a reasonable assumption. Since `ARRAYLEN` is a parameter of the benchmark we should enforce that constraint in benchmark initialization method, checking if the value is POT and failing otherwise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22963#discussion_r1968595640

From smarks at openjdk.org  Tue Feb 25 00:54:24 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 25 Feb 2025 00:54:24 GMT
Subject: RFR: 8138614: (spec str) StringBuffer and StringBuilder methods
 improperly require "new" String to be returned [v3]
In-Reply-To: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
References: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
Message-ID: <mXP7Jz7SBUKAxK4auIlz39PbXrYEe_5VjRLBhq0sbLI=.e6e3021e-1ac6-4f4e-95f7-dfda3221a3d4@github.com>

> A couple adjustments to the specs for four methods of StringBuilder and StringBuffer so that they no longer require new Strings to be created, just a String with the right contents. No implementation changes. Note that the actual specs (and implementations) are actually in AbstractStringBuilder, and they're inherited by StringBuilder and StringBuffer.

Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8138614-relax-new-string-requirement
 - A tiny bit of wordsmithing.
 - 8138614: Relax StringBuilder/StringBuffer requirement to create new Strings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23599/files
  - new: https://git.openjdk.org/jdk/pull/23599/files/0633c022..f4aed5d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23599&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23599&range=01-02

  Stats: 25683 lines in 1009 files changed: 16035 ins; 6300 del; 3348 mod
  Patch: https://git.openjdk.org/jdk/pull/23599.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23599/head:pull/23599

PR: https://git.openjdk.org/jdk/pull/23599

From asemenyuk at openjdk.org  Tue Feb 25 01:02:54 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Feb 2025 01:02:54 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging [v2]
In-Reply-To: <oRWVWBdi3kSQRqK4dGm7dQiBlvN6SCoe97zc2_1Pjgg=.e409ad86-5cb2-45bc-9189-f52e0854042b@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <YMOglLxAdTtYM1xCYTBOhgm6lu7rFl1ajvPNud9iCNk=.b9a7921e-85d6-41b7-ae16-6ae2ae07ebf3@github.com>
 <oRWVWBdi3kSQRqK4dGm7dQiBlvN6SCoe97zc2_1Pjgg=.e409ad86-5cb2-45bc-9189-f52e0854042b@github.com>
Message-ID: <95_ax6JPdiSiufM61wrGCC96OvpOxTDYDOjE0E8pJOc=.7e4140d5-84f1-4879-98c9-d84512954be1@github.com>

On Mon, 24 Feb 2025 22:20:27 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Currently it sounds that CLI option "--install-dir" is not supported, but it will work if it points to default location.

The warning will be shown only if `--install-dir` doesn't point to the default location. This is the change from the current behavior when the warning is shown if the `--install-dir` option is present on the command line regardless of its value.

If they pass `--install-dir /Applications` they will not see the warning.
If they pass, say `--install-dir /opt` they will see the warning. Currently, it will be:

Warning: "--install-dir" is not supported by DMG and will be default to /Applications.


Do you prefer:

Warning: "--install-dir" value "/opt" is not supported by DMG and will be default to /Applications.

?

If we want to improve the warning text additionally to making it accurate for runtime packaging, I'd rather have this wording:

Warning: "--install-dir" option is ignored for DMG packaging. The installation directory will default to {0}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23752#discussion_r1968647620

From asemenyuk at openjdk.org  Tue Feb 25 01:05:53 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Feb 2025 01:05:53 GMT
Subject: RFR: 8350601: Miscellaneous updates to jpackage test lib [v3]
In-Reply-To: <2pIkTcwmKLSzk1fFtX2wdnEUtCox2YgK9lXTbexfy_0=.157ff385-01ae-4950-b2d7-7f0200a7dace@github.com>
References: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
 <0FwuZfTqsEtFdRbEtS3OSpdFtUgx5Q6ky3PiRN1EYXY=.a4617553-a64e-4d0f-8b9a-5b6c819dab37@github.com>
 <2pIkTcwmKLSzk1fFtX2wdnEUtCox2YgK9lXTbexfy_0=.157ff385-01ae-4950-b2d7-7f0200a7dace@github.com>
Message-ID: <ZDmQtEv1PUK8cTZ-5dSSmpxubvGQ2S91FI2jzLAHnd8=.5e3fec79-ee19-4d2e-b1b9-65fd029930e5@github.com>

On Mon, 24 Feb 2025 22:57:21 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This one is confusing. It will evaluate to true if both != null

Correct. They both shouldn't be `true`. One of them must be `true`, and another one must be `false`.

> Did you mean "&&" instead of "=="?

No. I meant `==` :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23754#discussion_r1968649331

From almatvee at openjdk.org  Tue Feb 25 01:06:58 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 25 Feb 2025 01:06:58 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging [v2]
In-Reply-To: <95_ax6JPdiSiufM61wrGCC96OvpOxTDYDOjE0E8pJOc=.7e4140d5-84f1-4879-98c9-d84512954be1@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <YMOglLxAdTtYM1xCYTBOhgm6lu7rFl1ajvPNud9iCNk=.b9a7921e-85d6-41b7-ae16-6ae2ae07ebf3@github.com>
 <oRWVWBdi3kSQRqK4dGm7dQiBlvN6SCoe97zc2_1Pjgg=.e409ad86-5cb2-45bc-9189-f52e0854042b@github.com>
 <95_ax6JPdiSiufM61wrGCC96OvpOxTDYDOjE0E8pJOc=.7e4140d5-84f1-4879-98c9-d84512954be1@github.com>
Message-ID: <kHXD517NWUIbk1EP3FO31sCAlNEPvXoNhl6ex8xCfuw=.99a4b1d8-489a-4840-9978-e91aedd56790@github.com>

On Tue, 25 Feb 2025 01:00:31 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties line 94:
>> 
>>> 92: message.signing.pkg=Warning: For signing PKG, you might need to set "Always Trust" for your certificate using "Keychain Access" tool.
>>> 93: message.setfile.dmg=Setting custom icon on DMG file skipped because 'SetFile' utility was not found. Installing Xcode with Command Line Tools should resolve this issue.
>>> 94: message.install-dir-ignored=Warning: "--install-dir" is not supported by DMG and will be default to {0}.
>> 
>> I think it is better to change message to "Warning: "--install-dir" value "{0}" is not supported by DMG and will be default to {1}." Currently it sounds that CLI option "--install-dir" is not supported, but it will work if it points to default location.
>
>> Currently it sounds that CLI option "--install-dir" is not supported, but it will work if it points to default location.
> 
> The warning will be shown only if `--install-dir` doesn't point to the default location. This is the change from the current behavior when the warning is shown if the `--install-dir` option is present on the command line regardless of its value.
> 
> If they pass `--install-dir /Applications` they will not see the warning.
> If they pass, say `--install-dir /opt` they will see the warning. Currently, it will be:
> 
> Warning: "--install-dir" is not supported by DMG and will be default to /Applications.
> 
> 
> Do you prefer:
> 
> Warning: "--install-dir" value "/opt" is not supported by DMG and will be default to /Applications.
> 
> ?
> 
> If we want to improve the warning text additionally to making it accurate for runtime packaging, I'd rather have this wording:
> 
> Warning: "--install-dir" option is ignored for DMG packaging. The installation directory will default to {0}.

I like this one and yes lets change it: `Warning: "--install-dir" option is ignored for DMG packaging. The installation directory will default to {0}.`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23752#discussion_r1968650421

From almatvee at openjdk.org  Tue Feb 25 01:16:51 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 25 Feb 2025 01:16:51 GMT
Subject: RFR: 8350601: Miscellaneous updates to jpackage test lib [v3]
In-Reply-To: <ZDmQtEv1PUK8cTZ-5dSSmpxubvGQ2S91FI2jzLAHnd8=.5e3fec79-ee19-4d2e-b1b9-65fd029930e5@github.com>
References: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
 <0FwuZfTqsEtFdRbEtS3OSpdFtUgx5Q6ky3PiRN1EYXY=.a4617553-a64e-4d0f-8b9a-5b6c819dab37@github.com>
 <2pIkTcwmKLSzk1fFtX2wdnEUtCox2YgK9lXTbexfy_0=.157ff385-01ae-4950-b2d7-7f0200a7dace@github.com>
 <ZDmQtEv1PUK8cTZ-5dSSmpxubvGQ2S91FI2jzLAHnd8=.5e3fec79-ee19-4d2e-b1b9-65fd029930e5@github.com>
Message-ID: <q3hiQwGm4GcrqpmrZb_869Dt4IFJYlK84qHMTrDK-ko=.6e872ef6-33c4-4993-9795-72cd9a8fb8b2@github.com>

On Tue, 25 Feb 2025 01:02:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/TKitTest.java line 232:
>> 
>>> 230:             if ((expectedExceptionClass == null) == (expectedPath == null)) {
>>> 231:                 throw new IllegalArgumentException("Only one of `expectedPath` and `expectedExceptionClass` can be null");
>>> 232:             }
>> 
>> This one is confusing. It will evaluate to true if both != null. Did you mean "&&" instead of "=="?
>
>> This one is confusing. It will evaluate to true if both != null
> 
> Correct. They both shouldn't be `true`. One of them must be `true`, and another one must be `false`.
> 
>> Did you mean "&&" instead of "=="?
> 
> No. I meant `==` :)

If they both set to non-null value, then exception will be thrown since false == false. In this case exception message is confusing. Maybe change it to: `Only one of `expectedPath` and `expectedExceptionClass` should be set`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23754#discussion_r1968658398

From smarks at openjdk.org  Tue Feb 25 01:30:01 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 25 Feb 2025 01:30:01 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v6]
In-Reply-To: <1_MYqF28HW1ASAglx6I3PhgIff6ZLN_mcCqOWQSSIxg=.942bd5e5-56a4-4cbe-b551-536c714297f7@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <1_MYqF28HW1ASAglx6I3PhgIff6ZLN_mcCqOWQSSIxg=.942bd5e5-56a4-4cbe-b551-536c714297f7@github.com>
Message-ID: <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>

On Mon, 24 Feb 2025 13:08:49 GMT, David Beaumont <duke at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaking @implNote for better rendering.

src/java.logging/share/classes/java/util/logging/Formatter.java line 94:

> 92:      * important to avoid making callbacks to unknown user-provided arguments
> 93:      * (e.g. log record parameters captured from previous calls to
> 94:      * {@link #format(LogRecord)}.

I'm having trouble getting my head around these comments. Are they intended for callers or for subclassers? Is the "associated" handler the same handler as the argument, or a different one? I saw the discussion of potential (largely theoretical?) deadlock in the discussion in StreamHandler.publish(), but I'm having trouble figuring out what kind of actual constraint that potential imposes on which code.

src/java.logging/share/classes/java/util/logging/Handler.java line 62:

> 60:  * {@link #isLoggable(LogRecord)} while allowing code synchronized on the
> 61:  * {@code Handler} instance to set a new log level.
> 62:  * <p>

The above discussion is mostly internal to Handler implementations so I don't think it belongs in public javadoc. The implementation comments at line 91 below cover this (though they could be clarified a bit) but I think the mutables-volatile/unlocked-get/locked-set convention is mostly orthogonal to the deadlock issue we're trying to solve here. I'd recommend simply removing this material.

As an aside I think using volatiles this way is quite error-prone and I don't like advertising it in the javadoc.

src/java.logging/share/classes/java/util/logging/Handler.java line 80:

> 78:  * {@link FileHandler} or {@link Formatter} then, in order to have complete
> 79:  * control of synchronization, it is recommended to subclass {@code Handler}
> 80:  * directly.

The discussion here belongs on StreamHandler.publish(), because its implementation does lock on the StreamHandler instance itself. As such there isn't any other discussion of locking in the specs for this class, so it seems kind of misplaced.

src/java.logging/share/classes/java/util/logging/Handler.java line 163:

> 161:      * <p>
> 162:      * @implNote Implementations of this method should avoid holding any locks
> 163:      * around the formatting of {@code LogRecord}.

I actually do not think this is correct. It's safe to hold locks as long as no other path into this class attempts to take the same lock, which gives rise to the lock ordering problem.

src/java.logging/share/classes/java/util/logging/StreamHandler.java line 184:

> 182:      *
> 183:      * @param  record  description of the log event. A null record is
> 184:      *                 silently ignored and is not published

There needs to be an `@implSpec` somewhere in this method's javadoc comment that explains the locking policy here very crisply for subclassers. Specifically (1) the lock on `this` is not held during formatting; (2) the lock on `this` is held during publishing; (3) subclassers must not lock on `this` while calling super.publish() because it would contravene (1).

src/java.logging/share/classes/java/util/logging/StreamHandler.java line 268:

> 266:     }
> 267: 
> 268:     // Called synchronously.

I would be more specific here and say that it's called while the lock on `this` is held.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1968668798
PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1968657704
PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1968660845
PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1968662121
PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1968664835
PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1968662606

From smarks at openjdk.org  Tue Feb 25 01:30:02 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 25 Feb 2025 01:30:02 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v6]
In-Reply-To: <U9dqVBjuudxFSY8JmJJKf2qAa78SJGHAqDncQhf_1T8=.e5a7ca03-f5d5-4eb8-8ef1-2ae70c38ffab@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Pj4COzHIujrQIrdVZaPbYc0V4uDR9jBXAAmZ6iDdI0s=.6e94d34f-6d57-4dd1-b232-23c54f4bc4b1@github.com>
 <Xs0Wd1rYekZRiaPHys_89jY4TSXKwBhx8A-iz-jlYtU=.a9e83238-686a-4ef4-8ee0-81b3da941393@github.com>
 <U9dqVBjuudxFSY8JmJJKf2qAa78SJGHAqDncQhf_1T8=.e5a7ca03-f5d5-4eb8-8ef1-2ae70c38ffab@github.com>
Message-ID: <wW98J6TwTCR2pdrTXdOEyX6MHZu7CkNq3vCYEZw9I9o=.243c5403-5be9-41fe-aab4-904b24d62462@github.com>

On Fri, 14 Feb 2025 15:07:58 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Well spotted :) Yes, it's a theoretical risk, but not at the same level as that of log record formatting.
>> 
>> My original draft push of this PR had comments about lock expectations here, but I was asked to not change the JavaDoc on Formatter.
>> 
>> The getHead() and getTail() methods *could* cause deadlock, but only because of code directly associated with their implementation. They don't have any access to a log record (and no reason to have access to log records), so they aren't going to be calling into completely arbitrary user code.
>> 
>> It's also unlikely that a formatter implementation will do a lot of complex work in these methods since, semantically, they are called an arbitrary number of times (according to configuration) and at arbitrary times, so they really cannot meaningfully rely on user runtime data or much beyond things like timestamps and counters.
>> 
>> So while, in theory, it could be an issue, it's an issue that can almost certainly be fixed by the author of the Formatter class itself. This is contrasted with the issue at hand, which is inherent in the handler code and cannot be fixed in any other reasonable way by the user of the logging library.
>> 
>> I'd be happy to move the head/tail acquisition out of the locked regions if it were deemed a risk, but that's never something I've observed as an issue (I spent 10 years doing Java logging stuff and saw the publish() deadlock, but never issues with head/tail stuff). It's also hard to move it out, because tail writing happens in close(), called from flush(), both of which are much more expected to be synchronized, so you'd probably want to get and cache the tail() string when the file was opened.
>
> As for the example you gave there, that is interesting. Keeping an unformatted log record around for any time after the log statement that created it has exited would be quite problematic (it prevents GC of arbitrary things).
> 
> If I were doing some kind of summary tail entry, I'd pull, format (user args) and cache anything I needed out of the log record when I had it, but not keep it around. Then when the tail is written I'd just have what I need ready to go.
> 
> But yes, right now, with or without this PR, that code looks like it's got a deadlock risk.

Need to update to have single call to getFormatter().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1968667060

From syan at openjdk.org  Tue Feb 25 02:29:26 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 25 Feb 2025 02:29:26 GMT
Subject: RFR: 8350614: [JMH]
 jdk.incubator.vector.VectorCommutativeOperSharingBenchmark fails
Message-ID: <pOqOoUCtuYShw2uM7mzAJwRiCwgY2WhddyuguPlfSV8=.0b65cb1f-3888-4b96-988f-7085c7d9f473@github.com>

Hi all,

The newly added JMH test jdk.incubator.vector.VectorCommutativeOperSharingBenchmark run fails "java.lang.NoClassDefFoundError: jdk/incubator/vector/Vector".

The `@Fork(jvmArgsPrepend = ..)` in microbenchmarks should replaced as `@Fork(jvmArgs = ..)` after [JDK-8343345](https://bugs.openjdk.org/browse/JDK-8343345). Change has been verified locally, test-fix only, no risk.

-------------

Commit messages:
 - 8350614: [JMH] jdk.incubator.vector.VectorCommutativeOperSharingBenchmark fails

Changes: https://git.openjdk.org/jdk/pull/23761/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23761&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350614
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23761.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23761/head:pull/23761

PR: https://git.openjdk.org/jdk/pull/23761

From mik3hall at gmail.com  Tue Feb 25 03:27:12 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 24 Feb 2025 21:27:12 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging [v2]
In-Reply-To: <kHXD517NWUIbk1EP3FO31sCAlNEPvXoNhl6ex8xCfuw=.99a4b1d8-489a-4840-9978-e91aedd56790@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <YMOglLxAdTtYM1xCYTBOhgm6lu7rFl1ajvPNud9iCNk=.b9a7921e-85d6-41b7-ae16-6ae2ae07ebf3@github.com>
 <oRWVWBdi3kSQRqK4dGm7dQiBlvN6SCoe97zc2_1Pjgg=.e409ad86-5cb2-45bc-9189-f52e0854042b@github.com>
 <95_ax6JPdiSiufM61wrGCC96OvpOxTDYDOjE0E8pJOc=.7e4140d5-84f1-4879-98c9-d84512954be1@github.com>
 <kHXD517NWUIbk1EP3FO31sCAlNEPvXoNhl6ex8xCfuw=.99a4b1d8-489a-4840-9978-e91aedd56790@github.com>
Message-ID: <52B989DC-3789-4309-9C02-EF5A4136CFCB@gmail.com>


>> 
>> Warning: "--install-dir" option is ignored for DMG packaging. The installation directory will default to {0}.
> 
> I like this one and yes lets change it: `Warning: "--install-dir" option is ignored for DMG packaging. The installation directory will default to {0}.`
> 

I must be misunderstanding this concern.  Maybe packaging implies something other than just putting the app into a dmg?
jpackage help shows?

Valid values are: {"app-image", "dmg", "pkg?}

By DMG packaging do you mean ?dmg? or ?pkg??

Possibly for pkg this makes sense.
 
For MacOS dmg builds if you open them you usually get a Finder window with the application icon and an image with an arrow pointing to an alias of the Application directory. 
The user can then drag and drop the application to the Application directory in that window to do the install themselves. Correct?

For my own development I usually have my build open the dmg and extract the app to the same test directory it is built from.

e.g.

open -Wg HalfPipe-1.0.dmg
ditto /Volumes/HalfPipe/HalfPipe.app outputdir/HalfPipe.app

Either way, I don?t understand where there is ever any need for a ?install-dir parameter and am unclear when an installation directory would ever be used for a DMG?

I would think a warning should just indicate that ?install-dir is always ignored for dmg builds.




From jpai at openjdk.org  Tue Feb 25 06:55:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Feb 2025 06:55:52 GMT
Subject: RFR: 8345213: JVM Prefers /etc/timezone Over /etc/localtime on
 Debian 12
In-Reply-To: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
References: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
Message-ID: <qpEIgEVC7Al633vqNCMjG2fG9FnToVFTUzY9Iig1rgU=.08b7b802-40d6-4c67-8b67-118c093d51bf@github.com>

On Mon, 24 Feb 2025 19:46:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the support for /etc/timezone file that is Debian distro specific. The file is no longer considered authoritative (https://wiki.debian.org/TimeZoneChanges#Check_Configured_Timezone), and in fact, it is now out of sync as the bug reports. The fix was confirmed manually on a Ubuntu 25.04.

Hello Naoto, this looks reasonable to me. Do you think we should add a release note for this change?

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23755#pullrequestreview-2639718954

From alanb at openjdk.org  Tue Feb 25 07:19:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Feb 2025 07:19:53 GMT
Subject: RFR: 8345213: JVM Prefers /etc/timezone Over /etc/localtime on
 Debian 12
In-Reply-To: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
References: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
Message-ID: <gCkNGL60d9XxcN32po1GoPskETQU66dpQRDK0ga4OEM=.4302956a-cc0c-4eef-9f3e-1a5e07fa2d0e@github.com>

On Mon, 24 Feb 2025 19:46:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the support for /etc/timezone file that is Debian distro specific. The file is no longer considered authoritative (https://wiki.debian.org/TimeZoneChanges#Check_Configured_Timezone), and in fact, it is now out of sync as the bug reports. The fix was confirmed manually on a Ubuntu 25.04.

@naotoj Do you know what was the last Debian release where this file was used? I'm looking at JDK-6456628 to try to understand if any of the distros from that needed this code have any supported releases that might need it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23755#issuecomment-2680905932

From tvaleev at openjdk.org  Tue Feb 25 07:21:31 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 25 Feb 2025 07:21:31 GMT
Subject: RFR: 8350518: org.openjdk.bench.java.util.TreeMapUpdate.compute
 fails with  "java.lang.IllegalArgumentException: key out of range" [v2]
In-Reply-To: <sUX5c-b5uzJ7biA1mOTwB_DuXU9kJwU1CZwA26NZysM=.67ea4b42-ebd6-44ad-a344-d8b06806c21f@github.com>
References: <sUX5c-b5uzJ7biA1mOTwB_DuXU9kJwU1CZwA26NZysM=.67ea4b42-ebd6-44ad-a344-d8b06806c21f@github.com>
Message-ID: <7ABpqMOv-4x02dCC4BBUGP53tSvHY75tji8yLPHEy-o=.5d9cbb8f-7f6e-424d-9c7a-f2aa4653720b@github.com>

> It appears that the benchmark was erroneous. The combination of "tailMap" mode and comparator = true didn't work correctly, as the comparator is descending. This PR changes the benchmark to use headMap instead of tailMap in comparator mode. The "tailMap" mode is renamed to "subMap". Now, all parameter combinations work correctly.

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23744/files
  - new: https://git.openjdk.org/jdk/pull/23744/files/1cf4704a..24991c64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23744&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23744&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23744/head:pull/23744

PR: https://git.openjdk.org/jdk/pull/23744

From tvaleev at openjdk.org  Tue Feb 25 07:21:31 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Tue, 25 Feb 2025 07:21:31 GMT
Subject: RFR: 8350518: org.openjdk.bench.java.util.TreeMapUpdate.compute
 fails with  "java.lang.IllegalArgumentException: key out of range" [v2]
In-Reply-To: <sYU-1DkqTcl0D1vp4INiAA0W20XJSZORhRJ-6qC0Xuo=.7b091bd3-26e1-4f4b-941c-18e9c79797a7@github.com>
References: <sUX5c-b5uzJ7biA1mOTwB_DuXU9kJwU1CZwA26NZysM=.67ea4b42-ebd6-44ad-a344-d8b06806c21f@github.com>
 <sYU-1DkqTcl0D1vp4INiAA0W20XJSZORhRJ-6qC0Xuo=.7b091bd3-26e1-4f4b-941c-18e9c79797a7@github.com>
Message-ID: <xjcBDuMGa_ZSVr1crTcVLdXJ9kOC_Rcs42gQCi2qLwQ=.0c6ae622-46e3-46c8-ba31-50643963c6a1@github.com>

On Mon, 24 Feb 2025 19:29:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright
>
> This file needs a copyright year update, from `(c) 2020, Oracle` to `(c) 2020, 2025, Oracle`.

@liach thank you. It would be nice to have this check automated, similar to erroneous whitespace check...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23744#issuecomment-2680911448

From asotona at openjdk.org  Tue Feb 25 08:21:57 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Feb 2025 08:21:57 GMT
Subject: RFR: 8350548: java.lang.classfile package javadoc has errors
In-Reply-To: <hn1StpIZRkCqK75GKcI-4xOjYKVUdc3W0tHIfYi-T5o=.70cca0e2-be53-4019-9e4f-6e01dcd66c1b@github.com>
References: <hn1StpIZRkCqK75GKcI-4xOjYKVUdc3W0tHIfYi-T5o=.70cca0e2-be53-4019-9e4f-6e01dcd66c1b@github.com>
Message-ID: <XP8HOb_21_0lu0XRLBEACpjboGNT7fK7Kheu-Nl6EQ4=.4755a9b7-b2ae-4397-b010-312fe9c271a5@github.com>

On Mon, 24 Feb 2025 08:09:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> j.l.classfile package-summary contains many code snippets.
> Some of the shorter snippets are embedded in the javadoc and therefore are not validated by the tests.
> One embedded code snippet contains a typo, and two snippets do not reflect the actual API method name.
> 
> This patch fixes the code snippets.
> 
> Please review.
> 
> Thanks,
> Adam

Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23743#issuecomment-2681072862

From asotona at openjdk.org  Tue Feb 25 08:21:58 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 25 Feb 2025 08:21:58 GMT
Subject: Integrated: 8350548: java.lang.classfile package javadoc has errors
In-Reply-To: <hn1StpIZRkCqK75GKcI-4xOjYKVUdc3W0tHIfYi-T5o=.70cca0e2-be53-4019-9e4f-6e01dcd66c1b@github.com>
References: <hn1StpIZRkCqK75GKcI-4xOjYKVUdc3W0tHIfYi-T5o=.70cca0e2-be53-4019-9e4f-6e01dcd66c1b@github.com>
Message-ID: <R45sBCgH5q1UDpEPOMniYXag0Cdgl8YqJ_B7A4Q3AVM=.d4e26ece-e673-4995-a0d7-53aa137856bc@github.com>

On Mon, 24 Feb 2025 08:09:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> j.l.classfile package-summary contains many code snippets.
> Some of the shorter snippets are embedded in the javadoc and therefore are not validated by the tests.
> One embedded code snippet contains a typo, and two snippets do not reflect the actual API method name.
> 
> This patch fixes the code snippets.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: ab86a135
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab86a13519a50c5d8a05c493594e6bda329133f4
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8350548: java.lang.classfile package javadoc has errors

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/23743

From jwaters at openjdk.org  Tue Feb 25 08:43:00 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 25 Feb 2025 08:43:00 GMT
Subject: RFR: 8342868: Errors related to unused code on Windows after
 8339120 in core libs [v2]
In-Reply-To: <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
Message-ID: <t7TC5dtafc-_tjEK9fvprB2ZLW38bg6L7jrcrfaw0A4=.a75619b2-9840-48be-ae17-e03d56f05eab@github.com>

On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the got local

Keep open please

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-2681144858

From rgiulietti at openjdk.org  Tue Feb 25 09:07:55 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 25 Feb 2025 09:07:55 GMT
Subject: RFR: 8138614: (spec str) StringBuffer and StringBuilder methods
 improperly require "new" String to be returned [v3]
In-Reply-To: <mXP7Jz7SBUKAxK4auIlz39PbXrYEe_5VjRLBhq0sbLI=.e6e3021e-1ac6-4f4e-95f7-dfda3221a3d4@github.com>
References: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
 <mXP7Jz7SBUKAxK4auIlz39PbXrYEe_5VjRLBhq0sbLI=.e6e3021e-1ac6-4f4e-95f7-dfda3221a3d4@github.com>
Message-ID: <gHbjSy276tNOx-eFgaeRJzv-RRUYgOkStkJlFzw5Sdk=.83dc4c1b-622f-45cb-8471-84154a5cf2ce@github.com>

On Tue, 25 Feb 2025 00:54:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> A couple adjustments to the specs for four methods of StringBuilder and StringBuffer so that they no longer require new Strings to be created, just a String with the right contents. No implementation changes. Note that the actual specs (and implementations) are actually in AbstractStringBuilder, and they're inherited by StringBuilder and StringBuffer.
>
> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8138614-relax-new-string-requirement
>  - A tiny bit of wordsmithing.
>  - 8138614: Relax StringBuilder/StringBuffer requirement to create new Strings

Marked as reviewed by rgiulietti (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23599#pullrequestreview-2640195429

From mcimadamore at openjdk.org  Tue Feb 25 09:53:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Feb 2025 09:53:57 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <K880Nrod0JY0dzsAgXtNDc-FzTxbGAdQ0AZUshRUibo=.b002fc8f-7133-401d-a64f-5aeae7495935@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2640368169

From mcimadamore at openjdk.org  Tue Feb 25 09:53:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Feb 2025 09:53:58 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <3yhXZNAbPb_sRC_CXmKGzUNsvhl1rOfIvtdGfUCsvq4=.66ca9688-2bf1-4eec-9a38-c499a8390fcc@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <3yhXZNAbPb_sRC_CXmKGzUNsvhl1rOfIvtdGfUCsvq4=.66ca9688-2bf1-4eec-9a38-c499a8390fcc@github.com>
Message-ID: <jIE0fp1SkujHwIanTtWKszq_kIadq7erKWrk_zLnZqI=.3ca1bc86-1257-4f4c-802b-4af638cc8463@github.com>

On Fri, 21 Feb 2025 22:19:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> Benchmark results for the latest revision appears performance neutral. bytestacks same as last revision. 11 jobs left in tier 1-3, no failure so far. Also created CSR for this minor behavioral change.
> 
> Benchmark                                                (polluteProfile)  Mode  Cnt  Score   Error  Units
> LoopOverNonConstantHeap.BB_get                                      false  avgt   30  0.934 ? 0.027  ns/op
> LoopOverNonConstantHeap.BB_get                                       true  avgt   30  0.946 ? 0.028  ns/op
> LoopOverNonConstantHeap.BB_loop                                     false  avgt   30  0.208 ? 0.004  ms/op
> LoopOverNonConstantHeap.BB_loop                                      true  avgt   30  0.211 ? 0.003  ms/op
> LoopOverNonConstantHeap.segment_get                                 false  avgt   30  1.123 ? 0.040  ns/op
> LoopOverNonConstantHeap.segment_get                                  true  avgt   30  1.120 ? 0.040  ns/op
> LoopOverNonConstantHeap.segment_loop                                false  avgt   30  0.205 ? 0.004  ms/op
> LoopOverNonConstantHeap.segment_loop                                 true  avgt   30  0.202 ? 0.003  ms/op
> LoopOverNonConstantHeap.segment_loop_instance                       false  avgt   30  0.209 ? 0.005  ms/op
> LoopOverNonConstantHeap.segment_loop_instance                        true  avgt   30  0.202 ? 0.003  ms/op
> LoopOverNonConstantHeap.segment_loop_instance_unaligned             false  avgt   30  0.209 ? 0.004  ms/op
> LoopOverNonConstantHeap.segment_loop_instance_unaligned              true  avgt   30  0.210 ? 0.004  ms/op
> LoopOverNonConstantHeap.segment_loop_readonly                       false  avgt   30  0.206 ? 0.004  ms/op
> LoopOverNonConstantHeap.segment_loop_readonly                        true  avgt   30  0.206 ? 0.005  ms/op
> LoopOverNonConstantHeap.segment_loop_slice                          false  avgt   30  0.203 ? 0.002  ms/op
> LoopOverNonConstantHeap.segment_loop_slice                           true  avgt   30  0.207 ? 0.004  ms/op
> LoopOverNonConstantHeap.segment_loop_unaligned                      false  avgt   30  0.206 ? 0.004  ms/op
> LoopOverNonConstantHeap.segment_loop_unaligned                       true  avgt   30  0.209 ? 0.003  ms/op
> LoopOverNonConstantHeap.unsafe_get                                  false  avgt   30  0.386 ? 0.017  ns/op
> LoopOverNonConstantHeap.unsafe_get                                   true  avgt   30  0.381 ? 0.017  ns/op
> LoopOverNonConstantHeap.unsafe_loop                ...

Great work @liach -- I've bumped the number of reviewers as this whole area is rather tricky, and I think the PR can probably benefit from another independent pass.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2681378356

From mcimadamore at openjdk.org  Tue Feb 25 09:53:59 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Feb 2025 09:53:59 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <iN-WtpFC1zxkX6fcLHMlvWb816k8dhk2l6LpOYB1pRY=.01a3ed67-1bfc-43df-aff8-def1e1ed4f4f@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <ytp02QFVAb3DzxcsHNaN_XyjGAy9Io-IsBtceST1uxU=.de12ebfa-33a3-4a16-b502-58a8771c57c9@github.com>
 <rrYvP3pPD6i_WJS63SFQ2q1lgxPq5XfpcvGw6z6z9YY=.0c979090-fc24-4b19-b1eb-7c4e6e1b2848@github.com>
 <IyNzHb2JxMJ1JTwLtyGN9edwrcfaBCXWMwzfQBPUWnk=.f5efd544-183c-4acf-a53f-a7790fa1c5b6@github.com>
 <iN-WtpFC1zxkX6fcLHMlvWb816k8dhk2l6LpOYB1pRY=.01a3ed67-1bfc-43df-aff8-def1e1ed4f4f@github.com>
Message-ID: <pDEcJ-PR_3EBt7SNwVipX52RxUv6XRv9fBkWGhEVMTU=.071d8d71-c6b4-4362-890b-9ed17cba147a@github.com>

On Mon, 24 Feb 2025 17:53:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Maybe let's leave it, at least in this round
>
> Done in latest update.

Thanks! I think it looks very good!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1969396191

From mcimadamore at openjdk.org  Tue Feb 25 09:54:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 25 Feb 2025 09:54:00 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <EJJGa5hbTu2Cgl9gwSnCZEnSkxj5N2pHV3ALhqI6TPs=.0b1fb59c-5a71-43ef-b759-cc0e384a55a9@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <8JTFy-f-rYCzlLbpHImCvEbWG7VCSnlUDG4MkAAHaa0=.cfb825a4-0124-4022-a1c8-15cb4d4b0697@github.com>
 <EJJGa5hbTu2Cgl9gwSnCZEnSkxj5N2pHV3ALhqI6TPs=.0b1fb59c-5a71-43ef-b759-cc0e384a55a9@github.com>
Message-ID: <7O_pS8xWC9YwStjIu2GVFpaBQS70qfXy45TbPjsVG-I=.ff32c917-5a0e-43f3-9718-e205e91ec752@github.com>

On Mon, 24 Feb 2025 19:11:23 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think direct var handles are quite cheap already and don't really need caching. What really worth caching should be the combinators and the VH derived from those combinators.

Right -- and one big advantage of this PR, if I'm correct, is that if you have a VH to access a single field, that will be a non-strided VH with a static offset (saved in the VH instance). So no adaptation is required (meaning no spinning of bytecodes) and, also, var handle guards will apply too. This is a very good result!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1969394463

From pminborg at openjdk.org  Tue Feb 25 10:05:59 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 25 Feb 2025 10:05:59 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <kLulYPr02EH8x0KhMdIjLPKsOlodiqdfNe-LyAVufPI=.1c2e1b5f-0015-46d5-b767-66a1e6c66ae1@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

src/java.base/share/classes/java/lang/invoke/SegmentVarHandle.java line 50:

> 48:     final MemoryLayout enclosing;
> 49:     /** The fixed offset value, if exists. vform decides if the fixed offset is used. */
> 50:     final long offset;

These fields are already trusted by virtue of residing in the `j.l.i` package?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1969439774

From duke at openjdk.org  Tue Feb 25 11:14:00 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 25 Feb 2025 11:14:00 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v6]
In-Reply-To: <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <1_MYqF28HW1ASAglx6I3PhgIff6ZLN_mcCqOWQSSIxg=.942bd5e5-56a4-4cbe-b551-536c714297f7@github.com>
 <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
Message-ID: <7ASvm2DDqs9t6ZFex7pdj0Ak5Wto3lA6ZD9ECx_YtnA=.58e2988a-991d-4ead-87f6-a5c212d885d2@github.com>

On Tue, 25 Feb 2025 01:12:55 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweaking @implNote for better rendering.
>
> src/java.logging/share/classes/java/util/logging/Handler.java line 62:
> 
>> 60:  * {@link #isLoggable(LogRecord)} while allowing code synchronized on the
>> 61:  * {@code Handler} instance to set a new log level.
>> 62:  * <p>
> 
> The above discussion is mostly internal to Handler implementations so I don't think it belongs in public javadoc. The implementation comments at line 91 below cover this (though they could be clarified a bit) but I think the mutables-volatile/unlocked-get/locked-set convention is mostly orthogonal to the deadlock issue we're trying to solve here. I'd recommend simply removing this material.
> 
> As an aside I think using volatiles this way is quite error-prone and I don't like advertising it in the javadoc.

Fair enough. Logging is a weird space in which certain synchronization/consistency strategies become quite important for performance, so I was thinking it would be useful to explain it a bit more. I agree it's not a "neat" solution, but it can can be used safely. There are definitely a few pitfalls here though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1969556294

From duke at openjdk.org  Tue Feb 25 11:18:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 25 Feb 2025 11:18:54 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v6]
In-Reply-To: <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <1_MYqF28HW1ASAglx6I3PhgIff6ZLN_mcCqOWQSSIxg=.942bd5e5-56a4-4cbe-b551-536c714297f7@github.com>
 <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
Message-ID: <ClmjKm2n1rUlnNNtt4Cn8i8Ctg51_GAwqy4YOPl02dU=.03a964ea-9fb8-4fa3-a981-9b54c98f78de@github.com>

On Tue, 25 Feb 2025 01:17:21 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweaking @implNote for better rendering.
>
> src/java.logging/share/classes/java/util/logging/Handler.java line 80:
> 
>> 78:  * {@link FileHandler} or {@link Formatter} then, in order to have complete
>> 79:  * control of synchronization, it is recommended to subclass {@code Handler}
>> 80:  * directly.
> 
> The discussion here belongs on StreamHandler.publish(), because its implementation does lock on the StreamHandler instance itself. As such there isn't any other discussion of locking in the specs for this class, so it seems kind of misplaced.

Yeah, it's difficult to know where this should go, because while `StreamHandler` is the only important case in the JDK which suffer(s/ed) from this, if you look through github, I'd say the majority of publish() methods are (erroneously) synchronized. That's why I hoisted the docs here, because it's something I want people to see when they consider writing or modifying their own subclasses. The mentions of StreamHandler, FileHandler et al are just the examples we can point at, but the warning is meant to be general, and I personally think it fits better in the class which defines the publish() method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1969562270

From duke at openjdk.org  Tue Feb 25 11:25:58 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 25 Feb 2025 11:25:58 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v6]
In-Reply-To: <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <1_MYqF28HW1ASAglx6I3PhgIff6ZLN_mcCqOWQSSIxg=.942bd5e5-56a4-4cbe-b551-536c714297f7@github.com>
 <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
Message-ID: <FfLLld4lBuJ4KKc91nQfwLsmgYkNinsCQA9ZDgbM3aM=.0f998e08-5e63-4706-aff5-164e95860e12@github.com>

On Tue, 25 Feb 2025 01:18:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweaking @implNote for better rendering.
>
> src/java.logging/share/classes/java/util/logging/Handler.java line 163:
> 
>> 161:      * <p>
>> 162:      * @implNote Implementations of this method should avoid holding any locks
>> 163:      * around the formatting of {@code LogRecord}.
> 
> I actually do not think this is correct. It's safe to hold locks as long as no other path into this class attempts to take the same lock, which gives rise to the lock ordering problem.

Well that's true for any locking, but `publish()` is essentially required (unless you're just throwing away information) to call `toString()` or similar on the arbitrary parameters it's passed.
You can't squirrel away the parameters and format them later (that's a serious issue for mutable parameters) so you must process them before this method exits (yes, you could do it in another thread and block until processing is done, but you can't exit the log statement until it is).

So, in all but the most specialized implementations of `publish()` you are expected to be calling `toString()` or arbitrary user provided objects. And if you do that, you are absolutely at risk of deadlock (see the issue description for an example).

I mean you could explain how there are a tiny number of special case situations in which technically you'll get away with holding a lock while formatting a log record, but this does say "should" and not "must", so I think it's worded fairly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1969572397

From duke at openjdk.org  Tue Feb 25 11:37:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 25 Feb 2025 11:37:55 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v6]
In-Reply-To: <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <1_MYqF28HW1ASAglx6I3PhgIff6ZLN_mcCqOWQSSIxg=.942bd5e5-56a4-4cbe-b551-536c714297f7@github.com>
 <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
Message-ID: <_Trjm7t7oWxRTydRKqeS6adOJ6qT2l_iGU1UGUiG01g=.9fe16a20-a8e6-4647-938a-9e9dff48c7d4@github.com>

On Tue, 25 Feb 2025 01:27:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweaking @implNote for better rendering.
>
> src/java.logging/share/classes/java/util/logging/Formatter.java line 94:
> 
>> 92:      * important to avoid making callbacks to unknown user-provided arguments
>> 93:      * (e.g. log record parameters captured from previous calls to
>> 94:      * {@link #format(LogRecord)}.
> 
> I'm having trouble getting my head around these comments. Are they intended for callers or for subclassers? Is the "associated" handler the same handler as the argument, or a different one? I saw the discussion of potential (largely theoretical?) deadlock in the discussion in StreamHandler.publish(), but I'm having trouble figuring out what kind of actual constraint that potential imposes on which code.

The caller of this class is almost always JDK logging code, so these comments are intended for anyone implementing a formatter. The handler is the target handler (well spotted), and I don't believe it's ever actually null in any real code in the JDK.

The reason that I commented here is because in the PR conversation, it's been noted that formatter is odd because two of its methods are intended to be called without locks held (and for implementations to avoid taking more locks), and two methods are expected to be called with locks held, which means any implementation of them should avoid calling toString() etc.

Now while getHead() and getTail() aren't given any user arguments to format, it was pointed out that they might have held onto some (e.g. from the last processed log record). And this use case isn't entirely odd, because having a "getTail()" method that emits the last log statement timestamp, or some summary of the number of log statements of certain types has value. This can be done safely if you only capture timestamps and counters, because formatting them won't result in arbitrary user code being invoked, but it's easy to imagine people thinking it's also okay to capture certain logged arguments to processing here (while it would be safe to call toString(), and capture that when the record is processed, it's not safe to call toString() in getHead() or getTail()).

I felt that since, without guidance, there's a good chance people will assume all the methods in this class are "the same" in terms of locking constraints, something needed to be put in to distinguish the two (incompatible) constraints these methods have.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1969589330

From coleenp at openjdk.org  Tue Feb 25 12:40:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 25 Feb 2025 12:40:03 GMT
Subject: RFR: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native [v8]
In-Reply-To: <Da5eRkoxdxdezyjWC7_XfLct1aDhjd1ZtP6WPEZ5yis=.e4954c0d-91d7-47f3-a5f6-ec0afc0e8be2@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
 <Da5eRkoxdxdezyjWC7_XfLct1aDhjd1ZtP6WPEZ5yis=.e4954c0d-91d7-47f3-a5f6-ec0afc0e8be2@github.com>
Message-ID: <Kq_vMby90JoSY_5YK-poAQL0s2yg6z-0HAgWGLSl_oc=.189f710c-fb62-4d3a-beb1-f6cab96ea9e5@github.com>

On Mon, 24 Feb 2025 19:30:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
>> Tested with tier1-4 and performance tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment about Class constructor.

Thanks for reviewing Dean, Roger, Vladimir, Yudi and Chen, and comments David.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23572#issuecomment-2681823548

From coleenp at openjdk.org  Tue Feb 25 12:40:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 25 Feb 2025 12:40:04 GMT
Subject: Integrated: 8349860: Make Class.isArray(),
 Class.isInterface() and Class.isPrimitive() non-native
In-Reply-To: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
References: <aSp1Ao_f1Elwm9vJjKpKbWmkGRraemsiBzED07FdGtE=.95e9c60a-6da1-47bc-8cb3-a3399c9d62cc@github.com>
Message-ID: <CvC9FPVohZaQEDsTYU0rUh1mmxfR677aKYum2v_PH_Y=.48c73963-cf44-4626-8f94-0947a4c6e83a@github.com>

On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Class.isInterface() can check modifier flags, Class.isArray() can check whether component mirror is non-null and Class.isPrimitive() needs a new final transient boolean in java.lang.Class that the JVM code initializes.
> Tested with tier1-4 and performance tests.

This pull request has now been integrated.

Changeset: c413549e
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c413549eb775f4209416c718dc9aa0748144a6b4
Stats:     202 lines in 20 files changed: 43 ins; 128 del; 31 mod

8349860: Make Class.isArray(), Class.isInterface() and Class.isPrimitive() non-native

Reviewed-by: dlong, rriggs, vlivanov, yzheng, liach

-------------

PR: https://git.openjdk.org/jdk/pull/23572

From liach at openjdk.org  Tue Feb 25 13:03:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 13:03:57 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <kLulYPr02EH8x0KhMdIjLPKsOlodiqdfNe-LyAVufPI=.1c2e1b5f-0015-46d5-b767-66a1e6c66ae1@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <kLulYPr02EH8x0KhMdIjLPKsOlodiqdfNe-LyAVufPI=.1c2e1b5f-0015-46d5-b767-66a1e6c66ae1@github.com>
Message-ID: <J8X499VDQ_iu2bJO664CDFHGHLTHH6xfL4hyDLJQzv4=.ebcbf921-c231-4550-aa5d-dac20ecff687@github.com>

On Tue, 25 Feb 2025 10:02:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/java/lang/invoke/SegmentVarHandle.java line 50:
> 
>> 48:     final MemoryLayout enclosing;
>> 49:     /** The fixed offset value, if exists. vform decides if the fixed offset is used. */
>> 50:     final long offset;
> 
> These fields are already trusted by virtue of residing in the `j.l.i` package?

Yes. See https://github.com/openjdk/jdk/blob/8cfebc41dc8ec7b0d24d9c467b91de82d28b73fc/src/hotspot/share/ci/ciField.cpp#L223

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1969738602

From liach at openjdk.org  Tue Feb 25 13:06:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 13:06:52 GMT
Subject: RFR: 8350518: org.openjdk.bench.java.util.TreeMapUpdate.compute
 fails with  "java.lang.IllegalArgumentException: key out of range" [v2]
In-Reply-To: <7ABpqMOv-4x02dCC4BBUGP53tSvHY75tji8yLPHEy-o=.5d9cbb8f-7f6e-424d-9c7a-f2aa4653720b@github.com>
References: <sUX5c-b5uzJ7biA1mOTwB_DuXU9kJwU1CZwA26NZysM=.67ea4b42-ebd6-44ad-a344-d8b06806c21f@github.com>
 <7ABpqMOv-4x02dCC4BBUGP53tSvHY75tji8yLPHEy-o=.5d9cbb8f-7f6e-424d-9c7a-f2aa4653720b@github.com>
Message-ID: <vpqwgJkGvbufB5_HS-I4-8yMlgQ7tvL3UXnXUYJjitI=.ba45b397-ad49-4d1b-9e30-e6606d60168e@github.com>

On Tue, 25 Feb 2025 07:21:31 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> It appears that the benchmark was erroneous. The combination of "tailMap" mode and comparator = true didn't work correctly, as the comparator is descending. This PR changes the benchmark to use headMap instead of tailMap in comparator mode. The "tailMap" mode is renamed to "subMap". Now, all parameter combinations work correctly.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

I think there were some difficulties due to other companies that use their own copyright headers and may choose not to update the oracle header, so we only have a basic bot check ensuring the oracle header is not malformed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23744#issuecomment-2681920163

From liach at openjdk.org  Tue Feb 25 13:12:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 13:12:53 GMT
Subject: RFR: 8350518: org.openjdk.bench.java.util.TreeMapUpdate.compute
 fails with  "java.lang.IllegalArgumentException: key out of range" [v2]
In-Reply-To: <7ABpqMOv-4x02dCC4BBUGP53tSvHY75tji8yLPHEy-o=.5d9cbb8f-7f6e-424d-9c7a-f2aa4653720b@github.com>
References: <sUX5c-b5uzJ7biA1mOTwB_DuXU9kJwU1CZwA26NZysM=.67ea4b42-ebd6-44ad-a344-d8b06806c21f@github.com>
 <7ABpqMOv-4x02dCC4BBUGP53tSvHY75tji8yLPHEy-o=.5d9cbb8f-7f6e-424d-9c7a-f2aa4653720b@github.com>
Message-ID: <DtFea5CD-iIhGTDRe1AAiSyFKw7shjP_TflQ44XKyZ8=.50a06c0f-1dfa-4efd-b1eb-25f8769afbcf@github.com>

On Tue, 25 Feb 2025 07:21:31 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> It appears that the benchmark was erroneous. The combination of "tailMap" mode and comparator = true didn't work correctly, as the comparator is descending. This PR changes the benchmark to use headMap instead of tailMap in comparator mode. The "tailMap" mode is renamed to "subMap". Now, all parameter combinations work correctly.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

lgtm, maybe another collection engineer can double check.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23744#pullrequestreview-2641016660

From sgehwolf at openjdk.org  Tue Feb 25 14:04:20 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 25 Feb 2025 14:04:20 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <tJ3zjnmJ1lKiQR8c6dhE_kGUR9qr75rWZmvsnMh-_8w=.5a75cd5c-fd8d-4336-a0e6-7d98fe69c0ae@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
 <tJ3zjnmJ1lKiQR8c6dhE_kGUR9qr75rWZmvsnMh-_8w=.5a75cd5c-fd8d-4336-a0e6-7d98fe69c0ae@github.com>
Message-ID: <M36QkeYGfvJTfI8SSdGW6wSzUCq_8HBcI6JDCAqEvdg=.3f426fc5-bbc9-473a-a229-3cb48dc95d46@github.com>

On Mon, 24 Feb 2025 23:33:01 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> `CgroupV1Controller::set_subsystem_path` needs high level comment update to describe the logic happening.
>> 
>> Testing:
>>>>And after the patch this would become this, right?
>>>>```
>>>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>>>>/sys/fs/cgroup/cpu,cpuacct/
>>>>```
>>>
>>>It depends on whether it was a subgroup in the initial path. If bad/2f57368b-0eda-4e52-64d8-af5c is the subgroup, the reduction will be
>>>
>>>```
>>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>>>/sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c
>>>/sys/fs/cgroup/cpu,cpuacct/bad
>>>/sys/fs/cgroup/cpu,cpuacct/
>>>```
>> 
>> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those.
>
>> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those.
> 
> The subgroup path reduction is covered by `TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` (it wouldn't be possible in gtests as it requires touching cgroup tree on a host system). It actually checks that the subgroup directory exists and skips non-existent directories, that is reflected in the test log below. The bottom line comes from `CgroupV1Controller::set_subsystem_path`.
> 
> ========== NEW TEST CASE:      Cgroup V1 subgroup memory limit: 100m
> [COMMAND]
> docker run --tty=true --rm --privileged --cgroupns=host --memory 200m jdk-internal:test-containers-docker-TestMemoryWithSubgroups-subgroup sh -c mkdir -p /sys/fs/cgroup/memory/test ; echo 100m > /sys/fs/cgroup/memory/test/memory.limit_in_bytes ; echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs ; /jdk/bin/java -Xlog:os+container=trace -version
> [2025-02-24T22:33:28.049656218Z] Gathering output for process 23369
> [ELAPSED: 5385 ms]
> [STDERR]
> 
> [STDOUT]
> [0.002s][trace][os,container] OSContainer::init: Initializing Container Support
> [0.003s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
> [0.004s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
> [0.004s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test.
> 
> With additional logging added before line 77, this could be looking like
> 
> [STDOUT]
> [0.002s][trace][os,container] OSContainer::init: Initializing Container Support
> [0.002s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
> [0.003s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
> [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test.
> [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test.
> [0.005s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test.
> 
> Before the fix, the current path adjustment scheme would produce the following order:
> 
> /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test
> /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370
> /sys/fs/cgroup/memory/docker
> /sys/fs/cgroup/memory
> 
> Only the last path is valid in the conta...

@sercher As far as I can see this is a fairly simple case which would be covered by a simpler patch. My comment was in regards to my comment [here](https://github.com/openjdk/jdk/pull/21808#discussion_r1865630320). Where you replied with [this answer](https://github.com/openjdk/jdk/pull/21808#discussion_r1865663436). I don't see where anything you've described in your answer is being tested, covering this new code:

https://github.com/openjdk/jdk/pull/21808/files#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9R63-R77

That is, some sub-group without a match, but some with one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2682078012

From sgehwolf at openjdk.org  Tue Feb 25 14:09:03 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 25 Feb 2025 14:09:03 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v15]
In-Reply-To: <jPiUQFkkA_7ELb36w5iT9aI0SZyW67azvVcO_Y6kpmA=.43bd87a6-8e61-40a3-ac47-938ef992784d@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <jPiUQFkkA_7ELb36w5iT9aI0SZyW67azvVcO_Y6kpmA=.43bd87a6-8e61-40a3-ac47-938ef992784d@github.com>
Message-ID: <qv-d4q9Dgg1oGp0dQyvix_ss8iGon0XqKAa07hS_f2g=.e3318903-fd78-415e-8f87-75c755da92f1@github.com>

On Mon, 24 Feb 2025 21:20:49 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - added high level comment to CgroupV1Controller::set_subsystem_path
>  - fix minor issue calling .getNameCount() twice

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 42:

> 40:  * When runs in a container, the method handles the case
> 41:  * when a process is moved between cgroups.
> 42:  */

This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1969851316

From vklang at openjdk.org  Tue Feb 25 14:40:56 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 25 Feb 2025 14:40:56 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
Message-ID: <fdVqboct3V5R8JZZCMw3wfs_6knV1tPC52D_SZ_f0dU=.23d55bf1-4c71-4013-8bd3-e4e13dc5a9f8@github.com>

On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Standardize parameter checking

src/java.base/share/classes/java/util/concurrent/DelayScheduler.java line 99:

> 97:      * is typical with IO-based timeouts). The use of a 4-ary heap (in
> 98:      * which each element has up to 4 children) improves locality and
> 99:      * reduces movement and memory writes compared to a standard

Suggestion:

     * which each element has up to 4 children) improves locality,
     * reduces movement, and memory writes compared to a standard

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1969914919

From ihse at openjdk.org  Tue Feb 25 14:41:54 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 25 Feb 2025 14:41:54 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <a6GcFgRP6Mmghgl8tuOWhXNwtSSN1999BDg8SH2nyFg=.74bd0ae7-1d27-4b6a-a798-1eafbc9977c2@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
 <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
 <RW0eXeCodO55Qy8C5HLrB-kCp8jlqfVRFo6ELAO3OTs=.c85c04d1-4792-4bb0-aad3-f8a8c3be4695@github.com>
 <a6GcFgRP6Mmghgl8tuOWhXNwtSSN1999BDg8SH2nyFg=.74bd0ae7-1d27-4b6a-a798-1eafbc9977c2@github.com>
Message-ID: <FHuKYg-191BBUnAbMlBOEDorfydcdvj5B4iFMdWO9J4=.e2b49040-2543-4e84-a1ba-12b7a35bc4d1@github.com>

On Fri, 21 Feb 2025 20:17:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>>> I have disabled them with #, and the status is confirmed by test for access modes. I kept the infra to make future reenabling easy.
>> 
>> Doh - I missed the `#` -- maybe add few more to make that more explicit? (I agree with the approach)
>
> Left a space and an extra note to make the comment hash more obvious.

Unless you plan to shortly push a new PR where you either enable this functionality, or remove the commented-out lines, I strongly prefer *not* to have commented-out code in the makefiles. It's not that hard to re-create these lines should they be needed. And you can always find the history in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1969917926

From vklang at openjdk.org  Tue Feb 25 14:49:01 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 25 Feb 2025 14:49:01 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
Message-ID: <VQ8h_8H-NOTVl3rxYcVBiVz3k3ztjBfkmiRG0lQXW9o=.96b46c0c-c8c6-480d-a8bf-00b87551992c@github.com>

On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Standardize parameter checking

src/java.base/share/classes/java/util/concurrent/DelayScheduler.java line 356:

> 354:                         for (int ck = cs, j = 4;;) { // at most 4 children
> 355:                             if ((c = h[ck]) == null)
> 356:                                 break;

Is it "cheaper" to place this here instead of in the loop-conditional?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1969931724

From vklang at openjdk.org  Tue Feb 25 14:53:57 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 25 Feb 2025 14:53:57 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
Message-ID: <KOSR6nHYysK9Q0Mjfl9avkI6ofus7Wxm11Lv8UxCbSE=.f8cb4a04-fa51-4754-9593-c5637cba629f@github.com>

On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Standardize parameter checking

src/java.base/share/classes/java/util/concurrent/DelayScheduler.java line 455:

> 453:         final long nextDelay;       // 0: once; <0: fixedDelay; >0: fixedRate
> 454:         int heapIndex;              // if non-negative, index on heap
> 455:         final boolean isImmediate;  // run by scheduler vs submitted when ready

If desired, it would be possible to create a bitset for `isImmediate` and `isCallable` such that we could get rid of a reference field per ScheduledForkJoinTask.
I suspect it would also be possible to use the same field for `pool` and `result` as there shouldn't be a result available for as long as `pool` is non-null.

Might not be worth doing at this point, but saving 2 reference fields for something which might get allocated millions of times might be worth it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1969943618

From galder at openjdk.org  Tue Feb 25 14:57:05 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 25 Feb 2025 14:57:05 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
Message-ID: <er1-FErHR72DYYqkEh9jLiESwthoh4FQd0A_fPNKetw=.e7089ac7-387d-48fa-97bd-9eb53d361f65@github.com>

On Fri, 7 Feb 2025 12:39:24 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Fix typo
>  - Renaming methods and variables and add docu on algorithms
>  - Fix copyright years
>  - Make sure it runs with cpus with either avx512 or asimd
>  - Test can only run with 256 bit registers or bigger
>    
>    * Remove platform dependant check
>    and use platform independent configuration instead.
>  - Fix license header
>  - Tests should also run on aarch64 asimd=true envs
>  - Added comment around the assertions
>  - Adjust min/max identity IR test expectations after changes
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/d6aa3453...a190ae68

> > The interesting thing is intReductionSimpleMin @ 100%. We see a regression there but I didn't observe it with the perfasm run. So, this could be due to variance in the application of cmov or not?
> 
> I don't see the error / variance in the results you posted. Often I look at those, and if it is anywhere above 10% of the average, then I'm suspicious ;)

> > Re: [#20098 (comment)](https://github.com/openjdk/jdk/pull/20098#issuecomment-2671144644) - I was trying to think what could be causing this.
> 
> Maybe it is an issue with probabilities? Do you know at what point (if at all) the `MinI` node appears/disappears in that example?

@eme64 I think you're in the right direction:


            minLongA = negate(maxLongA);
            minLongB = negate(maxLongB);
            minIntA = toInts(minLongA);
            minIntB = toInts(minLongB);


To keep same data distribution algorithm for both min and max operations, I started with positive numbers for max and found out that I could use the same data with the same properties for min by negating them. As you can see in the above snippet, the min values for ints had not been negated. I'll fix that and show final numbers with the same subset shown in https://github.com/openjdk/jdk/pull/20098#issuecomment-2671144644

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2682263423

From tschatzl at openjdk.org  Tue Feb 25 15:04:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Feb 2025 15:04:28 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput
 with a More Efficient Write-Barrier
Message-ID: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>

Hi all,

  please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.

The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.

### Current situation

With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.

The main reason for the current barrier is how g1 implements concurrent refinement:
* g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
* For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
* Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.

These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:


// Filtering
if (region(@x.a) == region(y)) goto done; // same region check
if (y == null) goto done;     // null value check
if (card(@x.a) == young_card) goto done;  // write to young gen check
StoreLoad;                // synchronize
if (card(@x.a) == dirty_card) goto done;

*card(@x.a) = dirty

// Card tracking
enqueue(card-address(@x.a)) into thread-local-dcq;
if (thread-local-dcq is not full) goto done;

call runtime to move thread-local-dcq into dcqs

done:


Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.

The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.

There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).

The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a second card table ("refinement table"). The second card table also replaces the dirty card queue.

In that scheme the fine-grained synchronization is unnecessary because mutator and refinement threads always write to different memory areas (and no concurrent write where an update can be lost can occur). This removes the necessity for synchronization for every reference write.
Also no card enqueuing is required any more.

Only the filters and the card mark remain.

### How this works

In the beginning both the card table and the refinement table are completely unmarked (contain "clean" cards). The mutator dirties the card table, until G1 heuristics think that a significant enough amount of cards were dirtied based on what is allocated for scanning them during the garbage collection.

At that point, the card table and the refinement table are exchanged "atomically" using handshakes. The mutator keeps dirtying the (the previous, clean refinement table which is now the) card table, while the refinement threads look for and refine dirty cards on the refinement table as before.

Refinement of cards is very similar to before: if an interesting reference in a dirty card has been found, G1 records it in appropriate remembered sets. In this implementation there is an exception for references to the current collection set (typically young gen) - the refinement threads redirty that card on the card table with a special `to-collection-set` value.

This is valid because races with the mutator for that write do not matter - the entire card will eventually be rescanned anyway, regardless of whether it ends up as dirty or to-collection-set. The advantage of marking to-collection-set cards specially is that the next time the card tables are swapped, the refinement threads will not re-refine them on the assumption that that reference to the collection set will not change. This decreases refinement work substantially.

If refinement gets interrupted by GC, the refinement table will be merged with the card table before card scanning, which works as before.

New barrier pseudo-code for an assignment `x.a = y`:

// Filtering
if (region(@x.a) == region(y)) goto done; // same region check
if (y == null) goto done;     // null value check
if (card(@x.a) != clean_card) goto done;  // skip already non-clean cards
*card(@x.a) = dirty

This is basically the Serial/Parallel GC barrier with additional filters to keep the number of dirty cards as little as possible.

A few more comments about the barrier:
* the barrier now loads the card table base offset from a thread local instead of inlining it. This is necessary for this mechanism to work as the card table to dirty changes over time, and may even be faster on some architectures (code size), and some architectures already do.
* all existing pre-filters were kept. Benchmarks showed some significant regressions wrt to pause times and even throughput compared to G1 in master. Using the Parallel GC barrier (just the dirty card write) would be possible, and further investigation on stripping parts will be made as follow-up.
* the final check tests for non-clean cards to avoid overwriting existing cards, in particular the "to-collection set" cards described above.

Current G1 marks the cards corresponding to young gen regions as all "young" so that the original barrier could potentially avoid the `StoreLoad`. This implementation removes this facility (which might be re-introduced later), but measurements showed that pre-dirtying the young generation region's cards as "dirty" (g1 does not need to use an extra "young" value) did not yield any measurable performance difference.

### Refinement process

The goal of the refinement (threads) is to make sure that the number of cards to scan in the garbage collection is below a particular threshold.

The prototype changes the refinement threads into a single control thread and a set of (refinement) worker threads. Differently to the previous implementation, the control thread does not do any refinement, but only executes the heuristics to start a calculated amount of worker threads and tracking refinement progress. 

The refinement trigger is based on current known number of pending (i.e. dirty) cards on the card table and a pending card generation rate, fairly similarly to the previous algorithm. After the refinement control thread determines that it is time to do refinement, it starts the following sequence:

1) **Swap the card table**. This consists of several steps:
    1) **Swap the global card table** - the global card table pointer is swapped; newly created threads and runtime calls will eventually use the new values, at the latest after the next two steps.
    2) **Update the pointers in all JavaThread**'s TLS storage to the new card table pointer using a handshake operation
    3) **Update the pointers in the GC thread**'s TLS storage to the new card table pointer using the SuspendibleThreadSet mechanism
2) **Snapshot the heap** - determine the extent of work needed for all regions where the refinement threads need to do some work on the refinement table (the previous card table). The snapshot stores the work progress for each region so that work can be interrupted and continued at any time.
    This work either consists of refinement of the particular card (old generation regions) or clearing the cards (next collection set/young generation regions).
3) **Sweep the refinement table** by activating the refinement worker threads. The threads refine dirty cards using the heap snapshot where worker threads claim parts of regions to process.
      * Cards with references to the young generation are not added to the young generation's card based remembered set. Instead these cards are marked as to-collection-set  in the card table and any remaining refinement of that card skipped.
      * If refinement encounters a card that is already marked as to-collection-set  it is not refined and re-marked as to-collection-set  on the card table .
      * During refinement, the refinement table is also cleared (in bulk for collection set regions as they do not need any refinement, and in other regions as they are refined for the non-clean cards).
      * Dirty cards within unparsable heap areas are forwarded to/redirtied on the card table as is.
4) **Completion work**, mostly statistics.

If the work is interrupted by a non-garbage collection synchronization point, work is suspended temporarily and resumed later using the heap snapshot.

After the refinement process the refinement table is all-clean again and ready to be swapped again.

### Garbage collection pause changes

Since a garbage collection (young or full gc) pause may occur at any point during the refinement process, the garbage collection needs some compensating work for the not yet swept parts of the refinement table.

Note that this situation is very rare, and the heuristics try to avoid that, so in most cases nothing needs to be done as the refinement table is all clean.

If this happens, young collections add a new phase called `Merge Refinement Table` in the garbage collection pause right before the `Merge Heap Roots` phase. This compensating phase does the following:

  0) (Optional) Snapshot the heap if not done yet (if the process has been interrupted between state 1 and 3 of the refinement process)
  1) Merge the refinement table into the card table - in this step the dirty cards of interesting regions are
  2) Completion work (statistics)

If a full collection interrupts concurrent refinement, the refinement table is simply cleared and all dirty cards thrown away.

A garbage collection generates new cards (e.g. references from promoted objects into the young generation) on the refinement table. This acts similarly to the extra DCQS used to record these interesting references/cards and redirty the card table using them in the previous implementation. G1 swaps the card tables at the end of the collection to keep the post-condition of the refinement table being all clean (and any to-be-refined cards on the card table) at the end of garbage collection.

### Performance metrics

Following is an overview of the changes in behavior. Some numbers are provided in the CR in the first comment.

#### Native memory usage

The refinement table takes an additional 0.2% of the Java heap size of native memory compared to JDK 21 and above (in JDK 21 we removed one card table sized data structure, so this is a non-issue when updating from before).

Some of that additional memory usage is automatically reclaimed by removing the dirty card queues. Additional memory is reclaimed by managing the cards containing to-collection-set references on the card table by dropping the explicit remembered sets for young generation completely and any remembered set entries which would otherwise be duplicated into the other region's remembered sets.

In some applications/benchmarks these gains completely offset the additional card table, however most of the time this is not the case, particularly for throughput applications currently.
It is possible to allocate the refinement table lazily, which means that since these applications often do not need any concurrent refinement, there is no overhead at all but actually a net reduction of native memory usage. This is not implemented in this prototype.

#### Latency ("Pause times")

Not affected or slightly better. Pause times decrease due to a shorter "Merge remembered sets" phase due to no work required for the remembered sets for the young generation - they are always already on the card table!

However merging of the refinement table into the card table is extremely fast and is always faster than merging remembered sets for the young gen in my measurements. Since this work is linearly scanning some memory, this is embarassingly parallel too.

The cards created during garbage collection do not need to be redirtied, so that phase has also been removed.

The card table swap is based on predictions for mutator card dirtying rate and refinement rate as before, and the policy is actually fairly similar to before. It is still rather aggressive, but in most cases takes less cpu resources than the one before, mostly because refining takes less cpu time. Many applications do not do any refinement at all like before. More investigation could be done to improve this in the future.

#### Throughput

This change always increases throughput in my measurements, depending on benchmark/application it may not actually show up in scores though.

Due to the pre-barrier and the additional filters in the barrier G1 is still slower than Parallel on raw throughput benchmarks, but is typically somewhere half-way to Parallel GC or closer.

### Platform support

Since the post write barrier changed, additional work for some platforms is required to allow this change to proceed. At this time all work for all platforms is done, but needs testing

- GraalVM (contributed by the GraalVM team)
- S390 (contributed by A. Kumar from IBM)
- PPC (contributed by M. Doerr, from SAP)
- ARM (should work, HelloWorld compiles and runs)
- RISCV (should work, HelloWorld compiles and runs)
- x86 (should work, build/HelloWorld compiles and runs)

None of the above mentioned platforms implement the barrier method to write cards for a reference array (aarch64 and x64 are fully implemented), they call the runtime as before. I believe it is doable fairly easily now with this simplified barrier for some extra performance, but not necessary.

### Alternatives

The JEP text extensively discusses alternatives.

### Reviewing

The change can be roughly divided in these fairly isolated parts
* platform specific changes to the barrier
* refinement and refinement control thread changes; this is best reviewed starting from the `G1ConcurrentRefineThread::run_service` method
* changes to garbage collection: `merge_refinement_table()` in `g1RemSet.cpp`
* policy modifications are typically related to code around the calls to `G1Policy::record_dirtying_stats`.

Further information is available in the [JEP draft](https://bugs.openjdk.org/browse/JDK-8340827); there is also an a bit more extensive discussion of the change on my [blog](https://tschatzl.github.io/2025/02/21/new-write-barriers.html).

Some additional comments:
* the pre-marking of young generation cards has been removed. Benchmarks did not show any significant difference either way. To me this makes somewhat sense because the entire young gen will quickly get marked anyway. I.e. one only saves a single additional card table write (for every card). With the old barrier the costs for a card table mark has been much higher.
* G1 sets `UseCondCardMark` to true by default. The conditional card mark corresponds to the third filter in the write barrier now, and since I decided to keep all filters for this change, it makes sense to directly use this mechanism.

If there are any questions, feel free to ask.

Testing: tier1-7 (multiple tier1-7, tier1-8 with slightly older versions)

Thanks,
  Thomas

-------------

Commit messages:
 - * only provide byte map base for JavaThreads
 - * mdoerr review: fix comments in ppc code
 - * fix crash when writing dirty cards for memory regions during card table switching
 - * remove mention of "enqueue" or "enqueuing" for actions related to post barrier
 - * remove some commented out debug code
 - Card table as DCQ

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342382
  Stats: 6543 lines in 103 files changed: 2162 ins; 3461 del; 920 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From mdoerr at openjdk.org  Tue Feb 25 15:04:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 25 Feb 2025 15:04:29 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <G83FK3KxY1dsv3aaFy0NmOqXr2nl1tE_2deUJfrYjjE=.5c37af96-e130-4156-86f0-7c42d22db295@github.com>

On Sun, 23 Feb 2025 18:53:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

PPC64 code looks great! Thanks for doing this! Only some comments are no longer correct.

src/hotspot/cpu/ppc/gc/g1/g1BarrierSetAssembler_ppc.cpp line 244:

> 242: 
> 243:   __ xorr(R0, store_addr, new_val);                          // tmp1 := store address ^ new value
> 244:   __ srdi_(R0, R0, G1HeapRegion::LogOfHRGrainBytes);         // tmp1 := ((store address ^ new value) >> LogOfHRGrainBytes)

Comment: R0 is used instead of tmp1

src/hotspot/cpu/ppc/gc/g1/g1BarrierSetAssembler_ppc.cpp line 259:

> 257: 
> 258:   __ ld(tmp1, G1ThreadLocalData::card_table_base_offset(), thread);
> 259:   __ srdi(tmp2, store_addr, CardTable::card_shift());        // tmp1 := card address relative to card table base

Comment: tmp2 is used, here

src/hotspot/cpu/ppc/gc/g1/g1BarrierSetAssembler_ppc.cpp line 261:

> 259:   __ srdi(tmp2, store_addr, CardTable::card_shift());        // tmp1 := card address relative to card table base
> 260:   if (UseCondCardMark) {
> 261:     __ lbzx(R0, tmp1, tmp2);                                 // tmp1 := card address

Can you remove the comment, please? It's wrong.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-2637143540
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1967669777
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1967670850
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1967671593

From duke at openjdk.org  Tue Feb 25 15:04:29 2025
From: duke at openjdk.org (Piotr Tarsa)
Date: Tue, 25 Feb 2025 15:04:29 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <mM84AwxY2EZXYcvhxn0c1ULbZ8qAyUWbN4tIDf1b_5k=.b88e32a6-ac41-4a29-a34c-e8973ddf6599@github.com>

On Sun, 23 Feb 2025 18:53:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

in this pr you've wrote

if (region(@x.a) != region(y)) goto done; // same region check

but on https://tschatzl.github.io/2025/02/21/new-write-barriers.html you wrote:

(1)  if (region(x.a) == region(y)) goto done;    // Ignore references within the same region/area

i guess the second one is correct

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2677075290

From stuefe at openjdk.org  Tue Feb 25 15:04:29 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Feb 2025 15:04:29 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <vccICgwHGbpmqNDM2u1xObw2CDIupybtOmIN0LpVcY0=.d5c2d7ac-5eca-4168-b25c-8bb0675062a2@github.com>

On Sun, 23 Feb 2025 18:53:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

@tschatzl I did not contribute the ppc port. Did you mean @TheRealMDoerr or @reinrich ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2677512780

From tschatzl at openjdk.org  Tue Feb 25 15:13:43 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Feb 2025 15:13:43 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v2]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <sATIRzYvi1wLv1tzkXOuwBN2F2YKy7SLSxaU6mnPWTg=.93b86875-3f5f-4ffe-91f0-a59ef68b2157@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * remove unnecessarily added logging

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/0100d8e2..9ef9c5f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=00-01

  Stats: 4 lines in 4 files changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From smarks at openjdk.org  Tue Feb 25 15:21:02 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 25 Feb 2025 15:21:02 GMT
Subject: Integrated: 8138614: (spec str) StringBuffer and StringBuilder methods
 improperly require "new" String to be returned
In-Reply-To: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
References: <R5Khfw-p67sD8ZYmEfgdq3FL3pU7deVUj1Izfse5fNI=.ca433150-39ef-4e2f-b3da-613af2212193@github.com>
Message-ID: <RNUB329zWpZGq9V2I8qGzHJrb6QB45EEBLDsYjObBV0=.5d03660f-7722-4e37-ba5f-9893bb07f7f1@github.com>

On Wed, 12 Feb 2025 19:55:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> A couple adjustments to the specs for four methods of StringBuilder and StringBuffer so that they no longer require new Strings to be created, just a String with the right contents. No implementation changes. Note that the actual specs (and implementations) are actually in AbstractStringBuilder, and they're inherited by StringBuilder and StringBuffer.

This pull request has now been integrated.

Changeset: 08bc59da
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08bc59da9b66c6504a2d2712feebf37cc5eb2d3e
Stats:     9 lines in 1 file changed: 0 ins; 1 del; 8 mod

8138614: (spec str) StringBuffer and StringBuilder methods improperly require "new" String to be returned

Reviewed-by: rgiulietti, shade, alanb, rriggs, liach

-------------

PR: https://git.openjdk.org/jdk/pull/23599

From asemenyuk at openjdk.org  Tue Feb 25 15:48:29 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Feb 2025 15:48:29 GMT
Subject: RFR: 8350601: Miscellaneous updates to jpackage test lib [v4]
In-Reply-To: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
References: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
Message-ID: <LwR103Nd6_tN9egExGVG8J-jdLSicsPDT_JNKt4vSbk=.466944d3-410c-4143-ad8c-28645e5183e8@github.com>

> - Unify TKit.createTempDirectory() and TKit.createTempFile() functions. Remove `throws IOexception` from their signatures. Add relevant tests.
>  - JPackageCommand.java: remove try/catch(IOexception) around `TKit.createTempDirectory()` call.
>  - AppImagePackageTest.java: replace `TKit.createTempDirectory(null)` with `TKit.createTempDirectory("appimage")` to fix NPE.
>  - Make `TKit.assertDirectoryExists(Path, Optional<Boolean>)` private. This is internal and shouldn't be exposed.
>  - add `TKit.assertEquals(boolean, boolean)` and `TKit.assertNotEquals(boolean, boolean)` with tests.
>  - AdditionalLauncher.java: remove redundant code duplicating functionality of `TKit.createTempFile()` (should have been cleaned long ago).
>  - JPackageCommand.java: add a check for the main jar in the app image if the main jar was specified. Missing part of [JDK-8325089](https://bugs.openjdk.org/browse/JDK-8325089).

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Better exception message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23754/files
  - new: https://git.openjdk.org/jdk/pull/23754/files/71072247..2e538caf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23754&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23754&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23754/head:pull/23754

PR: https://git.openjdk.org/jdk/pull/23754

From asemenyuk at openjdk.org  Tue Feb 25 15:48:29 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Feb 2025 15:48:29 GMT
Subject: RFR: 8350601: Miscellaneous updates to jpackage test lib [v3]
In-Reply-To: <q3hiQwGm4GcrqpmrZb_869Dt4IFJYlK84qHMTrDK-ko=.6e872ef6-33c4-4993-9795-72cd9a8fb8b2@github.com>
References: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
 <0FwuZfTqsEtFdRbEtS3OSpdFtUgx5Q6ky3PiRN1EYXY=.a4617553-a64e-4d0f-8b9a-5b6c819dab37@github.com>
 <2pIkTcwmKLSzk1fFtX2wdnEUtCox2YgK9lXTbexfy_0=.157ff385-01ae-4950-b2d7-7f0200a7dace@github.com>
 <ZDmQtEv1PUK8cTZ-5dSSmpxubvGQ2S91FI2jzLAHnd8=.5e3fec79-ee19-4d2e-b1b9-65fd029930e5@github.com>
 <q3hiQwGm4GcrqpmrZb_869Dt4IFJYlK84qHMTrDK-ko=.6e872ef6-33c4-4993-9795-72cd9a8fb8b2@github.com>
Message-ID: <e_fKz88Qpd5xkaU0jX2qhttKNwqSmqyaOzGgWyQDCPo=.72672e62-076a-4dac-a4d6-6c4914163e92@github.com>

On Tue, 25 Feb 2025 01:14:05 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>>> This one is confusing. It will evaluate to true if both != null
>> 
>> Correct. They both shouldn't be `true`. One of them must be `true`, and another one must be `false`.
>> 
>>> Did you mean "&&" instead of "=="?
>> 
>> No. I meant `==` :)
>
> If they both set to non-null value, then exception will be thrown since false == false. In this case exception message is confusing. Maybe change it to: `Only one of `expectedPath` and `expectedExceptionClass` should be set`

Fixed as suggested

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23754#discussion_r1970049352

From erikj at openjdk.org  Tue Feb 25 16:05:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Feb 2025 16:05:57 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <Ed1aLasBLCT-yzpycHzUzxePm9HnrKCvDq0NbJrmJmQ=.8ccd3dca-ab93-4881-8e6e-0593f3f11638@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

Build changes look ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2641639547

From asemenyuk at openjdk.org  Tue Feb 25 16:14:22 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Feb 2025 16:14:22 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging [v3]
In-Reply-To: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
Message-ID: <9mgllgaUDGiiFYekXcXOsZDei0hDRflNHQhKwCJeRMQ=.80469bf5-882d-41e7-98df-74c59dc3ea0d@github.com>

> - Fix the warning message about the custom installation directory location jpackage issues for DMG runtime packaging.
>  - Don't issue the warning when the `-install-dir` value equals the default installation directory location.
>  - Add relevant tests.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Better warning wording

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23752/files
  - new: https://git.openjdk.org/jdk/pull/23752/files/afc341c4..38b5c346

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23752&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23752&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23752/head:pull/23752

PR: https://git.openjdk.org/jdk/pull/23752

From asemenyuk at openjdk.org  Tue Feb 25 16:20:09 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Feb 2025 16:20:09 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <52B989DC-3789-4309-9C02-EF5A4136CFCB@gmail.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <52B989DC-3789-4309-9C02-EF5A4136CFCB@gmail.com>
Message-ID: <Pu9TItBA1iaFPpyfqfD1cs11Uf42jhY2f3eRVAw3CSg=.4d94a860-5b04-4c16-ab41-88d3615d3300@github.com>

On Tue, 25 Feb 2025 03:28:46 GMT, Michael Hall <mik3hall at gmail.com> wrote:

> I would think a warning should just indicate that ?install-dir is always ignored for dmg builds.

Do you suggest bringing back the behavior of jpackage that always issued the warning when the `--install-dir` option is used with DMG packaging, or do you have different wording for the waning? Or both? :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23752#issuecomment-2682539392

From mik3hall at gmail.com  Tue Feb 25 16:25:28 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 25 Feb 2025 10:25:28 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <Pu9TItBA1iaFPpyfqfD1cs11Uf42jhY2f3eRVAw3CSg=.4d94a860-5b04-4c16-ab41-88d3615d3300@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <52B989DC-3789-4309-9C02-EF5A4136CFCB@gmail.com>
 <Pu9TItBA1iaFPpyfqfD1cs11Uf42jhY2f3eRVAw3CSg=.4d94a860-5b04-4c16-ab41-88d3615d3300@github.com>
Message-ID: <F2F02AE0-5395-449E-9A56-906A5ED0FA74@gmail.com>



> On Feb 25, 2025, at 10:20?AM, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:
> 
> On Tue, 25 Feb 2025 03:28:46 GMT, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> I would think a warning should just indicate that ?install-dir is always ignored for dmg builds.
> 
> Do you suggest bringing back the behavior of jpackage that always issued the warning when the `--install-dir` option is used with DMG packaging, or do you have different wording for the waning? Or both? :)
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/23752#issuecomment-2682539392

I guess yes. Either always warn it doesn?t do anything with a dmg or ignore it silently and let them use it if it makes them happy. 
But I still myself don?t see what any directory has to do with a dmg.  You don?t install the dmg or the app anywhere? You just put the app into the dmg. 
Or I am still somehow misunderstanding.

From schernyshev at openjdk.org  Tue Feb 25 16:34:04 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 25 Feb 2025 16:34:04 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v15]
In-Reply-To: <qv-d4q9Dgg1oGp0dQyvix_ss8iGon0XqKAa07hS_f2g=.e3318903-fd78-415e-8f87-75c755da92f1@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <jPiUQFkkA_7ELb36w5iT9aI0SZyW67azvVcO_Y6kpmA=.43bd87a6-8e61-40a3-ac47-938ef992784d@github.com>
 <qv-d4q9Dgg1oGp0dQyvix_ss8iGon0XqKAa07hS_f2g=.e3318903-fd78-415e-8f87-75c755da92f1@github.com>
Message-ID: <pK7gXk5Nv6_6EMQS-sqQprcMMz_v6y305aUNaal7EWA=.3a1033fe-867a-439d-9041-683be9e83019@github.com>

On Tue, 25 Feb 2025 14:06:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly?

Either it shall be a high level comment such as in your suggestion [here](https://github.com/openjdk/jdk/pull/21808#pullrequestreview-2620718790), or a deeper description in detail what happens where. Could you please be more specific on what kind of description is required and where? Please note the method has inline comments that are fairly self describing. In the meanwhile I'll try to add a description of what "a process is moved between cgroups" exactly means.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1970137041

From vklang at openjdk.org  Tue Feb 25 17:09:02 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 25 Feb 2025 17:09:02 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
Message-ID: <rn2QsMz78Q2TtcqCbRM3G7z3qUyevKBv6JOvdutrMbg=.1260e240-5836-421c-a314-773935351c34@github.com>

On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Standardize parameter checking

test/jdk/java/util/concurrent/tck/ForkJoinPool20Test.java line 510:

> 508: 
> 509:         try (PoolCleaner cleaner = cleaner(p, done)) {
> 510:             for (int i = p.getParallelism(); i--> 0; ) {

Suggestion:

            for (int i = p.getParallelism(); i-- > 0; ) {

test/jdk/java/util/concurrent/tck/ForkJoinPool20Test.java line 523:

> 521:             done.countDown();   // release blocking tasks
> 522:             assertTrue(p.awaitTermination(LONG_DELAY_MS, MILLISECONDS));
> 523: 

Suggestion:

test/jdk/java/util/concurrent/tck/ForkJoinPool20Test.java line 577:

> 575:                 Thread.sleep(LONGER_DELAY_MS); return Boolean.TRUE; }};
> 576:         ForkJoinTask<?> task = p.submitWithTimeout(c, 1, NANOSECONDS, null);
> 577:         Thread.sleep(timeoutMillis());

Do we need to sleep here or just get the result with a timeout expecting a CancellationException then asserting isCancelled == true?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1970199274
PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1970199879
PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1970203366

From naoto at openjdk.org  Tue Feb 25 17:14:03 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Feb 2025 17:14:03 GMT
Subject: RFR: 8345213: JVM Prefers /etc/timezone Over /etc/localtime on
 Debian 12
In-Reply-To: <qpEIgEVC7Al633vqNCMjG2fG9FnToVFTUzY9Iig1rgU=.08b7b802-40d6-4c67-8b67-118c093d51bf@github.com>
References: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
 <qpEIgEVC7Al633vqNCMjG2fG9FnToVFTUzY9Iig1rgU=.08b7b802-40d6-4c67-8b67-118c093d51bf@github.com>
Message-ID: <mt5EOPi3AfbMMLtdhVTiPYB8Yd1lX-tX5fYRVcgE0pM=.c051ab14-d7b6-4727-9ea2-5143b90079ff@github.com>

On Tue, 25 Feb 2025 06:53:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Naoto, this looks reasonable to me. Do you think we should add a release note for this change?

Good point. I will draft a release note for this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23755#issuecomment-2682700376

From sgehwolf at openjdk.org  Tue Feb 25 17:14:10 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 25 Feb 2025 17:14:10 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v15]
In-Reply-To: <pK7gXk5Nv6_6EMQS-sqQprcMMz_v6y305aUNaal7EWA=.3a1033fe-867a-439d-9041-683be9e83019@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <jPiUQFkkA_7ELb36w5iT9aI0SZyW67azvVcO_Y6kpmA=.43bd87a6-8e61-40a3-ac47-938ef992784d@github.com>
 <qv-d4q9Dgg1oGp0dQyvix_ss8iGon0XqKAa07hS_f2g=.e3318903-fd78-415e-8f87-75c755da92f1@github.com>
 <pK7gXk5Nv6_6EMQS-sqQprcMMz_v6y305aUNaal7EWA=.3a1033fe-867a-439d-9041-683be9e83019@github.com>
Message-ID: <IburxTbm543dAyzexBk6JLRSB98aV9Gi7yi38FsrKog=.2a2bced5-4319-4aff-9eb1-67ee4448c695@github.com>

On Tue, 25 Feb 2025 16:31:05 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 42:
>> 
>>> 40:  * When runs in a container, the method handles the case
>>> 41:  * when a process is moved between cgroups.
>>> 42:  */
>> 
>> This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly?
>
>> This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly?
> 
> Either it shall be a high level comment such as in your suggestion [here](https://github.com/openjdk/jdk/pull/21808#pullrequestreview-2620718790), or a deeper description in detail what happens where. Could you please be more specific on what kind of description is required and where? Please note the method has inline comments that are fairly self describing. In the meanwhile I'll try to add a description of what "a process is moved between cgroups" exactly means.

A high level description that mentions what the function does. The inline comments are not very self describing for anyone not having written the patch.

Example:

Sets the subsystem path for a controller. The common container case is
handled by XXX. When a process has been moved from a cgroup to another
the following happens:
 - A
 - B
 - C


I believe this is desperately needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1970211567

From asemenyuk at openjdk.org  Tue Feb 25 17:15:07 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Feb 2025 17:15:07 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <F2F02AE0-5395-449E-9A56-906A5ED0FA74@gmail.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <F2F02AE0-5395-449E-9A56-906A5ED0FA74@gmail.com>
Message-ID: <58X4rQNeeMvcmKdhL1N5pthpqTNmjh5nt8cg_08a8zA=.0f269d88-424b-4c0f-a6c9-2068445a73dc@github.com>

On Tue, 25 Feb 2025 16:27:51 GMT, Michael Hall <mik3hall at gmail.com> wrote:

> ignore it silently

I don't like it. If they pass a cli option ignored by jpackage, we should warn them.

> But I still myself don?t see what any directory has to do with a dmg

We need to put a directory on the right side from the copy arrow on the dialog that pops up when you open a dmg. In other words, we need a default directory where you can copy the dmg. Of course, you can copy it to another directory and ignore the default one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23752#issuecomment-2682702120

From naoto at openjdk.org  Tue Feb 25 17:18:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Feb 2025 17:18:01 GMT
Subject: RFR: 8345213: JVM Prefers /etc/timezone Over /etc/localtime on
 Debian 12
In-Reply-To: <mt5EOPi3AfbMMLtdhVTiPYB8Yd1lX-tX5fYRVcgE0pM=.c051ab14-d7b6-4727-9ea2-5143b90079ff@github.com>
References: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
 <qpEIgEVC7Al633vqNCMjG2fG9FnToVFTUzY9Iig1rgU=.08b7b802-40d6-4c67-8b67-118c093d51bf@github.com>
 <mt5EOPi3AfbMMLtdhVTiPYB8Yd1lX-tX5fYRVcgE0pM=.c051ab14-d7b6-4727-9ea2-5143b90079ff@github.com>
Message-ID: <L1l4QUVUkMhv5cnWfCPcYCofevbk1I9cztK-zKXKet8=.a0aec683-94cf-478c-be00-96ba601f56c4@github.com>

On Tue, 25 Feb 2025 17:11:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello Naoto, this looks reasonable to me. Do you think we should add a release note for this change?
>
>> Hello Naoto, this looks reasonable to me. Do you think we should add a release note for this change?
> 
> Good point. I will draft a release note for this change.

> @naotoj Do you know what was the last Debian release where this file was used? I'm looking at JDK-6456628 to try to understand if any of the distros from that needed this code have any supported releases that might need it.

Here is a quote from this Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822733


This now leaves /etc/timezone completely redundant, as you should get
exactly the same answer by readlink /etc/localtime -- and if you do
not get the same answer, you have an inconsistency. /etc/localtime
obviously "wins" for the actual clock (as that's what programs are
reading), but you presumably get the /etc/timezone value in some
"system configuration tool" packages which read /etc/timezone first.


This seems to imply that as of 2016, /etc/timezone is a redundant file. Our supported Debian distros (as of JDK23) are Ubuntu 24.04LTS and 24.10, so I think we are OK just remove the support for /etc/timezone

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23755#issuecomment-2682711288

From schernyshev at openjdk.org  Tue Feb 25 17:23:00 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 25 Feb 2025 17:23:00 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <tJ3zjnmJ1lKiQR8c6dhE_kGUR9qr75rWZmvsnMh-_8w=.5a75cd5c-fd8d-4336-a0e6-7d98fe69c0ae@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
 <tJ3zjnmJ1lKiQR8c6dhE_kGUR9qr75rWZmvsnMh-_8w=.5a75cd5c-fd8d-4336-a0e6-7d98fe69c0ae@github.com>
Message-ID: <1dczYd447I2XbdYWyDWOceZH6YjiJIM7rmsM2l2kAMM=.ea796f48-3ac2-412f-badd-46e08942c9bd@github.com>

On Mon, 24 Feb 2025 23:33:01 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> `CgroupV1Controller::set_subsystem_path` needs high level comment update to describe the logic happening.
>> 
>> Testing:
>>>>And after the patch this would become this, right?
>>>>```
>>>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>>>>/sys/fs/cgroup/cpu,cpuacct/
>>>>```
>>>
>>>It depends on whether it was a subgroup in the initial path. If bad/2f57368b-0eda-4e52-64d8-af5c is the subgroup, the reduction will be
>>>
>>>```
>>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>>>/sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c
>>>/sys/fs/cgroup/cpu,cpuacct/bad
>>>/sys/fs/cgroup/cpu,cpuacct/
>>>```
>> 
>> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those.
>
>> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those.
> 
> The subgroup path reduction is covered by `TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` (it wouldn't be possible in gtests as it requires touching cgroup tree on a host system). It actually checks that the subgroup directory exists and skips non-existent directories, that is reflected in the test log below. The bottom line comes from `CgroupV1Controller::set_subsystem_path`.
> 
> ========== NEW TEST CASE:      Cgroup V1 subgroup memory limit: 100m
> [COMMAND]
> docker run --tty=true --rm --privileged --cgroupns=host --memory 200m jdk-internal:test-containers-docker-TestMemoryWithSubgroups-subgroup sh -c mkdir -p /sys/fs/cgroup/memory/test ; echo 100m > /sys/fs/cgroup/memory/test/memory.limit_in_bytes ; echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs ; /jdk/bin/java -Xlog:os+container=trace -version
> [2025-02-24T22:33:28.049656218Z] Gathering output for process 23369
> [ELAPSED: 5385 ms]
> [STDERR]
> 
> [STDOUT]
> [0.002s][trace][os,container] OSContainer::init: Initializing Container Support
> [0.003s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
> [0.004s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
> [0.004s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test.
> 
> With additional logging added before line 77, this could be looking like
> 
> [STDOUT]
> [0.002s][trace][os,container] OSContainer::init: Initializing Container Support
> [0.002s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
> [0.003s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
> [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test.
> [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test.
> [0.005s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test.
> 
> Before the fix, the current path adjustment scheme would produce the following order:
> 
> /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test
> /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370
> /sys/fs/cgroup/memory/docker
> /sys/fs/cgroup/memory
> 
> Only the last path is valid in the conta...

> @sercher As far as I can see this is a fairly simple case which would be covered by a simpler patch. My comment was in regards to my comment [here](https://github.com/openjdk/jdk/pull/21808#discussion_r1865630320). Where you replied with [this answer](https://github.com/openjdk/jdk/pull/21808#discussion_r1865663436). I don't see where anything you've described in your answer is being tested, covering this new code:
> 
> https://github.com/openjdk/jdk/pull/21808/files#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9R63-R77

The code fragment you mentioned is executed under condition at line 62, that is, `_root` and `cgroup_path` are not equal. This happens exactly when a process PID is written to `cgroup.procs` file in the directory, belonging to a certain control group G, i.e. the process PID is moved to the control group G. Now that we have `_root` and `cgroup_path` non-equal, such as in my response [here](https://github.com/openjdk/jdk/pull/21808#discussion_r1865663436), i.e.


_root: /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c
cgroup_path: /system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c

the loop at lines 67-77 is determining the "subgroup" part of the above `cgroup_path` , producing the debug message at line 73. The above case is CloudFoundry specific, while in the default docker setup it will be

_root: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370
cgroup_path: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test

In both cases it needs to be determined what (trailing) part of `cgroup_path` is an actual subgroup path, because this is how we find a directory that exists in the container. It's not known whether the subgroup path is

/bad/2f57368b-0eda-4e52-64d8-af5c

or

/garden/bad/2f57368b-0eda-4e52-64d8-af5c

and then the cgroup files path is either 

/sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c

or

/sys/fs/cgroup/cpu,cpuacct/garden/bad/2f57368b-0eda-4e52-64d8-af5c

The docker case is not any different from the CF case. I therefore suggest [this](https://github.com/openjdk/jdk/pull/21808#discussion_r1865663436) case is covered by `TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` as noted previously. Hope this helps.
> 
> That is, some sub-group without a match, but some with one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2682721738

From vklang at openjdk.org  Tue Feb 25 17:25:14 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 25 Feb 2025 17:25:14 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
Message-ID: <uGcOd2C4T-mit0tXqtPlnocXVBNFdry5u5_KqXp_6NE=.4566606d-8c66-430b-a9c0-b433f6a6e1d6@github.com>

On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Standardize parameter checking

test/jdk/java/util/concurrent/tck/ForkJoinPool20Test.java line 630:

> 628:                 return Boolean.TRUE; }};
> 629:         ForkJoinTask<?> task = p.submitWithTimeout(c, LONGER_DELAY_MS, MILLISECONDS, null);
> 630:         Thread.sleep(timeoutMillis());

Suggest to check that the task was successfully completed with the right result (as well).

test/jdk/java/util/concurrent/tck/ForkJoinPool20Test.java line 649:

> 647:             p.shutdown();
> 648:             assertTrue(p.awaitTermination(LONG_DELAY_MS, MILLISECONDS));
> 649:             assertTrue(f.isDone());

Might make sense to factor out assertions of sets of states associated with successful, cancelled, failed and use those asserts throughout these tests (just to make sure that there aren't weird combinations of states).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1970227926
PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1970230047

From mik3hall at gmail.com  Tue Feb 25 17:38:56 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 25 Feb 2025 11:38:56 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <58X4rQNeeMvcmKdhL1N5pthpqTNmjh5nt8cg_08a8zA=.0f269d88-424b-4c0f-a6c9-2068445a73dc@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <F2F02AE0-5395-449E-9A56-906A5ED0FA74@gmail.com>
 <58X4rQNeeMvcmKdhL1N5pthpqTNmjh5nt8cg_08a8zA=.0f269d88-424b-4c0f-a6c9-2068445a73dc@github.com>
Message-ID: <186CC11A-EB88-400A-AF67-E0AF2B6862CB@gmail.com>



> On Feb 25, 2025, at 11:15?AM, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:
> 
> On Tue, 25 Feb 2025 16:27:51 GMT, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> ignore it silently
> 
> I don't like it. If they pass a cli option ignored by jpackage, we should warn them.
> 
>> But I still myself don?t see what any directory has to do with a dmg
> 
> We need to put a directory on the right side from the copy arrow on the dialog that pops up when you open a dmg. In other words, we need a default directory where you can copy the dmg. Of course, you can copy it to another directory and ignore the default one.
> 

I wasn?t entirely serious about ignoring. Yes, actually I think they should always be warned the cli option is ignored or has no effect. The dmg image should always have the Application directory. This is standard MacOS practice. I don?t know if you should even call it the default. I would say for any application install dmg it is ?the choice?. You are correct the user can then opt to install it elsewhere. 

A warning that cli has no effect I think would always make sense. Even if they make it the Application directory it isn?t really doing anything right?


From epeter at openjdk.org  Tue Feb 25 17:45:54 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 25 Feb 2025 17:45:54 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <LFxhMM1c0TdQTfXOGwZejzv1ChoF1NITOm3gYk-JbsI=.781ce977-2a85-4a90-a3cd-13284b0ec1e8@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

test/micro/org/openjdk/bench/vm/compiler/MergeStores.java line 175:

> 173:     public byte[] store_B2_con_offs_allocate_bale() {
> 174:         byte[] aB = new byte[RANGE];
> 175:         ByteArray.setShortLE(aB, offset, (short)0x0201);

Did you run this benchmark to see if there is any impact?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1970261194

From asemenyuk at openjdk.org  Tue Feb 25 18:42:00 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Feb 2025 18:42:00 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <186CC11A-EB88-400A-AF67-E0AF2B6862CB@gmail.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <186CC11A-EB88-400A-AF67-E0AF2B6862CB@gmail.com>
Message-ID: <XcIu_pJdEaZzgzFosfF_ZxrrpaZuCqHQC1QEfuBtR4E=.2a12c38d-68dc-4bba-b553-9d1da8eff884@github.com>

On Tue, 25 Feb 2025 17:40:46 GMT, Michael Hall <mik3hall at gmail.com> wrote:

> Yes, actually I think they should always be warned the cli option is ignored or has no effect.

Even if the cli option has a value that is not ignored because it is equal to the default one? Why issue a warning if the value of the option is accepted?

>  The dmg image should always have the Application directory

This is not the case for Java runtime packages, They are installed in `/Library/Java/JavaVirtualMachines` subtree by default, not in `/Applications`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23752#issuecomment-2682954375

From vaivanov at openjdk.org  Tue Feb 25 19:11:05 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 25 Feb 2025 19:11:05 GMT
Subject: RFR: 8350682 [JMH] vector.IndexInRangeBenchmark failed with IOOBE
Message-ID: <a1_5DZ8fmibdpMXTNaQEzF2q4ExfqGVpxfKxTIjAPgc=.5aba77b1-53a8-4d50-8622-959d163592c0@github.com>

Array initialization by parameter was added. Extra constant was used to align cycle step with used arrays.

-------------

Commit messages:
 - 8350682 [JMH] vector.IndexInRangeBenchmark failed with IndexOutOfBoundsException for size=1024

Changes: https://git.openjdk.org/jdk/pull/23783/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23783&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350682
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23783.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23783/head:pull/23783

PR: https://git.openjdk.org/jdk/pull/23783

From mik3hall at gmail.com  Tue Feb 25 19:22:50 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 25 Feb 2025 13:22:50 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <XcIu_pJdEaZzgzFosfF_ZxrrpaZuCqHQC1QEfuBtR4E=.2a12c38d-68dc-4bba-b553-9d1da8eff884@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <186CC11A-EB88-400A-AF67-E0AF2B6862CB@gmail.com>
 <XcIu_pJdEaZzgzFosfF_ZxrrpaZuCqHQC1QEfuBtR4E=.2a12c38d-68dc-4bba-b553-9d1da8eff884@github.com>
Message-ID: <E3883335-36D2-4E2C-AA4F-E2B3212A6887@gmail.com>



> On Feb 25, 2025, at 12:42?PM, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:
> 
> On Tue, 25 Feb 2025 17:40:46 GMT, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> Yes, actually I think they should always be warned the cli option is ignored or has no effect.
> 
> Even if the cli option has a value that is not ignored because it is equal to the default one? Why issue a warning if the value of the option is accepted?

Because for dmg?s including the cli option doesn?t actually do anything. Which they should know before they don?t get a warning on the Application directory but do when they try something else. 
They should realize why, but maybe won?t understand the difference.

> 
>> The dmg image should always have the Application directory
> 
> This is not the case for Java runtime packages, They are installed in `/Library/Java/JavaVirtualMachines` subtree by default, not in `/Applications`.
> 

Again I?ve been assuming type dmg builds. For pkg it might be different. I haven?t done any of those.


From asemenyuk at openjdk.org  Tue Feb 25 19:41:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Feb 2025 19:41:57 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <E3883335-36D2-4E2C-AA4F-E2B3212A6887@gmail.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <E3883335-36D2-4E2C-AA4F-E2B3212A6887@gmail.com>
Message-ID: <Mceya-kVfUsyFkJoJgr1fih2Bck7uOll9U5OF5BkcG0=.0310af16-8472-4edd-88c2-eb46f0ce3c5f@github.com>

On Tue, 25 Feb 2025 19:24:46 GMT, Michael Hall <mik3hall at gmail.com> wrote:

> Again I?ve been assuming type dmg builds.

Me too. jpackage can package Java runtime in a dmg.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23752#issuecomment-2683097211

From duke at openjdk.org  Tue Feb 25 19:44:56 2025
From: duke at openjdk.org (Sunmisc Unsafe)
Date: Tue, 25 Feb 2025 19:44:56 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling
In-Reply-To: <rsvIPXG0q5KZJY8svll6a78ZEJwIjAZx0MxwFgd04DU=.32ebadf4-182e-47c5-b804-92028b40fc29@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <rsvIPXG0q5KZJY8svll6a78ZEJwIjAZx0MxwFgd04DU=.32ebadf4-182e-47c5-b804-92028b40fc29@github.com>
Message-ID: <4L5Ay2O3BjFZKPBvXAhOJV3W0w15gDRvV6EF5RghC1E=.94498d38-bc87-4ccc-9662-770fba012b38@github.com>

On Thu, 20 Feb 2025 22:35:07 GMT, Sunmisc Unsafe <duke at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Is it possible to use getAndSet instead of cas-loop on #pend?
> 
> final Task t = tail.getAndSet(task);
> t.next = task;
> 
> but that would require a new head field to bypass, probably not worth the gamble if the footprint increases a lot

> @sunmisc You are right that it would be nice if there were a way to efficiently use getAndSet here because a failed reference CAS hits slow paths that vary across GCs. But all of the ways I know to do this are much worse.

After a few days of benchmarks, I realized that you would be absolutely right. Although I thought if we separate the head (for deleting) and the tail (for inserting) there would be less contention. 
Even the fact that we can change the head (delete) only in one thread does not help us from volatile, moreover, it became worse.
Perhaps I have made a mistake somewhere in the implementation

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23702#issuecomment-2683105690

From dl at openjdk.org  Tue Feb 25 20:03:01 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 25 Feb 2025 20:03:01 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <fdVqboct3V5R8JZZCMw3wfs_6knV1tPC52D_SZ_f0dU=.23d55bf1-4c71-4013-8bd3-e4e13dc5a9f8@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
 <fdVqboct3V5R8JZZCMw3wfs_6knV1tPC52D_SZ_f0dU=.23d55bf1-4c71-4013-8bd3-e4e13dc5a9f8@github.com>
Message-ID: <aF5e2PACb9659h3T1yPx2yBgjO9KSDAKsltp5NqjJtw=.9fdda4bb-d757-4b1a-94a9-8487a39080f4@github.com>

On Tue, 25 Feb 2025 14:37:49 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Standardize parameter checking
>
> src/java.base/share/classes/java/util/concurrent/DelayScheduler.java line 99:
> 
>> 97:      * is typical with IO-based timeouts). The use of a 4-ary heap (in
>> 98:      * which each element has up to 4 children) improves locality and
>> 99:      * reduces movement and memory writes compared to a standard
> 
> Suggestion:
> 
>      * which each element has up to 4 children) improves locality,
>      * reduces movement, and memory writes compared to a standard

Now:
     * which each element has up to 4 children) improves locality, and
     * reduces the need for array movement and memory writes compared

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1970465266

From alanb at openjdk.org  Tue Feb 25 20:20:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Feb 2025 20:20:55 GMT
Subject: RFR: 8345213: JVM Prefers /etc/timezone Over /etc/localtime on
 Debian 12
In-Reply-To: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
References: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
Message-ID: <XOT978HqXHbRYfyNkxmv2grOm-bx3gSrAtPoGlHBNvU=.4731e2cd-9434-405e-84ab-200492efc17f@github.com>

On Mon, 24 Feb 2025 19:46:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the support for /etc/timezone file that is Debian distro specific. The file is no longer considered authoritative (https://wiki.debian.org/TimeZoneChanges#Check_Configured_Timezone), and in fact, it is now out of sync as the bug reports. The fix was confirmed manually on a Ubuntu 25.04.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23755#pullrequestreview-2642369500

From alanb at openjdk.org  Tue Feb 25 20:20:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Feb 2025 20:20:55 GMT
Subject: RFR: 8345213: JVM Prefers /etc/timezone Over /etc/localtime on
 Debian 12
In-Reply-To: <L1l4QUVUkMhv5cnWfCPcYCofevbk1I9cztK-zKXKet8=.a0aec683-94cf-478c-be00-96ba601f56c4@github.com>
References: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
 <qpEIgEVC7Al633vqNCMjG2fG9FnToVFTUzY9Iig1rgU=.08b7b802-40d6-4c67-8b67-118c093d51bf@github.com>
 <mt5EOPi3AfbMMLtdhVTiPYB8Yd1lX-tX5fYRVcgE0pM=.c051ab14-d7b6-4727-9ea2-5143b90079ff@github.com>
 <L1l4QUVUkMhv5cnWfCPcYCofevbk1I9cztK-zKXKet8=.a0aec683-94cf-478c-be00-96ba601f56c4@github.com>
Message-ID: <A6asnByYAht99rVzp6jQmJfdKHB99ssSwTauh1YXis4=.97eb7732-1c22-4991-b069-e55010272673@github.com>

On Tue, 25 Feb 2025 17:15:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This seems to imply that as of 2016, /etc/timezone is a redundant file. Our supported Debian distros (as of JDK23) are Ubuntu 24.04LTS and 24.10, so I think we are OK just remove the support for /etc/timezone

Okay, although I expect there is a much wider set of distros in use. Getting this in early for JDK 25 is good as it gives time for anything that might depend on this to show up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23755#issuecomment-2683191847

From mik3hall at gmail.com  Tue Feb 25 20:48:46 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 25 Feb 2025 14:48:46 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <Mceya-kVfUsyFkJoJgr1fih2Bck7uOll9U5OF5BkcG0=.0310af16-8472-4edd-88c2-eb46f0ce3c5f@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <E3883335-36D2-4E2C-AA4F-E2B3212A6887@gmail.com>
 <Mceya-kVfUsyFkJoJgr1fih2Bck7uOll9U5OF5BkcG0=.0310af16-8472-4edd-88c2-eb46f0ce3c5f@github.com>
Message-ID: <0AE748E5-836F-4459-BEE4-2FFF9768B1F3@gmail.com>



> On Feb 25, 2025, at 1:41?PM, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:
> 
> On Tue, 25 Feb 2025 19:24:46 GMT, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> Again I?ve been assuming type dmg builds.
> 
> Me too. jpackage can package Java runtime in a dmg.
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/23752#issuecomment-2683097211

I might be getting confused. It always packages a runtime for mine. Either a default one that is jlink'ed or you can provide one.

e.g.
ls ~/Documents/Election\ Games/eg_jpkg/outputdir/Election\ Games.app/Contents/runtime/Contents/Home 
conf	legal	lib	release

My memory is more questionable these days but for me, I think for Oracle you download a compressed runtime you decompress and manually add to /Library/Java/JavaVirtualMachines.Maybe that?s a dmg, I haven?t done one for a bit. Possibly if someone without their own runtime uses jpackage you download one for them and put it in JavaVirttualMachines? But I still assume you never indicate this as any kind of destination for any jpackage usage do you? It is never a install directory you are expected to know? Or that a dmg indicates as a target destination. 

From asemenyuk at openjdk.org  Tue Feb 25 21:02:55 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Feb 2025 21:02:55 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <0AE748E5-836F-4459-BEE4-2FFF9768B1F3@gmail.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <0AE748E5-836F-4459-BEE4-2FFF9768B1F3@gmail.com>
Message-ID: <kjTHwwIuuWhLrdrpPOfe324CMf_JNNawZV12uKGe2PA=.c92d51cb-2ba7-47fd-90dd-3b931b8b1bc8@github.com>

On Tue, 25 Feb 2025 20:50:46 GMT, Michael Hall <mik3hall at gmail.com> wrote:

> It always packages a runtime for mine

Right. When jpackage is used to bundle an app (which is the most common use case) it automatically adds Java runtime to the app image.

However, jpackage can be used to bundle standalone Java runtime without an app. For these bundles, the default installation location is in `/Library/Java/JavaVirtualMachines` subtree, not in `/Applications`. All bundle formats (pkg, dmg, exe, msi, rpm, deb) supported for app bundles are also supported for runtime bundles.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23752#issuecomment-2683282035

From dl at openjdk.org  Tue Feb 25 21:02:57 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 25 Feb 2025 21:02:57 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <VQ8h_8H-NOTVl3rxYcVBiVz3k3ztjBfkmiRG0lQXW9o=.96b46c0c-c8c6-480d-a8bf-00b87551992c@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
 <VQ8h_8H-NOTVl3rxYcVBiVz3k3ztjBfkmiRG0lQXW9o=.96b46c0c-c8c6-480d-a8bf-00b87551992c@github.com>
Message-ID: <jBUWQAer-7AcFCd6qgfAIs9OUxHCEsUTfRUKgmz3at4=.d48b9d16-4d09-4190-97d8-95f1d547e05b@github.com>

On Tue, 25 Feb 2025 14:46:07 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Standardize parameter checking
>
> src/java.base/share/classes/java/util/concurrent/DelayScheduler.java line 356:
> 
>> 354:                         for (int ck = cs, j = 4;;) { // at most 4 children
>> 355:                             if ((c = h[ck]) == null)
>> 356:                                 break;
> 
> Is it "cheaper" to place this here instead of in the loop-conditional?

It's there in that way to make it easier to revisit decision about whether to null out slot immediately on seeing  cancellation. I don't think it impacts anything else.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1970535302

From dl at openjdk.org  Tue Feb 25 21:06:55 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 25 Feb 2025 21:06:55 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <KOSR6nHYysK9Q0Mjfl9avkI6ofus7Wxm11Lv8UxCbSE=.f8cb4a04-fa51-4754-9593-c5637cba629f@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
 <KOSR6nHYysK9Q0Mjfl9avkI6ofus7Wxm11Lv8UxCbSE=.f8cb4a04-fa51-4754-9593-c5637cba629f@github.com>
Message-ID: <0msF-rVH7lRmx_uR06wdXzOrdlQXZmloRkhoG-jLONs=.7ac25a66-154f-48b2-b5cc-5d28b1960dae@github.com>

On Tue, 25 Feb 2025 14:51:29 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Standardize parameter checking
>
> src/java.base/share/classes/java/util/concurrent/DelayScheduler.java line 455:
> 
>> 453:         final long nextDelay;       // 0: once; <0: fixedDelay; >0: fixedRate
>> 454:         int heapIndex;              // if non-negative, index on heap
>> 455:         final boolean isImmediate;  // run by scheduler vs submitted when ready
> 
> If desired, it would be possible to create a bitset for `isImmediate` and `isCallable` such that we could get rid of a reference field per ScheduledForkJoinTask.
> I suspect it would also be possible to use the same field for `pool` and `result` as there shouldn't be a result available for as long as `pool` is non-null.
> 
> Might not be worth doing at this point, but saving 2 reference fields for something which might get allocated millions of times might be worth it?

I tried a few variants and didn't see improvements. But I added a sentence to doc with my guess why:
     *  (We use the same structure for both
     * Runnable and Callable versions, since including an extra field
     * in either case doesn't hurt -- it seems mildly preferable
     * for these objects to be larger than other kinds of tasks to
     * reduce false sharing during possibly frequent bookkeeping
     * updates.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1970539084

From almatvee at openjdk.org  Tue Feb 25 21:16:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 25 Feb 2025 21:16:57 GMT
Subject: RFR: 8350601: Miscellaneous updates to jpackage test lib [v4]
In-Reply-To: <LwR103Nd6_tN9egExGVG8J-jdLSicsPDT_JNKt4vSbk=.466944d3-410c-4143-ad8c-28645e5183e8@github.com>
References: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
 <LwR103Nd6_tN9egExGVG8J-jdLSicsPDT_JNKt4vSbk=.466944d3-410c-4143-ad8c-28645e5183e8@github.com>
Message-ID: <hIauK8xMbTw6o7DjGbVilwq7LXxpIuz_kaak3Frh_fo=.b757beeb-71f5-4193-b833-bbe71d6801dd@github.com>

On Tue, 25 Feb 2025 15:48:29 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Unify TKit.createTempDirectory() and TKit.createTempFile() functions. Remove `throws IOexception` from their signatures. Add relevant tests.
>>  - JPackageCommand.java: remove try/catch(IOexception) around `TKit.createTempDirectory()` call.
>>  - AppImagePackageTest.java: replace `TKit.createTempDirectory(null)` with `TKit.createTempDirectory("appimage")` to fix NPE.
>>  - Make `TKit.assertDirectoryExists(Path, Optional<Boolean>)` private. This is internal and shouldn't be exposed.
>>  - add `TKit.assertEquals(boolean, boolean)` and `TKit.assertNotEquals(boolean, boolean)` with tests.
>>  - AdditionalLauncher.java: remove redundant code duplicating functionality of `TKit.createTempFile()` (should have been cleaned long ago).
>>  - JPackageCommand.java: add a check for the main jar in the app image if the main jar was specified. Missing part of [JDK-8325089](https://bugs.openjdk.org/browse/JDK-8325089).
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better exception message

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23754#pullrequestreview-2642475227

From dl at openjdk.org  Tue Feb 25 21:26:57 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 25 Feb 2025 21:26:57 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <rn2QsMz78Q2TtcqCbRM3G7z3qUyevKBv6JOvdutrMbg=.1260e240-5836-421c-a314-773935351c34@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
 <rn2QsMz78Q2TtcqCbRM3G7z3qUyevKBv6JOvdutrMbg=.1260e240-5836-421c-a314-773935351c34@github.com>
Message-ID: <-tbu0wqeE72xg_eelqmB2PKaxVYjWaj5zpj8eeR8Q2Q=.12288d24-31d5-4cad-b5af-cc39492e0363@github.com>

On Tue, 25 Feb 2025 17:04:20 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Standardize parameter checking
>
> test/jdk/java/util/concurrent/tck/ForkJoinPool20Test.java line 523:
> 
>> 521:             done.countDown();   // release blocking tasks
>> 522:             assertTrue(p.awaitTermination(LONG_DELAY_MS, MILLISECONDS));
>> 523: 
> 
> Suggestion:

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1970562115

From vaivanov at openjdk.org  Tue Feb 25 21:40:27 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 25 Feb 2025 21:40:27 GMT
Subject: RFR: 8350701 test foreign.AllocFromSliceTest failed with Exception for
 size >1024
Message-ID: <gHU0mnJCT_0ZTzWEGwmoyXcFuk_0BGJz1ULAWPpERKk=.ab3631d0-b381-47cb-9eea-8c1a5af4ac65@github.com>

The 'size' parameters was used instead of hardcoded constant to improve support for different sizes.

-------------

Commit messages:
 - JDK-8350701 [JMH] test foreign.AllocFromSliceTest failed with Exception for size>1024

Changes: https://git.openjdk.org/jdk/pull/23785/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23785&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350701
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23785.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23785/head:pull/23785

PR: https://git.openjdk.org/jdk/pull/23785

From liach at openjdk.org  Tue Feb 25 21:53:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 21:53:10 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
Message-ID: <FNT_CxUYR4qsc135rb-GgEI0SmH47O4gP9tWxen9Agk=.72be6fc5-5276-484e-af6c-03a7d78db7d6@github.com>

Remove the intrinsicData field. We can obtain this from the customized MH when we spin ultra-customized lambda forms. In the long run, we aim to remove this intrinsic if there is no regression for call site sharing.

The existing tableSwitch combinator's LF is unnecessarily complex. This patch also simplifies the tableSwitch combinator.

Note that I was forced to add `@ForceInline` on immutable lists due to regressions in `MethodHandlesTableSwitchRandom` with `sorted == true`, which eliminates the regression. Otherwise, all benchmark results are the same. Tested java/lang/invoke.

-------------

Commit messages:
 - Fix and upgrade the test
 - Improve error messages
 - Clean up MH switch combinator

Changes: https://git.openjdk.org/jdk/pull/23763/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23763&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350617
  Stats: 695 lines in 9 files changed: 244 ins; 356 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/23763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23763/head:pull/23763

PR: https://git.openjdk.org/jdk/pull/23763

From hgreule at openjdk.org  Tue Feb 25 21:53:11 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 25 Feb 2025 21:53:11 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: <FNT_CxUYR4qsc135rb-GgEI0SmH47O4gP9tWxen9Agk=.72be6fc5-5276-484e-af6c-03a7d78db7d6@github.com>
References: <FNT_CxUYR4qsc135rb-GgEI0SmH47O4gP9tWxen9Agk=.72be6fc5-5276-484e-af6c-03a7d78db7d6@github.com>
Message-ID: <vIHd-KdSd6_qz3yedjcwVacm8q8QmkHv6e5V41Jmu4A=.e03aa254-a6ea-408e-8fc4-a6b559666cad@github.com>

On Tue, 25 Feb 2025 02:45:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove the intrinsicData field. We can obtain this from the customized MH when we spin ultra-customized lambda forms. In the long run, we aim to remove this intrinsic if there is no regression for call site sharing.
> 
> The existing tableSwitch combinator's LF is unnecessarily complex. This patch also simplifies the tableSwitch combinator.
> 
> Note that I was forced to add `@ForceInline` on immutable lists due to regressions in `MethodHandlesTableSwitchRandom` with `sorted == true`, which eliminates the regression. Otherwise, all benchmark results are the same. Tested java/lang/invoke.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7659:

> 7657:         if (!(expectedType.parameterCount() >= 1) || expectedType.parameterType(0) != int.class)
> 7658:             throw new IllegalArgumentException(
> 7659:                 "Case actions must have int as leading parameter: " + caseActions);

As you're already touching this: `expectedType` is the default case, but it's not printed here. This can lead to very confusing output if all caseActions have a leading int parameter but the defaultCase hasn't.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23763#discussion_r1969044767

From liach at openjdk.org  Tue Feb 25 21:53:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 21:53:11 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: <vIHd-KdSd6_qz3yedjcwVacm8q8QmkHv6e5V41Jmu4A=.e03aa254-a6ea-408e-8fc4-a6b559666cad@github.com>
References: <FNT_CxUYR4qsc135rb-GgEI0SmH47O4gP9tWxen9Agk=.72be6fc5-5276-484e-af6c-03a7d78db7d6@github.com>
 <vIHd-KdSd6_qz3yedjcwVacm8q8QmkHv6e5V41Jmu4A=.e03aa254-a6ea-408e-8fc4-a6b559666cad@github.com>
Message-ID: <9-yh4q1l4RDOCVlJWZqaev6MvWbQgtvMtX5DCGkLPvE=.6856270b-7518-4039-9379-2755b6c4fb73@github.com>

On Tue, 25 Feb 2025 06:37:08 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Remove the intrinsicData field. We can obtain this from the customized MH when we spin ultra-customized lambda forms. In the long run, we aim to remove this intrinsic if there is no regression for call site sharing.
>> 
>> The existing tableSwitch combinator's LF is unnecessarily complex. This patch also simplifies the tableSwitch combinator.
>> 
>> Note that I was forced to add `@ForceInline` on immutable lists due to regressions in `MethodHandlesTableSwitchRandom` with `sorted == true`, which eliminates the regression. Otherwise, all benchmark results are the same. Tested java/lang/invoke.
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7659:
> 
>> 7657:         if (!(expectedType.parameterCount() >= 1) || expectedType.parameterType(0) != int.class)
>> 7658:             throw new IllegalArgumentException(
>> 7659:                 "Case actions must have int as leading parameter: " + caseActions);
> 
> As you're already touching this: `expectedType` is the default case, but it's not printed here. This can lead to very confusing output if all caseActions have a leading int parameter but the defaultCase hasn't.

True, why did this insufficent message slip through the original reviews ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23763#discussion_r1969067288

From redestad at openjdk.org  Tue Feb 25 21:54:00 2025
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 25 Feb 2025 21:54:00 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: <fc3PZJ4V4V5SHyLJVfRYzRL6AhHiI7yJUMeM7bgoZhI=.5b31249a-b4d4-42e3-8204-fea187c1aff5@github.com>
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 <fc3PZJ4V4V5SHyLJVfRYzRL6AhHiI7yJUMeM7bgoZhI=.5b31249a-b4d4-42e3-8204-fea187c1aff5@github.com>
Message-ID: <aDN5WNAnSUTvhAA_MDZbakH0DQD5A29DZ5z_FdauADM=.cbaaaa8f-dd76-48be-b39a-aaecf832e26b@github.com>

On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> LF editor spins classes, this avoids the spinning overhead and should speed up non-capturing lambdas too.
>> 
>> There may need to be additional intrinsic work for MH combinator lf bytecode generation.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We no longer load DelegateMH as we no longer rebind

Just got back home. Some comments inline, will need to run some tests and mull this over before approval.

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 2241:

> 2239:         var form = constantForm(basicType);
> 2240: 
> 2241:         if (type.isPrimitive()) {

I think you could simplify this using `Wrapper.forBasicType`; all variants should be able to use `wrapper.convert`

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4874:

> 4872:         Objects.requireNonNull(type);
> 4873:         return type.isPrimitive() ? primitiveZero(Wrapper.forPrimitiveType(type))
> 4874:                 : MethodHandleImpl.makeConstantReturning(type, null);

Not sure if it's important but the existing impl would cache `zero(Object.class)` while this new impl won't. Behaviorally neutral for any other reference type, though.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23706#pullrequestreview-2642528847
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1970580771
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1970592504

From asemenyuk at openjdk.org  Tue Feb 25 21:55:58 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Feb 2025 21:55:58 GMT
Subject: Integrated: 8350601: Miscellaneous updates to jpackage test lib
In-Reply-To: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
References: <KbeNMfhqsW_9F4mdIcw8HcupgwwIZySLVQjSrWpHXiY=.5f235b54-b5df-4642-9445-a1b17635e576@github.com>
Message-ID: <YLXwlqUcvxqWUvJFZ4nTSAvBzUJAWMa1RnuOOxhQv4o=.fbb467fc-8284-44c8-b66a-c3f163600a53@github.com>

On Mon, 24 Feb 2025 19:18:27 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Unify TKit.createTempDirectory() and TKit.createTempFile() functions. Remove `throws IOexception` from their signatures. Add relevant tests.
>  - JPackageCommand.java: remove try/catch(IOexception) around `TKit.createTempDirectory()` call.
>  - AppImagePackageTest.java: replace `TKit.createTempDirectory(null)` with `TKit.createTempDirectory("appimage")` to fix NPE.
>  - Make `TKit.assertDirectoryExists(Path, Optional<Boolean>)` private. This is internal and shouldn't be exposed.
>  - add `TKit.assertEquals(boolean, boolean)` and `TKit.assertNotEquals(boolean, boolean)` with tests.
>  - AdditionalLauncher.java: remove redundant code duplicating functionality of `TKit.createTempFile()` (should have been cleaned long ago).
>  - JPackageCommand.java: add a check for the main jar in the app image if the main jar was specified. Missing part of [JDK-8325089](https://bugs.openjdk.org/browse/JDK-8325089).

This pull request has now been integrated.

Changeset: 2efb0336
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2efb0336e0c257c34f9e49a50cbad1704691582e
Stats:     252 lines in 5 files changed: 199 ins; 26 del; 27 mod

8350601: Miscellaneous updates to jpackage test lib

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/23754

From swen at openjdk.org  Tue Feb 25 22:11:59 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 25 Feb 2025 22:11:59 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v19]
In-Reply-To: <QrgMhkd02a2XjQWEC-lxm0hqRhcrc3kcXFQV_c3G3M0=.05db60a1-4184-45e2-ae8f-8beee48e7d0b@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
 <QrgMhkd02a2XjQWEC-lxm0hqRhcrc3kcXFQV_c3G3M0=.05db60a1-4184-45e2-ae8f-8beee48e7d0b@github.com>
Message-ID: <jUxnnyBQOc4si0jWi98z3-DeoVdKOH62jZXBt6Pmijc=.b3fc0463-161b-4c58-bebd-444b030805f7@github.com>

On Wed, 5 Feb 2025 17:06:57 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
>> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
>> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
>> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ForceInline

Keep it alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2683407418

From liach at openjdk.org  Tue Feb 25 22:16:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 22:16:58 GMT
Subject: RFR: 8350607: Consolidate MethodHandles::zero into
 MethodHandles::constant [v2]
In-Reply-To: <aDN5WNAnSUTvhAA_MDZbakH0DQD5A29DZ5z_FdauADM=.cbaaaa8f-dd76-48be-b39a-aaecf832e26b@github.com>
References: <63wa37lcsq3wy7OLKOr_n-F8nPNvnrD-zZdaM7Vn4kE=.676086a5-fd53-4a74-8927-878ba5d7ae26@github.com>
 <fc3PZJ4V4V5SHyLJVfRYzRL6AhHiI7yJUMeM7bgoZhI=.5b31249a-b4d4-42e3-8204-fea187c1aff5@github.com>
 <aDN5WNAnSUTvhAA_MDZbakH0DQD5A29DZ5z_FdauADM=.cbaaaa8f-dd76-48be-b39a-aaecf832e26b@github.com>
Message-ID: <ex9PqNkHNas9LmsbUpXRRE-c4MqJZUJJY-FAKJyzkmA=.e44dc20c-4e66-4743-8faa-707bca839c2e@github.com>

On Tue, 25 Feb 2025 21:38:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   We no longer load DelegateMH as we no longer rebind
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 2241:
> 
>> 2239:         var form = constantForm(basicType);
>> 2240: 
>> 2241:         if (type.isPrimitive()) {
> 
> I think you could simplify this using `Wrapper.forBasicType`; all variants should be able to use `wrapper.convert`

The cast is not performed if the `type` is an interface; this is a behavioral disparity with the old `value = ptype.cast(value);` in `insertArguments`.

> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4874:
> 
>> 4872:         Objects.requireNonNull(type);
>> 4873:         return type.isPrimitive() ? primitiveZero(Wrapper.forPrimitiveType(type))
>> 4874:                 : MethodHandleImpl.makeConstantReturning(type, null);
> 
> Not sure if it's important but the existing impl would cache `zero(Object.class)` while this new impl won't. Behaviorally neutral for any other reference type, though.

`type == Object.class` can use the primitive path, but I am too lazy to add another of this check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1970611614
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1970616917

From liach at openjdk.org  Tue Feb 25 22:17:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 22:17:59 GMT
Subject: RFR: 8350617: Improve MethodHandles.tableSwitch and remove
 intrinsicData
In-Reply-To: <FNT_CxUYR4qsc135rb-GgEI0SmH47O4gP9tWxen9Agk=.72be6fc5-5276-484e-af6c-03a7d78db7d6@github.com>
References: <FNT_CxUYR4qsc135rb-GgEI0SmH47O4gP9tWxen9Agk=.72be6fc5-5276-484e-af6c-03a7d78db7d6@github.com>
Message-ID: <BncJ62Gmqzo7ztfmdGaZFTHEbOgw-y2CrwoVGMJc6lU=.6de83ed5-d259-4abd-9ede-358a24d3cf47@github.com>

On Tue, 25 Feb 2025 02:45:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove the intrinsicData field. We can obtain this from the customized MH when we spin ultra-customized lambda forms. In the long run, we aim to remove this intrinsic if there is no regression for call site sharing.
> 
> The existing tableSwitch combinator's LF is unnecessarily complex. This patch also simplifies the tableSwitch combinator.
> 
> Note that I was forced to add `@ForceInline` on immutable lists due to regressions in `MethodHandlesTableSwitchRandom` with `sorted == true`, which eliminates the regression. Otherwise, all benchmark results are the same. Tested java/lang/invoke.

The revision with updated tests to junit passes tier 1-3.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23763#issuecomment-2683415871

From dl at openjdk.org  Tue Feb 25 22:18:01 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 25 Feb 2025 22:18:01 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <rn2QsMz78Q2TtcqCbRM3G7z3qUyevKBv6JOvdutrMbg=.1260e240-5836-421c-a314-773935351c34@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
 <rn2QsMz78Q2TtcqCbRM3G7z3qUyevKBv6JOvdutrMbg=.1260e240-5836-421c-a314-773935351c34@github.com>
Message-ID: <13OzVbNCK8pwWCRayuqjSCeqd7YLIPblhLBKjGuckGE=.7d2f15d6-72a5-4a19-976e-d05022baf419@github.com>

On Tue, 25 Feb 2025 17:06:31 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Standardize parameter checking
>
> test/jdk/java/util/concurrent/tck/ForkJoinPool20Test.java line 577:
> 
>> 575:                 Thread.sleep(LONGER_DELAY_MS); return Boolean.TRUE; }};
>> 576:         ForkJoinTask<?> task = p.submitWithTimeout(c, 1, NANOSECONDS, null);
>> 577:         Thread.sleep(timeoutMillis());
> 
> Do we need to sleep here or just get the result with a timeout expecting a CancellationException then asserting isCancelled == true?

This checks: The task is not run and will eventually show up as cancelled. So as is done in other juc-tck test, we sleep a little for the "eventually" part. This and many similar cases can rarely misfire, in which case timeoutMillis is increased as a check by harness.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1970618201

From liach at openjdk.org  Tue Feb 25 22:21:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 22:21:46 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
 [v5]
In-Reply-To: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
Message-ID: <nA2oxacJOUpsDdwS6db3Snx2JWKdSGWscWsqshIvZUM=.ae2a6592-8655-4c86-b102-916530a09bdf@github.com>

> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well.
> 
> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Improve BytecodeDescriptor error message
 - Years, test facelift
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
 - 8333377: Migrate Generic Signature parsing to ClassFile API

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19281/files
  - new: https://git.openjdk.org/jdk/pull/19281/files/dea7a235..5745bfd0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19281&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19281&range=03-04

  Stats: 260667 lines in 7833 files changed: 131422 ins; 99508 del; 29737 mod
  Patch: https://git.openjdk.org/jdk/pull/19281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19281/head:pull/19281

PR: https://git.openjdk.org/jdk/pull/19281

From dl at openjdk.org  Tue Feb 25 22:22:54 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 25 Feb 2025 22:22:54 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <uGcOd2C4T-mit0tXqtPlnocXVBNFdry5u5_KqXp_6NE=.4566606d-8c66-430b-a9c0-b433f6a6e1d6@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
 <uGcOd2C4T-mit0tXqtPlnocXVBNFdry5u5_KqXp_6NE=.4566606d-8c66-430b-a9c0-b433f6a6e1d6@github.com>
Message-ID: <766i6hktcEXJzA-_jo2C00zB_mKPgJNHFwgtobA_IK4=.be4b8700-70f4-44e9-b151-894a5482906a@github.com>

On Tue, 25 Feb 2025 17:21:56 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Standardize parameter checking
>
> test/jdk/java/util/concurrent/tck/ForkJoinPool20Test.java line 630:
> 
>> 628:                 return Boolean.TRUE; }};
>> 629:         ForkJoinTask<?> task = p.submitWithTimeout(c, LONGER_DELAY_MS, MILLISECONDS, null);
>> 630:         Thread.sleep(timeoutMillis());
> 
> Suggest to check that the task was successfully completed with the right result (as well).

done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1970623290

From liach at openjdk.org  Tue Feb 25 22:26:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 22:26:16 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
 [v5]
In-Reply-To: <nA2oxacJOUpsDdwS6db3Snx2JWKdSGWscWsqshIvZUM=.ae2a6592-8655-4c86-b102-916530a09bdf@github.com>
References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
 <nA2oxacJOUpsDdwS6db3Snx2JWKdSGWscWsqshIvZUM=.ae2a6592-8655-4c86-b102-916530a09bdf@github.com>
Message-ID: <LThq-_vB0YNUG5nEoM0m7K8jO95CBtpHIh1_D8iKXaw=.80ce1064-89b6-453a-89af-72b9b2f1ac35@github.com>

On Tue, 25 Feb 2025 22:21:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well.
>> 
>> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Improve BytecodeDescriptor error message
>  - Years, test facelift
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info
>  - 8333377: Migrate Generic Signature parsing to ClassFile API

After a revisit to this PR, I think I might split the work of improving BytecodeDescriptor error message and tests covering failure-case behaviors into a prerequisite PR to this one, to ensure this PR preserves the failure behavior present on mainline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19281#issuecomment-2683429016

From dl at openjdk.org  Tue Feb 25 22:29:06 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 25 Feb 2025 22:29:06 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <uGcOd2C4T-mit0tXqtPlnocXVBNFdry5u5_KqXp_6NE=.4566606d-8c66-430b-a9c0-b433f6a6e1d6@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
 <uGcOd2C4T-mit0tXqtPlnocXVBNFdry5u5_KqXp_6NE=.4566606d-8c66-430b-a9c0-b433f6a6e1d6@github.com>
Message-ID: <N0w2togpx9fsFf5McpMf_7SJmPqvdDTSjtNSthLTXHE=.4e689510-81d7-4d36-8557-5943a9d03e20@github.com>

On Tue, 25 Feb 2025 17:23:07 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Standardize parameter checking
>
> test/jdk/java/util/concurrent/tck/ForkJoinPool20Test.java line 649:
> 
>> 647:             p.shutdown();
>> 648:             assertTrue(p.awaitTermination(LONG_DELAY_MS, MILLISECONDS));
>> 649:             assertTrue(f.isDone());
> 
> Might make sense to factor out assertions of sets of states associated with successful, cancelled, failed and use those asserts throughout these tests (just to make sure that there aren't weird combinations of states).

Right. We have some helper methods along these lines, but in the wrong test files (mainly ForkJoinTaskTest), so would need some refactoring to use here. Someday.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1970630652

From dl at openjdk.org  Tue Feb 25 22:44:00 2025
From: dl at openjdk.org (Doug Lea)
Date: Tue, 25 Feb 2025 22:44:00 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling
In-Reply-To: <4L5Ay2O3BjFZKPBvXAhOJV3W0w15gDRvV6EF5RghC1E=.94498d38-bc87-4ccc-9662-770fba012b38@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <rsvIPXG0q5KZJY8svll6a78ZEJwIjAZx0MxwFgd04DU=.32ebadf4-182e-47c5-b804-92028b40fc29@github.com>
 <4L5Ay2O3BjFZKPBvXAhOJV3W0w15gDRvV6EF5RghC1E=.94498d38-bc87-4ccc-9662-770fba012b38@github.com>
Message-ID: <JiIR0EGFyQsK1JmjsuTLGOO39rO0tB3SWgyoeERVCUs=.616b59c9-edbe-4bcb-b91a-23a81c76447d@github.com>

On Tue, 25 Feb 2025 19:42:01 GMT, Sunmisc Unsafe <duke at openjdk.org> wrote:

>> Is it possible to use getAndSet instead of cas-loop on #pend?
>> 
>> final Task t = tail.getAndSet(task);
>> t.next = task;
>> 
>> but that would require a new head field to bypass, probably not worth the gamble if the footprint increases a lot
>
>> @sunmisc You are right that it would be nice if there were a way to efficiently use getAndSet here because a failed reference CAS hits slow paths that vary across GCs. But all of the ways I know to do this are much worse.
> 
> After a few days of benchmarks, I realized that you would be absolutely right. Although I thought if we separate the head (for deleting) and the tail (for inserting) there would be less contention. 
> Even the fact that we can change the head (delete) only in one thread does not help us from volatile, moreover, it became worse.
> Perhaps I have made a mistake somewhere in the implementation

@sunmisc Thanks for independently trying alternatives. We both had reasons to suspect that other mechanics might work out as well or better, but none seem to.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23702#issuecomment-2683456519

From asemenyuk at openjdk.org  Tue Feb 25 22:52:08 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 25 Feb 2025 22:52:08 GMT
Subject: Integrated: 8326447: jpackage creates Windows installers that cannot
 be signed
In-Reply-To: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
References: <o39dmAvnkSE09pEsDeg-C-Ob4sslLzpg_1BIBs6pRMg=.d183ca86-440f-41b2-a9ad-d09321cc614f@github.com>
Message-ID: <-G9ATOq-JKVh-3Vd3x4sgLwARB1CFrxpZYvRdO37cVI=.c6a9652e-fbb2-43b3-b761-9884c217def9@github.com>

On Sat, 22 Feb 2025 00:20:29 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Support the use of a custom msi wrapper executable when building an exe installer.
> 
> Put `installer.exe` file in the resource directory and jpackage will use it instead of the default `msiwrapper.exe` resource for exe installer.
> 
> To test this feature created a test that builds exe installer with a custom icon. The result installer exe is used as a custom msi wrapper executable in the second jpackage command that builds exe installer with the default icon. The installer exe produced by the second jackage command should have the same icon as the exe installer created in the first jpackage run.
> 
> Moved code verifying icons in executables from `LauncherIconVerifier.WinIconVerifier` class into `WinExecutableIconVerifier` class to make it available for tests. Replaced inline powershell script extracting icons from executables with standalone `read-executable-icon.ps1` powershell script. The script uses `ExtractIcon` instead of `ExtractAssociatedIcon`. It extracts icon from the executable's resources and will not fall back to anything if there is no icon resource.

This pull request has now been integrated.

Changeset: 267d69be
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/267d69bed6265ec2820f17eb7534ec64d80ad093
Stats:     656 lines in 7 files changed: 457 ins; 193 del; 6 mod

8326447: jpackage creates Windows installers that cannot be signed

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/23732

From psandoz at openjdk.org  Tue Feb 25 22:54:00 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 25 Feb 2025 22:54:00 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <yveRDsN80HbL-YFzZoAZfs6SbQDC9qycahJAIP4uu2g=.7a301862-9ea1-49fb-8f97-382686435e73@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

The read-modify-write access modes appear not to be supported for byte access to segments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2683470858

From naoto at openjdk.org  Tue Feb 25 23:05:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Feb 2025 23:05:56 GMT
Subject: RFR: 8345213: JVM Prefers /etc/timezone Over /etc/localtime on
 Debian 12
In-Reply-To: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
References: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
Message-ID: <oVgkFn9f6p8z2i4C5ZNmLXwIoz3nLGJrLjr7fA_xaVo=.2c80a66b-2f00-4899-b390-7ec7dd2952a4@github.com>

On Mon, 24 Feb 2025 19:46:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the support for /etc/timezone file that is Debian distro specific. The file is no longer considered authoritative (https://wiki.debian.org/TimeZoneChanges#Check_Configured_Timezone), and in fact, it is now out of sync as the bug reports. The fix was confirmed manually on a Ubuntu 25.04.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23755#issuecomment-2683486133

From naoto at openjdk.org  Tue Feb 25 23:05:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Feb 2025 23:05:56 GMT
Subject: Integrated: 8345213: JVM Prefers /etc/timezone Over /etc/localtime on
 Debian 12
In-Reply-To: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
References: <EBg-Rxt6qcKUax8o4mW62ft9-sj0InwCfIXDiMeYUzM=.a887b7c2-a2d0-4135-98e8-8a952ea7c190@github.com>
Message-ID: <uXHqLkw14u9FEL-N1Sc5HeVqECLddO7bIPOePy1Kp_A=.1f142c9e-aed7-419b-990a-b1a5b4fa25b3@github.com>

On Mon, 24 Feb 2025 19:46:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the support for /etc/timezone file that is Debian distro specific. The file is no longer considered authoritative (https://wiki.debian.org/TimeZoneChanges#Check_Configured_Timezone), and in fact, it is now out of sync as the bug reports. The fix was confirmed manually on a Ubuntu 25.04.

This pull request has now been integrated.

Changeset: c8a521fd
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8a521fddac9d42fe93ea9b3ab89e804bc48bf4e
Stats:     30 lines in 1 file changed: 0 ins; 28 del; 2 mod

8345213: JVM Prefers /etc/timezone Over /etc/localtime on Debian 12

Reviewed-by: joehw, jpai, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/23755

From liach at openjdk.org  Tue Feb 25 23:13:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 23:13:55 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <xAjXvHpq6KSwhctZxQOnQqW64h0J_C3_hqg-ALqtK20=.3f7eef86-4572-4158-bd9f-3d8d6b714aa4@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

Indeed, the byte access currently only supports read/write (automatically aligned). No CAS or bitwise for now in FFM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2683498943

From liach at openjdk.org  Tue Feb 25 23:55:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Feb 2025 23:55:33 GMT
Subject: RFR: 8350704: Create tests to ensure the failure behavior of core
 reflection APIs
Message-ID: <hALAQ2YPDV_gZIjVHV1pE8emYwh83IhrPg8PrnLWVLE=.62cdd46b-668a-47a1-a841-21fdb7537206@github.com>

Core reflection's generic signature parsing system is used for many aspects, including annotations and enclosing methods, yet it is under-tested. It is better for us to set up tests to ensure that sensitive error behaviors of core reflection remain the same across implementation updates, such as #19281.

This patch also includes a JUnit converted version of https://github.com/openjdk/jdk/pull/22581#issuecomment-2521703511 test checking behavior around annotations with duplicate interfaces. Interesting that this causes failure in class, field, and methods (constructors), but not in parameters.

-------------

Commit messages:
 - 8350704: Create tests to ensure the failure behavior of core reflection APIs

Changes: https://git.openjdk.org/jdk/pull/23788/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23788&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350704
  Stats: 703 lines in 7 files changed: 646 ins; 56 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23788.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23788/head:pull/23788

PR: https://git.openjdk.org/jdk/pull/23788

From jlu at openjdk.org  Wed Feb 26 00:02:43 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Feb 2025 00:02:43 GMT
Subject: RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException
Message-ID: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>

Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.

Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 

We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override. (Which ensures `SupplementalJapaneseEraTestRun.java` passes, which also tests against building (and succeeding) with an era value of 6.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/23789/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23789&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350646
  Stats: 16 lines in 2 files changed: 13 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23789/head:pull/23789

PR: https://git.openjdk.org/jdk/pull/23789

From liach at openjdk.org  Wed Feb 26 00:16:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 00:16:01 GMT
Subject: RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException
In-Reply-To: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
Message-ID: <n8LnahndpBjJSa966XOmel-filCFfrYRi77QYysYPXw=.464a4ef8-2e9c-4dcb-b818-e95a08aed0cb@github.com>

On Tue, 25 Feb 2025 23:58:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
> 
> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
> 
> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override. (Which ensures `SupplementalJapaneseEraTestRun.java` passes, which also tests against building (and succeeding) with an era value of 6.

This appears to be a behavioral change and warrants a CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23789#issuecomment-2683573479

From schernyshev at openjdk.org  Wed Feb 26 00:52:41 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 26 Feb 2025 00:52:41 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  updated comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/3568c138..c9391dd4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=14-15

  Stats: 42 lines in 1 file changed: 40 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From schernyshev at openjdk.org  Wed Feb 26 00:52:41 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 26 Feb 2025 00:52:41 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v15]
In-Reply-To: <IburxTbm543dAyzexBk6JLRSB98aV9Gi7yi38FsrKog=.2a2bced5-4319-4aff-9eb1-67ee4448c695@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <jPiUQFkkA_7ELb36w5iT9aI0SZyW67azvVcO_Y6kpmA=.43bd87a6-8e61-40a3-ac47-938ef992784d@github.com>
 <qv-d4q9Dgg1oGp0dQyvix_ss8iGon0XqKAa07hS_f2g=.e3318903-fd78-415e-8f87-75c755da92f1@github.com>
 <pK7gXk5Nv6_6EMQS-sqQprcMMz_v6y305aUNaal7EWA=.3a1033fe-867a-439d-9041-683be9e83019@github.com>
 <IburxTbm543dAyzexBk6JLRSB98aV9Gi7yi38FsrKog=.2a2bced5-4319-4aff-9eb1-67ee4448c695@github.com>
Message-ID: <Mds-9UWXepummBUMvAJQt88hAEbXpinJcVuIQXa5UyQ=.ab62dbbf-850c-45bb-9663-d4d67a909097@github.com>

On Tue, 25 Feb 2025 17:11:30 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly?
>> 
>> Either it shall be a high level comment such as in your suggestion [here](https://github.com/openjdk/jdk/pull/21808#pullrequestreview-2620718790), or a deeper description in detail what happens where. Could you please be more specific on what kind of description is required and where? Please note the method has inline comments that are fairly self describing. In the meanwhile I'll try to add a description of what "a process is moved between cgroups" exactly means.
>
> A high level description that mentions what the function does. The inline comments are not very self describing for anyone not having written the patch.
> 
> Example:
> 
> Sets the subsystem path for a controller. The common container case is
> handled by XXX. When a process has been moved from a cgroup to another
> the following happens:
>  - A
>  - B
>  - C
> 
> 
> I believe this is desperately needed.

Please see the updated comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1970739677

From duke at openjdk.org  Wed Feb 26 01:36:58 2025
From: duke at openjdk.org (Dustin4444)
Date: Wed, 26 Feb 2025 01:36:58 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <vZw_vPmBI2DH_U4CkbHYnqqu2wCqCXBU7AtAYQAO6Do=.9e493748-bb46-4f69-81a7-0fb9de340d7c@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

Marked as reviewed by Dustin4444 at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23550#pullrequestreview-2642819217

From psandoz at openjdk.org  Wed Feb 26 02:31:53 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 26 Feb 2025 02:31:53 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <xAjXvHpq6KSwhctZxQOnQqW64h0J_C3_hqg-ALqtK20=.3f7eef86-4572-4158-bd9f-3d8d6b714aa4@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <xAjXvHpq6KSwhctZxQOnQqW64h0J_C3_hqg-ALqtK20=.3f7eef86-4572-4158-bd9f-3d8d6b714aa4@github.com>
Message-ID: <aeGw9VVhhyH-phaFCZW6Sx4panQFmDhOpvsgZc4vz20=.c54ab713-be15-4f52-b6ac-deb5de72270a@github.com>

On Tue, 25 Feb 2025 23:11:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Indeed, the byte access currently only supports read/write (automatically aligned). No CAS or bitwise for now in FFM.

Do you know why that is so?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2683738533

From liach at openjdk.org  Wed Feb 26 03:04:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 03:04:53 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <jIE0fp1SkujHwIanTtWKszq_kIadq7erKWrk_zLnZqI=.3ca1bc86-1257-4f4c-802b-4af638cc8463@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <3yhXZNAbPb_sRC_CXmKGzUNsvhl1rOfIvtdGfUCsvq4=.66ca9688-2bf1-4eec-9a38-c499a8390fcc@github.com>
 <jIE0fp1SkujHwIanTtWKszq_kIadq7erKWrk_zLnZqI=.3ca1bc86-1257-4f4c-802b-4af638cc8463@github.com>
Message-ID: <qCGijw7AEXWCGkcMYoSnGdaKTLq2xf9-Wwhba7hvSJ4=.3ced0e14-a52c-443e-814d-fbb4735ea99d@github.com>

On Tue, 25 Feb 2025 09:51:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Benchmark results for the latest revision appears performance neutral. bytestacks same as last revision. 11 jobs left in tier 1-3, no failure so far. Also created CSR for this minor behavioral change.
>> 
>> Benchmark                                                (polluteProfile)  Mode  Cnt  Score   Error  Units
>> LoopOverNonConstantHeap.BB_get                                      false  avgt   30  0.934 ? 0.027  ns/op
>> LoopOverNonConstantHeap.BB_get                                       true  avgt   30  0.946 ? 0.028  ns/op
>> LoopOverNonConstantHeap.BB_loop                                     false  avgt   30  0.208 ? 0.004  ms/op
>> LoopOverNonConstantHeap.BB_loop                                      true  avgt   30  0.211 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_get                                 false  avgt   30  1.123 ? 0.040  ns/op
>> LoopOverNonConstantHeap.segment_get                                  true  avgt   30  1.120 ? 0.040  ns/op
>> LoopOverNonConstantHeap.segment_loop                                false  avgt   30  0.205 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop                                 true  avgt   30  0.202 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance                       false  avgt   30  0.209 ? 0.005  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance                        true  avgt   30  0.202 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance_unaligned             false  avgt   30  0.209 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance_unaligned              true  avgt   30  0.210 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_readonly                       false  avgt   30  0.206 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_readonly                        true  avgt   30  0.206 ? 0.005  ms/op
>> LoopOverNonConstantHeap.segment_loop_slice                          false  avgt   30  0.203 ? 0.002  ms/op
>> LoopOverNonConstantHeap.segment_loop_slice                           true  avgt   30  0.207 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_unaligned                      false  avgt   30  0.206 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_unaligned                       true  avgt   30  0.209 ? 0.003  ms/op
>> LoopOverNonConstantHeap.unsafe_get                                  false  avgt   30  0.386 ? 0.017  ns/op
>> LoopOverNonConstantHeap.unsafe_get                                   true  avgt   30  0.381 ? 0.017  ns/op
>> Loo...
>
> Great work @liach -- I've bumped the number of reviewers as this whole area is rather tricky, and I think the PR can probably benefit from another independent pass.

Unfortunately no. I don't really know about the Foreign Memory API as I only started to investigate its performance bottlenecks recently. @mcimadamore or @JornVernee were more involved in the development and likely know better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2683776781

From xgong at openjdk.org  Wed Feb 26 07:02:10 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 26 Feb 2025 07:02:10 GMT
Subject: RFR: 8350682 [JMH] vector.IndexInRangeBenchmark failed with IOOBE
In-Reply-To: <a1_5DZ8fmibdpMXTNaQEzF2q4ExfqGVpxfKxTIjAPgc=.5aba77b1-53a8-4d50-8622-959d163592c0@github.com>
References: <a1_5DZ8fmibdpMXTNaQEzF2q4ExfqGVpxfKxTIjAPgc=.5aba77b1-53a8-4d50-8622-959d163592c0@github.com>
Message-ID: <61Ao-ZnuK89eQnGAaGNkoR49DK38NEmk-hgelLlMh8o=.1b539e6c-8d25-4a54-9914-873cb1fc843b@github.com>

On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> Array initialization by parameter was added. Extra constant was used to align cycle step with used arrays.

Hi @IvaVladimir , thank you for fixing this benchmark. Could you please tell more information about the IOOBE crash (e.g. `size`, `benchmark name`, `arch info`, .etc) ? I still cannot figure out why it can fail with IOOBE. Thanks so much!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23783#issuecomment-2684108796

From xgong at openjdk.org  Wed Feb 26 07:04:51 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 26 Feb 2025 07:04:51 GMT
Subject: RFR: 8350682 [JMH] vector.IndexInRangeBenchmark failed with IOOBE
In-Reply-To: <61Ao-ZnuK89eQnGAaGNkoR49DK38NEmk-hgelLlMh8o=.1b539e6c-8d25-4a54-9914-873cb1fc843b@github.com>
References: <a1_5DZ8fmibdpMXTNaQEzF2q4ExfqGVpxfKxTIjAPgc=.5aba77b1-53a8-4d50-8622-959d163592c0@github.com>
 <61Ao-ZnuK89eQnGAaGNkoR49DK38NEmk-hgelLlMh8o=.1b539e6c-8d25-4a54-9914-873cb1fc843b@github.com>
Message-ID: <0JA15v33lIZAg8-KquYHGTIdcZVF1n1xIMp-86Jy3u8=.8c29d609-4e6b-4665-b716-685a5fdccdd8@github.com>

On Wed, 26 Feb 2025 06:59:27 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Hi @IvaVladimir , thank you for fixing this benchmark. Could you please tell more information about the IOOBE crash (e.g. `size`, `benchmark name`, `arch info`, .etc) ? I still cannot figure out why it can fail with IOOBE. Thanks so much!

I guess it happens when the parameter `size` is passed with a larger value than 512?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23783#issuecomment-2684113119

From duke at openjdk.org  Wed Feb 26 07:04:58 2025
From: duke at openjdk.org (Nicole Xu)
Date: Wed, 26 Feb 2025 07:04:58 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException [v2]
In-Reply-To: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
Message-ID: <3zzpTrqxv5KaBP-FKCAWjfffVonoWr9fKE6S8lO-cTY=.48f4cb20-f9e6-473f-8156-18d1694e7496@github.com>

> Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86 and AArch64 with the following error:
> 
> 
> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
> 
> 
> The variable `long256_arr_idx` is misused when indexing  'LongVector l2, l3, l4, l5' in function `maskedLogicOperationsLongKernel()`. 'long256_arr_idx' increases by 4 every time the benchmark runs and ensures the incremented value remains within the bounds of the array. However, for `LongVector.SPECIES_512`, it loads 8 numbers from the array each time the benchmark runs, resulting in an out-of-range indexing issue.
> 
> Hence, we revised the index variables from `long256_arr_idx` to `long512_arr_idx`, which has a stride of 8, to ensure that the loaded vector is inside of the array boundary for all vector species. This is also consistent with other kernel functions.
> 
> Additionally, some defined but unused variables have been removed.

Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:

 - 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException
   
   Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86
   and AArch64 with the following error:
   
   ```
   java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
   ```
   
   The variable `long256_arr_idx` is misused when indexing `LongVector l2`,
   `l3`, `l4`, `l5` in function `maskedLogicOperationsLongKernel()`
   resulting in the IndexOutOfBoundsException error. On the other hand, the
   unified index for 128-bit, 256-bit and 512-bit species might not be
   proper since it leaves gaps in between when accessing the data
   for 128-bit and 256-bit species. This will unnecessarily include the
   noise due to cache misses or (on some targets) prefetching additional
   cache lines which are not usable, thereby impacting the crispness of
   microbenchmark.
   
   Hence, we improved the benchmark from several aspects,
   1. Used sufficient number of predicated operations within the vector
   loop while minimizing the noise due to memory operations.
   2. Modified the index computation logic which can now withstand any
   ARRAYLEN without resulting in an IOOBE.
   3. Removed redundant vector read/writes to instance fields, thus
   eliminating significant boxing penalty which translates into throughput
   gains.
   
   Change-Id: Ie8a9d495b1ca5e36f1eae069ff70a815a2de00c0
 - Revert "8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException"
   
   This reverts commit 083bedec04d5ab78a420e156e74c1257ce30aee8.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22963/files
  - new: https://git.openjdk.org/jdk/pull/22963/files/083bedec..896c27ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22963&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22963&range=00-01

  Stats: 147 lines in 1 file changed: 14 ins; 29 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/22963.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22963/head:pull/22963

PR: https://git.openjdk.org/jdk/pull/22963

From jbhateja at openjdk.org  Wed Feb 26 07:14:54 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 26 Feb 2025 07:14:54 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException [v2]
In-Reply-To: <3zzpTrqxv5KaBP-FKCAWjfffVonoWr9fKE6S8lO-cTY=.48f4cb20-f9e6-473f-8156-18d1694e7496@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <3zzpTrqxv5KaBP-FKCAWjfffVonoWr9fKE6S8lO-cTY=.48f4cb20-f9e6-473f-8156-18d1694e7496@github.com>
Message-ID: <-XxRbrNVtFkEbaYMAihzsj9yfcyFC5cyW6VIh2rG_aU=.42dd122e-1222-49ac-b94d-e996c5c531f4@github.com>

On Wed, 26 Feb 2025 07:04:58 GMT, Nicole Xu <duke at openjdk.org> wrote:

>> Suite `MaskedLogicOpts.maskedLogicOperationsLong512()` failed on both x86 and AArch64 with the following error:
>> 
>> 
>> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
>> 
>> 
>> The variable `long256_arr_idx` is misused when indexing `LongVector l2`, `l3`, `l4`, `l5` in function `maskedLogicOperationsLongKernel()` resulting in the IndexOutOfBoundsException error. On the other hand, the unified index for 128-bit, 256-bit and 512-bit species might not be proper since it leaves gaps in between when accessing the data for 128-bit and 256-bit species. This will unnecessarily include the noise due to cache misses or (on some targets) prefetching additional cache lines which are not usable, thereby impacting the crispness of microbenchmark.
>> 
>> Hence, we improved the benchmark from several aspects,
>> 1. Used sufficient number of predicated operations within the vector loop while minimizing the noise due to memory operations.
>> 2. Modified the index computation logic which can now withstand any ARRAYLEN without resulting in an IOOBE.
>> 3. Removed redundant vector read/writes to instance fields, thus eliminating significant boxing penalty which translates into throughput gains.
>
> Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException
>    
>    Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86
>    and AArch64 with the following error:
>    
>    ```
>    java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
>    ```
>    
>    The variable `long256_arr_idx` is misused when indexing `LongVector l2`,
>    `l3`, `l4`, `l5` in function `maskedLogicOperationsLongKernel()`
>    resulting in the IndexOutOfBoundsException error. On the other hand, the
>    unified index for 128-bit, 256-bit and 512-bit species might not be
>    proper since it leaves gaps in between when accessing the data
>    for 128-bit and 256-bit species. This will unnecessarily include the
>    noise due to cache misses or (on some targets) prefetching additional
>    cache lines which are not usable, thereby impacting the crispness of
>    microbenchmark.
>    
>    Hence, we improved the benchmark from several aspects,
>    1. Used sufficient number of predicated operations within the vector
>    loop while minimizing the noise due to memory operations.
>    2. Modified the index computation logic which can now withstand any
>    ARRAYLEN without resulting in an IOOBE.
>    3. Removed redundant vector read/writes to instance fields, thus
>    eliminating significant boxing penalty which translates into throughput
>    gains.
>    
>    Change-Id: Ie8a9d495b1ca5e36f1eae069ff70a815a2de00c0
>  - Revert "8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException"
>    
>    This reverts commit 083bedec04d5ab78a420e156e74c1257ce30aee8.

LGTM

-------------

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22963#pullrequestreview-2643351624

From duke at openjdk.org  Wed Feb 26 07:14:55 2025
From: duke at openjdk.org (Nicole Xu)
Date: Wed, 26 Feb 2025 07:14:55 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <mXbBPLqvzMXLMLmsfIhrAwHwrYfmilbqAdNn-_bFDcI=.2e3a4a38-5e67-4f7c-9dc2-3bc060be420a@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <kaboVW6MtayTPC-GSt_U-S8KjPsenaU87af71HBem0U=.d4be0c75-637d-45d7-a291-bf8a3ee8313b@github.com>
 <mXbBPLqvzMXLMLmsfIhrAwHwrYfmilbqAdNn-_bFDcI=.2e3a4a38-5e67-4f7c-9dc2-3bc060be420a@github.com>
Message-ID: <dsTw5kVWxEh7Uy3LUjSpoEINprOPkarz5-YALeugHaA=.37bb62be-635f-4374-81a1-278ff6b0b46c@github.com>

On Thu, 20 Feb 2025 09:31:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Sure. Since I am very new to openJDK, I asked my teammate for help to file the follow-up RFE.
> > Here is the https://bugs.openjdk.org/browse/JDK-8350215 with description of the discussed issues.
> 
> Hi @xyyNicole ,
> 
> I have modified the benchmark keeping its essence intact, i.e. to use sufficient number of predicated operations within the vector loop while minimizing the noise due to memory operations. Modified the index computation logic which can now withstand any ARRAYLEN without resulting in an IOOBE. Removed redundant vector read/writes to instance fields, thus eliminating significant boxing penalty which translates into throughput gains.
> 
> Please feel free to include it along with this patch. [MaskedLogicOpts.txt](https://github.com/user-attachments/files/18884093/MaskedLogicOpts.txt)

Hi @jatin-bhateja , 

Thank you for your contributions. I've incorporated your modifications into this patch and made some minor formatting adjustments. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2684128574

From duke at openjdk.org  Wed Feb 26 07:25:04 2025
From: duke at openjdk.org (Nicole Xu)
Date: Wed, 26 Feb 2025 07:25:04 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
 <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
Message-ID: <iJFIHS0RGt5uE_RoDzHBzrhvgpoxPg3Cal-fJBr8o6Q=.3faf0fbb-cad8-4b9d-9d7f-638afeb350da@github.com>

On Fri, 21 Feb 2025 07:01:42 GMT, Nicole Xu <duke at openjdk.org> wrote:

>> The UnsafeOps JMH benchmark fails with the following error:
>> 
>>       ```
>>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>>       ```
>> 
>> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>> 
>> Note that even it will raise "proprietary API" warnings after this
>> patch, it is acceptable because the relevant APIs are bound for removal
>> for the integrity of the platform.
>
> Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
>    
>    The UnsafeOps JMH benchmark fails with the following error:
>    
>          ```
>          java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>          ```
>    
>    Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>    `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>    
>    Note that even it will raise "proprietary API" warnings after this
>    patch, it is acceptable because the relevant APIs are bound for removal
>    for the integrity of the platform.
>    
>    Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c
>  - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe"
>    
>    This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b.

Hi @cushon , I've prepared a rollback patch for your recent changes due to some balancing considerations. Could you please review and verify that? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2684145693

From pminborg at openjdk.org  Wed Feb 26 07:25:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 26 Feb 2025 07:25:58 GMT
Subject: RFR: 8350701 test foreign.AllocFromSliceTest failed with Exception
 for size >1024
In-Reply-To: <gHU0mnJCT_0ZTzWEGwmoyXcFuk_0BGJz1ULAWPpERKk=.ab3631d0-b381-47cb-9eea-8c1a5af4ac65@github.com>
References: <gHU0mnJCT_0ZTzWEGwmoyXcFuk_0BGJz1ULAWPpERKk=.ab3631d0-b381-47cb-9eea-8c1a5af4ac65@github.com>
Message-ID: <0wztZwlhEUDoYmgpZB3QHZ4QuTQwYT03soZ_aF2JQwE=.7c9a7e2a-7515-4936-a8e1-919cadf1554f@github.com>

On Tue, 25 Feb 2025 21:35:22 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> The 'size' parameters was used instead of hardcoded constant to improve support for different sizes.

LGTM. The results of the benchmarks would be comparable with older benchmarks.

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23785#pullrequestreview-2643381501

From tvaleev at openjdk.org  Wed Feb 26 10:11:07 2025
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 26 Feb 2025 10:11:07 GMT
Subject: Integrated: 8350518: org.openjdk.bench.java.util.TreeMapUpdate.compute
 fails with  "java.lang.IllegalArgumentException: key out of range"
In-Reply-To: <sUX5c-b5uzJ7biA1mOTwB_DuXU9kJwU1CZwA26NZysM=.67ea4b42-ebd6-44ad-a344-d8b06806c21f@github.com>
References: <sUX5c-b5uzJ7biA1mOTwB_DuXU9kJwU1CZwA26NZysM=.67ea4b42-ebd6-44ad-a344-d8b06806c21f@github.com>
Message-ID: <yw_DPKNfMM-sZWuOPJSqejhwzoXqE3nAhFWogg_QKaY=.9141cb20-b967-4f10-89a5-5ca654bc67c6@github.com>

On Mon, 24 Feb 2025 08:44:00 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> It appears that the benchmark was erroneous. The combination of "tailMap" mode and comparator = true didn't work correctly, as the comparator is descending. This PR changes the benchmark to use headMap instead of tailMap in comparator mode. The "tailMap" mode is renamed to "subMap". Now, all parameter combinations work correctly.

This pull request has now been integrated.

Changeset: a4310464
Author:    Tagir F. Valeev <tvaleev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a43104640420fbd82868788ccd8a3a8e938f365a
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8350518: org.openjdk.bench.java.util.TreeMapUpdate.compute fails with  "java.lang.IllegalArgumentException: key out of range"

Reviewed-by: liach, skuksenko

-------------

PR: https://git.openjdk.org/jdk/pull/23744

From alanb at openjdk.org  Wed Feb 26 10:16:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Feb 2025 10:16:07 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
Message-ID: <wwAXWH6Yddzqeh84fQW3YeYvz1D0vENfyOBNDYlz8E0=.7af34e97-a7f0-4a7f-b4a8-89c174098845@github.com>

On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Standardize parameter checking

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3131:

> 3129:         if ((p = (cp = common).parallelism) < 2)
> 3130:             U.compareAndSetInt(cp, PARALLELISM, p, 2);
> 3131:         return cp;

Is this okay for deployments that run with java.util.concurrent.ForkJoinPool.common.parallelism set?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1971313538

From duke at openjdk.org  Wed Feb 26 10:54:00 2025
From: duke at openjdk.org (Nicole Xu)
Date: Wed, 26 Feb 2025 10:54:00 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException [v2]
In-Reply-To: <xWPOEnpk0__054Vd9w7LnkBpHvWdwKtjhjE69b3rwoY=.420231ab-1323-45ef-bcb8-179af701583d@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <x9ETYwOSiE2ZfaP4xus4S6WppTevakAr0hHsRlA7YF8=.a22172e1-e5b5-42f9-9d92-2df2e09fdb05@github.com>
 <52HO_iL9asn1huCdJj82R1AwF1w8ON9HZetrdc9rQyQ=.28e137e0-a7f7-4839-a3e7-eda4f8a6c4f5@github.com>
 <Zzk64psydzXMRGpewo7BcvKmqBOwFL5cT0kgkXvY6GI=.b0def6d9-53ec-4be7-af67-d91354135546@github.com>
 <xWPOEnpk0__054Vd9w7LnkBpHvWdwKtjhjE69b3rwoY=.420231ab-1323-45ef-bcb8-179af701583d@github.com>
Message-ID: <Do3YZGQZkU6wzBLxHX1RnPw5EUX_nwemM-2C-ze59uA=.295c3542-7ea8-40ed-8cfb-9e13e4af2226@github.com>

On Tue, 25 Feb 2025 00:00:23 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Thanks for pointing that out. Typically, ARRAYLEN is almost always a POT value, which is also assumed by many other benchmarks. Are we realistically going to test with an ARRAYLEN of 30? 
>> 
>> I think the POT assumption is reasonable for our purposes.
>
> It's a reasonable assumption. Since `ARRAYLEN` is a parameter of the benchmark we should enforce that constraint in benchmark initialization method, checking if the value is POT and failing otherwise.

Hi, @PaulSandoz, thanks for your suggestions.

In @jatin-bhateja's latest updates, non-POT `ARRAYLEN` values have been supported by processing only the elements up to the nearest multiple of the vector length. In that case, we can use a wider range of `ARRAYLEN` values while focusing on the main loop for vector functionality.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22963#discussion_r1971372152

From galder at openjdk.org  Wed Feb 26 11:36:11 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 26 Feb 2025 11:36:11 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
Message-ID: <wDsCyP79rQ4dN3G6lMjZliTn6ym5-HwjGZ-Y-Xx_vQY=.0a187197-7505-4c95-a6cd-8b8eea0bea88@github.com>

On Fri, 7 Feb 2025 12:39:24 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Fix typo
>  - Renaming methods and variables and add docu on algorithms
>  - Fix copyright years
>  - Make sure it runs with cpus with either avx512 or asimd
>  - Test can only run with 256 bit registers or bigger
>    
>    * Remove platform dependant check
>    and use platform independent configuration instead.
>  - Fix license header
>  - Tests should also run on aarch64 asimd=true envs
>  - Added comment around the assertions
>  - Adjust min/max identity IR test expectations after changes
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/abdd4f5e...a190ae68

> > Re: [#20098 (comment)](https://github.com/openjdk/jdk/pull/20098#issuecomment-2671144644) - I was trying to think what could be causing this.
> 
> Maybe it is an issue with probabilities? Do you know at what point (if at all) the `MinI` node appears/disappears in that example?

The probabilities are fine.

I think the issue with `Math.min(II)` seems to be specific to when its compilation happens, and the combined fact that the intrinsic has been disabled and vectorization does not kick in (explicitly disabled). Note that other parts of the JDK invoke `Math.min(II)`.

In the slow cases it appears the compilation happens before the benchmark kicks in, and so it takes the profiling data before the benchmark to decide how to compile this in.

In the slow versions you see this `PrintMethodData`:

static java.lang.Math::min(II)I
  interpreter_invocation_count:       18171
  invocation_counter:                 18171
  backedge_counter:                       0
  decompile_count:                        0
  mdo size: 328 bytes

   0 iload_0
   1 iload_1
   2 if_icmpgt 9
  0    bci: 2    BranchData         taken(7732) displacement(56)
                                    not taken(10180)
   5 iload_0
   6 goto 10
  32   bci: 6    JumpData           taken(10180) displacement(24)
   9 iload_1
  10 ireturn

org.openjdk.bench.java.lang.MinMaxVector::intReductionSimpleMin(Lorg/openjdk/bench/java/lang/MinMaxVector$LoopState;)I
  interpreter_invocation_count:         189
  invocation_counter:                   189
  backedge_counter:                  313344
  decompile_count:                        0
  mdo size: 384 bytes

   0 iconst_0
   1 istore_2
   2 iconst_0
   3 istore_3
   4 iload_3
   5 aload_1
   6 fast_igetfield 35 <org/openjdk/bench/java/lang/MinMaxVector$LoopState.size:I>
   9 if_icmpge 33
  0    bci: 9    BranchData         taken(58) displacement(72)
                                    not taken(192512)
  12 aload_1
  13 fast_agetfield 41 <org/openjdk/bench/java/lang/MinMaxVector$LoopState.minIntA:[I>
  16 iload_3
  17 iaload
  18 istore #4
  20 iload_2
  21 fast_iload #4
  23 invokestatic 32 <java/lang/Math.min(II)I>
  32   bci: 23   CounterData        count(192512)
  26 istore_2
  27 iinc #3 1
  30 goto 4
  48   bci: 30   JumpData           taken(192512) displacement(-48)
  33 iload_2
  34 ireturn


The benchmark method calls Math.min `192_512` times, yet the method data shows only `18_171` invocations,
of which `7_732` are taken which is 42%.
So it gets compiled with a `cmov` and the benchmark will be slow because it will branch 100% one of the sides.

In the fast version, `PrintMethodData` looks like this:


static java.lang.Math::min(II)I
  interpreter_invocation_count:     1575322
  invocation_counter:               1575322
  backedge_counter:                       0
  decompile_count:                        0
  mdo size: 368 bytes

   0 iload_0
   1 iload_1
   2 if_icmpgt 9
  0    bci: 2    BranchData         taken(1418001) displacement(56)
                                    not taken(157062)
   5 iload_0
   6 goto 10
  32   bci: 6    JumpData           taken(157062) displacement(24)
   9 iload_1
  10 ireturn

org.openjdk.bench.java.lang.MinMaxVector::intReductionSimpleMin(Lorg/openjdk/bench/java/lang/MinMaxVector$LoopState;)I
  interpreter_invocation_count:         858
  invocation_counter:                   858
  backedge_counter:                 1756214
  decompile_count:                        0
  mdo size: 424 bytes

   0 iconst_0
   1 istore_2
   2 iconst_0
   3 istore_3
   4 iload_3
   5 aload_1
   6 fast_igetfield 35 <org/openjdk/bench/java/lang/MinMaxVector$LoopState.size:I>
   9 if_icmpge 33
  0    bci: 9    BranchData         taken(733) displacement(72)
                                    not taken(1637363)
  12 aload_1
  13 fast_agetfield 41 <org/openjdk/bench/java/lang/MinMaxVector$LoopState.minIntA:[I>
  16 iload_3
  17 iaload
  18 istore #4
  20 iload_2
  21 fast_iload #4
  23 invokestatic 32 <java/lang/Math.min(II)I>
  32   bci: 23   CounterData        count(1637363)
  26 istore_2
  27 iinc #3 1
  30 goto 4
  48   bci: 30   JumpData           taken(1637363) displacement(-48)
  33 iload_2
  34 ireturn


The benchmark method calls Math.min `1_637_363` times, and the method data shows `1_575_322` invocations,
of which `1_418_001` are taken which is 90%. So no cmov is introduced and the benchmark will be fast because it will branch 100% one of the sides.

A factor here might be my Xeon machine. I run the benchmark on a 4 core VM inside it, so given the limited resources compilation can take longer. I've noticed that it's easier to replicate this scenario there rather than my M1 laptop, which has 10 cores.

>> So, if those int scalar regressions were not a problem when int min/max intrinsic was added, I would expect the same to apply to long.
>
> Do you know when they were added? If that was a long time ago, we might not have noticed back then, but we might notice now.

I don't know when they were added.

> That said: if we know that it is only in the high-probability cases, then we can address those separately. I would not consider it a blocking issue, as long as we file the follow-up RFE for int/max scalar case with high branch probability.
> 
> What would be really helpful: a list of all regressions / issues, and how we intend to deal with them. If we later find a regression that someone cares about, then we can come back to that list, and justify the decision we made here.

I'll make up a list of regressions and post it here. I won't create RFEs for now. I'd rather wait until we have the list in front of us and we can decide which RFEs to create.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2684701935

From cushon at openjdk.org  Wed Feb 26 12:16:58 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 26 Feb 2025 12:16:58 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
 <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
Message-ID: <jkfg-8kwY2Qo_XUFl99EWMrK905F3ux87d3Znr8PCFI=.81a52252-0109-4156-aa48-fd9620f0757e@github.com>

On Fri, 21 Feb 2025 07:01:42 GMT, Nicole Xu <duke at openjdk.org> wrote:

>> The UnsafeOps JMH benchmark fails with the following error:
>> 
>>       ```
>>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>>       ```
>> 
>> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>> 
>> Note that even it will raise "proprietary API" warnings after this
>> patch, it is acceptable because the relevant APIs are bound for removal
>> for the integrity of the platform.
>
> Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
>    
>    The UnsafeOps JMH benchmark fails with the following error:
>    
>          ```
>          java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>          ```
>    
>    Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>    `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>    
>    Note that even it will raise "proprietary API" warnings after this
>    patch, it is acceptable because the relevant APIs are bound for removal
>    for the integrity of the platform.
>    
>    Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c
>  - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe"
>    
>    This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b.

Would it be possible to configure the build of the microbenchmarks to not pass `-Werror`, so they don't break when sunapi diagnostics are emitted?

> Note that even it will raise "proprietary API" warnings after this patch, it is acceptable because the relevant APIs are bound for removal for the integrity of the platform.

It will not raise those diagnostics today, because they don't work for this compilation due to [JDK-8349846](https://bugs.openjdk.org/browse/JDK-8349846). If that issue is fixed again it would break the build of these benchmarks, e.g. with 1ab1c1d53b86228be85aac96fa5d69db39ac6317 backed out and with this change it would fail with:


test/micro/org/openjdk/bench/sun/misc/UnsafeOps.java:27: warning: Unsafe is internal proprietary API and may be removed in a future release
import sun.misc.Unsafe;
               ^
...
error: warnings found and -Werror specified

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2684789082

From dl at openjdk.org  Wed Feb 26 12:54:04 2025
From: dl at openjdk.org (Doug Lea)
Date: Wed, 26 Feb 2025 12:54:04 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <wwAXWH6Yddzqeh84fQW3YeYvz1D0vENfyOBNDYlz8E0=.7af34e97-a7f0-4a7f-b4a8-89c174098845@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
 <wwAXWH6Yddzqeh84fQW3YeYvz1D0vENfyOBNDYlz8E0=.7af34e97-a7f0-4a7f-b4a8-89c174098845@github.com>
Message-ID: <pGyuEMb34waTa5uWmCJVv4Ikjb-BiR2AMZhZ9Js-Fso=.a8e29e1d-ead8-4e86-b9c4-051055d9b3f4@github.com>

On Wed, 26 Feb 2025 10:13:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Standardize parameter checking
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3131:
> 
>> 3129:         if ((p = (cp = common).parallelism) < 2)
>> 3130:             U.compareAndSetInt(cp, PARALLELISM, p, 2);
>> 3131:         return cp;
> 
> Is this okay for deployments that run with java.util.concurrent.ForkJoinPool.common.parallelism set?

Yes, but we must override only if set to 0. So changed to:
+        if ((p = (cp = common).parallelism) == 0)
+            U.compareAndSetInt(cp, PARALLELISM, 0, 2);

If users set to 1, some async CompletableFuture usages that used to bypass may run more slowly (or more quickly because of less overhead).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1971531909

From pminborg at openjdk.org  Wed Feb 26 12:58:23 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 26 Feb 2025 12:58:23 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno
Message-ID: <QHEUF-Wlk-NBSpBXX6BEbXy1vN_HNlYkvY0lqzoN6ww=.848bb36e-c272-4926-aa37-f66c68e9135f@github.com>

As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.

Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.

It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.


Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):


Benchmark                                                  Mode  Cnt   Score   Error  Units
CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op


Adapted system call:

        return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
```        
Explicit allocation:

        try (var arena = Arena.ofConfined()) {
            return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
        }
```        
Thread Local allocation:

        try (var arena = POOLS.take()) {
            return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
        }
```        
The adapted system call exhibits a ~4x performance improvement over the existing "explicit allocation" scheme for the happy path on platform threads. Because there needs to be sharing across threads for virtual-thread-capable carrier threads, these are a bit slower ("only" ~3x faster).

![image](https://github.com/user-attachments/assets/ae826d95-ae9b-4d46-a03b-d342e058169d)

Here are some benchmarks for the underlying ArenaPool (M1 Mac):


Benchmark                                   (ELEM_SIZE)  Mode  Cnt   Score    Error  Units
ArenaPoolBench.OfVirtual.confined                     4  avgt   30  23.543 ?  0.168  ns/op
ArenaPoolBench.OfVirtual.confined                    64  avgt   30  27.384 ?  0.167  ns/op
ArenaPoolBench.OfVirtual.confined2                    4  avgt   30  47.811 ?  0.220  ns/op
ArenaPoolBench.OfVirtual.confined2                   64  avgt   30  55.404 ?  0.286  ns/op
ArenaPoolBench.OfVirtual.pooled                       4  avgt   30   8.210 ?  0.043  ns/op
ArenaPoolBench.OfVirtual.pooled                      64  avgt   30  45.525 ? 52.525  ns/op
ArenaPoolBench.OfVirtual.pooled2                      4  avgt   30  50.670 ?  0.778  ns/op
ArenaPoolBench.OfVirtual.pooled2                     64  avgt   30  85.846 ?  2.304  ns/op
ArenaPoolBench.confined                               4  avgt   30  23.286 ?  0.184  ns/op
ArenaPoolBench.confined                              64  avgt   30  27.026 ?  0.111  ns/op
ArenaPoolBench.confined2                              4  avgt   30  48.301 ?  0.942  ns/op
ArenaPoolBench.confined2                             64  avgt   30  57.512 ?  5.373  ns/op
ArenaPoolBench.pooled                                 4  avgt   30   5.085 ?  0.048  ns/op
ArenaPoolBench.pooled                                64  avgt   30  29.621 ?  0.440  ns/op
ArenaPoolBench.pooled2                                4  avgt   30  10.610 ?  0.339  ns/op
ArenaPoolBench.pooled2                               64  avgt   30  60.815 ?  1.046  ns/op
ArenaPoolFromBench.OfVirtual.confinedInt            N/A  avgt   30  21.944 ?  0.122  ns/op
ArenaPoolFromBench.OfVirtual.confinedSting          N/A  avgt   30  26.190 ?  0.193  ns/op
ArenaPoolFromBench.OfVirtual.pooledInt              N/A  avgt   30   8.217 ?  0.043  ns/op
ArenaPoolFromBench.OfVirtual.pooledString           N/A  avgt   30   9.271 ?  0.056  ns/op
ArenaPoolFromBench.confinedInt                      N/A  avgt   30  21.892 ?  0.139  ns/op
ArenaPoolFromBench.confinedSting                    N/A  avgt   30  26.012 ?  0.058  ns/op
ArenaPoolFromBench.pooledInt                        N/A  avgt   30   5.056 ?  0.034  ns/op
ArenaPoolFromBench.pooledString                     N/A  avgt   30   6.419 ?  0.037  ns/op

Note: The pool size for the above benchmarks was 32 bytes.


This PR relates to https://github.com/openjdk/jdk/pull/23391 we had to back out. This PR attempts to ensure, that the problems encountered there do not surface in this PR.

The arena pool is able to share recyclable memory across several arenas, for platform threads.

This PR passes tier1, tier2, and tier3 testing.

-------------

Commit messages:
 - Use lazy initialization of method handles
 - Clean up visibility
 - Merge branch 'master' into errno-util3
 - Add @ForceInline annotations
 - Add out of order test for VTs
 - Allow memory reuse for several arenas
 - Remove file
 - Use more frequent allocations
 - Merge branch 'master' into errno-util3
 - Add unsafe variant
 - ... and 21 more: https://git.openjdk.org/jdk/compare/037e4711...907329e9

Changes: https://git.openjdk.org/jdk/pull/23765/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23765&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347408
  Stats: 1902 lines in 13 files changed: 1891 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23765.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23765/head:pull/23765

PR: https://git.openjdk.org/jdk/pull/23765

From liach at openjdk.org  Wed Feb 26 12:58:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 12:58:24 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno
In-Reply-To: <QHEUF-Wlk-NBSpBXX6BEbXy1vN_HNlYkvY0lqzoN6ww=.848bb36e-c272-4926-aa37-f66c68e9135f@github.com>
References: <QHEUF-Wlk-NBSpBXX6BEbXy1vN_HNlYkvY0lqzoN6ww=.848bb36e-c272-4926-aa37-f66c68e9135f@github.com>
Message-ID: <A17VEQ0PbMY63JxSsGLr1btudd69GU_522dWT3plbt4=.ef6a7712-9f84-4a6e-8e98-cb73731af27c@github.com>

On Tue, 25 Feb 2025 08:27:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op
> 
> 
> Adapted system call:
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> ```        
> Explicit allocation:
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> ```        
> Thread Local allocation:
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> ```        
> The adapted system call exhibits a ~4x performance improvement over the existing "explicit allocation" scheme for the happy path on platform threads. ...

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 56:

> 54:     // The method handles below are bound to static methods residing in this class
> 55: 
> 56:     private static final MethodHandle NON_NEGATIVE_INT_MH =

MethodHandle lookup has an overhead for class initialization. I think a better way of storage is something like the cache mechanism of `MethodHandleImpl.getConstantHandle`.

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 102:

> 100:     // A key that holds both the `returnType` and the `stateName` needed to look up a
> 101:     // specific "basic handle" in the `BASIC_HANDLE_CACHE`.
> 102:     //   returnType E {int.class | long.class}

I think using `&in;` or `\in` instead of `E` would be more clear.

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 211:

> 209:                 // This is equivalent to:
> 210:                 //   computeIfAbsent(basicKey, CaptureStateUtil::basicHandleFor);
> 211:                 .computeIfAbsent(basicKey, new Function<>() {

I recommend a local record and capture the record instance in a member static final field. This code creates a function on every call. Also might be of interest whether we should use get + putIfAbsent or computeIfAbsent, as CHM has some bug that makes cIA slower than get for certain access patterns.

src/java.base/share/classes/jdk/internal/foreign/CarrierLocalArenaPools.java line 123:

> 121:          * Thread safe implementation.
> 122:          */
> 123:         public static final class OfCarrier

A public member class in a private nested class... is just weird.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23765#discussion_r1970905900
PR Review Comment: https://git.openjdk.org/jdk/pull/23765#discussion_r1970909347
PR Review Comment: https://git.openjdk.org/jdk/pull/23765#discussion_r1970911090
PR Review Comment: https://git.openjdk.org/jdk/pull/23765#discussion_r1970912512

From pminborg at openjdk.org  Wed Feb 26 12:58:24 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 26 Feb 2025 12:58:24 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno
In-Reply-To: <A17VEQ0PbMY63JxSsGLr1btudd69GU_522dWT3plbt4=.ef6a7712-9f84-4a6e-8e98-cb73731af27c@github.com>
References: <QHEUF-Wlk-NBSpBXX6BEbXy1vN_HNlYkvY0lqzoN6ww=.848bb36e-c272-4926-aa37-f66c68e9135f@github.com>
 <A17VEQ0PbMY63JxSsGLr1btudd69GU_522dWT3plbt4=.ef6a7712-9f84-4a6e-8e98-cb73731af27c@github.com>
Message-ID: <lPvTUqXfsQNMKX6ru0R3ixVs8eG9pI-AhjM4lKocP3o=.06509b69-31f0-4cfd-8844-3ed7a16f31ef@github.com>

On Wed, 26 Feb 2025 05:00:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
>> 
>> 
>> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):
>> 
>> 
>> Benchmark                                                  Mode  Cnt   Score   Error  Units
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
>> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
>> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
>> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
>> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
>> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
>> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op
>> 
>> 
>> Adapted system call:
>> 
>>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
>> ```        
>> Explicit allocation:
>> 
>>         try (var arena = Arena.ofConfined()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>>         }
>> ```        
>> Thread Local allocation:
>> 
>>         try (var arena = POOLS.take()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>>         }
>> ```        
>> The adapted system call exhibits a ~4x performance improvement ove...
>
> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 102:
> 
>> 100:     // A key that holds both the `returnType` and the `stateName` needed to look up a
>> 101:     // specific "basic handle" in the `BASIC_HANDLE_CACHE`.
>> 102:     //   returnType E {int.class | long.class}
> 
> I think using `&in;` or `\in` instead of `E` would be more clear.

I didn't know about `&in;` so thanks for this piece of information @liach. However, in `//` comments it might be better to just type "in".

> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 211:
> 
>> 209:                 // This is equivalent to:
>> 210:                 //   computeIfAbsent(basicKey, CaptureStateUtil::basicHandleFor);
>> 211:                 .computeIfAbsent(basicKey, new Function<>() {
> 
> I recommend a local record and capture the record instance in a member static final field. This code creates a function on every call. Also might be of interest whether we should use get + putIfAbsent or computeIfAbsent, as CHM has some bug that makes cIA slower than get for certain access patterns.

Performance is not critical to this method so I would prioritize maintainability over performance here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23765#discussion_r1971271580
PR Review Comment: https://git.openjdk.org/jdk/pull/23765#discussion_r1971267260

From vklang at openjdk.org  Wed Feb 26 13:34:01 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 26 Feb 2025 13:34:01 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <wwAXWH6Yddzqeh84fQW3YeYvz1D0vENfyOBNDYlz8E0=.7af34e97-a7f0-4a7f-b4a8-89c174098845@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
 <wwAXWH6Yddzqeh84fQW3YeYvz1D0vENfyOBNDYlz8E0=.7af34e97-a7f0-4a7f-b4a8-89c174098845@github.com>
Message-ID: <E4p2S32zm_zM9DfTr1DruKAB4nO3wSP8fftDzxU6dCM=.5c2249cf-b61c-416a-b9c7-100413f45f8a@github.com>

On Wed, 26 Feb 2025 10:13:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Standardize parameter checking
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3131:
> 
>> 3129:         if ((p = (cp = common).parallelism) < 2)
>> 3130:             U.compareAndSetInt(cp, PARALLELISM, p, 2);
>> 3131:         return cp;
> 
> Is this okay for deployments that run with java.util.concurrent.ForkJoinPool.common.parallelism set?

@AlanBateman @DougLea Would it make sense to log something if this happens, or emit a JFR event, or somehow make people aware what occurred (and why)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1971592529

From vklang at openjdk.org  Wed Feb 26 13:40:11 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 26 Feb 2025 13:40:11 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v2]
In-Reply-To: <ENJYX5JbrLeyXN2uoSJgrntY6mW_0bZsre6CEQEeDDg=.a2078d52-ebf7-4f8b-bfad-a86bedfeea1b@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <ENJYX5JbrLeyXN2uoSJgrntY6mW_0bZsre6CEQEeDDg=.a2078d52-ebf7-4f8b-bfad-a86bedfeea1b@github.com>
Message-ID: <TFihLJsMV22kQSMy5PjWvR5G9qJUbLZwUJfRFpl4BFo=.7f62f833-b739-4f6e-b959-02862fde9886@github.com>

On Mon, 24 Feb 2025 16:21:33 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
>> 
>> Modification:
>> Add detail error messages.
>> 
>> Result:
>> Helpful messages.
>
> He-Pin(kerr) has updated the pull request incrementally with one additional commit since the last revision:
> 
>   chore: update tests

src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java line 1264:

> 1262:             throw new IllegalArgumentException("maximumPoolSize must be positive, but got " + maximumPoolSize);
> 1263:         } else if (maximumPoolSize < corePoolSize) {
> 1264:             throw new IllegalArgumentException("maximumPoolSize must be greater than or equal to corePoolSize , " + "but got maximumPoolSize:" + maximumPoolSize + " ,corePoolSize:" + corePoolSize);

Suggestion:

            throw new IllegalArgumentException("maximumPoolSize must be greater than or equal to corePoolSize , " + "but got maximumPoolSize: " + maximumPoolSize + " , and corePoolSize: " + corePoolSize);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r1971601932

From vklang at openjdk.org  Wed Feb 26 13:43:05 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 26 Feb 2025 13:43:05 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v2]
In-Reply-To: <ENJYX5JbrLeyXN2uoSJgrntY6mW_0bZsre6CEQEeDDg=.a2078d52-ebf7-4f8b-bfad-a86bedfeea1b@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <ENJYX5JbrLeyXN2uoSJgrntY6mW_0bZsre6CEQEeDDg=.a2078d52-ebf7-4f8b-bfad-a86bedfeea1b@github.com>
Message-ID: <lrTpt9-GhQTRDEeVu8p_fanRKFfwNR6DqHOiwHVnhHc=.9c5928e9-3b77-41f8-ae36-39c685626eb8@github.com>

On Mon, 24 Feb 2025 16:21:33 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
>> 
>> Modification:
>> Add detail error messages.
>> 
>> Result:
>> Helpful messages.
>
> He-Pin(kerr) has updated the pull request incrementally with one additional commit since the last revision:
> 
>   chore: update tests

src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java line 1513:

> 1511:         } else if (corePoolSize > maximumPoolSize) {
> 1512:             throw new IllegalArgumentException("corePoolSize must be less than or equal to maximumPoolSize, " +
> 1513:                 "but got maximumPoolSize:" + maximumPoolSize + " corePoolSize :" + corePoolSize);

Suggestion:

                "but got maximumPoolSize: " + maximumPoolSize + ", and corePoolSize : " + corePoolSize);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r1971607329

From lancea at openjdk.org  Wed Feb 26 14:05:03 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 26 Feb 2025 14:05:03 GMT
Subject: RFR: 8204868: java/util/zip/ZipFile/TestCleaner.java still fails
 with "cleaner failed to clean zipfile."
In-Reply-To: <SagoNViasiREITln_earADUSLDTN9stD2UAJotnE1d4=.b9f76665-937c-4d7d-b33e-5e304cfce189@github.com>
References: <SagoNViasiREITln_earADUSLDTN9stD2UAJotnE1d4=.b9f76665-937c-4d7d-b33e-5e304cfce189@github.com>
Message-ID: <4lXThpf8c6ZhATMOh2W1dBIrH0fB_fIpC2Ee6Jf7AA0=.c4fc46ab-0d1d-4e69-b99f-028caa001669@github.com>

On Mon, 24 Feb 2025 05:50:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address an intermittent failure in the `test/jdk/java/util/zip/ZipFile/TestCleaner.java` test?
> 
> This test does operations on Inflater/Deflater/ZipFile and  closes those instances and then waits for GC to kick in. After wait for a second, it then checks that the underlying resources held by these instances have been cleaned (by the Cleaner).
> 
> Once in a while, we have noticed that this test fails because the resources haven't been cleaned. I suspect this is because within the (fixed) 1 second wait time, the Cleaner hasn't yet invoked the cleaning action for these instances.
> 
> The commit in this PR updates the test to run it in `othervm` so that the Cleaner actions aren't delayed by any other test or code that might have previously run on the `agentvm`. Furthermore, the test is also updated to the use the `ForceGC` test util which takes into account the jtreg test timeout factor for deciding how long to wait for the Cleaner to initiate the cleaning action. Our CI is configured with a timeout factor of 4, so with this change, instead of a fixed maximum 1 second wait time, the test will now wait a maximum of 4 seconds for the cleaner action to be invoked.
> 
> The test continues to pass with this change, even with a repeat execution of 50 runs.

Hi Jai,

I think the changes look ok overall.  Thank you for tackling this one.

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23742#pullrequestreview-2644615337

From dl at openjdk.org  Wed Feb 26 14:39:59 2025
From: dl at openjdk.org (Doug Lea)
Date: Wed, 26 Feb 2025 14:39:59 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <E4p2S32zm_zM9DfTr1DruKAB4nO3wSP8fftDzxU6dCM=.5c2249cf-b61c-416a-b9c7-100413f45f8a@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
 <wwAXWH6Yddzqeh84fQW3YeYvz1D0vENfyOBNDYlz8E0=.7af34e97-a7f0-4a7f-b4a8-89c174098845@github.com>
 <E4p2S32zm_zM9DfTr1DruKAB4nO3wSP8fftDzxU6dCM=.5c2249cf-b61c-416a-b9c7-100413f45f8a@github.com>
Message-ID: <8ZbKIvr9hf7zhqMIIaTBO_-P_PMDJkxRe37J9FKttzc=.43e5c33b-97de-46f2-80dc-3aa682be67f5@github.com>

On Wed, 26 Feb 2025 13:30:56 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3131:
>> 
>>> 3129:         if ((p = (cp = common).parallelism) < 2)
>>> 3130:             U.compareAndSetInt(cp, PARALLELISM, p, 2);
>>> 3131:         return cp;
>> 
>> Is this okay for deployments that run with java.util.concurrent.ForkJoinPool.common.parallelism set?
>
> @AlanBateman @DougLea Would it make sense to log something if this happens, or emit a JFR event, or somehow make people aware what occurred (and why)?

I don't think this would help anyone? We override in those existing situations in which threads would have been created anyway via the (now removed) bypass in CompletableFuture (also SubmissionPublisher). So anyone who used them with zero parallelism expecting no internal jdk thread creation will already have been surprised.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1971708639

From mbaesken at openjdk.org  Wed Feb 26 15:53:21 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Feb 2025 15:53:21 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
Message-ID: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>

While testing a bit with a minimal JVM, it has been noticed that some java/lang jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .

-------------

Commit messages:
 - JDK-8350786

Changes: https://git.openjdk.org/jdk/pull/23805/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23805&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350786
  Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23805.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23805/head:pull/23805

PR: https://git.openjdk.org/jdk/pull/23805

From mukulg at apache.org  Wed Feb 26 15:59:13 2025
From: mukulg at apache.org (Mukul Gandhi)
Date: Wed, 26 Feb 2025 21:29:13 +0530
Subject: adding Xalan's XSL 3 implementation within jdk
In-Reply-To: <e6c986db-9816-4172-9589-e6ce08674dae@oracle.com>
References: <CABuuzNP66-_d7J=UKz2UBY17V2eVk=xvB5w4bRj4A5aEaDQXcw@mail.gmail.com>
 <CABuuzNPKrdhGyqD-FEP-SU7MS4T_7h1smMBg31G9V2LHcPoq=g@mail.gmail.com>
 <e6c986db-9816-4172-9589-e6ce08674dae@oracle.com>
Message-ID: <CABuuzNO58-iNcaE29133FUWVpz9jH-sCXfQQAZHu_eUiL_oeoA@mail.gmail.com>

Hi Alan,
    I've just seen this mail from you. Apologies for a delayed response.

My mail box has had few issues due to the volume of mails that I get
from mailing lists.

On Sun, Feb 2, 2025 at 9:38?PM Alan Bateman <alan.bateman at oracle.com> wrote:

> The stats for that branch suggest 5,845 changed files with 234,372 additions and 84,058 deletions. I can't easily tell how much of this would need to come into the jdk repo but this looks like a major update. If only 10% of this is applicable to the JDK then it still needs seems like a major update that would require a huge investment to audit and integrate this code. How much XML is in new applications developed in 2025? Only asking because it's an area that is surely much lower priority compared to all the other major investments right now. Maybe there are useful security or performance changes that would be useful to cherry pick instead? Finally, does this Xalan update work with the SPIs so that someone really looking for XSL 3 can just deploy it on the class path and module path?

Ofcourse, anyone could use Xalan-J's XSL 3 implementation with JDK by
placing Xalan jars on class path & module path.

Since Xalan-J's XSLT 1.0 & XPath 1.0 implementations are already
available within JDK, I thought its natural if JDK could pick
Xalan-J's XSL 3 implementation and include that within JDK. I can
imagine that this may surely be time consuming for someone from JDK
team to integrate with JDK. XSLT 1.0's use I think is very less these
days particularly for new XML projects, due to vast improvements in
language features offered by XSLT 3.0 and XPath 3.1.

IMHO, I wrote all the XSL 3 implementation code (and solved various
XSL 3 implementation bugs reported by community on Xalan-J's dev
forum) within Xalan-J's XSL 3 dev respos branch, enhancing upon
Xalan-J's XSLT 1.0 implementation. From my point of view, I'll be
happy if JDK could include Xalan-J's XSL 3 implementation.

I even wrote following two online articles on xml.com about few of XSL
3 language features, and how they're implemented within Xalan-J,
https://www.xml.com/articles/2024/07/22/string-analysis-with-analyze-string/
https://www.xml.com/articles/2023/12/05/xml-path-language-xpath-higher-order-functions/


Many thanks.


-- 
Regards,
Mukul Gandhi

From bpb at openjdk.org  Wed Feb 26 16:27:07 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 26 Feb 2025 16:27:07 GMT
Subject: Integrated: 8024695: new File("").exists() returns false whereas it is
 the current working directory
In-Reply-To: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
References: <p43jBZ5SRR_MtKPmIxKSEB5iqCArJR5-xezvdAhGgJk=.126de941-4f48-4d76-a797-c8bdb77d5d57@github.com>
Message-ID: <a92nTolaM-U3v3SLKwY-8rEPF1BuU4451gzh_TQytpA=.01ef3eae-e39a-4c28-ab83-2d9049960373@github.com>

On Thu, 19 Dec 2024 00:36:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the implementation of `java.io.File` so that it correctly handles the empty path `""`.

This pull request has now been integrated.

Changeset: 9477c705
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9477c705c0bd5ce2d445abb5ca44d46656fc315f
Stats:     306 lines in 5 files changed: 262 ins; 1 del; 43 mod

8024695: new File("").exists() returns false whereas it is the current working directory

Reviewed-by: alanb, rriggs, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/22821

From vaivanov at openjdk.org  Wed Feb 26 16:28:02 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 26 Feb 2025 16:28:02 GMT
Subject: RFR: 8350682 [JMH] vector.IndexInRangeBenchmark failed with IOOBE
In-Reply-To: <a1_5DZ8fmibdpMXTNaQEzF2q4ExfqGVpxfKxTIjAPgc=.5aba77b1-53a8-4d50-8622-959d163592c0@github.com>
References: <a1_5DZ8fmibdpMXTNaQEzF2q4ExfqGVpxfKxTIjAPgc=.5aba77b1-53a8-4d50-8622-959d163592c0@github.com>
Message-ID: <st1aQDRx0Z8tJKjA9O3492z8GFnV9e0g5FZtyiKk2d4=.873771e8-c4f9-4f8c-aeec-453cfa60e72a@github.com>

On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> Array initialization by parameter was added. Extra constant was used to align cycle step with used arrays.

Yes, exceptions reported for runs with size=1024. The test support max size=512 and have no checks for passed params.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23783#issuecomment-2685566479

From duke at openjdk.org  Wed Feb 26 16:44:53 2025
From: duke at openjdk.org (Mikhail Yankelevich)
Date: Wed, 26 Feb 2025 16:44:53 GMT
Subject: RFR: 8350704: Create tests to ensure the failure behavior of core
 reflection APIs
In-Reply-To: <hALAQ2YPDV_gZIjVHV1pE8emYwh83IhrPg8PrnLWVLE=.62cdd46b-668a-47a1-a841-21fdb7537206@github.com>
References: <hALAQ2YPDV_gZIjVHV1pE8emYwh83IhrPg8PrnLWVLE=.62cdd46b-668a-47a1-a841-21fdb7537206@github.com>
Message-ID: <The8q_zx7r8q9iWn4cWNJlGSwpEp1UvBJi_cv9aRCrI=.b0c65e8d-0b98-4e1f-9e67-f39e885af1c3@github.com>

On Tue, 25 Feb 2025 23:50:01 GMT, Chen Liang <liach at openjdk.org> wrote:

> Core reflection's generic signature parsing system is used for many aspects, including annotations and enclosing methods, yet it is under-tested. It is better for us to set up tests to ensure that sensitive error behaviors of core reflection remain the same across implementation updates, such as #19281.
> 
> This patch also includes a JUnit converted version of https://github.com/openjdk/jdk/pull/22581#issuecomment-2521703511 test checking behavior around annotations with duplicate interfaces. Interesting that this causes failure in class, field, and methods (constructors), but not in parameters.
> 
> Testing: jdk-tier 1, jdk-tier 2

test/jdk/java/lang/annotation/MalformedAnnotationTest.java line 30:

> 28:  *          that should stay in refactors
> 29:  * @library /test/lib
> 30:  * @comment

Minor: Do you need the `@comment` here if it's empty?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23788#discussion_r1971956709

From liach at openjdk.org  Wed Feb 26 16:53:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 16:53:58 GMT
Subject: RFR: 8350704: Create tests to ensure the failure behavior of core
 reflection APIs
In-Reply-To: <The8q_zx7r8q9iWn4cWNJlGSwpEp1UvBJi_cv9aRCrI=.b0c65e8d-0b98-4e1f-9e67-f39e885af1c3@github.com>
References: <hALAQ2YPDV_gZIjVHV1pE8emYwh83IhrPg8PrnLWVLE=.62cdd46b-668a-47a1-a841-21fdb7537206@github.com>
 <The8q_zx7r8q9iWn4cWNJlGSwpEp1UvBJi_cv9aRCrI=.b0c65e8d-0b98-4e1f-9e67-f39e885af1c3@github.com>
Message-ID: <T2kDvyfuiFKl5ceydLT3p72kmXz4GfsQDnOrN5OFQZs=.227ab782-d8c2-4aa2-b329-a1936f4c7a57@github.com>

On Wed, 26 Feb 2025 16:41:40 GMT, Mikhail Yankelevich <duke at openjdk.org> wrote:

>> Core reflection's generic signature parsing system is used for many aspects, including annotations and enclosing methods, yet it is under-tested. It is better for us to set up tests to ensure that sensitive error behaviors of core reflection remain the same across implementation updates, such as #19281.
>> 
>> This patch also includes a JUnit converted version of https://github.com/openjdk/jdk/pull/22581#issuecomment-2521703511 test checking behavior around annotations with duplicate interfaces. Interesting that this causes failure in class, field, and methods (constructors), but not in parameters.
>> 
>> Testing: jdk-tier 1, jdk-tier 2
>
> test/jdk/java/lang/annotation/MalformedAnnotationTest.java line 30:
> 
>> 28:  *          that should stay in refactors
>> 29:  * @library /test/lib
>> 30:  * @comment
> 
> Minor: Do you need the `@comment` here if it's empty?

Indeed. Looks like a copy-paste error!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23788#discussion_r1971971308

From jvernee at openjdk.org  Wed Feb 26 17:02:00 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 17:02:00 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <iog0kKFr_ePoJsQUo36J0soxHEf2-a0Ac7abgZ5Ys1M=.e67b1aa5-c695-4ba2-8831-71043242df49@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <iog0kKFr_ePoJsQUo36J0soxHEf2-a0Ac7abgZ5Ys1M=.e67b1aa5-c695-4ba2-8831-71043242df49@github.com>
Message-ID: <nteHGr0wm9PlWvxZn0qGlqg-pT99241lnggMQmOla2k=.1289eeb1-1cbc-4825-8d59-e7501e8eb868@github.com>

On Fri, 21 Feb 2025 10:05:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/java/lang/invoke/VarForm.java line 150:
> 
>> 148:         String methodName = value.methodName();
>> 149:         MethodType type = methodType_table[value.at.ordinal()].insertParameterTypes(0, VarHandle.class);
>> 150:         assert !UNSAFE.shouldBeInitialized(implClass) : implClass;
> 
> Thanks - took a long time to figure this one out -- hopefully it will save time in the future ;-)

TBH, I thought that resolving the member name would implicitly initialize the class

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1971985978

From liach at openjdk.org  Wed Feb 26 17:05:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 17:05:55 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <nteHGr0wm9PlWvxZn0qGlqg-pT99241lnggMQmOla2k=.1289eeb1-1cbc-4825-8d59-e7501e8eb868@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <iog0kKFr_ePoJsQUo36J0soxHEf2-a0Ac7abgZ5Ys1M=.e67b1aa5-c695-4ba2-8831-71043242df49@github.com>
 <nteHGr0wm9PlWvxZn0qGlqg-pT99241lnggMQmOla2k=.1289eeb1-1cbc-4825-8d59-e7501e8eb868@github.com>
Message-ID: <asdX2j19MxYN0Vpo45UQq7eRY-d-GF3JcDi0GfhL770=.756bafa5-49e6-444e-8b91-60682b1c232a@github.com>

On Wed, 26 Feb 2025 16:59:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/VarForm.java line 150:
>> 
>>> 148:         String methodName = value.methodName();
>>> 149:         MethodType type = methodType_table[value.at.ordinal()].insertParameterTypes(0, VarHandle.class);
>>> 150:         assert !UNSAFE.shouldBeInitialized(implClass) : implClass;
>> 
>> Thanks - took a long time to figure this one out -- hopefully it will save time in the future ;-)
>
> TBH, I thought that resolving the member name would implicitly initialize the class

I think the lack of initialization is WAI - DMH explicitly has an initialization barrier form. This form requires the invoked static method to be resolved, yet it does not initialize the declaring class until the initialization barrier.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1971991806

From jvernee at openjdk.org  Wed Feb 26 17:21:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 17:21:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 83:

> 81:                     bb.unsafeGetBase(),
> 82:                     offset(bb, base, offset),
> 83:                     handle.be);

Why do we not have a call to `convEndian` here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972019170

From naoto at openjdk.org  Wed Feb 26 17:23:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Feb 2025 17:23:56 GMT
Subject: RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException
In-Reply-To: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
Message-ID: <lbc_6-0e2mtkowoAcRSqniIfc2kbd386ZNxIXagPnHw=.e914e8d7-9b8b-4fe9-968e-74655436ef0a@github.com>

On Tue, 25 Feb 2025 23:58:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
> 
> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
> 
> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override. (Which ensures `SupplementalJapaneseEraTestRun.java` passes, which also tests against building (and succeeding) with an era value of 6.

Looks good to me. I would expect a test case with `jdk.calendar.japanese.supplemental.era` defined with something, and 7 would throw an IAE.

src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1862:

> 1860:             // BEFORE_MEIJI to be ignored during normalization
> 1861:             // We check against eras.length over Reiwa ERA due to possibility
> 1862:             // of additional eras via "jdk.calendar.japanese.supplemental.era"

The possibility is not only that emergency property, but by design Japanese calendar eras increase when the current emperor abdicates.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23789#pullrequestreview-2645256501
PR Review Comment: https://git.openjdk.org/jdk/pull/23789#discussion_r1972020190

From jvernee at openjdk.org  Wed Feb 26 17:26:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 17:26:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 216:

> 214:         } else {
> 215:             // simpler adaptation
> 216:             handle = MethodHandles.insertCoordinates(handle, 2, offset);            // (MS, long)

Okay, looking at this code I think I get it: when the offset into the enclosing layout is fixed, we don't have strides (from `sequenceElement()`), so we don't need the extra adaptation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972024703

From jvernee at openjdk.org  Wed Feb 26 17:26:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 17:26:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>
Message-ID: <4ZTgmEF7598oiRqCiAl43Ux559migTzfTcjkwLKw0no=.0e4b1001-eedd-462c-9283-8038565c96c7@github.com>

On Wed, 26 Feb 2025 17:22:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 216:
> 
>> 214:         } else {
>> 215:             // simpler adaptation
>> 216:             handle = MethodHandles.insertCoordinates(handle, 2, offset);            // (MS, long)
> 
> Okay, looking at this code I think I get it: when the offset into the enclosing layout is fixed, we don't have strides (from `sequenceElement()`), so we don't need the extra adaptation.

I suggest maybe renaming `noStride` to something like `fixedOffsetInEnclosing`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972026669

From jvernee at openjdk.org  Wed Feb 26 17:30:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 17:30:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <qbuLLDLrKCfiboQPKUm-foy78lVCZEuyAhMKUVTYjxg=.365781f5-ab80-46fa-836e-67dca7f53ed1@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 331:

> 329: 
> 330:     @ForceInline
> 331:     public static int unboxSegment32(MemorySegment segment) {

Could you add a comment here:
Suggestion:

    public static int unboxSegment32(MemorySegment segment) {
        // this cast to 'int' is safe, because we only call this method on 32-bit platforms, where we know the address of a segment is truncated to 32-bits.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972037179

From jvernee at openjdk.org  Wed Feb 26 17:41:14 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 17:41:14 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
Message-ID: <pUg1f70Sd3w2EGZI1gmxCyCM-7ShL2HkdCWnDHhPpE0=.25d93bb8-0cbe-4ab2-889b-c4e78f77c6d6@github.com>

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review remarks, dates, some more simplifications

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 74:

> 72:             return ret;
> 73:         return computeFilterHandle(index);
> 74:     }

Why is this using an array, instead of just having 3 fields?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972039341

From jlu at openjdk.org  Wed Feb 26 18:26:15 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Feb 2025 18:26:15 GMT
Subject: RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
Message-ID: <q3h949fNwUclnY6e2gCz075we3PXCqDYK8fdYOTnBWg=.168cebcf-760f-40a9-94b5-b1562c1c73b3@github.com>

> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
> 
> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
> 
> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override or future eras in general.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Naoto - correct comment regarding REIWA, add test case for IAE check w/ additional era via sys prop

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23789/files
  - new: https://git.openjdk.org/jdk/pull/23789/files/f14d7c64..e55053aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23789&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23789&range=00-01

  Stats: 23 lines in 4 files changed: 17 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23789/head:pull/23789

PR: https://git.openjdk.org/jdk/pull/23789

From jlu at openjdk.org  Wed Feb 26 18:28:57 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Feb 2025 18:28:57 GMT
Subject: RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <lbc_6-0e2mtkowoAcRSqniIfc2kbd386ZNxIXagPnHw=.e914e8d7-9b8b-4fe9-968e-74655436ef0a@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
 <lbc_6-0e2mtkowoAcRSqniIfc2kbd386ZNxIXagPnHw=.e914e8d7-9b8b-4fe9-968e-74655436ef0a@github.com>
Message-ID: <BvoA1xOqUn2kAO0HXKWlwl-V1RVh8625O4MZMJVlXQk=.72f24f12-4975-49bd-8713-30ca271ad76d@github.com>

On Wed, 26 Feb 2025 17:20:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naoto - correct comment regarding REIWA, add test case for IAE check w/ additional era via sys prop
>
> Looks good to me. I would expect a test case with `jdk.calendar.japanese.supplemental.era` defined with something, and 7 would throw an IAE.

@naotoj Addressed your comments in https://github.com/openjdk/jdk/pull/23789/commits/e55053aa92d735ec44844b426ebd8996eb24317f. 

@liach Filed a CSR: https://bugs.openjdk.org/browse/JDK-8350806.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23789#issuecomment-2685858142

From galder at openjdk.org  Wed Feb 26 18:33:03 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 26 Feb 2025 18:33:03 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <wDsCyP79rQ4dN3G6lMjZliTn6ym5-HwjGZ-Y-Xx_vQY=.0a187197-7505-4c95-a6cd-8b8eea0bea88@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
 <wDsCyP79rQ4dN3G6lMjZliTn6ym5-HwjGZ-Y-Xx_vQY=.0a187197-7505-4c95-a6cd-8b8eea0bea88@github.com>
Message-ID: <DvPOVOuqVlNY-0K5E201YQgKmguBMpJDQw2h1myD8S0=.81a46beb-90fa-4417-a9b2-9d3ebc746538@github.com>

On Wed, 26 Feb 2025 11:32:57 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> > That said: if we know that it is only in the high-probability cases, then we can address those separately. I would not consider it a blocking issue, as long as we file the follow-up RFE for int/max scalar case with high branch probability.
> > What would be really helpful: a list of all regressions / issues, and how we intend to deal with them. If we later find a regression that someone cares about, then we can come back to that list, and justify the decision we made here.
> 
> I'll make up a list of regressions and post it here. I won't create RFEs for now. I'd rather wait until we have the list in front of us and we can decide which RFEs to create.

Before noting the regressions, it's worth noting that PR also improves performance certain scenarios. I will summarise those tomorrow.

Here's a summary of the regressions

### Regression 1
Given a loop with a long min/max reduction pattern with one side of branch taken near 100% of time, when Supeword finds the pattern not profitable, then HotSpot will use scalar instructions (cmov) and performance will regress.

Possible solutions:
a) make Superword recognise these scenarios as profitable.

### Regression 2
Given a loop with a long min/max reduction pattern with one side of branch near 100% of time, when the platform does not support vector instructions to achieve this (e.g. AVX-512 quad word vpmax/vpmin), then HotSpot will use scalar instructions (cmov) and performance will regress.

Possible solutions
a) find a way to use other vector instructions (vpcmp+vpblend+vmov?)
b) fallback on more suitable scalar instructions, e.g. cmp+mov, when the branch is very one-sided

### Regression 3
Given a loop with a long min/max non-reduction pattern (e.g. `longLoopMax`) with one side of branch taken near 100% of time, when the platform does not vectorize it (either lack of CPU instruction support, or Superword finding not profitable), then HotSpot will use scalar instructions (cmov) and performance will regress.

Possible solutions:
a) find a way to use other vector instructions (e.g. `longLoopMax` vectorizes with AVX2 and might also do with earlier instruction sets)
b) fallback on more suitable scalar instructions, e.g. cmp+mov, when the branch is very one-sided,

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2685865807

From markus at headcrashing.eu  Wed Feb 26 19:01:13 2025
From: markus at headcrashing.eu (Markus KARG)
Date: Wed, 26 Feb 2025 20:01:13 +0100
Subject: adding Xalan's XSL 3 implementation within jdk
In-Reply-To: <CABuuzNO58-iNcaE29133FUWVpz9jH-sCXfQQAZHu_eUiL_oeoA@mail.gmail.com>
References: <CABuuzNP66-_d7J=UKz2UBY17V2eVk=xvB5w4bRj4A5aEaDQXcw@mail.gmail.com>
 <CABuuzNPKrdhGyqD-FEP-SU7MS4T_7h1smMBg31G9V2LHcPoq=g@mail.gmail.com>
 <e6c986db-9816-4172-9589-e6ce08674dae@oracle.com>
 <CABuuzNO58-iNcaE29133FUWVpz9jH-sCXfQQAZHu_eUiL_oeoA@mail.gmail.com>
Message-ID: <72e2e38c-25f7-441e-8241-042d2734dc15@headcrashing.eu>

As long as Xalan is contained in OpenJDK, it should be updated. It makes 
no sense to provide XSL 1 still, but not XSL 2 or 3.

A different question is whether that means that the source code must be 
copied into OpenJDK, or if it wouldn't be enough to instead bundle the 
original JAR from Apache, or to drop bundling of Xalan at all, asking 
people to download it manually.

-Markus Karg


Am 26.02.2025 um 16:59 schrieb Mukul Gandhi:
> Hi Alan,
>      I've just seen this mail from you. Apologies for a delayed response.
>
> My mail box has had few issues due to the volume of mails that I get
> from mailing lists.
>
> On Sun, Feb 2, 2025 at 9:38?PM Alan Bateman <alan.bateman at oracle.com> wrote:
>
>> The stats for that branch suggest 5,845 changed files with 234,372 additions and 84,058 deletions. I can't easily tell how much of this would need to come into the jdk repo but this looks like a major update. If only 10% of this is applicable to the JDK then it still needs seems like a major update that would require a huge investment to audit and integrate this code. How much XML is in new applications developed in 2025? Only asking because it's an area that is surely much lower priority compared to all the other major investments right now. Maybe there are useful security or performance changes that would be useful to cherry pick instead? Finally, does this Xalan update work with the SPIs so that someone really looking for XSL 3 can just deploy it on the class path and module path?
> Ofcourse, anyone could use Xalan-J's XSL 3 implementation with JDK by
> placing Xalan jars on class path & module path.
>
> Since Xalan-J's XSLT 1.0 & XPath 1.0 implementations are already
> available within JDK, I thought its natural if JDK could pick
> Xalan-J's XSL 3 implementation and include that within JDK. I can
> imagine that this may surely be time consuming for someone from JDK
> team to integrate with JDK. XSLT 1.0's use I think is very less these
> days particularly for new XML projects, due to vast improvements in
> language features offered by XSLT 3.0 and XPath 3.1.
>
> IMHO, I wrote all the XSL 3 implementation code (and solved various
> XSL 3 implementation bugs reported by community on Xalan-J's dev
> forum) within Xalan-J's XSL 3 dev respos branch, enhancing upon
> Xalan-J's XSLT 1.0 implementation. From my point of view, I'll be
> happy if JDK could include Xalan-J's XSL 3 implementation.
>
> I even wrote following two online articles on xml.com about few of XSL
> 3 language features, and how they're implemented within Xalan-J,
> https://www.xml.com/articles/2024/07/22/string-analysis-with-analyze-string/
> https://www.xml.com/articles/2023/12/05/xml-path-language-xpath-higher-order-functions/
>
>
> Many thanks.
>
>

From naoto at openjdk.org  Wed Feb 26 19:25:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Feb 2025 19:25:53 GMT
Subject: RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <q3h949fNwUclnY6e2gCz075we3PXCqDYK8fdYOTnBWg=.168cebcf-760f-40a9-94b5-b1562c1c73b3@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
 <q3h949fNwUclnY6e2gCz075we3PXCqDYK8fdYOTnBWg=.168cebcf-760f-40a9-94b5-b1562c1c73b3@github.com>
Message-ID: <u4nBgH0AolI9bDbXo4Ez97P02eFOrZ_wUfmvmeqAlJ4=.421df13c-aebd-4413-86d5-56b6b5aa66e5@github.com>

On Wed, 26 Feb 2025 18:26:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
>> 
>> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
>> 
>> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override or future eras in general.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto - correct comment regarding REIWA, add test case for IAE check w/ additional era via sys prop

test/jdk/java/util/Calendar/SupplementalJapaneseEraTest.java line 75:

> 73:             new Calendar.Builder()
> 74:                     .setCalendarType("japanese")
> 75:                     .setFields(ERA, 7)

Sorry I suggested this immediate value "7", but this can be `JapaneseEra.values().length + 2` which might be more meaningful

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23789#discussion_r1972249833

From jlu at openjdk.org  Wed Feb 26 19:48:10 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Feb 2025 19:48:10 GMT
Subject: RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException [v3]
In-Reply-To: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
Message-ID: <B6UdiMgJqb1x4CiyiCV06wub7dz4kwreMy8DLZVvNA4=.23b07720-d7a9-44c2-9352-d83b45aab573@github.com>

> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
> 
> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
> 
> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override or future eras in general.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Replace 7 w/ more meaningful value

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23789/files
  - new: https://git.openjdk.org/jdk/pull/23789/files/e55053aa..53a2e3ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23789&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23789&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23789/head:pull/23789

PR: https://git.openjdk.org/jdk/pull/23789

From jlu at openjdk.org  Wed Feb 26 19:48:11 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Feb 2025 19:48:11 GMT
Subject: RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <u4nBgH0AolI9bDbXo4Ez97P02eFOrZ_wUfmvmeqAlJ4=.421df13c-aebd-4413-86d5-56b6b5aa66e5@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
 <q3h949fNwUclnY6e2gCz075we3PXCqDYK8fdYOTnBWg=.168cebcf-760f-40a9-94b5-b1562c1c73b3@github.com>
 <u4nBgH0AolI9bDbXo4Ez97P02eFOrZ_wUfmvmeqAlJ4=.421df13c-aebd-4413-86d5-56b6b5aa66e5@github.com>
Message-ID: <MZoGvBGkb3bcYiRmmsFwqyfRsdUNWBMGg909WfNDtW4=.a9117982-0044-40f7-a96b-2f45a5fe9127@github.com>

On Wed, 26 Feb 2025 19:23:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naoto - correct comment regarding REIWA, add test case for IAE check w/ additional era via sys prop
>
> test/jdk/java/util/Calendar/SupplementalJapaneseEraTest.java line 75:
> 
>> 73:             new Calendar.Builder()
>> 74:                     .setCalendarType("japanese")
>> 75:                     .setFields(ERA, 7)
> 
> Sorry I suggested this immediate value "7", but this can be `JapaneseEra.values().length + 2` which might be more meaningful

Agree that is better; it's pushed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23789#discussion_r1972280397

From liach at openjdk.org  Wed Feb 26 19:58:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 19:58:07 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
Message-ID: <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>

On Wed, 26 Feb 2025 17:18:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 83:
> 
>> 81:                     bb.unsafeGetBase(),
>> 82:                     offset(bb, base, offset),
>> 83:                     handle.be);
> 
> Why do we not have a call to `convEndian` here?

This is just how it was. Refer to line 141 in old diff.

> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 74:
> 
>> 72:             return ret;
>> 73:         return computeFilterHandle(index);
>> 74:     }
> 
> Why is this using an array, instead of just having 3 fields?

This emulates how MethodHandleImpl does the cache.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972306931
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972312952

From liach at openjdk.org  Wed Feb 26 19:58:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 19:58:07 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <4ZTgmEF7598oiRqCiAl43Ux559migTzfTcjkwLKw0no=.0e4b1001-eedd-462c-9283-8038565c96c7@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>
 <4ZTgmEF7598oiRqCiAl43Ux559migTzfTcjkwLKw0no=.0e4b1001-eedd-462c-9283-8038565c96c7@github.com>
Message-ID: <ITL0ulKc9iZF4ShEflEc0r-3rdsN77wtTSalhWhA2tw=.973640ef-9843-4009-828b-8a1c7754be07@github.com>

On Wed, 26 Feb 2025 17:23:02 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 216:
>> 
>>> 214:         } else {
>>> 215:             // simpler adaptation
>>> 216:             handle = MethodHandles.insertCoordinates(handle, 2, offset);            // (MS, long)
>> 
>> Okay, looking at this code I think I get it: when the offset into the enclosing layout is fixed, we don't have strides (from `sequenceElement()`), so we don't need the extra adaptation.
>
> I suggest maybe renaming `noStride` to something like `fixedOffsetInEnclosing`

In last revision I called it `fixedOffset`, but it becomes confusing with the actual fixed value of the offset.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972310946

From naoto at openjdk.org  Wed Feb 26 20:03:02 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Feb 2025 20:03:02 GMT
Subject: RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException [v3]
In-Reply-To: <B6UdiMgJqb1x4CiyiCV06wub7dz4kwreMy8DLZVvNA4=.23b07720-d7a9-44c2-9352-d83b45aab573@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
 <B6UdiMgJqb1x4CiyiCV06wub7dz4kwreMy8DLZVvNA4=.23b07720-d7a9-44c2-9352-d83b45aab573@github.com>
Message-ID: <JmkTUduAFUwvAWddFui1xAjYzQqtqhMhPaHgqLuuRpE=.3a2e60ef-fd02-411f-958b-4b3b33e2bbc6@github.com>

On Wed, 26 Feb 2025 19:48:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
>> 
>> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
>> 
>> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override or future eras in general.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace 7 w/ more meaningful value

Thanks. I reviewed the CSR as well.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23789#pullrequestreview-2645746475

From liach at openjdk.org  Wed Feb 26 20:13:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 20:13:42 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v3]
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <IYCH1mvqXpuclq7MT4N1Lfw51WBcre18W2pHdcXRsAI=.47e67e2c-1c45-427f-9e05-06b6befff18f@github.com>

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Jorn vernee review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23720/files
  - new: https://git.openjdk.org/jdk/pull/23720/files/c4af6ebf..3d558a2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=01-02

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23720/head:pull/23720

PR: https://git.openjdk.org/jdk/pull/23720

From liach at openjdk.org  Wed Feb 26 20:13:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 20:13:42 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <qbuLLDLrKCfiboQPKUm-foy78lVCZEuyAhMKUVTYjxg=.365781f5-ab80-46fa-836e-67dca7f53ed1@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <qbuLLDLrKCfiboQPKUm-foy78lVCZEuyAhMKUVTYjxg=.365781f5-ab80-46fa-836e-67dca7f53ed1@github.com>
Message-ID: <k4ITJqaQO-8fY8y4I-wQr1VSDLtQIDqh8gx_8PfcMaY=.401181b9-cf61-40da-a5d9-a49d631bc0ce@github.com>

On Wed, 26 Feb 2025 17:26:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks, dates, some more simplifications
>
> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 331:
> 
>> 329: 
>> 330:     @ForceInline
>> 331:     public static int unboxSegment32(MemorySegment segment) {
> 
> Could you add a comment here:
> Suggestion:
> 
>     public static int unboxSegment32(MemorySegment segment) {
>         // this cast to 'int' is safe, because we only call this method on 32-bit platforms, where we know the address of a segment is truncated to 32-bits.

Done, pushed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1972329235

From jvernee at openjdk.org  Wed Feb 26 20:27:56 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 26 Feb 2025 20:27:56 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v3]
In-Reply-To: <IYCH1mvqXpuclq7MT4N1Lfw51WBcre18W2pHdcXRsAI=.47e67e2c-1c45-427f-9e05-06b6befff18f@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <IYCH1mvqXpuclq7MT4N1Lfw51WBcre18W2pHdcXRsAI=.47e67e2c-1c45-427f-9e05-06b6befff18f@github.com>
Message-ID: <MxSiu063m3vUD1fcNcaHIlR0_YbfWD-FVi3EXGN5OjM=.78937390-315e-46a5-bb73-587c7f0f255b@github.com>

On Wed, 26 Feb 2025 20:13:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Jorn vernee review

Some more general questions I have: Using which methodology was the performance impact of this patch measured? How can someone reproduce that measurement (now and in the future)? Is there some script or other automation we could add to the repo to do the measurement?

(I have an idea about the answers, but I think it's good to capture the answers here, as part of this review thread, as well)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2686113353

From liach at openjdk.org  Wed Feb 26 21:36:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 21:36:00 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v3]
In-Reply-To: <IYCH1mvqXpuclq7MT4N1Lfw51WBcre18W2pHdcXRsAI=.47e67e2c-1c45-427f-9e05-06b6befff18f@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <IYCH1mvqXpuclq7MT4N1Lfw51WBcre18W2pHdcXRsAI=.47e67e2c-1c45-427f-9e05-06b6befff18f@github.com>
Message-ID: <81ZuUBzSVN9T8h5PsmnA4ETdvpfz-fudKhTEWlrm8Dc=.473909fc-9954-47dc-9d32-58d71bc345c3@github.com>

On Wed, 26 Feb 2025 20:13:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Jorn vernee review

I put that 3 lines of code in a `public static void main` and measured the number of instructions executed using bytestacks. Unfortunately we don't have any automation, and this test is partial that we should probably add more things to the measurement (such as general foreign function cost, and cost of other kinds of foreign memory access).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2686250061

From asemenyuk at openjdk.org  Wed Feb 26 21:59:59 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 26 Feb 2025 21:59:59 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging [v3]
In-Reply-To: <9mgllgaUDGiiFYekXcXOsZDei0hDRflNHQhKwCJeRMQ=.80469bf5-882d-41e7-98df-74c59dc3ea0d@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <9mgllgaUDGiiFYekXcXOsZDei0hDRflNHQhKwCJeRMQ=.80469bf5-882d-41e7-98df-74c59dc3ea0d@github.com>
Message-ID: <PkXypks3bK7Ee5dx_L94CzqgU6nBMuJDjsJjc9qVH0U=.441b9bae-c82c-4a24-9765-fea7e951f482@github.com>

On Tue, 25 Feb 2025 16:14:22 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Fix the warning message about the custom installation directory location jpackage issues for DMG runtime packaging.
>>  - Don't issue the warning when the `--install-dir` value equals the default installation directory location.
>>  - Add relevant tests.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better warning wording

Are there any strong objections against showing the warning only when `--install-dir` is set to the non-default value for DMG packaging?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23752#issuecomment-2686296919

From almatvee at openjdk.org  Wed Feb 26 22:14:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 26 Feb 2025 22:14:57 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging [v3]
In-Reply-To: <9mgllgaUDGiiFYekXcXOsZDei0hDRflNHQhKwCJeRMQ=.80469bf5-882d-41e7-98df-74c59dc3ea0d@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <9mgllgaUDGiiFYekXcXOsZDei0hDRflNHQhKwCJeRMQ=.80469bf5-882d-41e7-98df-74c59dc3ea0d@github.com>
Message-ID: <i7YDPbkShc0NwlCYDxrCd6_AZ64_S-8rg7crEoG7ZmU=.84045ca7-d3f1-4688-8a84-c868219adf15@github.com>

On Tue, 25 Feb 2025 16:14:22 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> - Fix the warning message about the custom installation directory location jpackage issues for DMG runtime packaging.
>>  - Don't issue the warning when the `--install-dir` value equals the default installation directory location.
>>  - Add relevant tests.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better warning wording

No objections. Looks good to me.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23752#pullrequestreview-2646069966

From jlu at openjdk.org  Wed Feb 26 22:22:11 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Feb 2025 22:22:11 GMT
Subject: RFR: 4745837: Make grouping usage during parsing apparent in relevant
 NumberFormat methods
Message-ID: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>

Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.

Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/23813/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23813&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-4745837
  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23813.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23813/head:pull/23813

PR: https://git.openjdk.org/jdk/pull/23813

From mik3hall at gmail.com  Wed Feb 26 23:25:36 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 26 Feb 2025 17:25:36 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging [v3]
In-Reply-To: <PkXypks3bK7Ee5dx_L94CzqgU6nBMuJDjsJjc9qVH0U=.441b9bae-c82c-4a24-9765-fea7e951f482@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <9mgllgaUDGiiFYekXcXOsZDei0hDRflNHQhKwCJeRMQ=.80469bf5-882d-41e7-98df-74c59dc3ea0d@github.com>
 <PkXypks3bK7Ee5dx_L94CzqgU6nBMuJDjsJjc9qVH0U=.441b9bae-c82c-4a24-9765-fea7e951f482@github.com>
Message-ID: <AF89236A-84C2-481D-8A1A-95596C27AE1D@gmail.com>



> On Feb 26, 2025, at 3:59?PM, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:
> 
> On Tue, 25 Feb 2025 16:14:22 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:
> 
>>> - Fix the warning message about the custom installation directory location jpackage issues for DMG runtime packaging.
>>> - Don't issue the warning when the `--install-dir` value equals the default installation directory location.
>>> - Add relevant tests.
>> 
>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  Better warning wording
> 
> Are there any strong objections against showing the warning only when `--install-dir` is set to the non-default value for DMG packaging?
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/23752#issuecomment-2686296919

Thank you for helping me to understand the issue.

My opinion would still be that the warning should always be used since the parameter isn?t valid in this usage and not doing anything. If my understanding is in fact correct. Not a strong objection though.

After seeing this I was somewhat curious about the runtime packaging you mentioned.

The only reference I came across on some quick googling was here?

https://www.herongyang.com/Java-Tools/jpackage-What-Is-It.html

I copied my current /Library/Java/JavaVirtualMachines/jdk-22.0.1.jdk to a rt directory and ran?

jpackage -n rt -t dmg --runtime-image rt

The resulting dmg had 

ls /Volumes/rt/rt/Contents/Home
jdk-22.0.1.jdk

The actual runtime image is a couple directories deep. I tried removing my jdk22 and putting this into JavaVirtualMachines and it didn?t find it. 

/usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk-22.0.1.jdk/Contents/Home

Or 

java -version
openjdk version "21.0.1" 2023-10-17
OpenJDK Runtime Environment (build 21.0.1+12-29)
OpenJDK 64-Bit Server VM (build 21.0.1+12-29, mixed mode, sharing)

Given the original dmg directory structure I tried?

jpackage -n rt -t dmg --runtime-image rt/jdk-22.0.1.jdk/Contents/Home

For some reason this dmg would?t open.

Is my usage incorrect or dmg not actually the type that should be used for this?





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250226/281c5bb9/attachment-0001.htm>

From bchristi at openjdk.org  Thu Feb 27 00:15:53 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 27 Feb 2025 00:15:53 GMT
Subject: RFR: 8204868: java/util/zip/ZipFile/TestCleaner.java still fails
 with "cleaner failed to clean zipfile."
In-Reply-To: <SagoNViasiREITln_earADUSLDTN9stD2UAJotnE1d4=.b9f76665-937c-4d7d-b33e-5e304cfce189@github.com>
References: <SagoNViasiREITln_earADUSLDTN9stD2UAJotnE1d4=.b9f76665-937c-4d7d-b33e-5e304cfce189@github.com>
Message-ID: <HR8t88btBBBZVDpHEYnYYUnZQ-DdoGPJfcfODhtzK8A=.a013e67b-1367-4a94-aab6-7264a7545521@github.com>

On Mon, 24 Feb 2025 05:50:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address an intermittent failure in the `test/jdk/java/util/zip/ZipFile/TestCleaner.java` test?
> 
> This test does operations on Inflater/Deflater/ZipFile and  closes those instances and then waits for GC to kick in. After wait for a second, it then checks that the underlying resources held by these instances have been cleaned (by the Cleaner).
> 
> Once in a while, we have noticed that this test fails because the resources haven't been cleaned. I suspect this is because within the (fixed) 1 second wait time, the Cleaner hasn't yet invoked the cleaning action for these instances.
> 
> The commit in this PR updates the test to run it in `othervm` so that the Cleaner actions aren't delayed by any other test or code that might have previously run on the `agentvm`. Furthermore, the test is also updated to the use the `ForceGC` test util which takes into account the jtreg test timeout factor for deciding how long to wait for the Cleaner to initiate the cleaning action. Our CI is configured with a timeout factor of 4, so with this change, instead of a fixed maximum 1 second wait time, the test will now wait a maximum of 4 seconds for the cleaner action to be invoked.
> 
> The test continues to pass with this change, even with a repeat execution of 50 runs.

> There is discussion happening in #22165 about perhaps adding a facility that would also provide a reliable solution to this problem.

If we end up with such a facility, perhaps `ForceGC` could be reworked to use it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23742#issuecomment-2686489930

From xgong at openjdk.org  Thu Feb 27 01:39:58 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 27 Feb 2025 01:39:58 GMT
Subject: RFR: 8350682 [JMH] vector.IndexInRangeBenchmark failed with IOOBE
In-Reply-To: <a1_5DZ8fmibdpMXTNaQEzF2q4ExfqGVpxfKxTIjAPgc=.5aba77b1-53a8-4d50-8622-959d163592c0@github.com>
References: <a1_5DZ8fmibdpMXTNaQEzF2q4ExfqGVpxfKxTIjAPgc=.5aba77b1-53a8-4d50-8622-959d163592c0@github.com>
Message-ID: <AnbPIwxt7j-xl7_AjQgDzqb-p72rrCsaqWJ0xF7qEa8=.41a26ab7-18bc-4539-b594-c6ec2a0de7c6@github.com>

On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> Array initialization by parameter was added. Extra constant was used to align cycle step with used arrays.

Marked as reviewed by xgong (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23783#pullrequestreview-2646330008

From xgong at openjdk.org  Thu Feb 27 01:39:58 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 27 Feb 2025 01:39:58 GMT
Subject: RFR: 8350682 [JMH] vector.IndexInRangeBenchmark failed with IOOBE
In-Reply-To: <st1aQDRx0Z8tJKjA9O3492z8GFnV9e0g5FZtyiKk2d4=.873771e8-c4f9-4f8c-aeec-453cfa60e72a@github.com>
References: <a1_5DZ8fmibdpMXTNaQEzF2q4ExfqGVpxfKxTIjAPgc=.5aba77b1-53a8-4d50-8622-959d163592c0@github.com>
 <st1aQDRx0Z8tJKjA9O3492z8GFnV9e0g5FZtyiKk2d4=.873771e8-c4f9-4f8c-aeec-453cfa60e72a@github.com>
Message-ID: <JfapO5NmKVDBwoI18ZKoeEXVfCxhhiGwOjqS9vP5dOM=.b312d066-f5ec-4996-8aa3-4197e92d589e@github.com>

On Wed, 26 Feb 2025 16:25:46 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> Yes, exceptions reported for runs with size=1024. The test support max size=512 and have no checks for passed params.

The change makes sense to me. Thanks for your fixing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23783#issuecomment-2686586708

From duke at openjdk.org  Thu Feb 27 01:54:56 2025
From: duke at openjdk.org (Nicole Xu)
Date: Thu, 27 Feb 2025 01:54:56 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException
In-Reply-To: <z9kfMe4n2F1-bfTSNFATXVEBeMCUWx0eya6zelKq0eI=.461fb031-4a24-4afd-b948-1b67155f1161@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <ljxrhzoRck0LUkRbHYC_0hfPXiW_L1vuw0K7B8lKUKY=.fea555f9-651a-47a1-8c98-b33470d85a8b@github.com>
 <ikTvrFILQiZVSo1YUW_Sc3k3ifMin9UN2eHpcscdcmQ=.eddf8a3c-9e82-40b9-bfca-c79a9d69902d@github.com>
 <z9kfMe4n2F1-bfTSNFATXVEBeMCUWx0eya6zelKq0eI=.461fb031-4a24-4afd-b948-1b67155f1161@github.com>
Message-ID: <iJ-Qe7oIF7TxO-ioss-GSmsUNlYhdkxKAhwn4BjFzN0=.de152a07-6f07-4f9a-a13c-b08de138b006@github.com>

On Mon, 17 Feb 2025 10:43:36 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Hi @eme64, do you see any risks here? Would you please help to review the patch? Thanks.
>
> @xyyNicole @jatin-bhateja I think it is reasonable to just fix the benchmark so that it still has the same behaviour, just without the out-of-bounds exception. @jatin-bhateja you originally wrote the benchmark, and it could make sense if you fixed it up to what it should be more ideally. @xyyNicole I propose that we file a follow-up RFE to fix the benchmark, and just mention that issue in the benchmark.
> 
> What do you think?

Hi, @eme64, do you have any additional comments for this patch? Is it ready to be merged?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2686604173

From xgong at openjdk.org  Thu Feb 27 01:59:00 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 27 Feb 2025 01:59:00 GMT
Subject: RFR: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due
 to IndexOutOfBoundsException [v2]
In-Reply-To: <3zzpTrqxv5KaBP-FKCAWjfffVonoWr9fKE6S8lO-cTY=.48f4cb20-f9e6-473f-8156-18d1694e7496@github.com>
References: <EM3ciBJiM3Zxhvp9Q6PgB236xTg_Fa9m_EUtPhLq-KU=.3a9caa1d-88d1-4cba-9c2f-aca1c0c6f93e@github.com>
 <3zzpTrqxv5KaBP-FKCAWjfffVonoWr9fKE6S8lO-cTY=.48f4cb20-f9e6-473f-8156-18d1694e7496@github.com>
Message-ID: <uRuXZKTDw_yz46RIk4SnMPkV50QBqe_eB3XZDWPJnsI=.8167126d-3001-4b66-8b57-d02225440436@github.com>

On Wed, 26 Feb 2025 07:04:58 GMT, Nicole Xu <duke at openjdk.org> wrote:

>> Suite `MaskedLogicOpts.maskedLogicOperationsLong512()` failed on both x86 and AArch64 with the following error:
>> 
>> 
>> java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
>> 
>> 
>> The variable `long256_arr_idx` is misused when indexing `LongVector l2`, `l3`, `l4`, `l5` in function `maskedLogicOperationsLongKernel()` resulting in the IndexOutOfBoundsException error. On the other hand, the unified index for 128-bit, 256-bit and 512-bit species might not be proper since it leaves gaps in between when accessing the data for 128-bit and 256-bit species. This will unnecessarily include the noise due to cache misses or (on some targets) prefetching additional cache lines which are not usable, thereby impacting the crispness of microbenchmark.
>> 
>> Hence, we improved the benchmark from several aspects,
>> 1. Used sufficient number of predicated operations within the vector loop while minimizing the noise due to memory operations.
>> 2. Modified the index computation logic which can now withstand any ARRAYLEN without resulting in an IOOBE.
>> 3. Removed redundant vector read/writes to instance fields, thus eliminating significant boxing penalty which translates into throughput gains.
>
> Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException
>    
>    Suite MaskedLogicOpts.maskedLogicOperationsLong512() failed on both x86
>    and AArch64 with the following error:
>    
>    ```
>    java.lang.IndexOutOfBoundsException: Index 252 out of bounds for length 249
>    ```
>    
>    The variable `long256_arr_idx` is misused when indexing `LongVector l2`,
>    `l3`, `l4`, `l5` in function `maskedLogicOperationsLongKernel()`
>    resulting in the IndexOutOfBoundsException error. On the other hand, the
>    unified index for 128-bit, 256-bit and 512-bit species might not be
>    proper since it leaves gaps in between when accessing the data
>    for 128-bit and 256-bit species. This will unnecessarily include the
>    noise due to cache misses or (on some targets) prefetching additional
>    cache lines which are not usable, thereby impacting the crispness of
>    microbenchmark.
>    
>    Hence, we improved the benchmark from several aspects,
>    1. Used sufficient number of predicated operations within the vector
>    loop while minimizing the noise due to memory operations.
>    2. Modified the index computation logic which can now withstand any
>    ARRAYLEN without resulting in an IOOBE.
>    3. Removed redundant vector read/writes to instance fields, thus
>    eliminating significant boxing penalty which translates into throughput
>    gains.
>    
>    Change-Id: Ie8a9d495b1ca5e36f1eae069ff70a815a2de00c0
>  - Revert "8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException"
>    
>    This reverts commit 083bedec04d5ab78a420e156e74c1257ce30aee8.

Still looks good to me!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22963#issuecomment-2686608157

From asemenyuk at openjdk.org  Thu Feb 27 02:36:56 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 27 Feb 2025 02:36:56 GMT
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <AF89236A-84C2-481D-8A1A-95596C27AE1D@gmail.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <AF89236A-84C2-481D-8A1A-95596C27AE1D@gmail.com>
Message-ID: <TlvQzvzAvExG0dtuqjyT7CegIBi5JY9_jdQBxxr82yw=.19e394f5-223c-4ba5-b55d-55127da3f1d6@github.com>

On Wed, 26 Feb 2025 23:27:46 GMT, Michael Hall <mik3hall at gmail.com> wrote:

> My opinion would still be that the warning should always be used since the parameter isn?t valid in this usage and not doing anything. If my understanding is in fact correct. Not a strong objection though.

Understood. We don't have common ground here, but given you don't have a strong objection, I'll proceed with the change as is unless somebody speaks out in the next couple of days.

> I copied my current /Library/Java/JavaVirtualMachines/jdk-22.0.1.jdk to a rt directory and ran?

What version of jackage did you use?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23752#issuecomment-2686701902

From mik3hall at gmail.com  Thu Feb 27 02:51:09 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 26 Feb 2025 20:51:09 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <TlvQzvzAvExG0dtuqjyT7CegIBi5JY9_jdQBxxr82yw=.19e394f5-223c-4ba5-b55d-55127da3f1d6@github.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <AF89236A-84C2-481D-8A1A-95596C27AE1D@gmail.com>
 <TlvQzvzAvExG0dtuqjyT7CegIBi5JY9_jdQBxxr82yw=.19e394f5-223c-4ba5-b55d-55127da3f1d6@github.com>
Message-ID: <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>



> On Feb 26, 2025, at 8:36?PM, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:
> 
> On Wed, 26 Feb 2025 23:27:46 GMT, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> My opinion would still be that the warning should always be used since the parameter isn?t valid in this usage and not doing anything. If my understanding is in fact correct. Not a strong objection though.
> 
> Understood. We don't have common ground here, but given you don't have a strong objection, I'll proceed with the change as is unless somebody speaks out in the next couple of days.
> 
>> I copied my current /Library/Java/JavaVirtualMachines/jdk-22.0.1.jdk to a rt directory and ran?
> 
> What version of jackage did you use?
> 

jpackage --version
22.0.1


From mik3hall at gmail.com  Thu Feb 27 02:54:50 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 26 Feb 2025 20:54:50 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <AF89236A-84C2-481D-8A1A-95596C27AE1D@gmail.com>
 <TlvQzvzAvExG0dtuqjyT7CegIBi5JY9_jdQBxxr82yw=.19e394f5-223c-4ba5-b55d-55127da3f1d6@github.com>
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
Message-ID: <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>



> On Feb 26, 2025, at 8:51?PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Feb 26, 2025, at 8:36?PM, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:
>> 
>> On Wed, 26 Feb 2025 23:27:46 GMT, Michael Hall <mik3hall at gmail.com> wrote:
>> 
>>> My opinion would still be that the warning should always be used since the parameter isn?t valid in this usage and not doing anything. If my understanding is in fact correct. Not a strong objection though.
>> 
>> Understood. We don't have common ground here, but given you don't have a strong objection, I'll proceed with the change as is unless somebody speaks out in the next couple of days.
>> 
>>> I copied my current /Library/Java/JavaVirtualMachines/jdk-22.0.1.jdk to a rt directory and ran?
>> 
>> What version of jackage did you use?
>> 
> 
> jpackage --version
> 22.0.1

Verbose shows?

 Running /usr/bin/osascript
[20:53:15.974] Command [PID: 63430]:
    /usr/bin/osascript /var/folders/mp/64527rf1501726r7t53qpx0w0000gn/T/jdk.jpackage8494515577643747753/config/rt-dmg-setup.scpt
[20:53:15.974] Output:
    /var/folders/mp/64527rf1501726r7t53qpx0w0000gn/T/jdk.jpackage8494515577643747753/config/rt-dmg-setup.scpt:2769:2798: execution error: Finder got an error: {container window of disk "rt"} doesn?t understand the ?close? message. (-1708)
[20:53:15.974] Returned: 1

[20:53:15.975] java.io.IOException: Command [/usr/bin/osascript, /var/folders/mp/64527rf1501726r7t53qpx0w0000gn/T/jdk.jpackage8494515577643747753/config/rt-dmg-setup.scpt] exited with 1 code
	at jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:90)
	at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:229)
	at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:207)
	at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:186)
	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:403)
	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:90)
	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:578)
	at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:714)
	at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:561)
	at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:92)
	at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250226/73e16251/attachment-0001.htm>

From almatvee at openjdk.org  Thu Feb 27 03:01:32 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 27 Feb 2025 03:01:32 GMT
Subject: RFR: 8347139: [macos] Test tools/jpackage/share/InOutPathTest.java
 failed:  "execution error: Finder got an error: AppleEvent timed out."
Message-ID: <4mb74SEfiSr7QW_oKrGbOk20dz1qhCJwiJTjmsWv9aM=.a4730050-a0ad-4f1d-8221-99b61e37fd78@github.com>

- Fixed by increasing test timeout. Fix verified on host which reproduced issue.

-------------

Commit messages:
 - 8347139: [macos] Test tools/jpackage/share/InOutPathTest.java failed: "execution error: Finder got an error: AppleEvent timed out."

Changes: https://git.openjdk.org/jdk/pull/23816/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23816&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347139
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23816.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23816/head:pull/23816

PR: https://git.openjdk.org/jdk/pull/23816

From mik3hall at gmail.com  Thu Feb 27 03:02:34 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 26 Feb 2025 21:02:34 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <AF89236A-84C2-481D-8A1A-95596C27AE1D@gmail.com>
 <TlvQzvzAvExG0dtuqjyT7CegIBi5JY9_jdQBxxr82yw=.19e394f5-223c-4ba5-b55d-55127da3f1d6@github.com>
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
Message-ID: <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>



> On Feb 26, 2025, at 8:54?PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Feb 26, 2025, at 8:51?PM, Michael Hall <mik3hall at gmail.com> wrote:
>> 
>> 
>> 
>>> On Feb 26, 2025, at 8:36?PM, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:
>>> 
>>> On Wed, 26 Feb 2025 23:27:46 GMT, Michael Hall <mik3hall at gmail.com> wrote:
>>> 
>>>> My opinion would still be that the warning should always be used since the parameter isn?t valid in this usage and not doing anything. If my understanding is in fact correct. Not a strong objection though.
>>> 
>>> Understood. We don't have common ground here, but given you don't have a strong objection, I'll proceed with the change as is unless somebody speaks out in the next couple of days.
>>> 
>>>> I copied my current /Library/Java/JavaVirtualMachines/jdk-22.0.1.jdk to a rt directory and ran?
>>> 
>>> What version of jackage did you use?
>>> 
>> 
>> jpackage --version
>> 22.0.1
> 
> Verbose shows?
> 
>  Running /usr/bin/osascript
> [20:53:15.974] Command [PID: 63430]:
>     /usr/bin/osascript /var/folders/mp/64527rf1501726r7t53qpx0w0000gn/T/jdk.jpackage8494515577643747753/config/rt-dmg-setup.scpt
> [20:53:15.974] Output:
>     /var/folders/mp/64527rf1501726r7t53qpx0w0000gn/T/jdk.jpackage8494515577643747753/config/rt-dmg-setup.scpt:2769:2798: execution error: Finder got an error: {container window of disk "rt"} doesn?t understand the ?close? message. (-1708)
> [20:53:15.974] Returned: 1
> 
> [20:53:15.975] java.io.IOException: Command [/usr/bin/osascript, /var/folders/mp/64527rf1501726r7t53qpx0w0000gn/T/jdk.jpackage8494515577643747753/config/rt-dmg-setup.scpt] exited with 1 code
> 	at jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:90)
> 	at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:229)
> 	at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:207)
> 	at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:186)
> 	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.buildDMG(MacDmgBundler.java:403)
> 	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:90)
> 	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:578)
> 	at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:714)
> 	at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:561)
> 	at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:92)
> 	at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53)
> 

I don?t get that if I delete the existing dmg first.

Full verbose output at?

http://mikehall.pairserver.com/rt.txt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250226/a715b59c/attachment.htm>

From mik3hall at gmail.com  Thu Feb 27 03:22:53 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 26 Feb 2025 21:22:53 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <AF89236A-84C2-481D-8A1A-95596C27AE1D@gmail.com>
 <TlvQzvzAvExG0dtuqjyT7CegIBi5JY9_jdQBxxr82yw=.19e394f5-223c-4ba5-b55d-55127da3f1d6@github.com>
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
Message-ID: <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>

> 
> I don?t get that if I delete the existing dmg first.
> 
> Full verbose output at?
> 
> http://mikehall.pairserver.com/rt.txt

That output is from when I specified the path into the jdk image. It did open this time but still not a useable runtime I don?t think.

Using the path to the parent directory of an actual image still gets the extra directory wrappers. 

I can provide verbose output for that or I suppose bug report if wanted.

I?m not positive what the path should actually point to. A directory including a JavaVirtualMachines type image seems intuitively correct.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250226/ccb96bbf/attachment-0001.htm>

From duke at openjdk.org  Thu Feb 27 03:24:52 2025
From: duke at openjdk.org (Nicole Xu)
Date: Thu, 27 Feb 2025 03:24:52 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
 <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
Message-ID: <TTP3f4Io5h3mAVnzOagKY7DtjDTjw9Yomno-TuMUHyA=.d73873e1-0843-4fc9-9478-6ba28c8a4901@github.com>

On Fri, 21 Feb 2025 07:01:42 GMT, Nicole Xu <duke at openjdk.org> wrote:

>> The UnsafeOps JMH benchmark fails with the following error:
>> 
>>       ```
>>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>>       ```
>> 
>> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>> 
>> Note that even it will raise "proprietary API" warnings after this
>> patch, it is acceptable because the relevant APIs are bound for removal
>> for the integrity of the platform.
>
> Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
>    
>    The UnsafeOps JMH benchmark fails with the following error:
>    
>          ```
>          java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>          ```
>    
>    Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>    `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>    
>    Note that even it will raise "proprietary API" warnings after this
>    patch, it is acceptable because the relevant APIs are bound for removal
>    for the integrity of the platform.
>    
>    Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c
>  - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe"
>    
>    This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b.

> Would it be possible to configure the build of the microbenchmarks to not pass `-Werror`, so they don't break when sunapi diagnostics are emitted?
> 
> > Note that even it will raise "proprietary API" warnings after this patch, it is acceptable because the relevant APIs are bound for removal for the integrity of the platform.
> 
> It will not raise those diagnostics today, because they don't work for this compilation due to [JDK-8349846](https://bugs.openjdk.org/browse/JDK-8349846). If that issue is fixed again it would break the build of these benchmarks, e.g. with [1ab1c1d](https://github.com/openjdk/jdk/commit/1ab1c1d53b86228be85aac96fa5d69db39ac6317) backed out and with this change it would fail with:
> 
> ```
> test/micro/org/openjdk/bench/sun/misc/UnsafeOps.java:27: warning: Unsafe is internal proprietary API and may be removed in a future release
> import sun.misc.Unsafe;
>                ^
> ...
> error: warnings found and -Werror specified
> ```

Thank you for your comments. I understand your concerns about potential "proprietary API" warnings if we revert to using `sun.misc.Unsafe`. However, this specific microbenchmark is designed for `sun.misc.Unsafe`, not `jdk.internal.misc.Unsafe`.

For the "proprietary API" warning, while not passing `-Werror` during the build process for the microbenchmarks could have broad implications, I wonder if we could take a more targeted approach. Would it be possible to exclude just this particular microbenchmark from sunapi diagnostics?

@AlanBateman @liach Do you have any comments on that? I'd appreciate your inputs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2686755067

From liach at openjdk.org  Thu Feb 27 04:36:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 04:36:52 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <jkfg-8kwY2Qo_XUFl99EWMrK905F3ux87d3Znr8PCFI=.81a52252-0109-4156-aa48-fd9620f0757e@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
 <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
 <jkfg-8kwY2Qo_XUFl99EWMrK905F3ux87d3Znr8PCFI=.81a52252-0109-4156-aa48-fd9620f0757e@github.com>
Message-ID: <EzD4monwCJmqsFmlp9BL38TphkCHdzR_kJa7lrIOQR0=.351eddbe-a489-4549-b918-d2e9218b2e6c@github.com>

On Wed, 26 Feb 2025 12:13:59 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
>>    
>>    The UnsafeOps JMH benchmark fails with the following error:
>>    
>>          ```
>>          java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>>          ```
>>    
>>    Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>>    `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>>    
>>    Note that even it will raise "proprietary API" warnings after this
>>    patch, it is acceptable because the relevant APIs are bound for removal
>>    for the integrity of the platform.
>>    
>>    Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c
>>  - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe"
>>    
>>    This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b.
>
> Would it be possible to configure the build of the microbenchmarks to not pass `-Werror`, so they don't break when sunapi diagnostics are emitted?
> 
>> Note that even it will raise "proprietary API" warnings after this patch, it is acceptable because the relevant APIs are bound for removal for the integrity of the platform.
> 
> It will not raise those diagnostics today, because they don't work for this compilation due to [JDK-8349846](https://bugs.openjdk.org/browse/JDK-8349846). If that issue is fixed again it would break the build of these benchmarks, e.g. with 1ab1c1d53b86228be85aac96fa5d69db39ac6317 backed out and with this change it would fail with:
> 
> 
> test/micro/org/openjdk/bench/sun/misc/UnsafeOps.java:27: warning: Unsafe is internal proprietary API and may be removed in a future release
> import sun.misc.Unsafe;
>                ^
> ...
> error: warnings found and -Werror specified

Hi @cushon, I believe disabling `JAVA_WARNINGS_ARE_ERRORS` should be done as part of those javac patches instead of part of this patch. We cannot verify such an addition in this patch, and it will just cause meaningless extra review and update cycles.

This flag is defined at https://github.com/openjdk/jdk/blob/964dd18fd2ba998e5c1efed48e15e516b0c22b19/make/common/JavaCompilation.gmk#L268. Unfortunately I don't know about make well enough to say what's the best way to disable this for micro build.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2686877434

From epeter at openjdk.org  Thu Feb 27 06:57:04 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 27 Feb 2025 06:57:04 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <DvPOVOuqVlNY-0K5E201YQgKmguBMpJDQw2h1myD8S0=.81a46beb-90fa-4417-a9b2-9d3ebc746538@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
 <wDsCyP79rQ4dN3G6lMjZliTn6ym5-HwjGZ-Y-Xx_vQY=.0a187197-7505-4c95-a6cd-8b8eea0bea88@github.com>
 <DvPOVOuqVlNY-0K5E201YQgKmguBMpJDQw2h1myD8S0=.81a46beb-90fa-4417-a9b2-9d3ebc746538@github.com>
Message-ID: <63F-0aHgMthexL0b2DFmkW8_QrJeo8OOlCaIyZApfpY=.4744070d-9d56-4031-8684-be14cf66d1e5@github.com>

On Wed, 26 Feb 2025 18:29:58 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>>> > Re: [#20098 (comment)](https://github.com/openjdk/jdk/pull/20098#issuecomment-2671144644) - I was trying to think what could be causing this.
>>> 
>>> Maybe it is an issue with probabilities? Do you know at what point (if at all) the `MinI` node appears/disappears in that example?
>> 
>> The probabilities are fine.
>> 
>> I think the issue with `Math.min(II)` seems to be specific to when its compilation happens, and the combined fact that the intrinsic has been disabled and vectorization does not kick in (explicitly disabled). Note that other parts of the JDK invoke `Math.min(II)`.
>> 
>> In the slow cases it appears the compilation happens before the benchmark kicks in, and so it takes the profiling data before the benchmark to decide how to compile this in.
>> 
>> In the slow versions you see this `PrintMethodData`:
>> 
>> static java.lang.Math::min(II)I
>>   interpreter_invocation_count:       18171
>>   invocation_counter:                 18171
>>   backedge_counter:                       0
>>   decompile_count:                        0
>>   mdo size: 328 bytes
>> 
>>    0 iload_0
>>    1 iload_1
>>    2 if_icmpgt 9
>>   0    bci: 2    BranchData         taken(7732) displacement(56)
>>                                     not taken(10180)
>>    5 iload_0
>>    6 goto 10
>>   32   bci: 6    JumpData           taken(10180) displacement(24)
>>    9 iload_1
>>   10 ireturn
>> 
>> org.openjdk.bench.java.lang.MinMaxVector::intReductionSimpleMin(Lorg/openjdk/bench/java/lang/MinMaxVector$LoopState;)I
>>   interpreter_invocation_count:         189
>>   invocation_counter:                   189
>>   backedge_counter:                  313344
>>   decompile_count:                        0
>>   mdo size: 384 bytes
>> 
>>    0 iconst_0
>>    1 istore_2
>>    2 iconst_0
>>    3 istore_3
>>    4 iload_3
>>    5 aload_1
>>    6 fast_igetfield 35 <org/openjdk/bench/java/lang/MinMaxVector$LoopState.size:I>
>>    9 if_icmpge 33
>>   0    bci: 9    BranchData         taken(58) displacement(72)
>>                                     not taken(192512)
>>   12 aload_1
>>   13 fast_agetfield 41 <org/openjdk/bench/java/lang/MinMaxVector$LoopState.minIntA:[I>
>>   16 iload_3
>>   17 iaload
>>   18 istore #4
>>   20 iload_2
>>   21 fast_iload #4
>>   23 invokestatic 32 <java/lang/Math.min(II)I>
>>   32   bci: 23   CounterData        count(192512)
>>   26 istore_2
>>   27 iinc #3 1
>>   30 goto 4
>>   48   bci: 30   JumpData           taken(192512) displacement(-48)
>>   33 iload_2
>>   34 ireturn
>> 
>> 
>> The benchmark method calls Math...
>
>> > That said: if we know that it is only in the high-probability cases, then we can address those separately. I would not consider it a blocking issue, as long as we file the follow-up RFE for int/max scalar case with high branch probability.
>> > What would be really helpful: a list of all regressions / issues, and how we intend to deal with them. If we later find a regression that someone cares about, then we can come back to that list, and justify the decision we made here.
>> 
>> I'll make up a list of regressions and post it here. I won't create RFEs for now. I'd rather wait until we have the list in front of us and we can decide which RFEs to create.
> 
> Before noting the regressions, it's worth noting that PR also improves performance certain scenarios. I will summarise those tomorrow.
> 
> Here's a summary of the regressions
> 
> ### Regression 1
> Given a loop with a long min/max reduction pattern with one side of branch taken near 100% of time, when Supeword finds the pattern not profitable, then HotSpot will use scalar instructions (cmov) and performance will regress.
> 
> Possible solutions:
> a) make Superword recognise these scenarios as profitable.
> 
> ### Regression 2
> Given a loop with a long min/max reduction pattern with one side of branch near 100% of time, when the platform does not support vector instructions to achieve this (e.g. AVX-512 quad word vpmax/vpmin), then HotSpot will use scalar instructions (cmov) and performance will regress.
> 
> Possible solutions
> a) find a way to use other vector instructions (vpcmp+vpblend+vmov?)
> b) fallback on more suitable scalar instructions, e.g. cmp+mov, when the branch is very one-sided
> 
> ### Regression 3
> Given a loop with a long min/max non-reduction pattern (e.g. `longLoopMax`) with one side of branch taken near 100% of time, when the platform does not vectorize it (either lack of CPU instruction support, or Superword finding not profitable), then HotSpot will use scalar instructions (cmov) and performance will regress.
> 
> Possible solutions:
> a) find a way to use other vector instructions (e.g. `longLoopMax` vectorizes with AVX2 and might also do with earlier instruction sets)
> b) fallback on more suitable scalar instructions, e.g. cmp+mov, when the branch is very one-sided,

@galderz Thanks for the summary of regressions! Yes, there are plenty of speedups, I assume primarily because of `Long.min/max` vectorization, but possibly also because the operation can now "float" out of a loop for example.

All your Regressions 1-3 are cases with "extreme" probabilitiy (close to 100% / 0%), you listed none else. That matches with my intuition, that branching code is usually better than cmove in extreme probability cases.

As for possible solutions. In all Regression 1-3 cases, it seems the issue is scalar cmove. So actually in all cases a possible solution is using branching code (i.e. `cmp+mov`). So to me, these are the follow-up RFE's:
- Detect "extreme" probability scalar cmove, and replace them with branching code. This should take care of all regressions here. This one has high priority, as it fixes the regression caused by this patch here. But it would also help to improve performance for the `Integer.min/max` cases, which have the same issue.
- Additional performance improvement: make SuperWord recognize more cases as profitble (see Regression 1). Optional.
- Additional performance improvement: extend backend capabilities for vectorization (see Regression 2 + 3). Optional.

Does that make sense, or am I missing something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2687067125

From xgong at openjdk.org  Thu Feb 27 06:58:33 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 27 Feb 2025 06:58:33 GMT
Subject: RFR: 8350748: VectorAPI: Method "checkMaskFromIndexSize" should be
 force inlined
Message-ID: <18Q2Zl2ip_eFS_Y4fflgS8XYBkbwCZ468DIjP3KwhDE=.240f4182-4b02-4fac-97c8-ac659427e4a8@github.com>

Method `checkMaskFromIndexSize` is called by some vector masked APIs like `fromArray/intoArray/fromMemorySegment/...`. It is used to check whether the index of any active lanes in a mask will reach out of the boundary of the given Array/MemorySegment. This function should be force inlined, or a VectorMask object is generated once the function call is not inlined by C2 compiler, which affects the API performance a lot.

This patch changed to call the `VectorMask.checkFromIndexSize` method directly inside of these APIs instead of `checkMaskFromIndexSize`. Since it has added the `@ForceInline` annotation already, it will be inlined and intrinsified by C2. And then the expected vector instructions can be generated. With this change, the unused `checkMaskFromIndexSize` can be removed.

Performance of some JMH benchmarks can improve up to 14x on a NVIDIA Grace CPU (AArch64 SVE2, 128-bit vectors). We can also observe the similar performance improvement on a Intel CPU which supports AVX512.

Following is the performance data on Grace:


Benchmark                                             Mode  Cnt  Units     Before      After   Gain
LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE      thrpt   30  ops/ms  31544.304  31610.598  1.002
LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE    thrpt   30  ops/ms   3896.202   3903.249  1.001
LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE     thrpt   30  ops/ms    570.415   7174.320  12.57
LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE       thrpt   30  ops/ms    566.694   7193.520  12.69
LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE      thrpt   30  ops/ms   3899.269   3878.258  0.994
LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE     thrpt   30  ops/ms   1134.301  16053.847  14.15
StoreMaskedIOOBEBenchmark.byteStoreArrayMaskIOOBE    thrpt   30  ops/ms  26449.558  28699.480  1.085
StoreMaskedIOOBEBenchmark.doubleStoreArrayMaskIOOBE  thrpt   30  ops/ms   1922.167   5781.077  3.007
StoreMaskedIOOBEBenchmark.floatStoreArrayMaskIOOBE   thrpt   30  ops/ms   3784.190  11789.276  3.115
StoreMaskedIOOBEBenchmark.intStoreArrayMaskIOOBE     thrpt   30  ops/ms   3694.082  15633.547  4.232
StoreMaskedIOOBEBenchmark.longStoreArrayMaskIOOBE    thrpt   30  ops/ms   1966.956   6049.790  3.075
StoreMaskedIOOBEBenchmark.shortStoreArrayMaskIOOBE   thrpt   30  ops/ms   7647.309  27412.387  3.584

-------------

Commit messages:
 - 8350748: VectorAPI: Method "checkMaskFromIndexSize" should be force inlined

Changes: https://git.openjdk.org/jdk/pull/23817/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23817&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350748
  Stats: 213 lines in 7 files changed: 36 ins; 140 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/23817.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23817/head:pull/23817

PR: https://git.openjdk.org/jdk/pull/23817

From alan.bateman at oracle.com  Thu Feb 27 08:10:21 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Thu, 27 Feb 2025 08:10:21 +0000
Subject: adding Xalan's XSL 3 implementation within jdk
In-Reply-To: <CABuuzNO58-iNcaE29133FUWVpz9jH-sCXfQQAZHu_eUiL_oeoA@mail.gmail.com>
References: <CABuuzNP66-_d7J=UKz2UBY17V2eVk=xvB5w4bRj4A5aEaDQXcw@mail.gmail.com>
 <CABuuzNPKrdhGyqD-FEP-SU7MS4T_7h1smMBg31G9V2LHcPoq=g@mail.gmail.com>
 <e6c986db-9816-4172-9589-e6ce08674dae@oracle.com>
 <CABuuzNO58-iNcaE29133FUWVpz9jH-sCXfQQAZHu_eUiL_oeoA@mail.gmail.com>
Message-ID: <e48ea4d7-2a5b-4d4a-8175-7f1201f2db9a@oracle.com>



On 26/02/2025 15:59, Mukul Gandhi wrote:
> Hi Alan,
>      I've just seen this mail from you. Apologies for a delayed response.
>
> My mail box has had few issues due to the volume of mails that I get
> from mailing lists.
>
> On Sun, Feb 2, 2025 at 9:38?PM Alan Bateman<alan.bateman at oracle.com>  wrote:
>
>> The stats for that branch suggest 5,845 changed files with 234,372 additions and 84,058 deletions. I can't easily tell how much of this would need to come into the jdk repo but this looks like a major update. If only 10% of this is applicable to the JDK then it still needs seems like a major update that would require a huge investment to audit and integrate this code. How much XML is in new applications developed in 2025? Only asking because it's an area that is surely much lower priority compared to all the other major investments right now. Maybe there are useful security or performance changes that would be useful to cherry pick instead? Finally, does this Xalan update work with the SPIs so that someone really looking for XSL 3 can just deploy it on the class path and module path?
> Ofcourse, anyone could use Xalan-J's XSL 3 implementation with JDK by
> placing Xalan jars on class path & module path.
Can you clarify if this is using javax.xml APIs, with Xalan-J deployed 
as an implementation, or this some Xalan-J specific API?

> Since Xalan-J's XSLT 1.0 & XPath 1.0 implementations are already
> available within JDK, I thought its natural if JDK could pick
> Xalan-J's XSL 3 implementation and include that within JDK.
Are you sure that developers are clamoring to develop new code that uses 
XML and XSL 3? It would require a big investment by JDK maintainers to 
audit and review this huge volume of code. The priorities for the XML 
APIs/implementation right now are on making XML processing be secure by 
default and bringing sanity to the configuration of applications that 
still use XML. This is the reason for the incremental improvements in 
recent releases.

If you are interested in contributing to the XML implementations in the 
java.xml module then this would be welcomed. It's always better to start 
small with bug fixes, test improvements and other changes to get used to 
working in this project and build up confidence that you are someone 
that is interested in maintaining this area in the long term.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250227/b1d476c9/attachment.htm>

From alanb at openjdk.org  Thu Feb 27 08:40:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Feb 2025 08:40:01 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
In-Reply-To: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
Message-ID: <C-MYCDaVr2YJLZHDABKKZ784_rLxla6e6hUYxv9oa9U=.a69932b7-f057-4b67-bbd7-f49aac88a28b@github.com>

On Wed, 26 Feb 2025 15:47:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> While testing a bit with a minimal JVM, it has been noticed that some java/lang jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .

test/jdk/java/lang/Thread/ThreadSleepEvent.java line 28:

> 26:  * @summary Test that Thread.sleep emits a JFR jdk.ThreadSleep event
> 27:  * @requires vm.hasJFR
> 28:  * @modules jdk.jfr

These tests already have `@modules jdk.jfr` so the tests won't be selected by jtreg to execute when the JDK under test doesn't have this module. I realize `vm.hasJFR` is whether the VM has been built with JFR included but it seems a bit strange to have a JDK containing `jdk.jfr` but not supporting JFR. So I'm curious what is being tested. Is this a run-time image that contains more than one VM, maybe everything in the "server VM" and also the minimal VM?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23805#discussion_r1973117512

From mbaesken at openjdk.org  Thu Feb 27 08:45:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Feb 2025 08:45:52 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
In-Reply-To: <C-MYCDaVr2YJLZHDABKKZ784_rLxla6e6hUYxv9oa9U=.a69932b7-f057-4b67-bbd7-f49aac88a28b@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <C-MYCDaVr2YJLZHDABKKZ784_rLxla6e6hUYxv9oa9U=.a69932b7-f057-4b67-bbd7-f49aac88a28b@github.com>
Message-ID: <PXb8sEre4Eb6HduJpADX6bfvY9oP8LzF_7oMmm8vJAk=.087b442f-360a-4d00-b3a7-3e261b82829a@github.com>

On Thu, 27 Feb 2025 08:36:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> While testing a bit with a minimal JVM, it has been noticed that some java/lang jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .
>
> test/jdk/java/lang/Thread/ThreadSleepEvent.java line 28:
> 
>> 26:  * @summary Test that Thread.sleep emits a JFR jdk.ThreadSleep event
>> 27:  * @requires vm.hasJFR
>> 28:  * @modules jdk.jfr
> 
> These tests already have `@modules jdk.jfr` so the tests won't be selected by jtreg to execute when the JDK under test doesn't have this module. I realize `vm.hasJFR` is whether the VM has been built with JFR included but it seems a bit strange to have a JDK containing `jdk.jfr` but not supporting JFR. So I'm curious what is being tested. Is this a run-time image that contains more than one VM, maybe everything in the "server VM" and also the minimal VM?

A minimal JVM (**--with-jvm-features=minimal --with-jvm-variants=minimal**) is tested.  This contains no JFR in Hotspot.
If you configure the build without JVM feature JFR (like minimal) ,  the tests need the correct requires tags; most tests have this but some not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23805#discussion_r1973130489

From alanb at openjdk.org  Thu Feb 27 08:52:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Feb 2025 08:52:02 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
In-Reply-To: <PXb8sEre4Eb6HduJpADX6bfvY9oP8LzF_7oMmm8vJAk=.087b442f-360a-4d00-b3a7-3e261b82829a@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <C-MYCDaVr2YJLZHDABKKZ784_rLxla6e6hUYxv9oa9U=.a69932b7-f057-4b67-bbd7-f49aac88a28b@github.com>
 <PXb8sEre4Eb6HduJpADX6bfvY9oP8LzF_7oMmm8vJAk=.087b442f-360a-4d00-b3a7-3e261b82829a@github.com>
Message-ID: <lK8OE6nUsQnMkSzAEEA8cR7nddUjlj91pt11HpNJO2Y=.c3113ec2-d158-45d2-ba31-e441355ffa75@github.com>

On Thu, 27 Feb 2025 08:43:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/ThreadSleepEvent.java line 28:
>> 
>>> 26:  * @summary Test that Thread.sleep emits a JFR jdk.ThreadSleep event
>>> 27:  * @requires vm.hasJFR
>>> 28:  * @modules jdk.jfr
>> 
>> These tests already have `@modules jdk.jfr` so the tests won't be selected by jtreg to execute when the JDK under test doesn't have this module. I realize `vm.hasJFR` is whether the VM has been built with JFR included but it seems a bit strange to have a JDK containing `jdk.jfr` but not supporting JFR. So I'm curious what is being tested. Is this a run-time image that contains more than one VM, maybe everything in the "server VM" and also the minimal VM?
>
> A minimal JVM (**--with-jvm-features=minimal --with-jvm-variants=minimal**) is tested.  This contains no JFR in Hotspot.
> If you configure the build without JVM feature JFR (like minimal) ,  the tests need the correct requires tags; most tests have this but some not.

If the only VM to be built is the minimal VM then maybe it should filter down the set of modules to include. Just saying that it's a bit strange to include the `jdk.jfr` module but not support JFR, if you see what I mean.

BTW: I don't object to the change, it's just means that any test using the JFR APIs has to say so twice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23805#discussion_r1973140230

From mbaesken at openjdk.org  Thu Feb 27 09:15:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Feb 2025 09:15:03 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
In-Reply-To: <lK8OE6nUsQnMkSzAEEA8cR7nddUjlj91pt11HpNJO2Y=.c3113ec2-d158-45d2-ba31-e441355ffa75@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <C-MYCDaVr2YJLZHDABKKZ784_rLxla6e6hUYxv9oa9U=.a69932b7-f057-4b67-bbd7-f49aac88a28b@github.com>
 <PXb8sEre4Eb6HduJpADX6bfvY9oP8LzF_7oMmm8vJAk=.087b442f-360a-4d00-b3a7-3e261b82829a@github.com>
 <lK8OE6nUsQnMkSzAEEA8cR7nddUjlj91pt11HpNJO2Y=.c3113ec2-d158-45d2-ba31-e441355ffa75@github.com>
Message-ID: <-wgA3ZuOnRPwj0WaR2DZdvf-AXIAZYJtfHTNa6CKnNk=.d67aff51-2877-4d26-87e3-320fb989a807@github.com>

On Thu, 27 Feb 2025 08:49:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A minimal JVM (**--with-jvm-features=minimal --with-jvm-variants=minimal**) is tested.  This contains no JFR in Hotspot.
>> If you configure the build without JVM feature JFR (like minimal) ,  the tests need the correct requires tags; most tests have this but some not.
>
> If the only VM to be built is the minimal VM then maybe it should filter down the set of modules to include. Just saying that it's a bit strange to include the `jdk.jfr` module but not support JFR, if you see what I mean.
> 
> BTW: I don't object to the change, it's just means that any test using the JFR APIs has to say so twice.

when I list the modules of the  minimal JVM I see a number of modules that will most likely not work because the related JVM features are not present 


images/jdk/bin/java --list-modules
 ...
jdk.jdi at 25.0.0.1-internal
jdk.jdwp.agent at 25.0.0.1-internal
 ...
jdk.jfr at 25.0.0.1-internal
jdk.management at 25.0.0.1-internal
jdk.management.agent at 25.0.0.1-internal
jdk.management.jfr at 25.0.0.1-internal


The minimal JVM does not  contain e.g. JFR, JVMTI or management  JVM features. So most likely those modules miss basic functionality and will not or not fully work.
But fixing this is most likely out of scope of this PR .
Is there some JVM feature to module  mapping and tool support already, I am not aware of it ? 
Would be nice to have this, because removing unneeded (and not working) modules from the image is probably a good idea.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23805#discussion_r1973177693

From alanb at openjdk.org  Thu Feb 27 09:39:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Feb 2025 09:39:59 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
In-Reply-To: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
Message-ID: <tpEhVcVH1eoYXDEYrSLuyhQ-3ScUo4k6nyqtMKQvm7Q=.706b1372-f8b5-44ef-b9f6-77fc15e94d27@github.com>

On Wed, 26 Feb 2025 15:47:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> While testing a bit with a minimal JVM, it has been noticed that some java/lang jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .

I assume you've bumping the end copyright header date on these before integrating.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23805#pullrequestreview-2647177352

From mbaesken at openjdk.org  Thu Feb 27 10:19:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Feb 2025 10:19:51 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
Message-ID: <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>

> While testing a bit with a minimal JVM, it has been noticed that some java/lang jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  copyright years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23805/files
  - new: https://git.openjdk.org/jdk/pull/23805/files/7117462e..c167dc1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23805&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23805&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23805.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23805/head:pull/23805

PR: https://git.openjdk.org/jdk/pull/23805

From jvernee at openjdk.org  Thu Feb 27 10:30:06 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Feb 2025 10:30:06 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
 <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
Message-ID: <fcsa6WE_4AWLnAloX6hsm-0BDZszbsUfq_En8Ms_Zzk=.faff52ee-0afd-45c0-9d14-25dbedacc7fe@github.com>

On Wed, 26 Feb 2025 19:56:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 74:
>> 
>>> 72:             return ret;
>>> 73:         return computeFilterHandle(index);
>>> 74:     }
>> 
>> Why is this using an array, instead of just having 3 fields?
>
> This emulates how MethodHandleImpl does the cache.

Ok. I think the benefit is that each element is individually lazy initialized. I'm not sure about the setup with the array though. It seems like having 3 stable fields would be simpler? Or maybe just initialize them up front in clinit, since they are mostly used together. That would also avoid the need to create a `Lookup` every time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1973301941

From david at dgregory.dev  Thu Feb 27 10:43:59 2025
From: david at dgregory.dev (David Gregory)
Date: Thu, 27 Feb 2025 10:43:59 +0000
Subject: New candidate JEP: 502: Stable Values (Preview)
In-Reply-To: <da1f77a2-fed8-4439-a83d-bc286234e963@oracle.com>
References: <4eb86dce-e930-4f1a-a46f-3c142af672c7@oracle.com>
 <f3a89c36-3a5d-4dab-b9e7-5a3cc52408dc@dgregory.dev>
 <da1f77a2-fed8-4439-a83d-bc286234e963@oracle.com>
Message-ID: <c200ac74-840d-4922-a120-aa584b2c0647@dgregory.dev>

Hi Maurizio,

On 21/02/2025 18:42, Maurizio Cimadamore wrote:
> There's different meaning for the word "trusted". If, by that, you 
> mean that fields of type StableValue<X> should be trusted the same way 
> that record components are trusted (e.g. where "final" really means 
> "final"), this is something we can do. I believe the prototype we have 
> today does that to some extent -- but we don't know yet whether that 
> "hack" will be made official :-) 

That's awesome! Does creating a StableValue allocate an object, or is 
StableValue optimised away to some bytecode construct by javac?

The reason that I ask is that I wanted to know whether implementers of 
other JVM languages could use this feature - for example, could we mark 
a field as stable using some access modifier at the bytecode level 
without using the StableValue API?

I watched Per's talk at Devoxx and he suggested that it would be 
difficult to allow fields outside of JDK classes to be marked stable for 
security reasons, so I suspect the answer to this is no?

If not, is this a possibility in the future when "trust" and integrity 
of final fields is more fully fleshed out at the JVM level?

I've written up a gist explaining how this feature might be used by 
functional languages, using AtomicReference as a stand-in for 
StableValue, since the API is pretty similar: 
https://gist.github.com/DavidGregory084/6939b85b6fd3ccfdfc83e05011697ed4

The existing StableValue JEP will work great for me personally as the 
translation between my "data" and the underlying JVM classes is not as 
direct as e.g. Scala's case class or Kotlin's data class, and I'd rather 
it was possible to make more programs stack-safe, even if it requires 
allocating lots of StableValues, but I am developing more of a teaching 
language so performance is not exactly paramount for me!

However, it would be great if everybody could get their hands on 
"stable" - e.g. the "next" field in Scala's List cons cell is an amazing 
candidate for stable as it's only mutated immediately after creation, 
like in List#map:

https://github.com/scala/scala/blob/a2090009c4fc3791b545a257ec6d1431e87cb1f4/src/library/scala/collection/immutable/List.scala#L245

Thanks,

David Gregory


From maurizio.cimadamore at oracle.com  Thu Feb 27 11:50:08 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 27 Feb 2025 11:50:08 +0000
Subject: New candidate JEP: 502: Stable Values (Preview)
In-Reply-To: <c200ac74-840d-4922-a120-aa584b2c0647@dgregory.dev>
References: <4eb86dce-e930-4f1a-a46f-3c142af672c7@oracle.com>
 <f3a89c36-3a5d-4dab-b9e7-5a3cc52408dc@dgregory.dev>
 <da1f77a2-fed8-4439-a83d-bc286234e963@oracle.com>
 <c200ac74-840d-4922-a120-aa584b2c0647@dgregory.dev>
Message-ID: <b08044a6-5778-4dc6-ac70-e257201ccd9a@oracle.com>


On 27/02/2025 10:43, David Gregory wrote:
> Hi Maurizio,
>
> On 21/02/2025 18:42, Maurizio Cimadamore wrote:
>> There's different meaning for the word "trusted". If, by that, you 
>> mean that fields of type StableValue<X> should be trusted the same 
>> way that record components are trusted (e.g. where "final" really 
>> means "final"), this is something we can do. I believe the prototype 
>> we have today does that to some extent -- but we don't know yet 
>> whether that "hack" will be made official :-) 
>
> That's awesome! Does creating a StableValue allocate an object, or is 
> StableValue optimised away to some bytecode construct by javac?
>
> The reason that I ask is that I wanted to know whether implementers of 
> other JVM languages could use this feature - for example, could we 
> mark a field as stable using some access modifier at the bytecode 
> level without using the StableValue API?

It creates an object. One of the areas we'd like to explore some more is 
the Leyden connection -- maybe some of these objects can be eliminated 
if we know what they are set to (e.g. during a training run).


>
> I watched Per's talk at Devoxx and he suggested that it would be 
> difficult to allow fields outside of JDK classes to be marked stable 
> for security reasons, so I suspect the answer to this is no?
>
> If not, is this a possibility in the future when "trust" and integrity 
> of final fields is more fully fleshed out at the JVM level?

Exposing stable fields directly to user code would not be safe, correct.

That said, there might be other features that the language could expose 
that might provide similar functionalities. For instance, a "lazy" 
keyword. Now, it is important to understand that, while there might be 
an API-free path to get to lazy _static_ fields (e.g. using condy), lazy 
_instance_ fields are a completely different can of worms -- and you 
will end up reinventing the same coping mechanisms devised by the 
StableValue API (to ensure at-most once semantics across multiple threads).

So, our hope is that if, in the future, the language would like to 
explore a more direct way to model laziness, stable values could be used 
as a building block by the compiler. And what you write below goes in 
that direction -- we are surely interested to know how well stable value 
might be used in a backend of a compiler (and the addition of the 
imperative access API was -- at least in part -- motivated by that use 
case).

Thanks
Maurizio

>
> I've written up a gist explaining how this feature might be used by 
> functional languages, using AtomicReference as a stand-in for 
> StableValue, since the API is pretty similar: 
> https://urldefense.com/v3/__https://gist.github.com/DavidGregory084/6939b85b6fd3ccfdfc83e05011697ed4__;!!ACWV5N9M2RV99hQ!PrDYhBcrlkUbA_-yIoaBtq6WIZgfaEVacr_MCkC2CWner3RCKVjZ7l8yUr9w2kbrIw4Q-Q37k65n-qSVEa2GWE_MSg$ 
>
> The existing StableValue JEP will work great for me personally as the 
> translation between my "data" and the underlying JVM classes is not as 
> direct as e.g. Scala's case class or Kotlin's data class, and I'd 
> rather it was possible to make more programs stack-safe, even if it 
> requires allocating lots of StableValues, but I am developing more of 
> a teaching language so performance is not exactly paramount for me!
>
> However, it would be great if everybody could get their hands on 
> "stable" - e.g. the "next" field in Scala's List cons cell is an 
> amazing candidate for stable as it's only mutated immediately after 
> creation, like in List#map:
>
> https://urldefense.com/v3/__https://github.com/scala/scala/blob/a2090009c4fc3791b545a257ec6d1431e87cb1f4/src/library/scala/collection/immutable/List.scala*L245__;Iw!!ACWV5N9M2RV99hQ!PrDYhBcrlkUbA_-yIoaBtq6WIZgfaEVacr_MCkC2CWner3RCKVjZ7l8yUr9w2kbrIw4Q-Q37k65n-qSVEa1nTmvCuA$ 
>
> Thanks,
>
> David Gregory
>

From duke at openjdk.org  Thu Feb 27 12:46:36 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 27 Feb 2025 12:46:36 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v7]
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <7k2QcVVhdkip4zjJdolGkHnyRF5K111tbovc-aEzbhc=.d0c2cc89-81d8-4069-86b2-76aef0ce29bb@github.com>

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Rewording notes and spec changes in docs.
  Small change to read formatter once in streamhander methods.
  Reverting Formatter doc changes for now.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23491/files
  - new: https://git.openjdk.org/jdk/pull/23491/files/19e84728..35984b09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=05-06

  Stats: 65 lines in 3 files changed: 12 ins; 43 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/23491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491

PR: https://git.openjdk.org/jdk/pull/23491

From dl at openjdk.org  Thu Feb 27 12:52:14 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 27 Feb 2025 12:52:14 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v4]
In-Reply-To: <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
 <L1A_yliGsrSq658DT35M6MHS7J1nh1jviC-c5NYtx90=.ad207c25-31a6-4911-a838-29ef0d63f7d1@github.com>
Message-ID: <PtiJkKoSSoAnku444NEr8N2bD2oRjVVISJNQOiRIpBI=.316a45ec-a387-4ccf-b874-98705d54c396@github.com>

On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea <dl at openjdk.org> wrote:

>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>> 
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
>> 
>> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
>> 
>> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
>> 
>> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown sh...
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Standardize parameter checking

Thanks! Somehow we were missing a tck test case for this. I'll add one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23702#discussion_r1973521276

From alanb at openjdk.org  Thu Feb 27 13:21:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Feb 2025 13:21:52 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>
Message-ID: <BMtDC20Lpwg7DRfAtAt7dNHtwbstBPBRIhEAHyezWDg=.84037155-9c54-4b8f-9976-4d1b1e944539@github.com>

On Thu, 27 Feb 2025 10:19:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> While testing a bit with a minimal JVM, it has been noticed that some java/lang jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright years

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23805#pullrequestreview-2647757636

From liach at openjdk.org  Thu Feb 27 13:27:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 13:27:00 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <fcsa6WE_4AWLnAloX6hsm-0BDZszbsUfq_En8Ms_Zzk=.faff52ee-0afd-45c0-9d14-25dbedacc7fe@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
 <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
 <fcsa6WE_4AWLnAloX6hsm-0BDZszbsUfq_En8Ms_Zzk=.faff52ee-0afd-45c0-9d14-25dbedacc7fe@github.com>
Message-ID: <P3wPfN6jKOa2leSyMCN28qMLrWBjJDP6s40ZWfthc6E=.190dfe50-c01f-434d-afb0-8735ae2b0a2d@github.com>

On Thu, 27 Feb 2025 10:26:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This emulates how MethodHandleImpl does the cache.
>
> Ok. I think the benefit is that each element is individually lazy initialized. I'm not sure about the setup with the array though. It seems like having 3 stable fields would be simpler?
> 
> Or maybe just initialize them up front in clinit, since they are mostly used together. That would also avoid the need to create a `Lookup` every time, which might help performance since that method is CallerSenstive, so we need to do a stack walk to get the caller when running in the interpreter.

Well, the reason I removed the eager init is that their creation in clinit is super costly. Also I think one pair of getter + creator is better than 3 pairs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1973576054

From mbaesken at openjdk.org  Thu Feb 27 13:39:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Feb 2025 13:39:01 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>
Message-ID: <6N1H_8fOQL6z-uBDXJKLAG63K_PAbJwiC0x9gEEKDEA=.94cf061f-4231-4c45-b27b-22973b099170@github.com>

On Thu, 27 Feb 2025 10:19:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> While testing a bit with a minimal JVM, it has been noticed that some java/lang jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright years

Thanks for the review !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23805#issuecomment-2687979003

From mbaesken at openjdk.org  Thu Feb 27 13:39:02 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Feb 2025 13:39:02 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <-wgA3ZuOnRPwj0WaR2DZdvf-AXIAZYJtfHTNa6CKnNk=.d67aff51-2877-4d26-87e3-320fb989a807@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <C-MYCDaVr2YJLZHDABKKZ784_rLxla6e6hUYxv9oa9U=.a69932b7-f057-4b67-bbd7-f49aac88a28b@github.com>
 <PXb8sEre4Eb6HduJpADX6bfvY9oP8LzF_7oMmm8vJAk=.087b442f-360a-4d00-b3a7-3e261b82829a@github.com>
 <lK8OE6nUsQnMkSzAEEA8cR7nddUjlj91pt11HpNJO2Y=.c3113ec2-d158-45d2-ba31-e441355ffa75@github.com>
 <-wgA3ZuOnRPwj0WaR2DZdvf-AXIAZYJtfHTNa6CKnNk=.d67aff51-2877-4d26-87e3-320fb989a807@github.com>
Message-ID: <pwk1EGafGj4o6g2leboeuL9grLvCRv7jYl_89xx4MgM=.a910f73a-e91f-485b-a68e-89725a1d3751@github.com>

On Thu, 27 Feb 2025 09:12:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> when I list the modules of the minimal JVM I see a number of modules that will most likely not work because the related JVM features are not present
> 
> ```
> images/jdk/bin/java --list-modules
>  ...
> jdk.jdi at 25.0.0.1-internal
> jdk.jdwp.agent at 25.0.0.1-internal
>  ...
> jdk.jfr at 25.0.0.1-internal
> jdk.management at 25.0.0.1-internal
> jdk.management.agent at 25.0.0.1-internal
> jdk.management.jfr at 25.0.0.1-internal
> ```
> 
> The minimal JVM does not contain e.g. JFR, JVMTI or management JVM features. So most likely those modules miss basic functionality and will not or not fully work. But fixing this is most likely out of scope of this PR . Is there some JVM feature to module mapping and tool support already, I am not aware of it ? Would be nice to have this, because removing unneeded (and not working) modules from the image is probably a good idea.

@magicus , @erikj79  is there already something in the build system that can be used for this task ?
E.g. we still have the module  'jdk.jfr'  in the minimal JVM - but the module does not work because the related Hotspot feature is missing.
Same for JDWP/JDI - feature JVMTI is missing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23805#discussion_r1973596161

From mbaesken at openjdk.org  Thu Feb 27 13:39:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Feb 2025 13:39:03 GMT
Subject: Integrated: 8350786: Some java/lang jtreg tests miss requires
 vm.hasJFR
In-Reply-To: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
Message-ID: <EOYgWMWBx8RcfLk6kSASbi5opcmJeqW8eQfrBxpuAIY=.87a27465-ff8c-4abb-8d12-1a2bafb318c3@github.com>

On Wed, 26 Feb 2025 15:47:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> While testing a bit with a minimal JVM, it has been noticed that some java/lang jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .

This pull request has now been integrated.

Changeset: d6d94472
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6d94472c21b1fa4839f548b85908967057c3f07
Stats:     5 lines in 3 files changed: 1 ins; 0 del; 4 mod

8350786: Some java/lang jtreg tests miss requires vm.hasJFR

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/23805

From asemenyuk at openjdk.org  Thu Feb 27 14:04:02 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 27 Feb 2025 14:04:02 GMT
Subject: RFR: 8347139: [macos] Test tools/jpackage/share/InOutPathTest.java
 failed:  "execution error: Finder got an error: AppleEvent timed out."
In-Reply-To: <4mb74SEfiSr7QW_oKrGbOk20dz1qhCJwiJTjmsWv9aM=.a4730050-a0ad-4f1d-8221-99b61e37fd78@github.com>
References: <4mb74SEfiSr7QW_oKrGbOk20dz1qhCJwiJTjmsWv9aM=.a4730050-a0ad-4f1d-8221-99b61e37fd78@github.com>
Message-ID: <P9D7DGjFgpsribbjm48CWzwVbGHX470qs26oa5VAzHg=.ecfedc09-309d-48a8-8147-75821591867b@github.com>

On Thu, 27 Feb 2025 02:53:26 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Fixed by increasing test timeout. Fix verified on host which reproduced issue.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23816#pullrequestreview-2647877433

From jvernee at openjdk.org  Thu Feb 27 14:20:16 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Feb 2025 14:20:16 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <P3wPfN6jKOa2leSyMCN28qMLrWBjJDP6s40ZWfthc6E=.190dfe50-c01f-434d-afb0-8735ae2b0a2d@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
 <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
 <fcsa6WE_4AWLnAloX6hsm-0BDZszbsUfq_En8Ms_Zzk=.faff52ee-0afd-45c0-9d14-25dbedacc7fe@github.com>
 <P3wPfN6jKOa2leSyMCN28qMLrWBjJDP6s40ZWfthc6E=.190dfe50-c01f-434d-afb0-8735ae2b0a2d@github.com>
Message-ID: <oMPfvQ8dUa5B7ka6ZZfKcjmCoenfWP-LAueTZbsMF_M=.b3d38e82-cc63-4a91-92fe-150178f791e9@github.com>

On Thu, 27 Feb 2025 13:24:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> ...  creation in clinit is super costly

You mean because threads can not race to initialize? I'd think the extra walks to create 3 lookups might offset that though...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1973668377

From jvernee at openjdk.org  Thu Feb 27 14:24:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Feb 2025 14:24:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v3]
In-Reply-To: <ITL0ulKc9iZF4ShEflEc0r-3rdsN77wtTSalhWhA2tw=.973640ef-9843-4009-828b-8a1c7754be07@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>
 <4ZTgmEF7598oiRqCiAl43Ux559migTzfTcjkwLKw0no=.0e4b1001-eedd-462c-9283-8038565c96c7@github.com>
 <ITL0ulKc9iZF4ShEflEc0r-3rdsN77wtTSalhWhA2tw=.973640ef-9843-4009-828b-8a1c7754be07@github.com>
Message-ID: <9_Mp24kqJm3Txg5EreOQ0hze__fMkkLglPzrAOBq1ro=.a0c32391-aaa0-4a80-b885-1edf1901dfe7@github.com>

On Wed, 26 Feb 2025 19:54:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I suggest maybe renaming `noStride` to something like `fixedOffsetInEnclosing`
>
> In last revision I called it `fixedOffset`, but it becomes confusing with the actual fixed value of the offset.

Maybe something like `isOffsetFixed` or `hasFixedOffset` would be better?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1973677125

From jvernee at openjdk.org  Thu Feb 27 14:24:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Feb 2025 14:24:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
 <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
Message-ID: <pZm9yNcYzgZV499OVNRwQdsZjP_D9bjeXfr4k2UPhe0=.33f1992d-212c-45bf-aca7-8c08ce852b22@github.com>

On Wed, 26 Feb 2025 19:53:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 83:
>> 
>>> 81:                     bb.unsafeGetBase(),
>>> 82:                     offset(bb, base, offset),
>>> 83:                     handle.be);
>> 
>> Why do we not have a call to `convEndian` here?
>
> This is just how it was. Refer to line 141 in old diff.

Ah, right, the unaligned Unsafe routines support specifying the endianess already, but for the aligned variants it has to be emulated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1973675226

From ihse at openjdk.org  Thu Feb 27 15:15:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 27 Feb 2025 15:15:09 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <pwk1EGafGj4o6g2leboeuL9grLvCRv7jYl_89xx4MgM=.a910f73a-e91f-485b-a68e-89725a1d3751@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <C-MYCDaVr2YJLZHDABKKZ784_rLxla6e6hUYxv9oa9U=.a69932b7-f057-4b67-bbd7-f49aac88a28b@github.com>
 <PXb8sEre4Eb6HduJpADX6bfvY9oP8LzF_7oMmm8vJAk=.087b442f-360a-4d00-b3a7-3e261b82829a@github.com>
 <lK8OE6nUsQnMkSzAEEA8cR7nddUjlj91pt11HpNJO2Y=.c3113ec2-d158-45d2-ba31-e441355ffa75@github.com>
 <-wgA3ZuOnRPwj0WaR2DZdvf-AXIAZYJtfHTNa6CKnNk=.d67aff51-2877-4d26-87e3-320fb989a807@github.com>
 <pwk1EGafGj4o6g2leboeuL9grLvCRv7jYl_89xx4MgM=.a910f73a-e91f-485b-a68e-89725a1d3751@github.com>
Message-ID: <iEmMwagKTp1hzZBBecqENWyojc0ZFQDsNjJRRsjAqEk=.5a5d4494-7236-488d-ae53-2e6283ed6546@github.com>

On Thu, 27 Feb 2025 13:36:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> when I list the modules of the  minimal JVM I see a number of modules that will most likely not work because the related JVM features are not present 
>> 
>> 
>> images/jdk/bin/java --list-modules
>>  ...
>> jdk.jdi at 25.0.0.1-internal
>> jdk.jdwp.agent at 25.0.0.1-internal
>>  ...
>> jdk.jfr at 25.0.0.1-internal
>> jdk.management at 25.0.0.1-internal
>> jdk.management.agent at 25.0.0.1-internal
>> jdk.management.jfr at 25.0.0.1-internal
>> 
>> 
>> The minimal JVM does not  contain e.g. JFR, JVMTI or management  JVM features. So most likely those modules miss basic functionality and will not or not fully work.
>> But fixing this is most likely out of scope of this PR .
>> Is there some JVM feature to module  mapping and tool support already, I am not aware of it ? 
>> Would be nice to have this, because removing unneeded (and not working) modules from the image is probably a good idea.
>
>> when I list the modules of the minimal JVM I see a number of modules that will most likely not work because the related JVM features are not present
>> 
>> ```
>> images/jdk/bin/java --list-modules
>>  ...
>> jdk.jdi at 25.0.0.1-internal
>> jdk.jdwp.agent at 25.0.0.1-internal
>>  ...
>> jdk.jfr at 25.0.0.1-internal
>> jdk.management at 25.0.0.1-internal
>> jdk.management.agent at 25.0.0.1-internal
>> jdk.management.jfr at 25.0.0.1-internal
>> ```
>> 
>> The minimal JVM does not contain e.g. JFR, JVMTI or management JVM features. So most likely those modules miss basic functionality and will not or not fully work. But fixing this is most likely out of scope of this PR . Is there some JVM feature to module mapping and tool support already, I am not aware of it ? Would be nice to have this, because removing unneeded (and not working) modules from the image is probably a good idea.
> 
> @magicus , @erikj79  is there already something in the build system that can be used for this task ?
> E.g. we still have the module  'jdk.jfr'  in the minimal JVM - but the module does not work because the related Hotspot feature is missing.
> Same for JDWP/JDI - feature JVMTI is missing.

No, there is nothing for that. There is a conceptual leap between determining how to compile hotspot and how to decide which modules to include in the image, and is not at all clear how you would want to integrate these two. Like, should you exclude models by saying a hotspot feature is not needed? Or, should you modify how hotspot is compiled by saying that you want to exclude a model?

I think it is better left to whoever configures the build to figure such things out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23805#discussion_r1973793851

From mbaesken at openjdk.org  Thu Feb 27 15:37:02 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Feb 2025 15:37:02 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <iEmMwagKTp1hzZBBecqENWyojc0ZFQDsNjJRRsjAqEk=.5a5d4494-7236-488d-ae53-2e6283ed6546@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <C-MYCDaVr2YJLZHDABKKZ784_rLxla6e6hUYxv9oa9U=.a69932b7-f057-4b67-bbd7-f49aac88a28b@github.com>
 <PXb8sEre4Eb6HduJpADX6bfvY9oP8LzF_7oMmm8vJAk=.087b442f-360a-4d00-b3a7-3e261b82829a@github.com>
 <lK8OE6nUsQnMkSzAEEA8cR7nddUjlj91pt11HpNJO2Y=.c3113ec2-d158-45d2-ba31-e441355ffa75@github.com>
 <-wgA3ZuOnRPwj0WaR2DZdvf-AXIAZYJtfHTNa6CKnNk=.d67aff51-2877-4d26-87e3-320fb989a807@github.com>
 <pwk1EGafGj4o6g2leboeuL9grLvCRv7jYl_89xx4MgM=.a910f73a-e91f-485b-a68e-89725a1d3751@github.com>
 <iEmMwagKTp1hzZBBecqENWyojc0ZFQDsNjJRRsjAqEk=.5a5d4494-7236-488d-ae53-2e6283ed6546@github.com>
Message-ID: <U6YRQCFntBx0N-of4aDSWdoDJGMvII72W3d2w8QVIXc=.12012b0c-580a-45d6-a45d-5e418fd29459@github.com>

On Thu, 27 Feb 2025 15:11:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> No, there is nothing for that. There is a conceptual leap between determining how to compile hotspot and how to decide which modules to include in the image, and is not at all clear how you would want to integrate these two. Like, should you exclude models by saying a hotspot feature is not needed? Or, should you modify how hotspot is compiled by saying that you want to exclude a model?
> 
> I think it is better left to whoever configures the build to figure such things out.

I was just following up to the idea stated above 
'If the only VM to be built is the minimal VM then maybe it should filter down the set of modules to include'
but this is not so easy it seems.
Regarding - 'should you exclude models (modules?) by saying a hotspot feature is not needed?'  excluding the JVM feature  JFR means that the jfr related modules are broken/not (fully) working.
Excluding them would probably be logical (and also help the tests because quite a lot of tests do not have requires vm.hasJFR or requires vm.jvmti to check if the test makes sense on some JVM with limited features) .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23805#discussion_r1973837920

From liach at openjdk.org  Thu Feb 27 15:43:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 15:43:25 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v4]
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <aPHkpINA-c_CogUvT7q3d9t8lbcsLZd4eZ1RZzcN6bA=.27569d59-65ea-48fc-ae46-fd331d50931f@github.com>

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Rollback lazy Segment adapter cache per vernee, fix header indent
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline
 - Jorn vernee review
 - Review remarks, dates, some more simplifications
 - More cleanup
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline
 - Make sure the form impl class is initialized
 - Reduce MT initialization work
 - MH linkToStatic stall
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline
 - ... and 4 more: https://git.openjdk.org/jdk/compare/23dee8fd...d59ff23a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23720/files
  - new: https://git.openjdk.org/jdk/pull/23720/files/3d558a2d..d59ff23a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=02-03

  Stats: 13038 lines in 332 files changed: 7301 ins; 4580 del; 1157 mod
  Patch: https://git.openjdk.org/jdk/pull/23720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23720/head:pull/23720

PR: https://git.openjdk.org/jdk/pull/23720

From liach at openjdk.org  Thu Feb 27 16:00:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 16:00:47 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  noStride -> constantOffset, optimize VH classes to have only 2 instead of 3 classes for each type

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23720/files
  - new: https://git.openjdk.org/jdk/pull/23720/files/d59ff23a..e5839fb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=03-04

  Stats: 606 lines in 6 files changed: 28 ins; 30 del; 548 mod
  Patch: https://git.openjdk.org/jdk/pull/23720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23720/head:pull/23720

PR: https://git.openjdk.org/jdk/pull/23720

From jvernee at openjdk.org  Thu Feb 27 16:05:02 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Feb 2025 16:05:02 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>
Message-ID: <cjJJ0RRvf_vKt5B0kTguGn0_9x7g4UuUVDnCBNl_OS0=.c0a373c4-9069-48bd-af54-2d2941b0b9c9@github.com>

On Thu, 27 Feb 2025 16:00:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   noStride -> constantOffset, optimize VH classes to have only 2 instead of 3 classes for each type

Latest version looks good.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2648300971

From mik3hall at gmail.com  Thu Feb 27 16:11:50 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 27 Feb 2025 10:11:50 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <AF89236A-84C2-481D-8A1A-95596C27AE1D@gmail.com>
 <TlvQzvzAvExG0dtuqjyT7CegIBi5JY9_jdQBxxr82yw=.19e394f5-223c-4ba5-b55d-55127da3f1d6@github.com>
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
Message-ID: <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>



> On Feb 26, 2025, at 9:22?PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> 
>> I don?t get that if I delete the existing dmg first.
>> 
>> Full verbose output at?
>> 
>> http://mikehall.pairserver.com/rt.txt
> 

Is there a how-to on using --runtime-image on MacOS? How are you supposed to get a valid runtime to put into JavaVirtualMachines?

I installed jdk 23 to bootstrap a jdk build. I jpackage?d that.

jpackage --verbose -n rt -t dmg --runtime-image /Users/mjh/Documents/GitHub/jdk/build/macosx-aarch64-server-release/jdk

The resulting jdk actually appears to have a similar directory layout to what is in JavaVirtualMachines. 

It lacks the _CodeSignature, Info.plist, and MacOS file and directories.

It still is not found with either ?java ?version? or ?/usr/libexec/java_home?

I tried giving it a more standard name in case naming convention mattered.

The built is jdk 25 and the 23 bootstrap still shows current. 

I thought maybe using that runtime to build an application then jpackage would make it a valid MacOS runtime

But jpackage --runtime-image with the runtime from that gets a couple no such file exceptions on
runtime/Contents/Home/lib/libnio.dylib.dSYM/Contents/Info.plist

The app gets
HalfPipe.app/Contents/MacOS/HalfPipe
Error: could not open `/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home//lib/jvm.cfg?

Possibly not a bug but not obviously easy either. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250227/db188550/attachment.htm>

From galder at openjdk.org  Thu Feb 27 16:41:13 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 27 Feb 2025 16:41:13 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
Message-ID: <a5rgV-mShBLPGVHpb_rApMTUxpDMdPnD9L8VnTyfRxQ=.23a74fc4-e041-4c67-a653-1e00b2568d2c@github.com>

On Fri, 7 Feb 2025 12:39:24 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Fix typo
>  - Renaming methods and variables and add docu on algorithms
>  - Fix copyright years
>  - Make sure it runs with cpus with either avx512 or asimd
>  - Test can only run with 256 bit registers or bigger
>    
>    * Remove platform dependant check
>    and use platform independent configuration instead.
>  - Fix license header
>  - Tests should also run on aarch64 asimd=true envs
>  - Added comment around the assertions
>  - Adjust min/max identity IR test expectations after changes
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/92e82467...a190ae68

Also, I've started a [discussion on jmh-dev](https://mail.openjdk.org/pipermail/jmh-dev/2025-February/004094.html) to see if there's a way to minimise pollution of `Math.min(II)` compilation. As a follow to https://github.com/openjdk/jdk/pull/20098#issuecomment-2684701935 I looked at where the other `Math.min(II)` calls are coming from, and a big chunk seem related to the JMH infrastructure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2688510211

From naoto at openjdk.org  Thu Feb 27 16:40:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Feb 2025 16:40:53 GMT
Subject: RFR: 4745837: Make grouping usage during parsing apparent in
 relevant NumberFormat methods
In-Reply-To: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
Message-ID: <byn0BzdA2CC9kefFDrk3CdXpcCjkQIYxX9999LJ6pOk=.0524f24a-f764-438d-a6d9-1d27b5443516@github.com>

On Wed, 26 Feb 2025 22:18:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.
> 
> Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.

src/java.base/share/classes/java/text/NumberFormat.java line 889:

> 887:      * formatting and parsing. For example, in the English locale, with grouping on,
> 888:      * the number 1234567 might be formatted as "1,234,567". For the same format
> 889:      * with grouping off, the String "1,234,567" might be parsed as 1.

Although you used `might`, it may be helpful to mention the leniency here. I think it will throw exception in the strict mode.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23813#discussion_r1973958774

From galder at openjdk.org  Thu Feb 27 16:38:04 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 27 Feb 2025 16:38:04 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v12]
In-Reply-To: <63F-0aHgMthexL0b2DFmkW8_QrJeo8OOlCaIyZApfpY=.4744070d-9d56-4031-8684-be14cf66d1e5@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <pZjDpZKJUmXi85-qf3F-NX91qVc42_QgZGbuo36XhPk=.f2e4ba72-bf19-4ced-9656-c01907bdae1b@github.com>
 <wDsCyP79rQ4dN3G6lMjZliTn6ym5-HwjGZ-Y-Xx_vQY=.0a187197-7505-4c95-a6cd-8b8eea0bea88@github.com>
 <DvPOVOuqVlNY-0K5E201YQgKmguBMpJDQw2h1myD8S0=.81a46beb-90fa-4417-a9b2-9d3ebc746538@github.com>
 <63F-0aHgMthexL0b2DFmkW8_QrJeo8OOlCaIyZApfpY=.4744070d-9d56-4031-8684-be14cf66d1e5@github.com>
Message-ID: <UR_gzF8pDYx_j2m2J1UhSzkjG8Qcz6aL_T7FtxDCq28=.99f74160-15da-46ac-aa03-a01bbe21a399@github.com>

On Thu, 27 Feb 2025 06:54:30 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Detect "extreme" probability scalar cmove, and replace them with branching code. This should take care of all regressions here. This one has high priority, as it fixes the regression caused by this patch here. But it would also help to improve performance for the Integer.min/max cases, which have the same issue.

+1 and the rest of suggestions. Shall I create a JDK bug for this?

> Additional performance improvement: make SuperWord recognize more cases as profitble (see Regression 1). Optional.
> Additional performance improvement: extend backend capabilities for vectorization (see Regression 2 + 3). Optional.

Do we need JDK bug(s) for these? If so, how many? 1 or 2?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2688502397

From kevinw at openjdk.org  Thu Feb 27 16:48:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Feb 2025 16:48:13 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <w7EwNH5soJlrUBiMZGGF7pFQ98SMY_NxP-jlSPf1K-E=.9f33d393-b78b-44e4-b7fa-d47b054638d3@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

This change is implicated in the regression JDK-8350820 in the Windows management/cpu usage functions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688528615

From jwaters at openjdk.org  Thu Feb 27 16:57:05 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 27 Feb 2025 16:57:05 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <Ew21DejHpQXKCoI4QoT9qZcPpTJbhVJmxyS1-FURJTE=.719d0640-0fa5-4fd0-a7e8-19e9e31f66bf@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

That's not good. I cannot view JDK-8350820 however

Is the issue in HotSpot, or another component?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688552358
PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688554610

From duke at openjdk.org  Thu Feb 27 17:00:28 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 27 Feb 2025 17:00:28 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v8]
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <SWj8w17OSYtuIuKbnxau8ui_SytIIP5iCjeKxH9Hj4s=.dab9e9d4-94e0-4f75-851e-142e79a7e20f@github.com>

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Make class level docs just docs (no annotation).

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23491/files
  - new: https://git.openjdk.org/jdk/pull/23491/files/35984b09..6051c690

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491

PR: https://git.openjdk.org/jdk/pull/23491

From kevinw at openjdk.org  Thu Feb 27 17:00:25 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Feb 2025 17:00:25 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <Xfa55gXs5qXMaifp0YRrFKLZzAdldbbUDa4yUeDdtps=.1457e6a0-ef90-408a-bca4-212b91e393df@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

Issue recently logged, was marked confidential, will update...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688560132

From duke at openjdk.org  Thu Feb 27 17:15:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 27 Feb 2025 17:15:56 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v9]
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <i6qWEAJ6su3eRLy4wqylbVl0hG88eTMyr2zKP4_07cg=.6eeffc2d-9dd2-4c12-89c6-f53624f4ca27@github.com>

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Fix @implNote to @apiNote.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23491/files
  - new: https://git.openjdk.org/jdk/pull/23491/files/6051c690..147aecae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491

PR: https://git.openjdk.org/jdk/pull/23491

From asemenyuk at openjdk.org  Thu Feb 27 17:38:06 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 27 Feb 2025 17:38:06 GMT
Subject: RFR: 8350013: Add a test for JDK-8150442
In-Reply-To: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>
References: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>
Message-ID: <TF-k6mUSrxdHKrKxYmB8XZx-SDzjREx6LmefSvCu0VE=.964a6db3-d137-490f-9813-684824c98641@github.com>

On Thu, 27 Feb 2025 14:17:30 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add a test to verify jpackage is using a custom MSI condition blocking package installation depending on the version of Windows where the package installer runs. Support for this MSI condition was added in [JDK-8150442](https://bugs.openjdk.org/browse/JDK-8150442).
> 
> The test adds an unconditionally failing OS-version MSI condition to the resource directory. MSI installer using this condition should always fail. The exit code of the failed installation would be 1603. Extended error information can be dug in the MSI log file. To make the test work, the following changes to jpackage test lib have been made:
>  - Support non-0 exit code from MSI install handler. Support for non-0 exit codes was added to install handlers of all other types too. Added `PackageTest.setExpectedInstallExitCode(int)` method to configure the expected exit code of a package installation;
>  - Support using msi log files when MSI and EXE packages get installed, unpacked, or uninstalled. Added `PackageTest.createMsiLog(boolean)` to enable or disable creation of msi log files in a PackageTest instance and `Optional<Path> JPackageCommand.winMsiLogFile()` to access the current log file from the callbacks registered with the PackageTest instance.
> 
> Added tests for PackageTest class (PackageTestTest).
> 
> Additionally, improved the code in WindowsHelper detecting paths to Start Menu, Desktop, and other common paths. Previously, it relied on reading these paths from the registry. On some machines, required registry keys are not available. The code now will call .NET `Environment.GetFolderPath()` function through powershell if a registry key is missing.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23825#issuecomment-2688650160

From asemenyuk at openjdk.org  Thu Feb 27 17:38:06 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 27 Feb 2025 17:38:06 GMT
Subject: RFR: 8350013: Add a test for JDK-8150442
Message-ID: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>

Add a test to verify jpackage is using a custom MSI condition blocking package installation depending on the version of Windows where the package installer runs. Support for this MSI condition was added in [JDK-8150442](https://bugs.openjdk.org/browse/JDK-8150442).

The test adds an unconditionally failing OS-version MSI condition to the resource directory. MSI installer using this condition should always fail. The exit code of the failed installation would be 1603. Extended error information can be dug in the MSI log file. To make the test work, the following changes to jpackage test lib have been made:
 - Support non-0 exit code from MSI install handler. Support for non-0 exit codes was added to install handlers of all other types too. Added `PackageTest.setExpectedInstallExitCode(int)` method to configure the expected exit code of a package installation;
 - Support using msi log files when MSI and EXE packages get installed, unpacked, or uninstalled. Added `PackageTest.createMsiLog(boolean)` to enable or disable creation of msi log files in a PackageTest instance and `Optional<Path> JPackageCommand.winMsiLogFile()` to access the current log file from the callbacks registered with the PackageTest instance.

Added tests for PackageTest class (PackageTestTest).

Additionally, improved the code in WindowsHelper detecting paths to Start Menu, Desktop, and other common paths. Previously, it relied on reading these paths from the registry. On some machines, required registry keys are not available. The code now will call .NET `Environment.GetFolderPath()` function through powershell if a registry key is missing.

-------------

Commit messages:
 - Cleanup
 - Merge branch 'master' into decouple-os-condition
 - Merge branch 'decouple-tkit' into decouple-os-condition
 - Better log message
 - Better test description and add tests for roles with dots
 - Merge branch 'master' into decouple-tkit
 - Test if the main jar is in the app image if specified.
 - Merge branch 'decouple-executor-result' into decouple-tkit
 - Merge branch 'decouple-fix-annotations' into decouple-executor-result
 - Fix javac error
 - ... and 37 more: https://git.openjdk.org/jdk/compare/0f822681...a27cb527

Changes: https://git.openjdk.org/jdk/pull/23825/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23825&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350013
  Stats: 1879 lines in 8 files changed: 1405 ins; 160 del; 314 mod
  Patch: https://git.openjdk.org/jdk/pull/23825.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23825/head:pull/23825

PR: https://git.openjdk.org/jdk/pull/23825

From liach at openjdk.org  Thu Feb 27 17:41:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 17:41:48 GMT
Subject: RFR: 8350704: Create tests to ensure the failure behavior of core
 reflection APIs [v2]
In-Reply-To: <hALAQ2YPDV_gZIjVHV1pE8emYwh83IhrPg8PrnLWVLE=.62cdd46b-668a-47a1-a841-21fdb7537206@github.com>
References: <hALAQ2YPDV_gZIjVHV1pE8emYwh83IhrPg8PrnLWVLE=.62cdd46b-668a-47a1-a841-21fdb7537206@github.com>
Message-ID: <RcH92HhHNuwYuX1OETEqRTpBGblbEe3CPunZ_KQkqyw=.6cd2ff0b-f525-47c0-bbe2-9bcfd13c0a3a@github.com>

> Core reflection's generic signature parsing system is used for many aspects, including annotations and enclosing methods, yet it is under-tested. It is better for us to set up tests to ensure that sensitive error behaviors of core reflection remain the same across implementation updates, such as #19281.
> 
> This patch also includes a JUnit converted version of https://github.com/openjdk/jdk/pull/22581#issuecomment-2521703511 test checking behavior around annotations with duplicate interfaces. Interesting that this causes failure in class, field, and methods (constructors), but not in parameters.
> 
> Testing: jdk-tier 1, jdk-tier 2

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Remove useless directive

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23788/files
  - new: https://git.openjdk.org/jdk/pull/23788/files/57905632..e466c93c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23788&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23788&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23788.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23788/head:pull/23788

PR: https://git.openjdk.org/jdk/pull/23788

From alexey.semenyuk at oracle.com  Thu Feb 27 17:43:08 2025
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 27 Feb 2025 12:43:08 -0500
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <AF89236A-84C2-481D-8A1A-95596C27AE1D@gmail.com>
 <TlvQzvzAvExG0dtuqjyT7CegIBi5JY9_jdQBxxr82yw=.19e394f5-223c-4ba5-b55d-55127da3f1d6@github.com>
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
 <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
Message-ID: <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>

Hi Michael,

See my comments inline.

On 2/27/2025 11:11 AM, Michael Hall wrote:
>
>
>> On Feb 26, 2025, at 9:22?PM, Michael Hall <mik3hall at gmail.com> wrote:
>>
>>>
>>> I don?t get that if I delete the existing dmg first.
>>>
>>> Full verbose output at?
>>>
>>> http://mikehall.pairserver.com/rt.txt
>>
>
> Is there a how-to on using?--runtime-image on MacOS? How are you 
> supposed to get a valid runtime to put into JavaVirtualMachines?
>
> I installed jdk 23 to bootstrap a jdk build. I jpackage?d that.
>
> jpackage --verbose -n rt -t dmg --runtime-image 
> /Users/mjh/Documents/GitHub/jdk/build/macosx-aarch64-server-release/jdk
This command should produce a Java runtime in JavaVirtualMachines subtree.

>
> The resulting jdk actually appears to have a similar directory layout 
> to what is in JavaVirtualMachines.
>
> It lacks the?_CodeSignature, Info.plist, and MacOS file and directories.
This is intentional (not sure it is correct, though).

>
> It still is not found with either ?java ?version? or 
> ?/usr/libexec/java_home?
>
> I tried giving it a more standard name in case naming convention mattered.
No, it doesn't. The name you tried should work.

>
> The built is jdk 25 and the 23 bootstrap still shows current.
>
> I thought maybe using that runtime to build an application then 
> jpackage would make it a valid MacOS runtime
>
> But jpackage --runtime-image with the runtime from that gets a couple 
> no such file exceptions on
> runtime/Contents/Home/lib/libnio.dylib.dSYM/Contents/Info.plist
>
> The app gets
> HalfPipe.app/Contents/MacOS/HalfPipe
> Error: could not open 
> `/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home//lib/jvm.cfg?
>
> Possibly not a bug but not obviously easy either.

Thank you for trying it out! I'll look closer at the issues you reported 
and get back to you.

- Alexey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250227/cd411b12/attachment.htm>

From mik3hall at gmail.com  Thu Feb 27 17:47:53 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 27 Feb 2025 11:47:53 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <AF89236A-84C2-481D-8A1A-95596C27AE1D@gmail.com>
 <TlvQzvzAvExG0dtuqjyT7CegIBi5JY9_jdQBxxr82yw=.19e394f5-223c-4ba5-b55d-55127da3f1d6@github.com>
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
 <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
 <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
Message-ID: <A51B1985-9798-4A34-8766-1283CE962A0F@gmail.com>

Thanks, mainly curious. 
Now, mostly about how the JavaVirtualMachines MacOS specific JRE?s might be built.

> On Feb 27, 2025, at 11:43?AM, Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
> 
> Hi Michael,
> 
> See my comments inline.
> 
> On 2/27/2025 11:11 AM, Michael Hall wrote:
>> 
>> 
>>> On Feb 26, 2025, at 9:22?PM, Michael Hall <mik3hall at gmail.com> <mailto:mik3hall at gmail.com> wrote:
>>> 
>>>> 
>>>> I don?t get that if I delete the existing dmg first.
>>>> 
>>>> Full verbose output at?
>>>> 
>>>> http://mikehall.pairserver.com/rt.txt
>>> 
>> 
>> Is there a how-to on using --runtime-image on MacOS? How are you supposed to get a valid runtime to put into JavaVirtualMachines?
>> 
>> I installed jdk 23 to bootstrap a jdk build. I jpackage?d that.
>> 
>> jpackage --verbose -n rt -t dmg --runtime-image /Users/mjh/Documents/GitHub/jdk/build/macosx-aarch64-server-release/jdk
> This command should produce a Java runtime in JavaVirtualMachines subtree.
> 
>> 
>> The resulting jdk actually appears to have a similar directory layout to what is in JavaVirtualMachines. 
>> 
>> It lacks the _CodeSignature, Info.plist, and MacOS file and directories.
> This is intentional (not sure it is correct, though).
> 
>> 
>> It still is not found with either ?java ?version? or ?/usr/libexec/java_home?
>> 
>> I tried giving it a more standard name in case naming convention mattered.
> No, it doesn't. The name you tried should work.
> 
>> 
>> The built is jdk 25 and the 23 bootstrap still shows current. 
>> 
>> I thought maybe using that runtime to build an application then jpackage would make it a valid MacOS runtime
>> 
>> But jpackage --runtime-image with the runtime from that gets a couple no such file exceptions on
>> runtime/Contents/Home/lib/libnio.dylib.dSYM/Contents/Info.plist
>> 
>> The app gets
>> HalfPipe.app/Contents/MacOS/HalfPipe
>> Error: could not open `/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home//lib/jvm.cfg?
>> 
>> Possibly not a bug but not obviously easy either. 
> 
> Thank you for trying it out! I'll look closer at the issues you reported and get back to you.
> 
> - Alexey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250227/51907501/attachment-0001.htm>

From mik3hall at gmail.com  Thu Feb 27 17:47:53 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 27 Feb 2025 11:47:53 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <AF89236A-84C2-481D-8A1A-95596C27AE1D@gmail.com>
 <TlvQzvzAvExG0dtuqjyT7CegIBi5JY9_jdQBxxr82yw=.19e394f5-223c-4ba5-b55d-55127da3f1d6@github.com>
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
 <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
 <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
Message-ID: <A51B1985-9798-4A34-8766-1283CE962A0F@gmail.com>

Thanks, mainly curious. 
Now, mostly about how the JavaVirtualMachines MacOS specific JRE?s might be built.

> On Feb 27, 2025, at 11:43?AM, Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
> 
> Hi Michael,
> 
> See my comments inline.
> 
> On 2/27/2025 11:11 AM, Michael Hall wrote:
>> 
>> 
>>> On Feb 26, 2025, at 9:22?PM, Michael Hall <mik3hall at gmail.com> <mailto:mik3hall at gmail.com> wrote:
>>> 
>>>> 
>>>> I don?t get that if I delete the existing dmg first.
>>>> 
>>>> Full verbose output at?
>>>> 
>>>> http://mikehall.pairserver.com/rt.txt
>>> 
>> 
>> Is there a how-to on using --runtime-image on MacOS? How are you supposed to get a valid runtime to put into JavaVirtualMachines?
>> 
>> I installed jdk 23 to bootstrap a jdk build. I jpackage?d that.
>> 
>> jpackage --verbose -n rt -t dmg --runtime-image /Users/mjh/Documents/GitHub/jdk/build/macosx-aarch64-server-release/jdk
> This command should produce a Java runtime in JavaVirtualMachines subtree.
> 
>> 
>> The resulting jdk actually appears to have a similar directory layout to what is in JavaVirtualMachines. 
>> 
>> It lacks the _CodeSignature, Info.plist, and MacOS file and directories.
> This is intentional (not sure it is correct, though).
> 
>> 
>> It still is not found with either ?java ?version? or ?/usr/libexec/java_home?
>> 
>> I tried giving it a more standard name in case naming convention mattered.
> No, it doesn't. The name you tried should work.
> 
>> 
>> The built is jdk 25 and the 23 bootstrap still shows current. 
>> 
>> I thought maybe using that runtime to build an application then jpackage would make it a valid MacOS runtime
>> 
>> But jpackage --runtime-image with the runtime from that gets a couple no such file exceptions on
>> runtime/Contents/Home/lib/libnio.dylib.dSYM/Contents/Info.plist
>> 
>> The app gets
>> HalfPipe.app/Contents/MacOS/HalfPipe
>> Error: could not open `/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home//lib/jvm.cfg?
>> 
>> Possibly not a bug but not obviously easy either. 
> 
> Thank you for trying it out! I'll look closer at the issues you reported and get back to you.
> 
> - Alexey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250227/51907501/attachment-0002.htm>

From jlu at openjdk.org  Thu Feb 27 18:08:35 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Feb 2025 18:08:35 GMT
Subject: RFR: 4745837: Make grouping usage during parsing apparent in
 relevant NumberFormat methods [v2]
In-Reply-To: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
Message-ID: <ZiYza2xy8-y2i4woI1b5MjYVwUggTuquy-Ub6zK1oVU=.f7b02b65-266d-4cf4-97c5-b4d0a910d965@github.com>

> Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.
> 
> Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Naoto review - include strict parsing example. Also remove 'might' wording

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23813/files
  - new: https://git.openjdk.org/jdk/pull/23813/files/4f067f79..8c4ff2eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23813&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23813&range=00-01

  Stats: 12 lines in 1 file changed: 7 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23813.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23813/head:pull/23813

PR: https://git.openjdk.org/jdk/pull/23813

From jlu at openjdk.org  Thu Feb 27 18:08:36 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Feb 2025 18:08:36 GMT
Subject: RFR: 4745837: Make grouping usage during parsing apparent in
 relevant NumberFormat methods [v2]
In-Reply-To: <byn0BzdA2CC9kefFDrk3CdXpcCjkQIYxX9999LJ6pOk=.0524f24a-f764-438d-a6d9-1d27b5443516@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
 <byn0BzdA2CC9kefFDrk3CdXpcCjkQIYxX9999LJ6pOk=.0524f24a-f764-438d-a6d9-1d27b5443516@github.com>
Message-ID: <TcB4CRRTh0uRUqgUTxO_5hdlec2Zn8UP-BrqBuOGCX4=.9111bd50-06a4-44d9-bf0c-cbca5ee53ca2@github.com>

On Thu, 27 Feb 2025 16:37:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naoto review - include strict parsing example. Also remove 'might' wording
>
> src/java.base/share/classes/java/text/NumberFormat.java line 889:
> 
>> 887:      * formatting and parsing. For example, in the English locale, with grouping on,
>> 888:      * the number 1234567 might be formatted as "1,234,567". For the same format
>> 889:      * with grouping off, the String "1,234,567" might be parsed as 1.
> 
> Although you used `might`, it may be helpful to mention the leniency here. I think it will throw exception in the strict mode.

I originally included a strict behavior example as well but reverted it because the default behavior for NumberFormat does not support strict/non-strict. But I think we can include it as long as the wording is careful.

For the formatting example, I inferred that the "might" wording was regarding that there is no guarantee (however unlikely) that `,` remains the grouping separator and a size of 3 for the English locale. That's why I included that wording in the (previous) parsing example.

I changed the wording so that we can remove the ambiguous "might" wording. https://github.com/openjdk/jdk/pull/23813/commits/8c4ff2eb8c1746b524b661f37296cea6586161d9 contains these updates.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23813#discussion_r1974098707

From keshlam at alum.mit.edu  Wed Feb 26 21:46:46 2025
From: keshlam at alum.mit.edu (Joseph Kesselman)
Date: Wed, 26 Feb 2025 21:46:46 +0000
Subject: adding Xalan's XSL 3 implementation within jdk
In-Reply-To: <CABuuzNO58-iNcaE29133FUWVpz9jH-sCXfQQAZHu_eUiL_oeoA@mail.gmail.com>
References: <CABuuzNP66-_d7J=UKz2UBY17V2eVk=xvB5w4bRj4A5aEaDQXcw@mail.gmail.com>
 <CABuuzNPKrdhGyqD-FEP-SU7MS4T_7h1smMBg31G9V2LHcPoq=g@mail.gmail.com>
 <e6c986db-9816-4172-9589-e6ce08674dae@oracle.com>
 <CABuuzNO58-iNcaE29133FUWVpz9jH-sCXfQQAZHu_eUiL_oeoA@mail.gmail.com>
Message-ID: <CH2PR12MB42144DD63B2A5168BEA349CD9EC22@CH2PR12MB4214.namprd12.prod.outlook.com>

Note that many/most of the changes in the head branch are directory reshuffles, as we moved things around to conform to Maven's expectations.  There are relatively few actual code changes, as can be confirmed by comparing files by package/class rather than by which subtree they are in. The git history shows that most of that was straightforward and occurred in a small number of commits as move actions.



--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

Caveat: Opinionated old geezer with overcompensated writer's block. May be redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant.
________________________________
From: Mukul Gandhi <mukulg at apache.org>
Sent: Wednesday, 26 February 2025 10:59:13
To: Alan Bateman <alan.bateman at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; Joseph Kesselman <keshlam at alum.mit.edu>; Gary Gregory <garydgregory at gmail.com>
Subject: Re: adding Xalan's XSL 3 implementation within jdk

Hi Alan,
    I've just seen this mail from you. Apologies for a delayed response.

My mail box has had few issues due to the volume of mails that I get
from mailing lists.

On Sun, Feb 2, 2025 at 9:38?PM Alan Bateman <alan.bateman at oracle.com> wrote:

> The stats for that branch suggest 5,845 changed files with 234,372 additions and 84,058 deletions. I can't easily tell how much of this would need to come into the jdk repo but this looks like a major update. If only 10% of this is applicable to the JDK then it still needs seems like a major update that would require a huge investment to audit and integrate this code. How much XML is in new applications developed in 2025? Only asking because it's an area that is surely much lower priority compared to all the other major investments right now. Maybe there are useful security or performance changes that would be useful to cherry pick instead? Finally, does this Xalan update work with the SPIs so that someone really looking for XSL 3 can just deploy it on the class path and module path?

Ofcourse, anyone could use Xalan-J's XSL 3 implementation with JDK by
placing Xalan jars on class path & module path.

Since Xalan-J's XSLT 1.0 & XPath 1.0 implementations are already
available within JDK, I thought its natural if JDK could pick
Xalan-J's XSL 3 implementation and include that within JDK. I can
imagine that this may surely be time consuming for someone from JDK
team to integrate with JDK. XSLT 1.0's use I think is very less these
days particularly for new XML projects, due to vast improvements in
language features offered by XSLT 3.0 and XPath 3.1.

IMHO, I wrote all the XSL 3 implementation code (and solved various
XSL 3 implementation bugs reported by community on Xalan-J's dev
forum) within Xalan-J's XSL 3 dev respos branch, enhancing upon
Xalan-J's XSLT 1.0 implementation. From my point of view, I'll be
happy if JDK could include Xalan-J's XSL 3 implementation.

I even wrote following two online articles on xml.com about few of XSL
3 language features, and how they're implemented within Xalan-J,
https://www.xml.com/articles/2024/07/22/string-analysis-with-analyze-string/
https://www.xml.com/articles/2023/12/05/xml-path-language-xpath-higher-order-functions/


Many thanks.


--
Regards,
Mukul Gandhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250226/404144a7/attachment.htm>

From ayang at openjdk.org  Thu Feb 27 18:34:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 27 Feb 2025 18:34:14 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v2]
In-Reply-To: <sATIRzYvi1wLv1tzkXOuwBN2F2YKy7SLSxaU6mnPWTg=.93b86875-3f5f-4ffe-91f0-a59ef68b2157@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <sATIRzYvi1wLv1tzkXOuwBN2F2YKy7SLSxaU6mnPWTg=.93b86875-3f5f-4ffe-91f0-a59ef68b2157@github.com>
Message-ID: <3zmj-DeeRyPMHc32YnvfqACN0xJxLQ6jZZ7sd-Baa3w=.672912f6-e4a3-4679-b8a3-b7f6ad51589d@github.com>

On Tue, 25 Feb 2025 15:13:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
>> 
>> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
>> 
>> ### Current situation
>> 
>> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
>> 
>> The main reason for the current barrier is how g1 implements concurrent refinement:
>> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
>> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
>> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
>> 
>> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
>> 
>> 
>> // Filtering
>> if (region(@x.a) == region(y)) goto done; // same region check
>> if (y == null) goto done;     // null value check
>> if (card(@x.a) == young_card) goto done;  // write to young gen check
>> StoreLoad;                // synchronize
>> if (card(@x.a) == dirty_card) goto done;
>> 
>> *card(@x.a) = dirty
>> 
>> // Card tracking
>> enqueue(card-address(@x.a)) into thread-local-dcq;
>> if (thread-local-dcq is not full) goto done;
>> 
>> call runtime to move thread-local-dcq into dcqs
>> 
>> done:
>> 
>> 
>> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
>> 
>> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
>> 
>> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
>> 
>> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c...
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove unnecessarily added logging

src/hotspot/share/gc/g1/g1BarrierSet.hpp line 54:

> 52: // them, keeping the write barrier simple.
> 53: //
> 54: // The refinement threads mark cards in the the current collection set specially on the

"the the" typo.

src/hotspot/share/gc/g1/g1CardTable.inline.hpp line 47:

> 45: 
> 46: // Returns bits from a where mask is 0, and bits from b where mask is 1.
> 47: inline size_t blend(size_t a, size_t b, size_t mask) {

Can you provide some input/output examples in the doc?

src/hotspot/share/gc/g1/g1CardTableClaimTable.cpp line 45:

> 43: }
> 44: 
> 45: void G1CardTableClaimTable::initialize(size_t max_reserved_regions) {

Should the arg be `uint`?

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 280:

> 278:   assert_state(State::SweepRT);
> 279: 
> 280:   set_state_start_time();

This method is called in a loop; would that skew the state-starting time?

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 344:

> 342:     size_t _num_clean;
> 343:     size_t _num_dirty;
> 344:     size_t _num_to_cset;

Seem never read.

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 349:

> 347: 
> 348:     bool do_heap_region(G1HeapRegion* r) override {
> 349:       if (!r->is_free()) {

I am a bit lost on this closure; the intention seems to set unclaimed to all non-free regions, why can't this be done in one go, instead of first setting all regions to claimed (`reset_all_claims_to_claimed`), then set non-free ones unclaimed?

src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 116:

> 114: 
> 115:   // Current heap snapshot.
> 116:   G1CardTableClaimTable* _sweep_state;

Since this is a table, I wonder if we can name it "x_table" instead of "x_state".

src/hotspot/share/gc/g1/g1RemSet.cpp line 147:

> 145:     if (_contains[region]) {
> 146:       return;
> 147:     }

Indentation seems broken.

src/hotspot/share/gc/g1/g1RemSet.cpp line 830:

> 828:         size_t const start_idx = region_card_base_idx + claim.value();
> 829: 
> 830:         size_t* card_cur_card = (size_t*)card_table->byte_for_index(start_idx);

This var name should end with "_word", instead of "_card".

src/hotspot/share/gc/g1/g1RemSet.cpp line 1252:

> 1250:     G1ConcurrentRefineWorkState::snapshot_heap_into(&constructed);
> 1251:     claim = &constructed;
> 1252:   }

It's not super obvious to me why the "has_sweep_claims" checking needs to be on this level. Can `G1ConcurrentRefineWorkState` return a valid `G1CardTableClaimTable*` directly?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1974124792
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1971426039
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1973435950
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1974083760
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1973447654
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1973452168
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1974056492
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1973423400
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1974108760
PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1974134441

From huizhe.wang at oracle.com  Thu Feb 27 18:35:30 2025
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 27 Feb 2025 10:35:30 -0800
Subject: adding Xalan's XSL 3 implementation within jdk
In-Reply-To: <CABuuzNO58-iNcaE29133FUWVpz9jH-sCXfQQAZHu_eUiL_oeoA@mail.gmail.com>
References: <CABuuzNP66-_d7J=UKz2UBY17V2eVk=xvB5w4bRj4A5aEaDQXcw@mail.gmail.com>
 <CABuuzNPKrdhGyqD-FEP-SU7MS4T_7h1smMBg31G9V2LHcPoq=g@mail.gmail.com>
 <e6c986db-9816-4172-9589-e6ce08674dae@oracle.com>
 <CABuuzNO58-iNcaE29133FUWVpz9jH-sCXfQQAZHu_eUiL_oeoA@mail.gmail.com>
Message-ID: <deb2d908-450d-4a04-8fe9-e9cf65032748@oracle.com>

Hi Mukul,

Xalan-J's XSL 3 implementation has not been integrated into any Xalan 
releases. I understand it implemented most of the XSLT 3.0 
specification, but not all of them, esp. the Streaming feature. Was the 
incompleteness the reason why it was not included in an Xalan release? 
What's your assessment on the readiness for a formal release (or how 
much additional work is needed)? What are the conformance test results?

Also, do you have data showing how the Xalan-J's XSL 3 implementation is 
used in user applications? What are the feedback (or bug reports) from 
developers?

Thanks,

Joe


On 2/26/25 7:59 AM, Mukul Gandhi wrote:
> Hi Alan,
>      I've just seen this mail from you. Apologies for a delayed response.
>
> My mail box has had few issues due to the volume of mails that I get
> from mailing lists.
>
> On Sun, Feb 2, 2025 at 9:38?PM Alan Bateman <alan.bateman at oracle.com> wrote:
>
>> The stats for that branch suggest 5,845 changed files with 234,372 additions and 84,058 deletions. I can't easily tell how much of this would need to come into the jdk repo but this looks like a major update. If only 10% of this is applicable to the JDK then it still needs seems like a major update that would require a huge investment to audit and integrate this code. How much XML is in new applications developed in 2025? Only asking because it's an area that is surely much lower priority compared to all the other major investments right now. Maybe there are useful security or performance changes that would be useful to cherry pick instead? Finally, does this Xalan update work with the SPIs so that someone really looking for XSL 3 can just deploy it on the class path and module path?
> Ofcourse, anyone could use Xalan-J's XSL 3 implementation with JDK by
> placing Xalan jars on class path & module path.
>
> Since Xalan-J's XSLT 1.0 & XPath 1.0 implementations are already
> available within JDK, I thought its natural if JDK could pick
> Xalan-J's XSL 3 implementation and include that within JDK. I can
> imagine that this may surely be time consuming for someone from JDK
> team to integrate with JDK. XSLT 1.0's use I think is very less these
> days particularly for new XML projects, due to vast improvements in
> language features offered by XSLT 3.0 and XPath 3.1.
>
> IMHO, I wrote all the XSL 3 implementation code (and solved various
> XSL 3 implementation bugs reported by community on Xalan-J's dev
> forum) within Xalan-J's XSL 3 dev respos branch, enhancing upon
> Xalan-J's XSLT 1.0 implementation. From my point of view, I'll be
> happy if JDK could include Xalan-J's XSL 3 implementation.
>
> I even wrote following two online articles on xml.com about few of XSL
> 3 language features, and how they're implemented within Xalan-J,
> https://www.xml.com/articles/2024/07/22/string-analysis-with-analyze-string/
> https://www.xml.com/articles/2023/12/05/xml-path-language-xpath-higher-order-functions/
>
>
> Many thanks.
>
>

From duke at openjdk.org  Thu Feb 27 18:53:07 2025
From: duke at openjdk.org (duke)
Date: Thu, 27 Feb 2025 18:53:07 GMT
Subject: Withdrawn: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException
In-Reply-To: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
Message-ID: <CHKRHUx37DbMf5Rmw6G20v2RZMeRjTVJNDZolw5gOwU=.26adee25-6874-41bb-8144-a88a7c450514@github.com>

On Wed, 27 Mar 2024 17:36:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18522

From duke at openjdk.org  Thu Feb 27 18:58:06 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Thu, 27 Feb 2025 18:58:06 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v7]
In-Reply-To: <7k2QcVVhdkip4zjJdolGkHnyRF5K111tbovc-aEzbhc=.d0c2cc89-81d8-4069-86b2-76aef0ce29bb@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <7k2QcVVhdkip4zjJdolGkHnyRF5K111tbovc-aEzbhc=.d0c2cc89-81d8-4069-86b2-76aef0ce29bb@github.com>
Message-ID: <Mhge5WAMJMRFTWsH3VOrG19sW1tG-6g3yr3WRr30CzY=.380072d8-a24a-43c9-9622-108afac2db9a@github.com>

On Thu, 27 Feb 2025 12:46:36 GMT, David Beaumont <duke at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rewording notes and spec changes in docs.
>   Small change to read formatter once in streamhander methods.
>   Reverting Formatter doc changes for now.

src/java.logging/share/classes/java/util/logging/SocketHandler.java line 178:

> 176:         // JDK-8349206: Do NOT synchronize around the parent's publish() method.
> 177:         super.publish(record);
> 178:         flush();

May not matter, but flush should be called from synchronousPostWriteHook() as it was called under lock before this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1973622368

From duke at openjdk.org  Thu Feb 27 18:58:06 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Thu, 27 Feb 2025 18:58:06 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v9]
In-Reply-To: <wW98J6TwTCR2pdrTXdOEyX6MHZu7CkNq3vCYEZw9I9o=.243c5403-5be9-41fe-aab4-904b24d62462@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Pj4COzHIujrQIrdVZaPbYc0V4uDR9jBXAAmZ6iDdI0s=.6e94d34f-6d57-4dd1-b232-23c54f4bc4b1@github.com>
 <Xs0Wd1rYekZRiaPHys_89jY4TSXKwBhx8A-iz-jlYtU=.a9e83238-686a-4ef4-8ee0-81b3da941393@github.com>
 <U9dqVBjuudxFSY8JmJJKf2qAa78SJGHAqDncQhf_1T8=.e5a7ca03-f5d5-4eb8-8ef1-2ae70c38ffab@github.com>
 <wW98J6TwTCR2pdrTXdOEyX6MHZu7CkNq3vCYEZw9I9o=.243c5403-5be9-41fe-aab4-904b24d62462@github.com>
Message-ID: <waP0Lp2vilibQVwjkYn6fDMZPPqWR5m-8HhGc3PZZwY=.9fb550d1-75e4-4a46-a004-c9d8f6293cd3@github.com>

On Tue, 25 Feb 2025 01:24:54 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> As for the example you gave there, that is interesting. Keeping an unformatted log record around for any time after the log statement that created it has exited would be quite problematic (it prevents GC of arbitrary things).
>> 
>> If I were doing some kind of summary tail entry, I'd pull, format (user args) and cache anything I needed out of the log record when I had it, but not keep it around. Then when the tail is written I'd just have what I need ready to go.
>> 
>> But yes, right now, with or without this PR, that code looks like it's got a deadlock risk.
>
> Need to update to have single call to getFormatter().

>Keeping an unformatted log record around for any time after the log statement that created it has exited would be quite problematic (it prevents GC of arbitrary things).

I've always leaned on:
1. The words written in LogRecord API that once a record is given to the logging api it owns that record. Thefore, don't attach things to that record.  "Don't leave your belongings in the rental car when returning it."
3. Passing arbitrary objects to the logging API is a security risk because I can create a filter/handler/Formatter that casts the arguments and manipulates them. E.G. Map::clear, Map::put("user","root").
4. Logging api has supplier methods that allow callers to format arguments early on using String.format.
5. LogRecord records a timestamp. Passing string representation at time of logging both snapshots near the timestamp and makes a mutable argument safer for exposure to unknown classes.

That said, I'll probably create PRs for MailHandler and CollectorFormatter to optionally support deep cloning of the LogRecord via serialization before it is stored. Doing so would switch the params to string without tampering with the source record.  MemoryHander could do the same and effectively become a non-caching (pushLevel=ALL) TransformHandler to decorate Handers that over synchronize.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1973650209

From naoto at openjdk.org  Thu Feb 27 19:42:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Feb 2025 19:42:56 GMT
Subject: RFR: 4745837: Make grouping usage during parsing apparent in
 relevant NumberFormat methods [v2]
In-Reply-To: <ZiYza2xy8-y2i4woI1b5MjYVwUggTuquy-Ub6zK1oVU=.f7b02b65-266d-4cf4-97c5-b4d0a910d965@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
 <ZiYza2xy8-y2i4woI1b5MjYVwUggTuquy-Ub6zK1oVU=.f7b02b65-266d-4cf4-97c5-b4d0a910d965@github.com>
Message-ID: <eGssGU8zVetL6RF1bX-H50AusIo-UCnML-l8CS-tux0=.01a73266-841e-4ade-bedc-0d6b377f09fc@github.com>

On Thu, 27 Feb 2025 18:08:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.
>> 
>> Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto review - include strict parsing example. Also remove 'might' wording

src/java.base/share/classes/java/text/NumberFormat.java line 896:

> 894:      *   <li> Parsing {@code "1,234,567"} with grouping off and an implementation that
> 895:      *        implements strict parsing with {@link #isStrict()} returning {@code true}
> 896:      *        throws {@code ParseException}

Sorry for the nit, but I think "an implementation that implements strict parsing" can safely be removed without changing the context.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23813#discussion_r1974233971

From cushon at openjdk.org  Thu Feb 27 19:43:34 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 27 Feb 2025 19:43:34 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v9]
In-Reply-To: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
Message-ID: <_ziyFpDg0omKO6mnXP7OiR2cRI9hU-XY9s0YlN6Bc18=.6e9d6184-7689-403e-a390-48204ab2f338@github.com>

> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.

Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Update test/jdk/java/util/Collection/MOAT.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - Update copyright year
   
   and add the bug number to the modified test
 - Update unmodifiable map javadoc
 - Also throw UOE for mutators on keySet() and values()
   
   and add more test coverage to MOAT.
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - Check m.entrySet().hashCode() in MOAT
 - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
 - ... and 3 more: https://git.openjdk.org/jdk/compare/1522f869...d83ca7f3

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18522/files
  - new: https://git.openjdk.org/jdk/pull/18522/files/223164c4..d83ca7f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18522&range=07-08

  Stats: 317645 lines in 8435 files changed: 178168 ins; 107048 del; 32429 mod
  Patch: https://git.openjdk.org/jdk/pull/18522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18522/head:pull/18522

PR: https://git.openjdk.org/jdk/pull/18522

From jlu at openjdk.org  Thu Feb 27 19:52:13 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Feb 2025 19:52:13 GMT
Subject: RFR: 4745837: Make grouping usage during parsing apparent in
 relevant NumberFormat methods [v3]
In-Reply-To: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
Message-ID: <kDNySBaxIMOtEucLyIuL38UamV8WxYqHvJ6h5O7bZKw=.e419a0f8-1991-4891-a952-2e2527a7e6d2@github.com>

> Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.
> 
> Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  make strict example less wordy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23813/files
  - new: https://git.openjdk.org/jdk/pull/23813/files/8c4ff2eb..f36ec09d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23813&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23813&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23813.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23813/head:pull/23813

PR: https://git.openjdk.org/jdk/pull/23813

From jlu at openjdk.org  Thu Feb 27 19:52:13 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Feb 2025 19:52:13 GMT
Subject: RFR: 4745837: Make grouping usage during parsing apparent in
 relevant NumberFormat methods [v2]
In-Reply-To: <eGssGU8zVetL6RF1bX-H50AusIo-UCnML-l8CS-tux0=.01a73266-841e-4ade-bedc-0d6b377f09fc@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
 <ZiYza2xy8-y2i4woI1b5MjYVwUggTuquy-Ub6zK1oVU=.f7b02b65-266d-4cf4-97c5-b4d0a910d965@github.com>
 <eGssGU8zVetL6RF1bX-H50AusIo-UCnML-l8CS-tux0=.01a73266-841e-4ade-bedc-0d6b377f09fc@github.com>
Message-ID: <f7CB8wT97YIDl0VGLCOjiyUk9iDmEt_2Vmp6puN7oqc=.eee59c52-c4d6-4d06-8427-5914d169f967@github.com>

On Thu, 27 Feb 2025 19:39:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naoto review - include strict parsing example. Also remove 'might' wording
>
> src/java.base/share/classes/java/text/NumberFormat.java line 896:
> 
>> 894:      *   <li> Parsing {@code "1,234,567"} with grouping off and an implementation that
>> 895:      *        implements strict parsing with {@link #isStrict()} returning {@code true}
>> 896:      *        throws {@code ParseException}
> 
> Sorry for the nit, but I think "an implementation that implements strict parsing" can safely be removed without changing the context.

Yeah, it was a little wordy. Was worried users may not be aware that those `set/isStrict` methods need to be implemented, but the link is right there to `isStrict`, which makes it apparent they throw `UOE` by default. Shortened in https://github.com/openjdk/jdk/pull/23813/commits/f36ec09dd73ef2e88a87fa52658eb751072ed758.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23813#discussion_r1974246647

From vaivanov at openjdk.org  Thu Feb 27 19:53:00 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 27 Feb 2025 19:53:00 GMT
Subject: RFR: 8350701: [JMH] test foreign.AllocFromSliceTest failed with
 Exception for size>1024
In-Reply-To: <gHU0mnJCT_0ZTzWEGwmoyXcFuk_0BGJz1ULAWPpERKk=.ab3631d0-b381-47cb-9eea-8c1a5af4ac65@github.com>
References: <gHU0mnJCT_0ZTzWEGwmoyXcFuk_0BGJz1ULAWPpERKk=.ab3631d0-b381-47cb-9eea-8c1a5af4ac65@github.com>
Message-ID: <rJntro0AxY7GaN5aG08EZej-Xb4lBKYlr_KT5nszQF8=.67982e81-372b-46cb-85b1-86c63adbd818@github.com>

On Tue, 25 Feb 2025 21:35:22 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> The 'size' parameters was used instead of hardcoded constant to improve support for different sizes.

Thanks for your review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23785#issuecomment-2688965214

From duke at openjdk.org  Thu Feb 27 19:53:01 2025
From: duke at openjdk.org (duke)
Date: Thu, 27 Feb 2025 19:53:01 GMT
Subject: RFR: 8350701: [JMH] test foreign.AllocFromSliceTest failed with
 Exception for size>1024
In-Reply-To: <gHU0mnJCT_0ZTzWEGwmoyXcFuk_0BGJz1ULAWPpERKk=.ab3631d0-b381-47cb-9eea-8c1a5af4ac65@github.com>
References: <gHU0mnJCT_0ZTzWEGwmoyXcFuk_0BGJz1ULAWPpERKk=.ab3631d0-b381-47cb-9eea-8c1a5af4ac65@github.com>
Message-ID: <mmCz83zzrLV-1yG9WSdqzCMpte58steWiZhgRVTgRmk=.6bb36a56-0f1c-4402-9f97-a4ba3f85cbe6@github.com>

On Tue, 25 Feb 2025 21:35:22 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> The 'size' parameters was used instead of hardcoded constant to improve support for different sizes.

@IvaVladimir 
Your change (at version b45da29c5bf50c5961f59500cd22d84a35a09be4) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23785#issuecomment-2688967975

From liach at openjdk.org  Thu Feb 27 20:06:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 20:06:04 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v7]
In-Reply-To: <aSwqJgPFnys8JlNg9pRCSAyr7fV-iofjj4RMBELrHRU=.41e88406-57ba-4ef7-99fc-a8c51f0001dd@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <If4E-nt-VM_sg_7yTZnKfPD1wiKZaeVxYeONnR1AzPk=.34a8be90-522a-4d70-bbf1-44295e247a0d@github.com>
 <aSwqJgPFnys8JlNg9pRCSAyr7fV-iofjj4RMBELrHRU=.41e88406-57ba-4ef7-99fc-a8c51f0001dd@github.com>
Message-ID: <Q5eDrkX2KupVBXJe5dlfe2TjNxjT8VoHNsHwerJLrmo=.9b5c8804-4716-4b2a-8228-c0872c1bcd3c@github.com>

On Thu, 11 Jul 2024 06:24:31 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/util/Collection/MOAT.java
>>   
>>   Co-authored-by: Chen Liang <liach at openjdk.org>
>
> Please see the analysis I just added to the bug report:
> 
> https://bugs.openjdk.org/browse/JDK-8328821?focusedId=14688968&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14688968

@stuart-marks Do you think we should target this for early 26 to allow more testing and to avoid impacts on LTS releases?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2688994445

From liach at openjdk.org  Thu Feb 27 20:33:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 20:33:34 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v9]
In-Reply-To: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
Message-ID: <NQhDJ4V_syZAPJMLxP4zj0EDTrFkRCLS-R5OJwHP5Rg=.cec06982-e514-427e-8ced-86420f1b22f3@github.com>

> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
> 
> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
> 
> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
> 
> Here are some actions:
> 1. Add section for hierarchy overview for both Type and AnnotatedType
> 2. Specify the underlying type for different AnnotatedType subinterfaces
> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
> 5. Minor improvements to `ParameterizedType::getRawType`
> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
> 
> ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html
> Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/java.base/java/lang/reflect/package-summary.html
> 
> Please review the associated CSR as well.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:

 - TypeVariable fixup
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Notes about the design
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Year and typos
 - Merge branch 'm5' into doc/owner-type
 - Problems with owner type, kevin suggestions
 - Slightly improve snippet
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - ... and 11 more: https://git.openjdk.org/jdk/compare/7828c8a0...c237c2ad

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19977/files
  - new: https://git.openjdk.org/jdk/pull/19977/files/4f4d9b91..c237c2ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=07-08

  Stats: 211326 lines in 5010 files changed: 106495 ins; 83078 del; 21753 mod
  Patch: https://git.openjdk.org/jdk/pull/19977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19977/head:pull/19977

PR: https://git.openjdk.org/jdk/pull/19977

From liach at openjdk.org  Thu Feb 27 20:33:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 20:33:37 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v8]
In-Reply-To: <qy51peD9h2DREHKx_d4zS_yVCtDEBgyQLocJaiex1qg=.f2526cf0-b0f6-41f4-a5de-0edcc86a8087@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
 <qy51peD9h2DREHKx_d4zS_yVCtDEBgyQLocJaiex1qg=.f2526cf0-b0f6-41f4-a5de-0edcc86a8087@github.com>
Message-ID: <m45qrykRnqYX6g6IyKTjq3sKvXG8gLsMIpyhwIz7yRE=.3ac0e62e-f280-4c9b-be02-fffb175f6098@github.com>

On Fri, 10 Jan 2025 21:53:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
>> 
>> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
>> 
>> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
>> 
>> Here are some actions:
>> 1. Add section for hierarchy overview for both Type and AnnotatedType
>> 2. Specify the underlying type for different AnnotatedType subinterfaces
>> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
>> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
>> 5. Minor improvements to `ParameterizedType::getRawType`
>> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
>> 
>> ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html
>> Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/java.base/java/lang/reflect/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Year and typos
>  - Merge branch 'm5' into doc/owner-type
>  - Problems with owner type, kevin suggestions
>  - Slightly improve snippet
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Improve getRawType
>  - Intro and other various improvements
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Cleanup
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/878b88cd...4f4d9b91

I have updated the CR preview and did some minor updates; please review again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19977#issuecomment-2689045628

From mik3hall at gmail.com  Thu Feb 27 20:36:28 2025
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 27 Feb 2025 14:36:28 -0600
Subject: RFR: 8350594: Misleading warning about install dir for DMG
 packaging
In-Reply-To: <A51B1985-9798-4A34-8766-1283CE962A0F@gmail.com>
References: <TufjIR2DEuWfCD01cvK3joWPm21nWew09iGEfaFWYH8=.c84b177c-0814-437f-8d9c-2600541c7e45@github.com>
 <AF89236A-84C2-481D-8A1A-95596C27AE1D@gmail.com>
 <TlvQzvzAvExG0dtuqjyT7CegIBi5JY9_jdQBxxr82yw=.19e394f5-223c-4ba5-b55d-55127da3f1d6@github.com>
 <072D1D1F-9B4B-44C2-ADAD-8D6615E30550@gmail.com>
 <1F51D6B2-6FFC-4FFB-8D24-2DBCB864E2AD@gmail.com>
 <70F070BA-76CB-4D4F-810C-3D5AC42AAE1B@gmail.com>
 <8BE5BA17-374B-4A74-B0DE-EE586251FDB7@gmail.com>
 <3E3F5A19-7AD9-48AD-9D6C-86B03BB14479@gmail.com>
 <79e7fe0a-5a28-4660-814e-b8c1fd2a426e@oracle.com>
 <A51B1985-9798-4A34-8766-1283CE962A0F@gmail.com>
Message-ID: <3F7631AF-BA96-445B-9254-277C37D2BB74@gmail.com>



> On Feb 27, 2025, at 11:47?AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Now, mostly about how the JavaVirtualMachines MacOS specific JRE?s might be built.

Copied the MacOS directory and Info.plist file from another JavaVirtualMachines bundle. 

Updated the Info.plist version settings from the prior version to jdk 25.

java -version
openjdk version "25-internal" 2025-09-16
OpenJDK Runtime Environment (build 25-internal-adhoc.mjh.jdk)
OpenJDK 64-Bit Server VM (build 25-internal-adhoc.mjh.jdk, mixed mode)

So the above mystery is solved. Those files are sufficient for a Mac JavaVirtualMachines ready JRE. 
The version settings in the Info.plist must determine how it selects the latest and greatest.

There is no _CodeSignature file. I?m not sure what that might impact. A codesign command could probably be figured out.

So, there are really no jpackage concerns.

For an assist on --runtime-image for JavaVirtualMachines ready copies an enhancement could be provide these files and maybe do the codesign, if the provided runtime seems to need them.

Thanks again.

Mike
  

  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250227/5a615180/attachment-0001.htm>

From vaivanov at openjdk.org  Thu Feb 27 20:39:04 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 27 Feb 2025 20:39:04 GMT
Subject: Integrated: 8350701: [JMH] test foreign.AllocFromSliceTest failed with
 Exception for size>1024
In-Reply-To: <gHU0mnJCT_0ZTzWEGwmoyXcFuk_0BGJz1ULAWPpERKk=.ab3631d0-b381-47cb-9eea-8c1a5af4ac65@github.com>
References: <gHU0mnJCT_0ZTzWEGwmoyXcFuk_0BGJz1ULAWPpERKk=.ab3631d0-b381-47cb-9eea-8c1a5af4ac65@github.com>
Message-ID: <y5YcLfEUNnpz5fzCbLtXDiF3qH3eKpNxtnTdCKwVVQ4=.20fa8b45-2e65-4f35-8c54-82707b8fd8f1@github.com>

On Tue, 25 Feb 2025 21:35:22 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> The 'size' parameters was used instead of hardcoded constant to improve support for different sizes.

This pull request has now been integrated.

Changeset: f1398ecb
Author:    Vladimir Ivanov <vaivanov at openjdk.org>
Committer: Derek White <drwhite at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1398ecbe4a650d8d8c21fabb1b8e2e9600fdfec
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8350701: [JMH] test foreign.AllocFromSliceTest failed with Exception for size>1024

Reviewed-by: pminborg

-------------

PR: https://git.openjdk.org/jdk/pull/23785

From drwhite at openjdk.org  Thu Feb 27 20:39:04 2025
From: drwhite at openjdk.org (Derek White)
Date: Thu, 27 Feb 2025 20:39:04 GMT
Subject: RFR: 8350701: [JMH] test foreign.AllocFromSliceTest failed with
 Exception for size>1024
In-Reply-To: <gHU0mnJCT_0ZTzWEGwmoyXcFuk_0BGJz1ULAWPpERKk=.ab3631d0-b381-47cb-9eea-8c1a5af4ac65@github.com>
References: <gHU0mnJCT_0ZTzWEGwmoyXcFuk_0BGJz1ULAWPpERKk=.ab3631d0-b381-47cb-9eea-8c1a5af4ac65@github.com>
Message-ID: <iLknOhyE__RSImcD1EnqpCP3l9dR1pUqUMNPZEsDxao=.54bbe788-bdbc-4d93-b1a4-f49760f4d8a2@github.com>

On Tue, 25 Feb 2025 21:35:22 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> The 'size' parameters was used instead of hardcoded constant to improve support for different sizes.

looks good!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23785#issuecomment-2689055310

From vklang at openjdk.org  Thu Feb 27 20:52:03 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 27 Feb 2025 20:52:03 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v2]
In-Reply-To: <ENJYX5JbrLeyXN2uoSJgrntY6mW_0bZsre6CEQEeDDg=.a2078d52-ebf7-4f8b-bfad-a86bedfeea1b@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <ENJYX5JbrLeyXN2uoSJgrntY6mW_0bZsre6CEQEeDDg=.a2078d52-ebf7-4f8b-bfad-a86bedfeea1b@github.com>
Message-ID: <GTNLMHyqnA-cnBEXQ_Hss69Cz182Sf1L0Tddo470RU8=.5937798b-f591-4071-ab3e-9754a3309d5c@github.com>

On Mon, 24 Feb 2025 16:21:33 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
>> 
>> Modification:
>> Add detail error messages.
>> 
>> Result:
>> Helpful messages.
>
> He-Pin(kerr) has updated the pull request incrementally with one additional commit since the last revision:
> 
>   chore: update tests

test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java line 1158:

> 1156:             shouldThrow();
> 1157:         } catch (NullPointerException success) {
> 1158:             Assert.assertEquals("threadFactory", success.getMessage());

This seems wrong.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r1974318175

From liach at openjdk.org  Thu Feb 27 21:03:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 21:03:01 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v2]
In-Reply-To: <lrTpt9-GhQTRDEeVu8p_fanRKFfwNR6DqHOiwHVnhHc=.9c5928e9-3b77-41f8-ae36-39c685626eb8@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <ENJYX5JbrLeyXN2uoSJgrntY6mW_0bZsre6CEQEeDDg=.a2078d52-ebf7-4f8b-bfad-a86bedfeea1b@github.com>
 <lrTpt9-GhQTRDEeVu8p_fanRKFfwNR6DqHOiwHVnhHc=.9c5928e9-3b77-41f8-ae36-39c685626eb8@github.com>
Message-ID: <SkLb6atUIuT45q31V6BY-lh4BTBt6L8UCpRdsxiKAl0=.66f24e29-059d-494d-a0db-813763005978@github.com>

On Wed, 26 Feb 2025 13:40:31 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> He-Pin(kerr) has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   chore: update tests
>
> src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java line 1513:
> 
>> 1511:         } else if (corePoolSize > maximumPoolSize) {
>> 1512:             throw new IllegalArgumentException("corePoolSize must be less than or equal to maximumPoolSize, " +
>> 1513:                 "but got maximumPoolSize:" + maximumPoolSize + " corePoolSize :" + corePoolSize);
> 
> Suggestion:
> 
>                 "but got maximumPoolSize: " + maximumPoolSize + ", and corePoolSize : " + corePoolSize);

I wish we can have a bulit-in IAE formatter for `Preconditions` and then we can call `Preconditions.checkIndex(corePoolSize, maximumPoolSize, Precondtions.IAE_FORMATTER);`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r1974330598

From liach at openjdk.org  Thu Feb 27 21:12:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 21:12:05 GMT
Subject: RFR: 8347491: IllegalArgumentationException thrown by
 ThreadPoolExecutor doesn't have a useful message [v2]
In-Reply-To: <ENJYX5JbrLeyXN2uoSJgrntY6mW_0bZsre6CEQEeDDg=.a2078d52-ebf7-4f8b-bfad-a86bedfeea1b@github.com>
References: <sbNV8OcbPD1iBenC8lZvt1xVmBpbpp3ZrErrB5lQZ0w=.511b8995-ed69-4395-b1f2-2a0c7f5f10a6@github.com>
 <ENJYX5JbrLeyXN2uoSJgrntY6mW_0bZsre6CEQEeDDg=.a2078d52-ebf7-4f8b-bfad-a86bedfeea1b@github.com>
Message-ID: <kIda9_7_SQGHpXS2HkMSEBRqoWmRNQVwT3a_roMvBP8=.6df21611-33d6-49dd-9f3c-0a1a811333a2@github.com>

On Mon, 24 Feb 2025 16:21:33 GMT, He-Pin(kerr) <duke at openjdk.org> wrote:

>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful.
>> 
>> Modification:
>> Add detail error messages.
>> 
>> Result:
>> Helpful messages.
>
> He-Pin(kerr) has updated the pull request incrementally with one additional commit since the last revision:
> 
>   chore: update tests

test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java line 746:

> 744:             shouldThrow();
> 745:         } catch (IllegalArgumentException success) {
> 746:             Assert.assertEquals("corePoolSize must be non-negative, but got -1", success.getMessage());

I think just checking `corePoolSize` is contained in the error message is fine. Also printing the exact corePoolSize value might be unsafe.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23050#discussion_r1974340646

From liach at openjdk.org  Thu Feb 27 21:26:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 21:26:03 GMT
Subject: Withdrawn: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <u1vcmfWGYtRKa5FXTtCFIR8sShpbFRPRIYUycQEHKto=.28a878a0-8f79-4c43-b649-c4d10612ecd3@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23478

From liach at openjdk.org  Thu Feb 27 21:26:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 21:26:03 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <SkOkshE90_83MXQqI6i2u8P9di1-_fy5nogdpCFLZKs=.3dd67796-83c0-4d32-8a87-b09a88727e82@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

I think I should withdraw this patch: the multi-byte access is used for 2 purposes: to read actual larger data or just to read multiple bytes for performance, and ByteArray is for the former. We should probably look at vectors for the multiple byte access purpose.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23478#issuecomment-2689141951

From ihse at openjdk.org  Thu Feb 27 21:42:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 27 Feb 2025 21:42:57 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <U6YRQCFntBx0N-of4aDSWdoDJGMvII72W3d2w8QVIXc=.12012b0c-580a-45d6-a45d-5e418fd29459@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <C-MYCDaVr2YJLZHDABKKZ784_rLxla6e6hUYxv9oa9U=.a69932b7-f057-4b67-bbd7-f49aac88a28b@github.com>
 <PXb8sEre4Eb6HduJpADX6bfvY9oP8LzF_7oMmm8vJAk=.087b442f-360a-4d00-b3a7-3e261b82829a@github.com>
 <lK8OE6nUsQnMkSzAEEA8cR7nddUjlj91pt11HpNJO2Y=.c3113ec2-d158-45d2-ba31-e441355ffa75@github.com>
 <-wgA3ZuOnRPwj0WaR2DZdvf-AXIAZYJtfHTNa6CKnNk=.d67aff51-2877-4d26-87e3-320fb989a807@github.com>
 <pwk1EGafGj4o6g2leboeuL9grLvCRv7jYl_89xx4MgM=.a910f73a-e91f-485b-a68e-89725a1d3751@github.com>
 <iEmMwagKTp1hzZBBecqENWyojc0ZFQDsNjJRRsjAqEk=.5a5d4494-7236-488d-ae53-2e6283ed6546@github.com>
 <U6YRQCFntBx0N-of4aDSWdoDJGMvII72W3d2w8QVIXc=.12012b0c-580a-45d6-a45d-5e418fd29459@github.com>
Message-ID: <AljoLE8BPJXkjB2tx-NEzV20uHyMdYah6B7ck31RR-Q=.b3cf59fe-e58f-406b-8253-55eeefd2380a@github.com>

On Thu, 27 Feb 2025 15:33:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> No, there is nothing for that. There is a conceptual leap between determining how to compile hotspot and how to decide which modules to include in the image, and is not at all clear how you would want to integrate these two. Like, should you exclude models by saying a hotspot feature is not needed? Or, should you modify how hotspot is compiled by saying that you want to exclude a model?
>> 
>> I think it is better left to whoever configures the build to figure such things out.
>
>> No, there is nothing for that. There is a conceptual leap between determining how to compile hotspot and how to decide which modules to include in the image, and is not at all clear how you would want to integrate these two. Like, should you exclude models by saying a hotspot feature is not needed? Or, should you modify how hotspot is compiled by saying that you want to exclude a model?
>> 
>> I think it is better left to whoever configures the build to figure such things out.
> 
> I was just following up to the idea stated above 
> 'If the only VM to be built is the minimal VM then maybe it should filter down the set of modules to include'
> but this is not so easy it seems.
> Regarding - 'should you exclude models (modules?) by saying a hotspot feature is not needed?'  excluding the JVM feature  JFR means that the jfr related modules are broken/not (fully) working.
> Excluding them would probably be logical (and also help the tests because quite a lot of tests do not have requires vm.hasJFR or requires vm.jvmti to check if the test makes sense on some JVM with limited features) .

If you want to see that implemented, the first step is to open an enhancement issue on JBS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23805#discussion_r1974374119

From psandoz at openjdk.org  Thu Feb 27 23:33:04 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 27 Feb 2025 23:33:04 GMT
Subject: RFR: 8350748: VectorAPI: Method "checkMaskFromIndexSize" should be
 force inlined
In-Reply-To: <18Q2Zl2ip_eFS_Y4fflgS8XYBkbwCZ468DIjP3KwhDE=.240f4182-4b02-4fac-97c8-ac659427e4a8@github.com>
References: <18Q2Zl2ip_eFS_Y4fflgS8XYBkbwCZ468DIjP3KwhDE=.240f4182-4b02-4fac-97c8-ac659427e4a8@github.com>
Message-ID: <PMt5WDuazSKUSP8zT1hQ8sLOMNNWApUxakP8cts8IDw=.503cfefc-746d-45d1-912d-e00ef0d6376b@github.com>

On Thu, 27 Feb 2025 06:43:19 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Method `checkMaskFromIndexSize` is called by some vector masked APIs like `fromArray/intoArray/fromMemorySegment/...`. It is used to check whether the index of any active lanes in a mask will reach out of the boundary of the given Array/MemorySegment. This function should be force inlined, or a VectorMask object is generated once the function call is not inlined by C2 compiler, which affects the API performance a lot.
> 
> This patch changed to call the `VectorMask.checkFromIndexSize` method directly inside of these APIs instead of `checkMaskFromIndexSize`. Since it has added the `@ForceInline` annotation already, it will be inlined and intrinsified by C2. And then the expected vector instructions can be generated. With this change, the unused `checkMaskFromIndexSize` can be removed.
> 
> Performance of some JMH benchmarks can improve up to 14x on a NVIDIA Grace CPU (AArch64 SVE2, 128-bit vectors). We can also observe the similar performance improvement on a Intel CPU which supports AVX512.
> 
> Following is the performance data on Grace:
> 
> 
> Benchmark                                             Mode  Cnt  Units     Before      After   Gain
> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE      thrpt   30  ops/ms  31544.304  31610.598  1.002
> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE    thrpt   30  ops/ms   3896.202   3903.249  1.001
> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE     thrpt   30  ops/ms    570.415   7174.320  12.57
> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE       thrpt   30  ops/ms    566.694   7193.520  12.69
> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE      thrpt   30  ops/ms   3899.269   3878.258  0.994
> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE     thrpt   30  ops/ms   1134.301  16053.847  14.15
> StoreMaskedIOOBEBenchmark.byteStoreArrayMaskIOOBE    thrpt   30  ops/ms  26449.558  28699.480  1.085
> StoreMaskedIOOBEBenchmark.doubleStoreArrayMaskIOOBE  thrpt   30  ops/ms   1922.167   5781.077  3.007
> StoreMaskedIOOBEBenchmark.floatStoreArrayMaskIOOBE   thrpt   30  ops/ms   3784.190  11789.276  3.115
> StoreMaskedIOOBEBenchmark.intStoreArrayMaskIOOBE     thrpt   30  ops/ms   3694.082  15633.547  4.232
> StoreMaskedIOOBEBenchmark.longStoreArrayMaskIOOBE    thrpt   30  ops/ms   1966.956   6049.790  3.075
> StoreMaskedIOOBEBenchmark.shortStoreArrayMaskIOOBE   thrpt   30  ops/ms   7647.309  27412.387  3.584

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23817#pullrequestreview-2649322190

From almatvee at openjdk.org  Thu Feb 27 23:58:58 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 27 Feb 2025 23:58:58 GMT
Subject: RFR: 8350013: Add a test for JDK-8150442
In-Reply-To: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>
References: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>
Message-ID: <nvOZNKtL0FDcOwKUnMPoyr545iekkcSyBFh0GQx6KmY=.5e03279f-3dfc-45b9-83b7-8664c311d134@github.com>

On Thu, 27 Feb 2025 14:17:30 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add a test to verify jpackage is using a custom MSI condition blocking package installation depending on the version of Windows where the package installer runs. Support for this MSI condition was added in [JDK-8150442](https://bugs.openjdk.org/browse/JDK-8150442).
> 
> The test adds an unconditionally failing OS-version MSI condition to the resource directory. MSI installer using this condition should always fail. The exit code of the failed installation would be 1603. Extended error information can be dug in the MSI log file. To make the test work, the following changes to jpackage test lib have been made:
>  - Support non-0 exit code from MSI install handler. Support for non-0 exit codes was added to install handlers of all other types too. Added `PackageTest.setExpectedInstallExitCode(int)` method to configure the expected exit code of a package installation;
>  - Support using msi log files when MSI and EXE packages get installed, unpacked, or uninstalled. Added `PackageTest.createMsiLog(boolean)` to enable or disable creation of msi log files in a PackageTest instance and `Optional<Path> JPackageCommand.winMsiLogFile()` to access the current log file from the callbacks registered with the PackageTest instance.
> 
> Added tests for PackageTest class (PackageTestTest).
> 
> Additionally, improved the code in WindowsHelper detecting paths to Start Menu, Desktop, and other common paths. Previously, it relied on reading these paths from the registry. On some machines, required registry keys are not available. The code now will call .NET `Environment.GetFolderPath()` function through powershell if a registry key is missing.

Looks good with minor comments.

test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/PackageTestTest.java line 407:

> 405: 
> 406:         void configureUninstallVerifiers(PackageTest test, Consumer<Verifiable> verifiableAccumulator) {
> 407:             for (final var verifier  : uninstallVerifiers) {

Extra space after `verifier`.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java line 493:

> 491:                     TKit.trace(String.format("No handler of [%s] action for %s command",
> 492:                             action, cmd.getPrintableCommandLine()));
> 493:                     return;

Do we really need `return` here and at line 495? Also, do you think it might be better to make `switch` consistent? For example this one uses `->` and below `:`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23825#pullrequestreview-2649270868
PR Review Comment: https://git.openjdk.org/jdk/pull/23825#discussion_r1974455774
PR Review Comment: https://git.openjdk.org/jdk/pull/23825#discussion_r1974505960

From smarks at openjdk.org  Fri Feb 28 01:04:01 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 28 Feb 2025 01:04:01 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v7]
In-Reply-To: <Mhge5WAMJMRFTWsH3VOrG19sW1tG-6g3yr3WRr30CzY=.380072d8-a24a-43c9-9622-108afac2db9a@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <7k2QcVVhdkip4zjJdolGkHnyRF5K111tbovc-aEzbhc=.d0c2cc89-81d8-4069-86b2-76aef0ce29bb@github.com>
 <Mhge5WAMJMRFTWsH3VOrG19sW1tG-6g3yr3WRr30CzY=.380072d8-a24a-43c9-9622-108afac2db9a@github.com>
Message-ID: <GQnb1hcSEe1yT-2tKDWqLAJzoNqJYztg7xEs27Mhplc=.abce117b-7ec9-46a9-8dc6-7213bced7c0f@github.com>

On Thu, 27 Feb 2025 13:51:27 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rewording notes and spec changes in docs.
>>   Small change to read formatter once in streamhander methods.
>>   Reverting Formatter doc changes for now.
>
> src/java.logging/share/classes/java/util/logging/SocketHandler.java line 178:
> 
>> 176:         // JDK-8349206: Do NOT synchronize around the parent's publish() method.
>> 177:         super.publish(record);
>> 178:         flush();
> 
> May not matter, but flush should be called from synchronousPostWriteHook() as it was called under lock before this change.

It's correct that flush() was called under the lock previously, but there's no additional logic in this method, so I don't think it matters. If additional stuff is published it'll all get flushed eventually anyway. I note that ConsoleHandler.publish() flushes without holding the lock.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1974571069

From smarks at openjdk.org  Fri Feb 28 01:04:02 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 28 Feb 2025 01:04:02 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v6]
In-Reply-To: <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <1_MYqF28HW1ASAglx6I3PhgIff6ZLN_mcCqOWQSSIxg=.942bd5e5-56a4-4cbe-b551-536c714297f7@github.com>
 <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
Message-ID: <y-nl6FTkMMDo2sX5-se2Z50OYNl_0fWy9og2-uTUBL8=.e206db6c-28d4-4069-8582-31f037ec142e@github.com>

On Tue, 25 Feb 2025 01:21:40 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweaking @implNote for better rendering.
>
> src/java.logging/share/classes/java/util/logging/StreamHandler.java line 184:
> 
>> 182:      *
>> 183:      * @param  record  description of the log event. A null record is
>> 184:      *                 silently ignored and is not published
> 
> There needs to be an `@implSpec` somewhere in this method's javadoc comment that explains the locking policy here very crisply for subclassers. Specifically (1) the lock on `this` is not held during formatting; (2) the lock on `this` is held during publishing; (3) subclassers must not lock on `this` while calling super.publish() because it would contravene (1).

OK, this change is good. The only thing I'd say is that subclasses must not override publish() with a synchronized method AND ALSO call super.publish().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1974575569

From smarks at openjdk.org  Fri Feb 28 01:11:58 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 28 Feb 2025 01:11:58 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v9]
In-Reply-To: <i6qWEAJ6su3eRLy4wqylbVl0hG88eTMyr2zKP4_07cg=.6eeffc2d-9dd2-4c12-89c6-f53624f4ca27@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <i6qWEAJ6su3eRLy4wqylbVl0hG88eTMyr2zKP4_07cg=.6eeffc2d-9dd2-4c12-89c6-f53624f4ca27@github.com>
Message-ID: <g11UeTAkmQ1Q2Mynb7Uzndman_sEJQut9bz5K7XBdfA=.6a8a67f2-6c28-4086-a249-3d4ec14e9633@github.com>

On Thu, 27 Feb 2025 17:15:56 GMT, David Beaumont <duke at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix @implNote to @apiNote.

src/java.logging/share/classes/java/util/logging/StreamHandler.java line 288:

> 286:                     doneHeader = true;
> 287:                 }
> 288:                 writer.write(formatter.getTail(this));

Strictly speaking not necessary, since this is called with the lock held (as noted above!) but it's a reasonably good multi-threaded coding practice to fetch values into a local variable and reuse them, so I think this is ok as modified.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1974584279

From smarks at openjdk.org  Fri Feb 28 01:15:02 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 28 Feb 2025 01:15:02 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v9]
In-Reply-To: <i6qWEAJ6su3eRLy4wqylbVl0hG88eTMyr2zKP4_07cg=.6eeffc2d-9dd2-4c12-89c6-f53624f4ca27@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <i6qWEAJ6su3eRLy4wqylbVl0hG88eTMyr2zKP4_07cg=.6eeffc2d-9dd2-4c12-89c6-f53624f4ca27@github.com>
Message-ID: <eYTuO9yMpqiV9nJGHcB7eDIIXvVwxcc92RPcETQdqs4=.a3704d8f-f6ca-4a57-a110-9fb77665d71d@github.com>

On Thu, 27 Feb 2025 17:15:56 GMT, David Beaumont <duke at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix @implNote to @apiNote.

OK I think this is getting close. Only two small issues remain from my point of view:

1. small updates to `@implSpec` in StreamHandler.publish()
2. small update to be a bit more specific in the comment above StreamHandler.flushAndClose().

Unfortunately they require the CSR to be updated again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23491#issuecomment-2689476844

From asemenyuk at openjdk.org  Fri Feb 28 01:21:20 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 28 Feb 2025 01:21:20 GMT
Subject: RFR: 8350013: Add a test for JDK-8150442 [v2]
In-Reply-To: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>
References: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>
Message-ID: <2Yw3k5RFz3UaInBjN9US_fRiyvqsn-4R9wzzKHfyLN0=.c2de4d20-6f6a-4335-a9e6-14ef6124a825@github.com>

> Add a test to verify jpackage is using a custom MSI condition blocking package installation depending on the version of Windows where the package installer runs. Support for this MSI condition was added in [JDK-8150442](https://bugs.openjdk.org/browse/JDK-8150442).
> 
> The test adds an unconditionally failing OS-version MSI condition to the resource directory. MSI installer using this condition should always fail. The exit code of the failed installation would be 1603. Extended error information can be dug in the MSI log file. To make the test work, the following changes to jpackage test lib have been made:
>  - Support non-0 exit code from MSI install handler. Support for non-0 exit codes was added to install handlers of all other types too. Added `PackageTest.setExpectedInstallExitCode(int)` method to configure the expected exit code of a package installation;
>  - Support using msi log files when MSI and EXE packages get installed, unpacked, or uninstalled. Added `PackageTest.createMsiLog(boolean)` to enable or disable creation of msi log files in a PackageTest instance and `Optional<Path> JPackageCommand.winMsiLogFile()` to access the current log file from the callbacks registered with the PackageTest instance.
> 
> Added tests for PackageTest class (PackageTestTest).
> 
> Additionally, improved the code in WindowsHelper detecting paths to Start Menu, Desktop, and other common paths. Previously, it relied on reading these paths from the registry. On some machines, required registry keys are not available. The code now will call .NET `Environment.GetFolderPath()` function through powershell if a registry key is missing.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23825/files
  - new: https://git.openjdk.org/jdk/pull/23825/files/a27cb527..43ff8704

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23825&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23825&range=00-01

  Stats: 34 lines in 4 files changed: 2 ins; 8 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/23825.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23825/head:pull/23825

PR: https://git.openjdk.org/jdk/pull/23825

From asemenyuk at openjdk.org  Fri Feb 28 01:21:20 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 28 Feb 2025 01:21:20 GMT
Subject: RFR: 8350013: Add a test for JDK-8150442 [v2]
In-Reply-To: <nvOZNKtL0FDcOwKUnMPoyr545iekkcSyBFh0GQx6KmY=.5e03279f-3dfc-45b9-83b7-8664c311d134@github.com>
References: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>
 <nvOZNKtL0FDcOwKUnMPoyr545iekkcSyBFh0GQx6KmY=.5e03279f-3dfc-45b9-83b7-8664c311d134@github.com>
Message-ID: <6UwI1GaSbmtMU5XTT6LlBS1sTnwI-fXfBoWr4SVfitA=.5e04b700-5adc-40a7-9b0b-674733d9f6af@github.com>

On Thu, 27 Feb 2025 23:48:19 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Do we really need return here and at line 495?

Yes. It should exit the function early to avoid jumping in the next `switch` block.

> do you think it might be better to make `switch` consistent?

Totally!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23825#discussion_r1974589413

From vaivanov at openjdk.org  Fri Feb 28 01:25:43 2025
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 28 Feb 2025 01:25:43 GMT
Subject: RFR: 8350909: [JMH] test ThreadOnSpinWaitShared failed for 2 threads
 config
Message-ID: <P18TJiZtacKXtORGgiT6-QQx8ELMJZtNQBhH0F3Ni6c=.5577d909-348e-444c-9c0a-9b6832070602@github.com>

The scope was updated to support multithread configuration (jmh option '-t 2') . No other changes needed.

-------------

Commit messages:
 - JDK-8350909 [JMH] test ThreadOnSpinWaitShared failed for 2 threads config

Changes: https://git.openjdk.org/jdk/pull/23834/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23834&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350909
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23834.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23834/head:pull/23834

PR: https://git.openjdk.org/jdk/pull/23834

From dholmes at openjdk.org  Fri Feb 28 01:31:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Feb 2025 01:31:57 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>
Message-ID: <kZF8APp_EbniU8QWq-dev6ImxAv9_K6qeMH87zM1Iyw=.dc0d7c15-cda0-40e8-8c5a-b79039e61029@github.com>

On Thu, 27 Feb 2025 10:19:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> While testing a bit with a minimal JVM, it has been noticed that some java/lang jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright years

IIRC you still need the modules for the unsupported pieces because the API's themselves are not optional and you have to be able to ask if something is supported.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23805#issuecomment-2689494726

From almatvee at openjdk.org  Fri Feb 28 01:36:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 28 Feb 2025 01:36:57 GMT
Subject: RFR: 8350013: Add a test for JDK-8150442 [v2]
In-Reply-To: <6UwI1GaSbmtMU5XTT6LlBS1sTnwI-fXfBoWr4SVfitA=.5e04b700-5adc-40a7-9b0b-674733d9f6af@github.com>
References: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>
 <nvOZNKtL0FDcOwKUnMPoyr545iekkcSyBFh0GQx6KmY=.5e03279f-3dfc-45b9-83b7-8664c311d134@github.com>
 <6UwI1GaSbmtMU5XTT6LlBS1sTnwI-fXfBoWr4SVfitA=.5e04b700-5adc-40a7-9b0b-674733d9f6af@github.com>
Message-ID: <TqJCEz63JlNnDyBfLlfpwWAXBZErYyECCppGMkbQ11g=.47575906-488c-4263-82a1-2f63b72ff7d4@github.com>

On Fri, 28 Feb 2025 01:17:19 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Yes. It should exit the function early to avoid jumping in the next switch block.

With `->` it should not fall into next case. Maybe I am missing something.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23825#discussion_r1974602225

From asemenyuk at openjdk.org  Fri Feb 28 03:50:52 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 28 Feb 2025 03:50:52 GMT
Subject: RFR: 8350013: Add a test for JDK-8150442 [v2]
In-Reply-To: <TqJCEz63JlNnDyBfLlfpwWAXBZErYyECCppGMkbQ11g=.47575906-488c-4263-82a1-2f63b72ff7d4@github.com>
References: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>
 <nvOZNKtL0FDcOwKUnMPoyr545iekkcSyBFh0GQx6KmY=.5e03279f-3dfc-45b9-83b7-8664c311d134@github.com>
 <6UwI1GaSbmtMU5XTT6LlBS1sTnwI-fXfBoWr4SVfitA=.5e04b700-5adc-40a7-9b0b-674733d9f6af@github.com>
 <TqJCEz63JlNnDyBfLlfpwWAXBZErYyECCppGMkbQ11g=.47575906-488c-4263-82a1-2f63b72ff7d4@github.com>
Message-ID: <Ygge3xhu1DsjBg1C3s8456cKRLqwcozTsWUYb9fNZb0=.75601b50-e7fe-4042-b602-37289ac31184@github.com>

On Fri, 28 Feb 2025 01:34:22 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> With `->` it should not fall into next case. Maybe I am missing something.

Right, but there are two `siwtch` blocks in the function. Without `return` the control flow will get to the second one. `return`-s prevents this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23825#discussion_r1974717411

From alanb at openjdk.org  Fri Feb 28 07:24:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Feb 2025 07:24:57 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <kZF8APp_EbniU8QWq-dev6ImxAv9_K6qeMH87zM1Iyw=.dc0d7c15-cda0-40e8-8c5a-b79039e61029@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>
 <kZF8APp_EbniU8QWq-dev6ImxAv9_K6qeMH87zM1Iyw=.dc0d7c15-cda0-40e8-8c5a-b79039e61029@github.com>
Message-ID: <qqL2GPyi-2imfKnhXWbIoP50Y9q73AglIOBdAk9Mdbo=.e3c01445-c424-452c-ac90-dc55e2cfa7fe@github.com>

On Fri, 28 Feb 2025 01:29:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> IIRC you still need the modules for the unsupported pieces because the API's themselves are not optional and you have to be able to ask if something is supported.

In this case it's a JDK-specific module, and since JDK 9 it has been possible/allowed to create a run-time image that doesn't contain all the standard modules. I think the interesting topic coming up here is whether it make any sense to include "all modules" when the only VM is the minimal VM or specific features. In JDK 9 we put some basic checks in so that some command line options, like -javaagent or -Dcom.sun.management checked for the VM feature but more could be done if someone had the time to work through everything, likely significant build work to tie features to modules.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23805#issuecomment-2689920210

From mbaesken at openjdk.org  Fri Feb 28 07:47:57 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Feb 2025 07:47:57 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <AljoLE8BPJXkjB2tx-NEzV20uHyMdYah6B7ck31RR-Q=.b3cf59fe-e58f-406b-8253-55eeefd2380a@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <C-MYCDaVr2YJLZHDABKKZ784_rLxla6e6hUYxv9oa9U=.a69932b7-f057-4b67-bbd7-f49aac88a28b@github.com>
 <PXb8sEre4Eb6HduJpADX6bfvY9oP8LzF_7oMmm8vJAk=.087b442f-360a-4d00-b3a7-3e261b82829a@github.com>
 <lK8OE6nUsQnMkSzAEEA8cR7nddUjlj91pt11HpNJO2Y=.c3113ec2-d158-45d2-ba31-e441355ffa75@github.com>
 <-wgA3ZuOnRPwj0WaR2DZdvf-AXIAZYJtfHTNa6CKnNk=.d67aff51-2877-4d26-87e3-320fb989a807@github.com>
 <pwk1EGafGj4o6g2leboeuL9grLvCRv7jYl_89xx4MgM=.a910f73a-e91f-485b-a68e-89725a1d3751@github.com>
 <iEmMwagKTp1hzZBBecqENWyojc0ZFQDsNjJRRsjAqEk=.5a5d4494-7236-488d-ae53-2e6283ed6546@github.com>
 <U6YRQCFntBx0N-of4aDSWdoDJGMvII72W3d2w8QVIXc=.12012b0c-580a-45d6-a45d-5e418fd29459@github.com>
 <AljoLE8BPJXkjB2tx-NEzV20uHyMdYah6B7ck31RR-Q=.b3cf59fe-e58f-406b-8253-55eeefd2380a@github.com>
Message-ID: <vWfunP316TZuULd4L3e7awEUUs8nbPTCCgd2PDpB-Nw=.0b36c0bb-a13c-4841-9c2d-c29716165a2f@github.com>

On Thu, 27 Feb 2025 21:40:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> If you want to see that implemented, the first step is to open an enhancement issue on JBS.

For now I would probably be happy with fixing/adding the 'requires' statements of the tests, where they are missing.
This would allow jtreg-testing an image with limited JVM features (currently this is hard because you run into lots of errors because tests do not check properly what is required).
Kicking out modules from a feature-limited image sounds logical and promising (even smaller image) but it seems there are a number of hidden problems/issues.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23805#discussion_r1974952100

From dfuchs at openjdk.org  Fri Feb 28 09:16:01 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Feb 2025 09:16:01 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v7]
In-Reply-To: <GQnb1hcSEe1yT-2tKDWqLAJzoNqJYztg7xEs27Mhplc=.abce117b-7ec9-46a9-8dc6-7213bced7c0f@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <7k2QcVVhdkip4zjJdolGkHnyRF5K111tbovc-aEzbhc=.d0c2cc89-81d8-4069-86b2-76aef0ce29bb@github.com>
 <Mhge5WAMJMRFTWsH3VOrG19sW1tG-6g3yr3WRr30CzY=.380072d8-a24a-43c9-9622-108afac2db9a@github.com>
 <GQnb1hcSEe1yT-2tKDWqLAJzoNqJYztg7xEs27Mhplc=.abce117b-7ec9-46a9-8dc6-7213bced7c0f@github.com>
Message-ID: <ZPaOI0wOqRgitcc_U9Q_mKjidZU7UghKbZvH14ZWFO4=.6ad50709-4036-4e94-94f9-914f76152dbb@github.com>

On Fri, 28 Feb 2025 00:59:22 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.logging/share/classes/java/util/logging/SocketHandler.java line 178:
>> 
>>> 176:         // JDK-8349206: Do NOT synchronize around the parent's publish() method.
>>> 177:         super.publish(record);
>>> 178:         flush();
>> 
>> May not matter, but flush should be called from synchronousPostWriteHook() as it was called under lock before this change.
>
> It's correct that flush() was called under the lock previously, but there's no additional logic in this method, so I don't think it matters. If additional stuff is published it'll all get flushed eventually anyway. I note that ConsoleHandler.publish() flushes without holding the lock.

If that mattered it could be called within the `synchronousPostWriteHook` instead, but I agree with @stuart-marks that it most probably doesn't matter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1975069382

From dfuchs at openjdk.org  Fri Feb 28 09:30:59 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Feb 2025 09:30:59 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v9]
In-Reply-To: <i6qWEAJ6su3eRLy4wqylbVl0hG88eTMyr2zKP4_07cg=.6eeffc2d-9dd2-4c12-89c6-f53624f4ca27@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <i6qWEAJ6su3eRLy4wqylbVl0hG88eTMyr2zKP4_07cg=.6eeffc2d-9dd2-4c12-89c6-f53624f4ca27@github.com>
Message-ID: <bA6ZPOQyn2gq-pN4MrEu7TYffjiUkCKK_X-oZocDnNw=.d5408e74-1a66-409e-97c9-0f7b46eade25@github.com>

On Thu, 27 Feb 2025 17:15:56 GMT, David Beaumont <duke at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix @implNote to @apiNote.

src/java.logging/share/classes/java/util/logging/StreamHandler.java line 240:

> 238:     void synchronousPostWriteHook() {
> 239:         // Empty by default.
> 240:     }

It would be good to have a comment making it clear that this method is called while holding the monitor on this. I know we have a test for that - but it could be good to make it clear in the code as well.
What about:
Suggestion:

    void synchronousPostWriteHook() {
        // Empty by default. We could do:
        //    assert Thread.holdsLock(this);
        // but this is already covered by unit tests.
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1975092107

From dholmes at openjdk.org  Fri Feb 28 10:12:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Feb 2025 10:12:04 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <qqL2GPyi-2imfKnhXWbIoP50Y9q73AglIOBdAk9Mdbo=.e3c01445-c424-452c-ac90-dc55e2cfa7fe@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>
 <kZF8APp_EbniU8QWq-dev6ImxAv9_K6qeMH87zM1Iyw=.dc0d7c15-cda0-40e8-8c5a-b79039e61029@github.com>
 <qqL2GPyi-2imfKnhXWbIoP50Y9q73AglIOBdAk9Mdbo=.e3c01445-c424-452c-ac90-dc55e2cfa7fe@github.com>
Message-ID: <TvJXoA0FTYOV-kXr5Hh_b_h1n_M8kVdbAcWpU0aFVwA=.a8b48153-2463-41cc-8427-26d4dc7f9ce2@github.com>

On Fri, 28 Feb 2025 07:22:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In this case it's a JDK-specific module

Okay but is there a transitive dependency from the public module that has to be present to the internal module?

That said ... we are building a minimal VM we are not building Compact Profiles. I don't think we strip anything from the JDK side if we are only building the minimal VM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23805#issuecomment-2690247766

From ihse at openjdk.org  Fri Feb 28 10:22:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 28 Feb 2025 10:22:09 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>
Message-ID: <oB6bMWMzq2veJqMDGGFxBWgUUzLean0kMNn4HAK-DnU=.9bf6f047-7f5c-450f-b169-3e757a8ecd70@github.com>

On Thu, 27 Feb 2025 10:19:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> While testing a bit with a minimal JVM, it has been noticed that some java/lang jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright years

There is no user-selectable option to exclude modules during the build. The official answer is that you need to create your own image in a follow-up step using jlink, where you can select which modules to include. That is really stupid, since internally in the build system we have a `MODULES_FILTER` for modules to exclude, and we should really expose it to the user. (I've been thinking about this but never had the time to fix it.)

Anyway, I think this is an interesting discussion, but not really high-priority, and the build changes are unlikely to happen unless someone can argue that they should be given more priority (as there are simple work-arounds available). I created https://bugs.openjdk.org/browse/JDK-8350930 to track this discussion so we don't lose it, though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23805#issuecomment-2690268354

From mcimadamore at openjdk.org  Fri Feb 28 10:24:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 10:24:01 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <9_Mp24kqJm3Txg5EreOQ0hze__fMkkLglPzrAOBq1ro=.a0c32391-aaa0-4a80-b885-1edf1901dfe7@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>
 <4ZTgmEF7598oiRqCiAl43Ux559migTzfTcjkwLKw0no=.0e4b1001-eedd-462c-9283-8038565c96c7@github.com>
 <ITL0ulKc9iZF4ShEflEc0r-3rdsN77wtTSalhWhA2tw=.973640ef-9843-4009-828b-8a1c7754be07@github.com>
 <9_Mp24kqJm3Txg5EreOQ0hze__fMkkLglPzrAOBq1ro=.a0c32391-aaa0-4a80-b885-1edf1901dfe7@github.com>
Message-ID: <nxcnv-9LkKTnO4lK-ZpTUOARJEWtlO7QFJiCwc8JtdI=.b321790d-7ca2-4e99-8412-42c3a3cb3813@github.com>

On Thu, 27 Feb 2025 14:21:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> In last revision I called it `fixedOffset`, but it becomes confusing with the actual fixed value of the offset.
>
> Maybe something like `isOffsetFixed` or `hasFixedOffset` would be better?

(I suggested renaming to something that didn't contain the term "offset" -- it's a subjective thing and if I'm in the minority that's ok. Maybe `noIndex`, or `noVariableOffset` ?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975171803

From tschatzl at openjdk.org  Fri Feb 28 10:35:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 28 Feb 2025 10:35:03 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v2]
In-Reply-To: <3zmj-DeeRyPMHc32YnvfqACN0xJxLQ6jZZ7sd-Baa3w=.672912f6-e4a3-4679-b8a3-b7f6ad51589d@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <sATIRzYvi1wLv1tzkXOuwBN2F2YKy7SLSxaU6mnPWTg=.93b86875-3f5f-4ffe-91f0-a59ef68b2157@github.com>
 <3zmj-DeeRyPMHc32YnvfqACN0xJxLQ6jZZ7sd-Baa3w=.672912f6-e4a3-4679-b8a3-b7f6ad51589d@github.com>
Message-ID: <aqQgjLF5Uy31kSi3iSiC6uiypK-Hjk6zmJBQuU07Y-c=.1974c6fc-9924-4968-916e-d6bd48eece47@github.com>

On Thu, 27 Feb 2025 18:24:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * remove unnecessarily added logging
>
> src/hotspot/share/gc/g1/g1BarrierSet.hpp line 54:
> 
>> 52: // them, keeping the write barrier simple.
>> 53: //
>> 54: // The refinement threads mark cards in the the current collection set specially on the
> 
> "the the" typo.

I fixed one more occurrence in files changed in this CR. There are like 10 more of these duplications in our code, I will fix separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1975186407

From mcimadamore at openjdk.org  Fri Feb 28 10:35:06 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 10:35:06 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <oMPfvQ8dUa5B7ka6ZZfKcjmCoenfWP-LAueTZbsMF_M=.b3d38e82-cc63-4a91-92fe-150178f791e9@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
 <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
 <fcsa6WE_4AWLnAloX6hsm-0BDZszbsUfq_En8Ms_Zzk=.faff52ee-0afd-45c0-9d14-25dbedacc7fe@github.com>
 <P3wPfN6jKOa2leSyMCN28qMLrWBjJDP6s40ZWfthc6E=.190dfe50-c01f-434d-afb0-8735ae2b0a2d@github.com>
 <oMPfvQ8dUa5B7ka6ZZfKcjmCoenfWP-LAueTZbsMF_M=.b3d38e82-cc63-4a91-92fe-150178f791e9@github.com>
Message-ID: <ZiFG6GVy21-vNm4HRADnfTVA0RTR9fqLRyzvcyskCz4=.bae77b6e-5a66-4585-9e79-92bbe62424b3@github.com>

On Thu, 27 Feb 2025 14:17:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Well, the reason I removed the eager init is that their creation in clinit is super costly. Also I think one pair of getter + creator is better than 3 pairs.
>
>> ...  their creation in clinit is super costly
> 
> You mean because threads can not race to initialize? I'd think the extra stack walks to create 3 lookups might offset that though...

Another possible option -- if we don't like this, is to put the constants in an holder class. As @JornVernee  says, most of the times the fields are used together. Re. initialization cost, I agree with @liach as I have observed the same thing -- these helper method handles lead to some bytecode spinning -- which is better to delay if not strictly needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975182862

From mcimadamore at openjdk.org  Fri Feb 28 10:35:05 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 10:35:05 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <jIE0fp1SkujHwIanTtWKszq_kIadq7erKWrk_zLnZqI=.3ca1bc86-1257-4f4c-802b-4af638cc8463@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <3yhXZNAbPb_sRC_CXmKGzUNsvhl1rOfIvtdGfUCsvq4=.66ca9688-2bf1-4eec-9a38-c499a8390fcc@github.com>
 <jIE0fp1SkujHwIanTtWKszq_kIadq7erKWrk_zLnZqI=.3ca1bc86-1257-4f4c-802b-4af638cc8463@github.com>
Message-ID: <IFo9I0v2t7sJJuCUXqsRc9mmPl0qgVYOpr230yXlk50=.0a620658-79bc-4ed9-9e1e-7d4da98ce7ac@github.com>

On Tue, 25 Feb 2025 09:51:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Benchmark results for the latest revision appears performance neutral. bytestacks same as last revision. 11 jobs left in tier 1-3, no failure so far. Also created CSR for this minor behavioral change.
>> 
>> Benchmark                                                (polluteProfile)  Mode  Cnt  Score   Error  Units
>> LoopOverNonConstantHeap.BB_get                                      false  avgt   30  0.934 ? 0.027  ns/op
>> LoopOverNonConstantHeap.BB_get                                       true  avgt   30  0.946 ? 0.028  ns/op
>> LoopOverNonConstantHeap.BB_loop                                     false  avgt   30  0.208 ? 0.004  ms/op
>> LoopOverNonConstantHeap.BB_loop                                      true  avgt   30  0.211 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_get                                 false  avgt   30  1.123 ? 0.040  ns/op
>> LoopOverNonConstantHeap.segment_get                                  true  avgt   30  1.120 ? 0.040  ns/op
>> LoopOverNonConstantHeap.segment_loop                                false  avgt   30  0.205 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop                                 true  avgt   30  0.202 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance                       false  avgt   30  0.209 ? 0.005  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance                        true  avgt   30  0.202 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance_unaligned             false  avgt   30  0.209 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_instance_unaligned              true  avgt   30  0.210 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_readonly                       false  avgt   30  0.206 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_readonly                        true  avgt   30  0.206 ? 0.005  ms/op
>> LoopOverNonConstantHeap.segment_loop_slice                          false  avgt   30  0.203 ? 0.002  ms/op
>> LoopOverNonConstantHeap.segment_loop_slice                           true  avgt   30  0.207 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_unaligned                      false  avgt   30  0.206 ? 0.004  ms/op
>> LoopOverNonConstantHeap.segment_loop_unaligned                       true  avgt   30  0.209 ? 0.003  ms/op
>> LoopOverNonConstantHeap.unsafe_get                                  false  avgt   30  0.386 ? 0.017  ns/op
>> LoopOverNonConstantHeap.unsafe_get                                   true  avgt   30  0.381 ? 0.017  ns/op
>> Loo...
>
> Great work @liach -- I've bumped the number of reviewers as this whole area is rather tricky, and I think the PR can probably benefit from another independent pass.

> Unfortunately no. I don't really know about the Foreign Memory API as I only started to investigate its performance bottlenecks recently. @mcimadamore or @JornVernee were more involved in the development and likely know better.

After a chat with @PaulSandoz , it seems like the exclusion was not a deliberate one. Probably, sub-int atomic unsafe primitives were added in parallel with the var handle work:

https://github.com/openjdk/jdk/commit/e663206d

The above commit did add support for sub-word atomics, but only in the field access case. The BB view/array view var handles were left out. Then came FFM, whose implementation was originally based off the BB view var handle -- so we ended up inheriting same limitations.

It would be good to address this -- in a separate PR. As for this PR, as we discussed offline, I'd suggest to keep the ScopedMemoryAccess changes (even if some methods are now unused) and drop the commented lines from the var handle gensrc file. Then we can come back with a new PR and add support for missing access modes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2690284867

From mcimadamore at openjdk.org  Fri Feb 28 10:35:06 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 10:35:06 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v2]
In-Reply-To: <ZiFG6GVy21-vNm4HRADnfTVA0RTR9fqLRyzvcyskCz4=.bae77b6e-5a66-4585-9e79-92bbe62424b3@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <Ti068QBOTu0KnUR_J-sYO4hnZz7I6Ikfgxtyt_z0JF4=.490802ad-d421-4704-87f5-23d78c110de6@github.com>
 <V4cyuQ1-qGs5PohgoOpLkk0EGmbyF8zQBJzIt4bvgCw=.842ac20d-0cf8-4d12-9ee3-99d0feeffd6f@github.com>
 <fcsa6WE_4AWLnAloX6hsm-0BDZszbsUfq_En8Ms_Zzk=.faff52ee-0afd-45c0-9d14-25dbedacc7fe@github.com>
 <P3wPfN6jKOa2leSyMCN28qMLrWBjJDP6s40ZWfthc6E=.190dfe50-c01f-434d-afb0-8735ae2b0a2d@github.com>
 <oMPfvQ8dUa5B7ka6ZZfKcjmCoenfWP-LAueTZbsMF_M=.b3d38e82-cc63-4a91-92fe-150178f791e9@github.com>
 <ZiFG6GVy21-vNm4HRADnfTVA0RTR9fqLRyzvcyskCz4=.bae77b6e-5a66-4585-9e79-92bbe62424b3@github.com>
Message-ID: <VyWFtRvSy2Q_NhI86349UK3Q9AH1bPRYkLIPyzWWMFE=.27e29f07-dcf0-496d-b4ff-a80e0d9e8fd8@github.com>

On Fri, 28 Feb 2025 10:29:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I have observed the same thing -- these helper method handles lead to some bytecode spinning

Although - that was before; in the new code these helpers don't do adaptation... so it should be ok. (I also see the code has been updated)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975185780

From mcimadamore at openjdk.org  Fri Feb 28 10:43:10 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 10:43:10 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>
Message-ID: <8Q7qd2f4Dd-7YFf24NfoPG7Q1CzlOcmWxoBvMdXJHes=.07079a01-2566-435d-a729-daba2da85af2@github.com>

On Thu, 27 Feb 2025 16:00:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   noStride -> constantOffset, optimize VH classes to have only 2 instead of 3 classes for each type

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 53:

> 51: 
> 52:     static final VarForm CONSTANT_OFFSET_FORM = new VarForm(VarHandleSegmentAs$Type$s.class, MemorySegment.class, $type$.class, long.class);
> 53:     static final VarForm TAKE_OFFSET_FORM = new VarForm(VarHandleSegmentAs$Type$s.class, MemorySegment.class, $type$.class, long.class, long.class);

what does TAKE mean here? (the old names weren't great either, I realize). I think it would be better to decide, once and for all, how to refer to these things, and then use consistent naming throughout. I see we have discussed using "noStride" vs. "fixedOffset". Since the implementation now uses the term "constantOffset", let's just call the other "variableOffset" ?

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 120:

> 118: 
> 119: // This class must be accessed through non-aligned VarHandleSegmentAs$Type$s
> 120: final class VarHandleSegmentAs$Type$sAligned extends VarHandleSegmentAs$Type$s {

I kind of liked the nested classes -- why the change?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975192481
PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975193951

From mcimadamore at openjdk.org  Fri Feb 28 10:43:08 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 10:43:08 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <FHuKYg-191BBUnAbMlBOEDorfydcdvj5B4iFMdWO9J4=.e2b49040-2543-4e84-a1ba-12b7a35bc4d1@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <kq3FfXLHhQTVOTXaeesJZeKy4upG9Nkm3-1cVkXeayI=.8b0dff31-ec33-4448-8f86-9abd21e9c8bf@github.com>
 <9G64-uM0Pji8lgDcnuOvNA1oT8gjcugyrg40nxrs0YA=.95c64593-0494-4854-9564-1540a83f69ae@github.com>
 <RW0eXeCodO55Qy8C5HLrB-kCp8jlqfVRFo6ELAO3OTs=.c85c04d1-4792-4bb0-aad3-f8a8c3be4695@github.com>
 <a6GcFgRP6Mmghgl8tuOWhXNwtSSN1999BDg8SH2nyFg=.74bd0ae7-1d27-4b6a-a798-1eafbc9977c2@github.com>
 <FHuKYg-191BBUnAbMlBOEDorfydcdvj5B4iFMdWO9J4=.e2b49040-2543-4e84-a1ba-12b7a35bc4d1@github.com>
Message-ID: <anavQ_b94qrDKB0akrzR4krG0GAEMKNE9ZV68hVglqI=.52162b38-4deb-4d95-9a1c-75cda1e867b7@github.com>

On Tue, 25 Feb 2025 14:39:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Left a space and an extra note to make the comment hash more obvious.
>
> Unless you plan to shortly push a new PR where you either enable this functionality, or remove the commented-out lines, I strongly prefer *not* to have commented-out code in the makefiles. It's not that hard to re-create these lines should they be needed. And you can always find the history in this PR.

Yes, let's drop this for now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975196301

From kevinw at openjdk.org  Fri Feb 28 11:18:08 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 28 Feb 2025 11:18:08 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <i_NSaCTA6BLRKBO6QXgjfBijY8RacgjFXR8U7OtcRLE=.c6b2bda7-afa7-4187-800f-e0cd4184ae36@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

Quick fix is PR https://github.com/openjdk/jdk/pull/23832 taking care of it in JDK 25, and there should be a backport to JDK 24 first update.  I will come back with a further update in JDK-8350939 to reinstate snprintf.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2690383444

From tschatzl at openjdk.org  Fri Feb 28 11:25:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 28 Feb 2025 11:25:53 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v2]
In-Reply-To: <3zmj-DeeRyPMHc32YnvfqACN0xJxLQ6jZZ7sd-Baa3w=.672912f6-e4a3-4679-b8a3-b7f6ad51589d@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <sATIRzYvi1wLv1tzkXOuwBN2F2YKy7SLSxaU6mnPWTg=.93b86875-3f5f-4ffe-91f0-a59ef68b2157@github.com>
 <3zmj-DeeRyPMHc32YnvfqACN0xJxLQ6jZZ7sd-Baa3w=.672912f6-e4a3-4679-b8a3-b7f6ad51589d@github.com>
Message-ID: <9tS5E1tteGutSNX7rZh5WYLdZoF7Vgl_4_pjuAdT4WU=.c8c73c45-7abb-48a9-b623-769d3c1679ca@github.com>

On Thu, 27 Feb 2025 12:07:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * remove unnecessarily added logging
>
> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 349:
> 
>> 347: 
>> 348:     bool do_heap_region(G1HeapRegion* r) override {
>> 349:       if (!r->is_free()) {
> 
> I am a bit lost on this closure; the intention seems to set unclaimed to all non-free regions, why can't this be done in one go, instead of first setting all regions to claimed (`reset_all_claims_to_claimed`), then set non-free ones unclaimed?

`do_heap_region()` only visits committed regions in this case. I wanted to avoid the additional check in the iteration code. If you still think it is more clear to filter those out later, please tell me. I'll add a comment for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1975250646

From tschatzl at openjdk.org  Fri Feb 28 12:14:01 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 28 Feb 2025 12:14:01 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v2]
In-Reply-To: <3zmj-DeeRyPMHc32YnvfqACN0xJxLQ6jZZ7sd-Baa3w=.672912f6-e4a3-4679-b8a3-b7f6ad51589d@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <sATIRzYvi1wLv1tzkXOuwBN2F2YKy7SLSxaU6mnPWTg=.93b86875-3f5f-4ffe-91f0-a59ef68b2157@github.com>
 <3zmj-DeeRyPMHc32YnvfqACN0xJxLQ6jZZ7sd-Baa3w=.672912f6-e4a3-4679-b8a3-b7f6ad51589d@github.com>
Message-ID: <87L5pcyGAgyDsXTwlSdAFLyIAOcUl1ZdYXK-nwzLrUQ=.c3db7522-b3e6-46e0-b268-e457c3d2bdc2@github.com>

On Thu, 27 Feb 2025 18:31:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * remove unnecessarily added logging
>
> src/hotspot/share/gc/g1/g1RemSet.cpp line 1252:
> 
>> 1250:     G1ConcurrentRefineWorkState::snapshot_heap_into(&constructed);
>> 1251:     claim = &constructed;
>> 1252:   }
> 
> It's not super obvious to me why the "has_sweep_claims" checking needs to be on this level. Can `G1ConcurrentRefineWorkState` return a valid `G1CardTableClaimTable*` directly?

I agree. I remember having similar thoughts as well, but then did not do anything about this. Will fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r1975311607

From mbaesken at openjdk.org  Fri Feb 28 12:23:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Feb 2025 12:23:59 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
Message-ID: <Up2nvImQ0ygo9YKtNTpD1b4YtZFBmvt1d59nmky-ImI=.c7d8b52e-be3c-4533-9435-d3148a26947a@github.com>

On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated comment

src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2024, Red Hat Inc.

Guess this must be 2025 now ? Same for other files ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975321465

From mbaesken at openjdk.org  Fri Feb 28 12:30:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Feb 2025 12:30:13 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
Message-ID: <IwVJeqTk0HxHxFi4B64nemBTTG0Tq6gDsMA6CmMDMAU=.b28d7564-3af4-44f0-957b-a998cb0f5540@github.com>

On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated comment

test/jdk/jdk/internal/platform/cgroup/CgroupV1SubsystemControllerTest.java line 69:

> 67:     /*
> 68:      * Less common cases: Containers
> 69:      */

Not really sure why this comment was added, is it refering to 'container mode'  mentioned in the comment above in another file?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975330669

From duke at openjdk.org  Fri Feb 28 12:31:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 28 Feb 2025 12:31:54 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v9]
In-Reply-To: <waP0Lp2vilibQVwjkYn6fDMZPPqWR5m-8HhGc3PZZwY=.9fb550d1-75e4-4a46-a004-c9d8f6293cd3@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <Pj4COzHIujrQIrdVZaPbYc0V4uDR9jBXAAmZ6iDdI0s=.6e94d34f-6d57-4dd1-b232-23c54f4bc4b1@github.com>
 <Xs0Wd1rYekZRiaPHys_89jY4TSXKwBhx8A-iz-jlYtU=.a9e83238-686a-4ef4-8ee0-81b3da941393@github.com>
 <U9dqVBjuudxFSY8JmJJKf2qAa78SJGHAqDncQhf_1T8=.e5a7ca03-f5d5-4eb8-8ef1-2ae70c38ffab@github.com>
 <wW98J6TwTCR2pdrTXdOEyX6MHZu7CkNq3vCYEZw9I9o=.243c5403-5be9-41fe-aab4-904b24d62462@github.com>
 <waP0Lp2vilibQVwjkYn6fDMZPPqWR5m-8HhGc3PZZwY=.9fb550d1-75e4-4a46-a004-c9d8f6293cd3@github.com>
Message-ID: <Cvr1i5r3JvyAnxsgzpoZGP2PfYS1kaBpDo1VS4LlDzY=.d0307cb7-09ad-42dd-8c3c-b70c939412ef@github.com>

On Thu, 27 Feb 2025 14:07:17 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> Need to update to have single call to getFormatter().
>
>>Keeping an unformatted log record around for any time after the log statement that created it has exited would be quite problematic (it prevents GC of arbitrary things).
> 
> I've always leaned on:
> 1. The words written in LogRecord API that once a record is given to the logging api it owns that record. Thefore, don't attach things you own to that record.  "Don't leave your belongings in the rental car when returning it."
> 3. Passing arbitrary objects to the logging API is a security risk because I can create a filter/handler/Formatter that casts the arguments and manipulates them. E.G. Map::clear, Map::put("user","root").
> 4. Logging api has supplier methods that allow callers to format arguments early on using String.format.
> 5. LogRecord records a timestamp. Passing string representation at time of logging both snapshots near the timestamp and makes a mutable argument safer for exposure to unknown classes.
> 
> That said, I'll probably create PRs for MailHandler and CollectorFormatter to optionally support deep cloning of the LogRecord via serialization before it is stored. Doing so would switch the params to string without tampering with the source record.  MemoryHander could do the same and effectively become a non-caching (pushLevel=ALL) TransformHandler to decorate Handers that over synchronize.

I'd have to disagree with the points you make.

The fact is that loggers are never expected to modify the passed parameters. To ask people to "disown" the parameters they pass to a logger requires that your best advice on how to write a log statement with mutable values must look something like:


  if (logger.isEnabled(level)) {
    // Avoid copying parameters when logging is disabled.
    var arg1Copy = arg1.defensiveCopy();
    var arg2Copy = arg2.defensiveCopy();
    logger.log(level, "foo={0}, bar={1}", arg1Copy, arg2Copy);
  }


as opposed to:


    logger.log(level, "foo={0}, bar={1}", arg1, arg2);


The former is, in my opinion, a pretty awful user experience and (more to the point) something that almost nobody ever does in real code because, reasonably, they trust the internal logger classes not to be malicious.

The comment about the record being owned by the logger means that it can't be cached and reused, or passed to different log statements etc. It doesn't give logging classes any freedom to modify the log statement parameters.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1975333470

From duke at openjdk.org  Fri Feb 28 12:54:00 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 28 Feb 2025 12:54:00 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v6]
In-Reply-To: <_Trjm7t7oWxRTydRKqeS6adOJ6qT2l_iGU1UGUiG01g=.9fe16a20-a8e6-4647-938a-9e9dff48c7d4@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <1_MYqF28HW1ASAglx6I3PhgIff6ZLN_mcCqOWQSSIxg=.942bd5e5-56a4-4cbe-b551-536c714297f7@github.com>
 <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
 <_Trjm7t7oWxRTydRKqeS6adOJ6qT2l_iGU1UGUiG01g=.9fe16a20-a8e6-4647-938a-9e9dff48c7d4@github.com>
Message-ID: <vHKIq2PZNdFDY-1XV0EJGRsr0JQq5uBMNKP7yefRF0M=.2702ceff-5f56-42a6-9eb6-970324d646ef@github.com>

On Tue, 25 Feb 2025 11:35:18 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.logging/share/classes/java/util/logging/Formatter.java line 94:
>> 
>>> 92:      * important to avoid making callbacks to unknown user-provided arguments
>>> 93:      * (e.g. log record parameters captured from previous calls to
>>> 94:      * {@link #format(LogRecord)}.
>> 
>> I'm having trouble getting my head around these comments. Are they intended for callers or for subclassers? Is the "associated" handler the same handler as the argument, or a different one? I saw the discussion of potential (largely theoretical?) deadlock in the discussion in StreamHandler.publish(), but I'm having trouble figuring out what kind of actual constraint that potential imposes on which code.
>
> The caller of this class is almost always JDK logging code, so these comments are intended for anyone implementing a formatter. The handler is the target handler (well spotted), and I don't believe it's ever actually null in any real code in the JDK.
> 
> The reason that I commented here is because in the PR conversation, it's been noted that formatter is odd because two of its methods are intended to be called without locks held (and for implementations to avoid taking more locks), and two methods are expected to be called with locks held, which means any implementation of them should avoid calling toString() etc.
> 
> Now while getHead() and getTail() aren't given any user arguments to format, it was pointed out that they might have held onto some (e.g. from the last processed log record). And this use case isn't entirely odd, because having a "getTail()" method that emits the last log statement timestamp, or some summary of the number of log statements of certain types has value. This can be done safely if you only capture timestamps and counters, because formatting them won't result in arbitrary user code being invoked, but it's easy to imagine people thinking it's also okay to capture certain logged arguments to processing here (while it would be safe to call toString(), and capture that when the record is processed, it's not safe to call toString() in getHead() or getTail()).
> 
> I felt that since, without guidance, there's a good chance people will assume all the methods in this class are "the same" in terms of locking constraints, something needed to be put in to distinguish the two (incompatible) constraints these methods have.

After discussion, we decided this was too special-case and too tricky to explain in a simple JavaDoc note, so I revert these comments for now. We might add them back, or (more likely) I'll write a "how to write handlers and formatters" guide in some format tbd.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1975361890

From duke at openjdk.org  Fri Feb 28 12:54:02 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 28 Feb 2025 12:54:02 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v9]
In-Reply-To: <g11UeTAkmQ1Q2Mynb7Uzndman_sEJQut9bz5K7XBdfA=.6a8a67f2-6c28-4086-a249-3d4ec14e9633@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <i6qWEAJ6su3eRLy4wqylbVl0hG88eTMyr2zKP4_07cg=.6eeffc2d-9dd2-4c12-89c6-f53624f4ca27@github.com>
 <g11UeTAkmQ1Q2Mynb7Uzndman_sEJQut9bz5K7XBdfA=.6a8a67f2-6c28-4086-a249-3d4ec14e9633@github.com>
Message-ID: <3P5Xe8aHKZbGi-FPKF1p-Dje2SnqZBUipNgZ8S423TM=.36147d52-fda2-40e7-b42d-e5577f08cf14@github.com>

On Fri, 28 Feb 2025 01:09:21 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix @implNote to @apiNote.
>
> src/java.logging/share/classes/java/util/logging/StreamHandler.java line 288:
> 
>> 286:                     doneHeader = true;
>> 287:                 }
>> 288:                 writer.write(formatter.getTail(this));
> 
> Strictly speaking not necessary, since this is called with the lock held (as noted above!) but it's a reasonably good multi-threaded coding practice to fetch values into a local variable and reuse them, so I think this is ok as modified.

I was just being consistent with the other case (where a single read is probably needed).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1975364945

From pminborg at openjdk.org  Fri Feb 28 13:20:27 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 28 Feb 2025 13:20:27 GMT
Subject: RFR: 8347408: Create an internal method handle adapter for system
 calls with errno [v2]
In-Reply-To: <QHEUF-Wlk-NBSpBXX6BEbXy1vN_HNlYkvY0lqzoN6ww=.848bb36e-c272-4926-aa37-f66c68e9135f@github.com>
References: <QHEUF-Wlk-NBSpBXX6BEbXy1vN_HNlYkvY0lqzoN6ww=.848bb36e-c272-4926-aa37-f66c68e9135f@github.com>
Message-ID: <ZTWMgAhOPxLpn8lgL1yTtJsXkF6nLRIAPhnGin8iVK4=.7411d195-d443-44c1-aee8-f219bff479c9@github.com>

> As we advance, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a `MemorySegment` to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
> 
> Hence, this PR proposes adding a JDK internal method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
> 
> It relies on an efficient carrier-thread-local cache of memory regions to allide allocations.
> 
> 
> Here are some benchmarks that ran on a platform thread and virtual threads respectively (M1 Mac):
> 
> 
> Benchmark                                                  Mode  Cnt   Score   Error  Units
> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 ? 0.820  ns/op
> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 ? 0.117  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 ? 1.013  ns/op
> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 ? 0.463  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 ? 0.182  ns/op
> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 ? 0.156  ns/op
> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 ? 0.487  ns/op
> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 ? 0.089  ns/op
> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 ? 1.128  ns/op
> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 ? 0.413  ns/op
> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 ? 0.673  ns/op
> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 ? 0.152  ns/op
> 
> 
> Adapted system call:
> 
>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
> ```        
> Explicit allocation:
> 
>         try (var arena = Arena.ofConfined()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>         }
> ```        
> Thread Local allocation:
> 
>         try (var arena = POOLS.take()) {
>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a manually specified pool
>         }
> ```        
> The adapted system call exhibits a ~4x performance improvement over the existing "explicit allocation" scheme for the happy path on platform threads. ...

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 33 additional commits since the last revision:

 - Add test for woven allocation
 - Merge branch 'master' into errno-util3
 - Use lazy initialization of method handles
 - Clean up visibility
 - Merge branch 'master' into errno-util3
 - Add @ForceInline annotations
 - Add out of order test for VTs
 - Allow memory reuse for several arenas
 - Remove file
 - Use more frequent allocations
 - ... and 23 more: https://git.openjdk.org/jdk/compare/0fc22f57...2813c971

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23765/files
  - new: https://git.openjdk.org/jdk/pull/23765/files/907329e9..2813c971

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23765&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23765&range=00-01

  Stats: 1956 lines in 66 files changed: 1612 ins; 94 del; 250 mod
  Patch: https://git.openjdk.org/jdk/pull/23765.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23765/head:pull/23765

PR: https://git.openjdk.org/jdk/pull/23765

From liach at openjdk.org  Fri Feb 28 13:35:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 13:35:06 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <8Q7qd2f4Dd-7YFf24NfoPG7Q1CzlOcmWxoBvMdXJHes=.07079a01-2566-435d-a729-daba2da85af2@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>
 <8Q7qd2f4Dd-7YFf24NfoPG7Q1CzlOcmWxoBvMdXJHes=.07079a01-2566-435d-a729-daba2da85af2@github.com>
Message-ID: <cCTIEbnZzNbC6wjBSB9zgbiDUU2oyeXT59yMWop1wN8=.2a960ccc-6b2a-46c5-8982-e83057275e7b@github.com>

On Fri, 28 Feb 2025 10:38:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   noStride -> constantOffset, optimize VH classes to have only 2 instead of 3 classes for each type
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 120:
> 
>> 118: 
>> 119: // This class must be accessed through non-aligned VarHandleSegmentAs$Type$s
>> 120: final class VarHandleSegmentAs$Type$sAligned extends VarHandleSegmentAs$Type$s {
> 
> I kind of liked the nested classes -- why the change?

Nesting means we need to define 3 classes: AsXxx, Unaligned, Aligned. I wish to reduce class loading by merging AsXxx and Unaligned. The Aligned still works as if it is nested, but I put it out to make the indentation beautiful for boolean and byte.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975417166

From liach at openjdk.org  Fri Feb 28 13:35:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 13:35:07 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <nxcnv-9LkKTnO4lK-ZpTUOARJEWtlO7QFJiCwc8JtdI=.b321790d-7ca2-4e99-8412-42c3a3cb3813@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <N9WczjdrEIORU_2ZdT1Mk0l67SCWvN58lZHrIMFJ70w=.6a73ce34-ff6b-4c7e-aa4d-d5ffdf84e052@github.com>
 <p-5rxddQeol8Q91Y4ORXSJavMThAT1tpHWjsUj9cs5w=.a5d256c8-6fa6-4021-a2ee-29c732db18a4@github.com>
 <4ZTgmEF7598oiRqCiAl43Ux559migTzfTcjkwLKw0no=.0e4b1001-eedd-462c-9283-8038565c96c7@github.com>
 <ITL0ulKc9iZF4ShEflEc0r-3rdsN77wtTSalhWhA2tw=.973640ef-9843-4009-828b-8a1c7754be07@github.com>
 <9_Mp24kqJm3Txg5EreOQ0hze__fMkkLglPzrAOBq1ro=.a0c32391-aaa0-4a80-b885-1edf1901dfe7@github.com>
 <nxcnv-9LkKTnO4lK-ZpTUOARJEWtlO7QFJiCwc8JtdI=.b321790d-7ca2-4e99-8412-42c3a3cb3813@github.com>
Message-ID: <gk8c26xHhO3St3ZR_0hYEzeQx-OOvWBMS064Oy8wpP8=.337a9e91-b8e8-4fa4-9b86-44487e33156d@github.com>

On Fri, 28 Feb 2025 10:21:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maybe something like `isOffsetFixed` or `hasFixedOffset` would be better?
>
> (I suggested renaming to something that didn't contain the term "offset" -- it's a subjective thing and if I'm in the minority that's ok. Maybe `noIndex`, or `noVariableOffset` ?)

I have already used constantOffset and find it better than noStride in terms of clarity.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975413935

From tschatzl at openjdk.org  Fri Feb 28 13:43:24 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 28 Feb 2025 13:43:24 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v3]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <aJZNpCuhp1tRT7ZW5yAuvTH1OlbDDz7yTV8JyR9Qc6Y=.1d964dd8-910d-4ebf-b7e8-5a80246f8d28@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:

 - * ayang review 1 (ctd)
     * split up sweep-rt state into "start" (to be called once) and "step" (to be called repeatedly) phases
     * move building the snapshot our of g1remset
 - * ayang review 1
     * use uint for number of reserved regions consistently
     * rename *sweep_state to *sweep_table
     * improved comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/9ef9c5f4..7d361fc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=01-02

  Stats: 108 lines in 8 files changed: 40 ins; 24 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From mbaesken at openjdk.org  Fri Feb 28 14:05:02 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Feb 2025 14:05:02 GMT
Subject: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR
 [v2]
In-Reply-To: <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>
References: <2HTKkEEI5WNfeoqmhjDIpx7tEK6l4uI7qgJbyQPVSUA=.d9de2898-2c92-44b3-9da8-3a9733d18d3e@github.com>
 <abD5elB2gP_CUV4Fff9IK6A9sBev0Ff357Ec1RC7jBI=.5dcf1134-37cc-41cb-9a90-d50b8172d501@github.com>
Message-ID: <HOTKpLil4amq6QUHSojpC2zuX9BbRNs8lTJA7NO0I20=.c5929b3b-286d-4e39-ad75-3635a2019215@github.com>

On Thu, 27 Feb 2025 10:19:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> While testing a bit with a minimal JVM, it has been noticed that some java/lang jtreg tests use jfr but do not declare it with a "requires vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright years

Regarding the requires tags of the tests, I looked a bit more into the jdk :tier1 tests  (when executed with a minimal JVM).
There are  ~ 30  com/sun/jdi  tests failing - guess they need the jvmti  JVM feature and miss the tag, correct  ?

Then there are a few like like
java/util/concurrent/locks/Lock/TimedAcquireLeak.java
java/lang/Class/GetPackageBootLoaderChildLayer.java
jdk/java/util/logging/TestLoggerWeakRefLeak.java
running into this exception

Exception in thread "main" com.sun.tools.attach.AttachNotSupportedException: The VM does not support the attach mechanism
	at jdk.attach/sun.tools.attach.HotSpotAttachProvider.testAttachable(HotSpotAttachProvider.java:134)
	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:54)
	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201)
	at jdk.jcmd/sun.tools.jmap.JMap.executeCommandForPid(JMap.java:127)
	at jdk.jcmd/sun.tools.jmap.JMap.histo(JMap.java:199)
	at jdk.jcmd/sun.tools.jmap.JMap.main(JMap.java:112)


Is here also jvmti required or is it some other JVM feature ?

Btw. I also added as an experiment    JVM feature 'management' to the minimal configuration.
This makes only ~ 1% size difference , on my Linux test system 6272144 (normal minimal) vs. 6337680 (minimal + management added), but helps a lot of jtreg tests because java management is needed across tests and jtreg itself; considering the very small difference it might make sense to add it to default 'minimal' config.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23805#issuecomment-2690724840

From duke at openjdk.org  Fri Feb 28 14:18:01 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 28 Feb 2025 14:18:01 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v6]
In-Reply-To: <y-nl6FTkMMDo2sX5-se2Z50OYNl_0fWy9og2-uTUBL8=.e206db6c-28d4-4069-8582-31f037ec142e@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <1_MYqF28HW1ASAglx6I3PhgIff6ZLN_mcCqOWQSSIxg=.942bd5e5-56a4-4cbe-b551-536c714297f7@github.com>
 <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
 <y-nl6FTkMMDo2sX5-se2Z50OYNl_0fWy9og2-uTUBL8=.e206db6c-28d4-4069-8582-31f037ec142e@github.com>
Message-ID: <WqpM9TS1PljCUsPxK0dGkTHP9kRcNRmwvsjb4kGcvHI=.4dff0714-1432-46c8-aeb1-7d4bff2215d9@github.com>

On Fri, 28 Feb 2025 01:00:49 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.logging/share/classes/java/util/logging/StreamHandler.java line 184:
>> 
>>> 182:      *
>>> 183:      * @param  record  description of the log event. A null record is
>>> 184:      *                 silently ignored and is not published
>> 
>> There needs to be an `@implSpec` somewhere in this method's javadoc comment that explains the locking policy here very crisply for subclassers. Specifically (1) the lock on `this` is not held during formatting; (2) the lock on `this` is held during publishing; (3) subclassers must not lock on `this` while calling super.publish() because it would contravene (1).
>
> OK, this change is good. The only thing I'd say is that subclasses must not override publish() with a synchronized method AND ALSO call super.publish(). Also, since `@implSpec` adds a subhead and a new paragraph, the text that follows should have an initial capital letter.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1975485704

From duke at openjdk.org  Fri Feb 28 14:18:02 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 28 Feb 2025 14:18:02 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v9]
In-Reply-To: <bA6ZPOQyn2gq-pN4MrEu7TYffjiUkCKK_X-oZocDnNw=.d5408e74-1a66-409e-97c9-0f7b46eade25@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <i6qWEAJ6su3eRLy4wqylbVl0hG88eTMyr2zKP4_07cg=.6eeffc2d-9dd2-4c12-89c6-f53624f4ca27@github.com>
 <bA6ZPOQyn2gq-pN4MrEu7TYffjiUkCKK_X-oZocDnNw=.d5408e74-1a66-409e-97c9-0f7b46eade25@github.com>
Message-ID: <TKJ6DY4ABp0Fy4baJvdTCr4IR9OUqa8ThTP2kQBjCO0=.b46ffd46-3342-4cc1-bfc3-f45cd31303ea@github.com>

On Fri, 28 Feb 2025 09:28:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix @implNote to @apiNote.
>
> src/java.logging/share/classes/java/util/logging/StreamHandler.java line 240:
> 
>> 238:     void synchronousPostWriteHook() {
>> 239:         // Empty by default.
>> 240:     }
> 
> It would be good to have a comment making it clear that this method is called while holding the monitor on this. I know we have a test for that - but it could be good to make it clear in the code as well.
> What about:
> Suggestion:
> 
>     void synchronousPostWriteHook() {
>         // Empty by default. We could do:
>         //    assert Thread.holdsLock(this);
>         // but this is already covered by unit tests.
>     }

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1975483969

From duke at openjdk.org  Fri Feb 28 14:23:51 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 28 Feb 2025 14:23:51 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v6]
In-Reply-To: <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <1_MYqF28HW1ASAglx6I3PhgIff6ZLN_mcCqOWQSSIxg=.942bd5e5-56a4-4cbe-b551-536c714297f7@github.com>
 <2WhJvvXmPqQRNYXANs_az5_EVWvz8e4sla5yJrL5AYM=.b52186fd-1dce-489f-89e9-dd76a2de2630@github.com>
Message-ID: <pGu360agD5bV3e4AoEoMa2Ras4Jk8k-4bX6Q0rB8YNE=.3a018616-7fc2-4c1f-bc85-f94b1e9b396c@github.com>

On Tue, 25 Feb 2025 01:19:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweaking @implNote for better rendering.
>
> src/java.logging/share/classes/java/util/logging/StreamHandler.java line 268:
> 
>> 266:     }
>> 267: 
>> 268:     // Called synchronously.
> 
> I would be more specific here and say that it's called while the lock on `this` is held.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1975491616

From duke at openjdk.org  Fri Feb 28 14:23:49 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 28 Feb 2025 14:23:49 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v10]
In-Reply-To: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
Message-ID: <7Zm7nh3mSJQ-Qch5mPaPksEivxbZe_zAjm5TBNTpStY=.1d774849-e2b0-4a77-bb61-527d154b2476@github.com>

> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
> 
> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
> 2. Add explanatory comments to various affected methods.
> 3. Add a test to ensure deadlocks no longer occur.
> 
> Note that this change does not address issue in MemoryHandler (see JDK-8349208).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Final round of comment tweaks.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23491/files
  - new: https://git.openjdk.org/jdk/pull/23491/files/147aecae..1bf2da42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23491&range=08-09

  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23491/head:pull/23491

PR: https://git.openjdk.org/jdk/pull/23491

From dl at openjdk.org  Fri Feb 28 15:14:16 2025
From: dl at openjdk.org (Doug Lea)
Date: Fri, 28 Feb 2025 15:14:16 GMT
Subject: RFR: 8319447: Improve performance of delayed task handling [v5]
In-Reply-To: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
References: <RTRLwnAEdLk3KxmwhBJPjkIjUj_VOAbxHSYaeLrK2Vs=.40c77f54-c026-4e1b-8a4c-43558452e907@github.com>
Message-ID: <xthZ9IF3mPqvdUGoDMQwlrAgEhGGxOC7IuxeuGqSjYM=.0c8e49a3-1abf-441c-a7e4-48383e832088@github.com>

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
> 
> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is both ill-suited for many (if not most) of its applications, and is a performance bottleneck (as seen especially in Loom and CompletableFuture usages). After considering many options over the years, the approach taken here is to connect (lazily, only if used) a form of ScheduledExecutorService (DelayScheduler) to any ForkJoinPool (including the commonPool), which can then use more efficient and scalable techniques to request and trigger delayed actions, periodic actions, and cancellations, as well as coordinate shutdown and termination mechanics (see the internal documentation in DelayScheduler.java for algotihmic details). This speeds up some Loom operations by almost an order of magnitude (and similarly for CompletableFuture). Further incremental improvements may be possible, but delay scheduling overhead is now unlikely to be a common performance concern.
> 
> We also introduce method submitWithTimeout to schedule a timeout that cancels or otherwise completes a submitted task that takes too long. Support for this very common usage was missing from the ScheduledExecutorService API, and workarounds that users have tried are wasteful, often leaky, and error-prone. This cannot be added to the ScheduledExecutorService interface because it relies on ForkJoinTask methods (such as completeExceptionally) to be available in user-supplied timeout actions. The need to allow a pluggable handler reflects experience with the similar CompletableFuture.orTimeout, which users have found not to be flexible enough, so might be subject of future improvements.
> 
> A DelayScheduler is optionally (on first use of a scheduling method) constructed and started as part of a ForkJoinPool, not any other kind of ExecutorService. It doesn't make sense to do so with the other j.u.c pool implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already extends it in incompatible ways (which is why we can't just improve or replace STPE internals). However, as discussed in internal documentation, the implementation isolates calls and callbacks in a way that could be extracted out into (package-private) interfaces if another j.u.c pool type is introduced.
> 
> Only one of the policy controls in ScheduledThreadPoolExecutor applies to ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown controls whether quiescent shutdown should wait for dela...

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments; reactivation tweak

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23702/files
  - new: https://git.openjdk.org/jdk/pull/23702/files/c9bc41ac..b40513fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23702&range=03-04

  Stats: 27 lines in 4 files changed: 5 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/23702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23702/head:pull/23702

PR: https://git.openjdk.org/jdk/pull/23702

From liach at openjdk.org  Fri Feb 28 15:57:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 15:57:18 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v6]
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Use "variable offset", remove extra makefile comments, comment fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23720/files
  - new: https://git.openjdk.org/jdk/pull/23720/files/e5839fb8..b995a268

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=04-05

  Stats: 31 lines in 6 files changed: 4 ins; 13 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/23720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23720/head:pull/23720

PR: https://git.openjdk.org/jdk/pull/23720

From liach at openjdk.org  Fri Feb 28 15:57:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 15:57:19 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v5]
In-Reply-To: <8Q7qd2f4Dd-7YFf24NfoPG7Q1CzlOcmWxoBvMdXJHes=.07079a01-2566-435d-a729-daba2da85af2@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <_1Az6Shks5J1SPDWPfq1yoL-wpZM1nXrdz1k0IoigvU=.86f97004-e5b2-4ff9-a295-d1dafdbcb212@github.com>
 <8Q7qd2f4Dd-7YFf24NfoPG7Q1CzlOcmWxoBvMdXJHes=.07079a01-2566-435d-a729-daba2da85af2@github.com>
Message-ID: <46TXxv_4RUZf00NsEsk8tmOVHfQ3j6GJ7foEQo85B7g=.399adafc-5e1b-4efc-b061-52914995bde6@github.com>

On Fri, 28 Feb 2025 10:37:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   noStride -> constantOffset, optimize VH classes to have only 2 instead of 3 classes for each type
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 53:
> 
>> 51: 
>> 52:     static final VarForm CONSTANT_OFFSET_FORM = new VarForm(VarHandleSegmentAs$Type$s.class, MemorySegment.class, $type$.class, long.class);
>> 53:     static final VarForm TAKE_OFFSET_FORM = new VarForm(VarHandleSegmentAs$Type$s.class, MemorySegment.class, $type$.class, long.class, long.class);
> 
> what does TAKE mean here? (the old names weren't great either, I realize). I think it would be better to decide, once and for all, how to refer to these things, and then use consistent naming throughout. I see we have discussed using "noStride" vs. "fixedOffset". Since the implementation now uses the term "constantOffset", let's just call the other "variableOffset" ?

Done renaming to `VARIABLE_OFFSET_FORM`. I have also cleaned up some other stale names in the comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23720#discussion_r1975640481

From mcimadamore at openjdk.org  Fri Feb 28 16:02:04 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Feb 2025 16:02:04 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v6]
In-Reply-To: <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>
Message-ID: <fCBnV08d7pDsscwS-UL4NDr74Am-OQ8JnZKRa-UGXcU=.ed5e28f6-b8fa-4d95-9314-4d6cb1897bae@github.com>

On Fri, 28 Feb 2025 15:57:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "variable offset", remove extra makefile comments, comment fixes

Very nice -- thanks!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2651162993

From jvernee at openjdk.org  Fri Feb 28 16:46:58 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 28 Feb 2025 16:46:58 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v6]
In-Reply-To: <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>
Message-ID: <e432_fOgKqFpPy2Ll4zR03yH3QswWaki6WDl1_XYU1A=.760133a3-0177-4ecd-acda-46ef954d6276@github.com>

On Fri, 28 Feb 2025 15:57:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "variable offset", remove extra makefile comments, comment fixes

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23720#pullrequestreview-2651272766

From sgehwolf at openjdk.org  Fri Feb 28 17:15:05 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 28 Feb 2025 17:15:05 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
Message-ID: <9BhHiBHy6g34Uq67jJQb4J2vnCl7rksMT0aSFJTZss0=.16c54e0f-7306-4cde-8d7c-6c0b2ee425a3@github.com>

On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated comment

OK. I had another look and the Docker test `TestMemoryWithSubgroups.java` does indeed cover this case for cg v1.

Please update copyright years to 2025 and this should be good to go (FYI: I'll be away the next week).

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 80:

> 78:  * The method trims cgroup path from left, until the subgroup
> 79:  * component is found. The subsystem path will be set to
> 80:  * the _mount_point joined with the subgroup path.

Thanks for the comment.

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2024, Oracle and/or its affiliates. All rights reserved.

2025

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 2:

> 1: /*
> 2:  * Copyright (C) 2024, BELLSOFT. All rights reserved.

2025

test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, BELLSOFT. All rights reserved.

2025

-------------

PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2651325697
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975746247
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975747062
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975748210
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975748978

From sgehwolf at openjdk.org  Fri Feb 28 17:15:06 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 28 Feb 2025 17:15:06 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <Up2nvImQ0ygo9YKtNTpD1b4YtZFBmvt1d59nmky-ImI=.c7d8b52e-be3c-4533-9435-d3148a26947a@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
 <Up2nvImQ0ygo9YKtNTpD1b4YtZFBmvt1d59nmky-ImI=.c7d8b52e-be3c-4533-9435-d3148a26947a@github.com>
Message-ID: <v4YkWq0uGypzhC-M3jt8LzuTuAKDWrB_zLqzwRF8v9E=.947b5d5c-8858-44de-b33d-08bdd1f4fb95@github.com>

On Fri, 28 Feb 2025 12:19:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated comment
>
> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2024, Red Hat Inc.
> 
> Guess this must be 2025 now ? Same for other files ...

yes indeed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975746706

From dfuchs at openjdk.org  Fri Feb 28 17:27:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Feb 2025 17:27:15 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v10]
In-Reply-To: <7Zm7nh3mSJQ-Qch5mPaPksEivxbZe_zAjm5TBNTpStY=.1d774849-e2b0-4a77-bb61-527d154b2476@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <7Zm7nh3mSJQ-Qch5mPaPksEivxbZe_zAjm5TBNTpStY=.1d774849-e2b0-4a77-bb61-527d154b2476@github.com>
Message-ID: <o62Egs7CenL10E-6gHk8Q6-fepI_7n9GHy6uImrcWb0=.a4ba1bed-ab48-47fc-8fdd-3491dee29071@github.com>

On Fri, 28 Feb 2025 14:23:49 GMT, David Beaumont <duke at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Final round of comment tweaks.

src/java.logging/share/classes/java/util/logging/FileHandler.java line 747:

> 745: 
> 746:     @Override
> 747:     void synchronousPostWriteHook() {

Suggestion:

    void synchronousPostWriteHook() {
        // no need to synchronize here, this method is called from within a
        // synchronized block.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23491#discussion_r1975777682

From joehw at openjdk.org  Fri Feb 28 17:47:43 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 28 Feb 2025 17:47:43 GMT
Subject: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty CDATA
Message-ID: <HJSpgswJ9FI08VZV39byvPJarJSstSD6repz59HBdhE=.e5628296-51c3-4ce8-8a5a-8a64aef29a47@github.com>

Fix handleCharacters by adding a guard to zero length and letting the rest of the process continue (e.g. closing tags and etc).

-------------

Commit messages:
 - 8349516: StAXStream2SAX.handleCharacters() fails on empty CDATA

Changes: https://git.openjdk.org/jdk/pull/23847/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23847&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349516
  Stats: 54 lines in 2 files changed: 51 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23847/head:pull/23847

PR: https://git.openjdk.org/jdk/pull/23847

From naoto at openjdk.org  Fri Feb 28 17:50:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Feb 2025 17:50:54 GMT
Subject: RFR: 4745837: Make grouping usage during parsing apparent in
 relevant NumberFormat methods [v3]
In-Reply-To: <kDNySBaxIMOtEucLyIuL38UamV8WxYqHvJ6h5O7bZKw=.e419a0f8-1991-4891-a952-2e2527a7e6d2@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
 <kDNySBaxIMOtEucLyIuL38UamV8WxYqHvJ6h5O7bZKw=.e419a0f8-1991-4891-a952-2e2527a7e6d2@github.com>
Message-ID: <XdHtt8At46bgZswWJNoheaMngB93mM9eeQ5yjPEfyKw=.311ab2fa-75f5-4efa-9f4b-556764bcb229@github.com>

On Thu, 27 Feb 2025 19:52:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.
>> 
>> Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make strict example less wordy

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23813#pullrequestreview-2651436794

From tschatzl at openjdk.org  Fri Feb 28 17:52:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 28 Feb 2025 17:52:56 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v4]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <AgRxsR4WWKDB45qANJJeb6wzR4CrY5uncSKOvK5AeIE=.ced521a5-6380-4a9f-a4f2-7f5702ce9120@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * fix assert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23739/files
  - new: https://git.openjdk.org/jdk/pull/23739/files/7d361fc1..d87935a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

PR: https://git.openjdk.org/jdk/pull/23739

From smarks at openjdk.org  Fri Feb 28 18:18:56 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 28 Feb 2025 18:18:56 GMT
Subject: RFR: 8349206: j.u.l.Handler classes create deadlock risk via
 synchronized publish() method [v10]
In-Reply-To: <7Zm7nh3mSJQ-Qch5mPaPksEivxbZe_zAjm5TBNTpStY=.1d774849-e2b0-4a77-bb61-527d154b2476@github.com>
References: <lRK7kHIBlutiwsYIrg23T_r5ZwGUOjXVt9TMCJMMrD8=.eb060a92-50b2-4384-b555-3754ed730666@github.com>
 <7Zm7nh3mSJQ-Qch5mPaPksEivxbZe_zAjm5TBNTpStY=.1d774849-e2b0-4a77-bb61-527d154b2476@github.com>
Message-ID: <X3EWr6za0tekHaxvTEOYVk_UCLUW1YeOaRiOXDqyRaw=.5f2f7edf-8055-4f26-9825-a0ea12a49ca6@github.com>

On Fri, 28 Feb 2025 14:23:49 GMT, David Beaumont <duke at openjdk.org> wrote:

>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method.
>> 
>> 1. Remove synchronization of calls to publish() in Handlers in java.util.logging package.
>> 2. Add explanatory comments to various affected methods.
>> 3. Add a test to ensure deadlocks no longer occur.
>> 
>> Note that this change does not address issue in MemoryHandler (see JDK-8349208).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Final round of comment tweaks.

With the latest updates, all looks good.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23491#pullrequestreview-2651492751

From jlu at openjdk.org  Fri Feb 28 19:39:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 28 Feb 2025 19:39:59 GMT
Subject: Integrated: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException
In-Reply-To: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
Message-ID: <QxIiTi1qVanUkCzIYx0Jcv3e1x7DkaviVM3lYvfzXlY=.793ac4ca-1fb1-44b7-8b8b-d9481dc511af@github.com>

On Tue, 25 Feb 2025 23:58:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
> 
> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
> 
> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override or future eras in general.

This pull request has now been integrated.

Changeset: 3a7d9868
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a7d98687849ba0625fed2b516f4103ee8d27e41
Stats:     36 lines in 4 files changed: 30 ins; 0 del; 6 mod

8350646: Calendar.Builder.build() Throws ArrayIndexOutOfBoundsException

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/23789

From liach at openjdk.org  Fri Feb 28 20:04:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 20:04:05 GMT
Subject: RFR: 8350118: Simplify the layout access VarHandle [v6]
In-Reply-To: <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
 <8QQsuqKgzPNUIGMnD-4qaWpZzCduZgnwgJ3MAcJBYe4=.7641c728-a9e3-4494-9cce-80758afd583b@github.com>
Message-ID: <P5UGpZiYwmrB5VUIww3KwQz9HdYTd6tq0kQzvZ4QazE=.bf67f90c-6290-47e1-afe9-0567f621f972@github.com>

On Fri, 28 Feb 2025 15:57:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
>> 
>> Reduces the instructions to execute this code in a simple main by 47%:
>> 
>> long[] arr = new long[8];
>> var ms = MemorySegment.ofArray(arr);
>> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
>> 
>> 
>> Main overheads in FFM are identified to be:
>> 1. Eager initialization of direct MethodHandle; can be CDS archived
>> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
>> 
>> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
>> 
>> Tests: 2 unrelated failures on tier 1-3
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "variable offset", remove extra makefile comments, comment fixes

Tier 1-3 looks good besides some unrelated desktop tests. Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23720#issuecomment-2691447859

From liach at openjdk.org  Fri Feb 28 20:04:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 20:04:07 GMT
Subject: Integrated: 8350118: Simplify the layout access VarHandle
In-Reply-To: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
References: <YPopRTnS7AoSVkmyxsTZv5MkrWOp-b3z-0gnxRKHpjo=.af064c67-c9f5-4d65-95d5-1d9835280355@github.com>
Message-ID: <pJirzD-ZIip_BbPrHox4B7c3jtMM3-3qMBnj7QvlhpQ=.45d95ac5-513b-4cb6-afb0-d3c2014b21d7@github.com>

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH.
> 
> Reduces the instructions to execute this code in a simple main by 47%:
> 
> long[] arr = new long[8];
> var ms = MemorySegment.ofArray(arr);
> ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3);
> 
> 
> Main overheads in FFM are identified to be:
> 1. Eager initialization of direct MethodHandle; can be CDS archived
> 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead
> 
> Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow.
> 
> Tests: 2 unrelated failures on tier 1-3

This pull request has now been integrated.

Changeset: c7fa499b
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7fa499bf5023a3f16bb3742d2ba3cd74f2b41bd
Stats:     1720 lines in 18 files changed: 1046 ins; 209 del; 465 mod

8350118: Simplify the layout access VarHandle

Reviewed-by: mcimadamore, jvernee, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/23720

From almatvee at openjdk.org  Fri Feb 28 20:24:58 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 28 Feb 2025 20:24:58 GMT
Subject: Integrated: 8347139: [macos] Test
 tools/jpackage/share/InOutPathTest.java  failed:
 "execution error: Finder got an error: AppleEvent timed out."
In-Reply-To: <4mb74SEfiSr7QW_oKrGbOk20dz1qhCJwiJTjmsWv9aM=.a4730050-a0ad-4f1d-8221-99b61e37fd78@github.com>
References: <4mb74SEfiSr7QW_oKrGbOk20dz1qhCJwiJTjmsWv9aM=.a4730050-a0ad-4f1d-8221-99b61e37fd78@github.com>
Message-ID: <bvfEk6ZzIzwP49BNXG51Z7JCkvZAJnKpcalzkR3JUZ0=.c673f5aa-a198-4e82-a6ef-d5c81b1b9f2c@github.com>

On Thu, 27 Feb 2025 02:53:26 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Fixed by increasing test timeout. Fix verified on host which reproduced issue.

This pull request has now been integrated.

Changeset: a87dd1a7
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a87dd1a75f78cf872df49bea83ba48af8acfa2fd
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8347139: [macos] Test tools/jpackage/share/InOutPathTest.java  failed:  "execution error: Finder got an error: AppleEvent timed out."

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/23816

From schernyshev at openjdk.org  Fri Feb 28 20:40:37 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 28 Feb 2025 20:40:37 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright headers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/c9391dd4..bae78ff7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=15-16

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From schernyshev at openjdk.org  Fri Feb 28 20:40:38 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 28 Feb 2025 20:40:38 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <v4YkWq0uGypzhC-M3jt8LzuTuAKDWrB_zLqzwRF8v9E=.947b5d5c-8858-44de-b33d-08bdd1f4fb95@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
 <Up2nvImQ0ygo9YKtNTpD1b4YtZFBmvt1d59nmky-ImI=.c7d8b52e-be3c-4533-9435-d3148a26947a@github.com>
 <v4YkWq0uGypzhC-M3jt8LzuTuAKDWrB_zLqzwRF8v9E=.947b5d5c-8858-44de-b33d-08bdd1f4fb95@github.com>
Message-ID: <I2JqMAlGL8F-Aht1YRm4mjZmVr_rpjjSRdSi7AVLvLQ=.7b23dafc-dbb6-4e82-bc38-58b9375aa6dc@github.com>

On Fri, 28 Feb 2025 17:07:59 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2020, 2024, Red Hat Inc.
>> 
>> Guess this must be 2025 now ? Same for other files ...
>
> yes indeed.

indeed, updated the copyright headers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975983416

From schernyshev at openjdk.org  Fri Feb 28 20:40:38 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 28 Feb 2025 20:40:38 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <9BhHiBHy6g34Uq67jJQb4J2vnCl7rksMT0aSFJTZss0=.16c54e0f-7306-4cde-8d7c-6c0b2ee425a3@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
 <9BhHiBHy6g34Uq67jJQb4J2vnCl7rksMT0aSFJTZss0=.16c54e0f-7306-4cde-8d7c-6c0b2ee425a3@github.com>
Message-ID: <d2YBoS1QSE3F0IT5bxvDk_Gav5regN3-ee6fNcMkwQk=.7f460d0b-7dbe-497a-8eda-d5c9f3fcefd5@github.com>

On Fri, 28 Feb 2025 17:08:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated comment
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> 2025

thanks. done.

> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (C) 2024, BELLSOFT. All rights reserved.
> 
> 2025

fixed.

> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, BELLSOFT. All rights reserved.
> 
> 2025

done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975981433
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975980784
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975980336

From schernyshev at openjdk.org  Fri Feb 28 20:47:08 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 28 Feb 2025 20:47:08 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <IwVJeqTk0HxHxFi4B64nemBTTG0Tq6gDsMA6CmMDMAU=.b28d7564-3af4-44f0-957b-a998cb0f5540@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
 <IwVJeqTk0HxHxFi4B64nemBTTG0Tq6gDsMA6CmMDMAU=.b28d7564-3af4-44f0-957b-a998cb0f5540@github.com>
Message-ID: <bBJChknHwVdJDVd9Rr6qRUClSrpSiLRyKQg6vdG6N_M=.a58287c6-8320-4e47-8459-dcf59fb36e82@github.com>

On Fri, 28 Feb 2025 12:27:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated comment
>
> test/jdk/jdk/internal/platform/cgroup/CgroupV1SubsystemControllerTest.java line 69:
> 
>> 67:     /*
>> 68:      * Less common cases: Containers
>> 69:      */
> 
> Not really sure why this comment was added, is it refering to 'container mode'  mentioned in the comment above in another file?

It's because there are already "Common case: Containers" and "Common case: Host". The old test testCgPathSubstring() and the new test testCgPathToMovedPath() do not belong to "Common case: Host" that comes just before them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975991035

From drwhite at openjdk.org  Fri Feb 28 21:34:53 2025
From: drwhite at openjdk.org (Derek White)
Date: Fri, 28 Feb 2025 21:34:53 GMT
Subject: RFR: 8350682: [JMH] vector.IndexInRangeBenchmark failed with
 IndexOutOfBoundsException for size=1024
In-Reply-To: <a1_5DZ8fmibdpMXTNaQEzF2q4ExfqGVpxfKxTIjAPgc=.5aba77b1-53a8-4d50-8622-959d163592c0@github.com>
References: <a1_5DZ8fmibdpMXTNaQEzF2q4ExfqGVpxfKxTIjAPgc=.5aba77b1-53a8-4d50-8622-959d163592c0@github.com>
Message-ID: <t3PQBFa1c1gmLiSnm7woHvO30Vu5kaRmLM9dZ1xAWh4=.4953656f-02c2-4f70-930f-bf5a17f5d1bc@github.com>

On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> Array initialization by parameter was added. Extra constant was used to align cycle step with used arrays.

Marked as reviewed by drwhite (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23783#pullrequestreview-2651809802

From naoto at openjdk.org  Fri Feb 28 22:35:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Feb 2025 22:35:54 GMT
Subject: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty
 CDATA
In-Reply-To: <HJSpgswJ9FI08VZV39byvPJarJSstSD6repz59HBdhE=.e5628296-51c3-4ce8-8a5a-8a64aef29a47@github.com>
References: <HJSpgswJ9FI08VZV39byvPJarJSstSD6repz59HBdhE=.e5628296-51c3-4ce8-8a5a-8a64aef29a47@github.com>
Message-ID: <7zxz6_G_TmXAP2BlpuFRND7wlK6_zAsIszPiZbRIPUg=.001da59a-2818-491a-8e88-36b4e043a807@github.com>

On Fri, 28 Feb 2025 17:42:24 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix handleCharacters by adding a guard to zero length and letting the rest of the process continue (e.g. closing tags and etc).

src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXStream2SAX.java line 286:

> 284:         if (textLength > 0) {
> 285:             staxStreamReader.getTextCharacters(0, chars, 0, textLength);
> 286:         }

Hi Joe,
The comment above this piece reads:

        // workaround for bugid 5046319 - switch over to commented section
        // below when it is fixed.

And the bug 5046319 (closed issue about AIOOBE) is fixed. Should the commented section be considered?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23847#discussion_r1976081092

From asemenyuk at openjdk.org  Fri Feb 28 22:36:32 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 28 Feb 2025 22:36:32 GMT
Subject: RFR: 8350013: Add a test for JDK-8150442 [v3]
In-Reply-To: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>
References: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>
Message-ID: <5GZO2sEWzAn3ceSvW4LpxZ7l6MXdc6vZWunT4N_1qbI=.1fb2bc4f-fd6a-4dba-b5ab-90e5d58d9486@github.com>

> Add a test to verify jpackage is using a custom MSI condition blocking package installation depending on the version of Windows where the package installer runs. Support for this MSI condition was added in [JDK-8150442](https://bugs.openjdk.org/browse/JDK-8150442).
> 
> The test adds an unconditionally failing OS-version MSI condition to the resource directory. MSI installer using this condition should always fail. The exit code of the failed installation would be 1603. Extended error information can be dug in the MSI log file. To make the test work, the following changes to jpackage test lib have been made:
>  - Support non-0 exit code from MSI install handler. Support for non-0 exit codes was added to install handlers of all other types too. Added `PackageTest.setExpectedInstallExitCode(int)` method to configure the expected exit code of a package installation;
>  - Support using msi log files when MSI and EXE packages get installed, unpacked, or uninstalled. Added `PackageTest.createMsiLog(boolean)` to enable or disable creation of msi log files in a PackageTest instance and `Optional<Path> JPackageCommand.winMsiLogFile()` to access the current log file from the callbacks registered with the PackageTest instance.
> 
> Added tests for PackageTest class (PackageTestTest).
> 
> Additionally, improved the code in WindowsHelper detecting paths to Start Menu, Desktop, and other common paths. Previously, it relied on reading these paths from the registry. On some machines, required registry keys are not available. The code now will call .NET `Environment.GetFolderPath()` function through powershell if a registry key is missing.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Trailing whitespace cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23825/files
  - new: https://git.openjdk.org/jdk/pull/23825/files/43ff8704..a38876d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23825&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23825&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23825.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23825/head:pull/23825

PR: https://git.openjdk.org/jdk/pull/23825

From almatvee at openjdk.org  Fri Feb 28 22:45:52 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 28 Feb 2025 22:45:52 GMT
Subject: RFR: 8350013: Add a test for JDK-8150442 [v3]
In-Reply-To: <5GZO2sEWzAn3ceSvW4LpxZ7l6MXdc6vZWunT4N_1qbI=.1fb2bc4f-fd6a-4dba-b5ab-90e5d58d9486@github.com>
References: <WxOrXvjyFYukstcybu6em_XNaf_ec50AtJL11GA5oe0=.5352e7d8-9d82-46bf-bf50-16c51ddf69ee@github.com>
 <5GZO2sEWzAn3ceSvW4LpxZ7l6MXdc6vZWunT4N_1qbI=.1fb2bc4f-fd6a-4dba-b5ab-90e5d58d9486@github.com>
Message-ID: <sqEbozQvCrjyYLG2a0hBvp_00BbZ1QEna4V6lOR97xA=.b9a99bdb-d348-4bff-9733-974263bc6862@github.com>

On Fri, 28 Feb 2025 22:36:32 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Add a test to verify jpackage is using a custom MSI condition blocking package installation depending on the version of Windows where the package installer runs. Support for this MSI condition was added in [JDK-8150442](https://bugs.openjdk.org/browse/JDK-8150442).
>> 
>> The test adds an unconditionally failing OS-version MSI condition to the resource directory. MSI installer using this condition should always fail. The exit code of the failed installation would be 1603. Extended error information can be dug in the MSI log file. To make the test work, the following changes to jpackage test lib have been made:
>>  - Support non-0 exit code from MSI install handler. Support for non-0 exit codes was added to install handlers of all other types too. Added `PackageTest.setExpectedInstallExitCode(int)` method to configure the expected exit code of a package installation;
>>  - Support using msi log files when MSI and EXE packages get installed, unpacked, or uninstalled. Added `PackageTest.createMsiLog(boolean)` to enable or disable creation of msi log files in a PackageTest instance and `Optional<Path> JPackageCommand.winMsiLogFile()` to access the current log file from the callbacks registered with the PackageTest instance.
>> 
>> Added tests for PackageTest class (PackageTestTest).
>> 
>> Additionally, improved the code in WindowsHelper detecting paths to Start Menu, Desktop, and other common paths. Previously, it relied on reading these paths from the registry. On some machines, required registry keys are not available. The code now will call .NET `Environment.GetFolderPath()` function through powershell if a registry key is missing.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Trailing whitespace cleanup

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23825#pullrequestreview-2651906002

From joehw at openjdk.org  Fri Feb 28 22:58:54 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 28 Feb 2025 22:58:54 GMT
Subject: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty
 CDATA
In-Reply-To: <7zxz6_G_TmXAP2BlpuFRND7wlK6_zAsIszPiZbRIPUg=.001da59a-2818-491a-8e88-36b4e043a807@github.com>
References: <HJSpgswJ9FI08VZV39byvPJarJSstSD6repz59HBdhE=.e5628296-51c3-4ce8-8a5a-8a64aef29a47@github.com>
 <7zxz6_G_TmXAP2BlpuFRND7wlK6_zAsIszPiZbRIPUg=.001da59a-2818-491a-8e88-36b4e043a807@github.com>
Message-ID: <r1AQ03K9EPnnjPIhqZYFznTjW8tn2bS0N4avQt4GgK4=.acc3aaf7-78ea-42aa-82c7-fe4eb29a18d4@github.com>

On Fri, 28 Feb 2025 22:33:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fix handleCharacters by adding a guard to zero length and letting the rest of the process continue (e.g. closing tags and etc).
>
> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXStream2SAX.java line 286:
> 
>> 284:         if (textLength > 0) {
>> 285:             staxStreamReader.getTextCharacters(0, chars, 0, textLength);
>> 286:         }
> 
> Hi Joe,
> The comment above this piece reads:
> 
>         // workaround for bugid 5046319 - switch over to commented section
>         // below when it is fixed.
> 
> And the bug 5046319 (closed issue about AIOOBE) is fixed. Should the commented section be considered?

Hi Naoto,

Yes, I did look through that code and bug 5046319. Unfortunately, it happened when JAXP was standalone, the history of the change was lost. 
The variable "buf" seems to be an instance variable that serves to cache the text read. That part had been changed as well. Furthermore, if buf starts with zero length, the call to getTextCharacters would still result in IndexOutOfBoundsException.

Maybe the commented code can be removed, I kept them as is in case they may be useful reference as a history.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23847#discussion_r1976096219

From naoto at openjdk.org  Fri Feb 28 23:04:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Feb 2025 23:04:53 GMT
Subject: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty
 CDATA
In-Reply-To: <r1AQ03K9EPnnjPIhqZYFznTjW8tn2bS0N4avQt4GgK4=.acc3aaf7-78ea-42aa-82c7-fe4eb29a18d4@github.com>
References: <HJSpgswJ9FI08VZV39byvPJarJSstSD6repz59HBdhE=.e5628296-51c3-4ce8-8a5a-8a64aef29a47@github.com>
 <7zxz6_G_TmXAP2BlpuFRND7wlK6_zAsIszPiZbRIPUg=.001da59a-2818-491a-8e88-36b4e043a807@github.com>
 <r1AQ03K9EPnnjPIhqZYFznTjW8tn2bS0N4avQt4GgK4=.acc3aaf7-78ea-42aa-82c7-fe4eb29a18d4@github.com>
Message-ID: <cPkJFhhZ8rNeQdsfBR7itv_kPuaiIpH1lJoDTYsnh9A=.b94368fe-5982-4acd-aec9-0414fc821b77@github.com>

On Fri, 28 Feb 2025 22:56:27 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXStream2SAX.java line 286:
>> 
>>> 284:         if (textLength > 0) {
>>> 285:             staxStreamReader.getTextCharacters(0, chars, 0, textLength);
>>> 286:         }
>> 
>> Hi Joe,
>> The comment above this piece reads:
>> 
>>         // workaround for bugid 5046319 - switch over to commented section
>>         // below when it is fixed.
>> 
>> And the bug 5046319 (closed issue about AIOOBE) is fixed. Should the commented section be considered?
>
> Hi Naoto,
> 
> Yes, I did look through that code and bug 5046319. Unfortunately, it happened when JAXP was standalone, the history of the change was lost. 
> The variable "buf" seems to be an instance variable that serves to cache the text read. That part had been changed as well. Furthermore, if buf starts with zero length, the call to getTextCharacters would still result in IndexOutOfBoundsException.
> 
> Maybe the commented code can be removed, I kept them as is in case they may be useful reference as a history.

OK, then I'd suggest removing the above comment and commented section altogether, as it only provides confusion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23847#discussion_r1976100268

From smarks at openjdk.org  Fri Feb 28 23:06:01 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 28 Feb 2025 23:06:01 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v9]
In-Reply-To: <_ziyFpDg0omKO6mnXP7OiR2cRI9hU-XY9s0YlN6Bc18=.6e9d6184-7689-403e-a390-48204ab2f338@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <_ziyFpDg0omKO6mnXP7OiR2cRI9hU-XY9s0YlN6Bc18=.6e9d6184-7689-403e-a390-48204ab2f338@github.com>
Message-ID: <DBOfNAt2zLAi4wG2m9M3Jdcwjk3cKaFftWGwrUMRBYU=.bcebf31a-168b-46ca-9298-f78e9ab24443@github.com>

On Thu, 27 Feb 2025 19:43:34 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Update test/jdk/java/util/Collection/MOAT.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Update copyright year
>    
>    and add the bug number to the modified test
>  - Update unmodifiable map javadoc
>  - Also throw UOE for mutators on keySet() and values()
>    
>    and add more test coverage to MOAT.
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Check m.entrySet().hashCode() in MOAT
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/25f63eb1...d83ca7f3

I've moved it from `25` to `tbd`. That means that it isn't committed to go into 25, but that also doesn't mean that it _won't_ go into 25. In practice I don't think makes much difference which release it goes in. I understand the sentiment of not wanting impact 25 because it's an LTS release. But there are regular bugfix updates for the LTS releases, so if this were integrated in 25 and if people did encounter problems with it, they could be fixed quickly. On the other hand, if it went into a non-LTS release, fewer people run those, so it might take a while for any hypothetical problem to actually surface.

Ideally, though, we'd generate some evidence that would give us some confidence that the change wouldn't likely cause problems, in which case we could put it into any release. I still intend to do some analysis at some point that will tell us one way or another. (Yes, we will reach that point eventually, though I'm sorry that it's taken so long!)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2691690170